IT4Change/gradido
3
0
Fork 0
mirror of https://github.com/IT4Change/gradido.git synced 2025-12-13 07:45:54 +00:00
Code Issues Packages Projects Releases Wiki Activity

included existing docu

Browse Source 
transformed a lot of odt & txt files to md format
This commit is contained in:
Ulf Gebhardt 2021-04-16 14:09:06 +02:00
parent 8ae2e65e12
commit 610971f5d3
No known key found for this signature in database
GPG Key ID: 81308EFE29ABFEBD
93 changed files with 3734 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

109
docu/README.md
View File

@ -51,4 +51,111 @@ Some ideas of regarding fixing the broken authentication
One upon a time the repository was split into multiple parts. This compartimalisation resulted in some inefficiencies which were resolved by merging (most of) them into a mono repository. The following graphic was made to explain the idea and plan the "mono-repoisation"
![](./graphics/repo-structure.png)
![](./graphics/repo-structure.png)
## Questions
### why distributed system for gradidos? is it needed to add this type of complexity?
- ensuring uptime
- data is not stored in single place, no single point of failure
- even if most important nodes are hacked, we still have a replayable gradido blockchains, which can be migrated to another cluster
### main ideas for gradido distributed system
- system would rely on existence of honest / incorrupted nodes in the network
- consists of nodes (not gradido nodes, but universal ones)
- using blockchains to store data
- generally open and transparent, with few exceptions (monitoring health, last-resort backup creation)
- single topology blockchain for a cluster; TB contains at least:
- list of all nodes in the cluster along with their types
- updates to states of nodes (active, banned, etc.)
- not all nodes can write to all blockchains
- distributed system consists of nodes, each having at least:
- type
- signature key
- copy of TB
- read sequence: sending same request to random many nodes, receiving answer, reporting other nodes to management in case of discrepancies, which could lead to node ban
- write sequence: transaction goes to ordering service, receives consensus sequence id, is sent to listener nodes, is written to blockchain replicas
### proposed nodes
- management node
- adding new nodes to network on request, banning nodes
- should be maintained by us for our cluster
- ordering node
- orders requests just like Hedera; can use Hedera (at least initially)
- login server node
- gradido blockchain node
- gradido blockchain backup node
- relay node: to anonymize blockchain read requests (for better cluster health)
- community server is not a node; it stands out from distributed network and accesses cluster via login server
### example sequences
- user actions
- browse groups
- community server addresses login server; login server has TB; it asks for data, reporting invalid nodes in the process; result is returned to community server and presented
- required signatures: community server
- create group
- community server -> login server node -> management node (as it has to write to TB)
- required signatures: community server, login server node, management node
- join group
- by invitation: applies for invitation via email, gets link to URL (hosted by community server), clicks it, login server node gets notification
- required signatures: community server, login server node
- do work
- hours worked could be stored on community server, as necessary
- receive gradidos
- sent by group leader; they cannot exceed amount set in rules
- cross group transfer
- sender@sender-group issues request via community server, mentioning recipient@recipient-group in it; sender's login server receives it, adds outbound transfer on sender-group blockchain, notifies login server of receiver-group (found by looking up in TB); inbound transfer is added to recipient-group's blockchain by login server #2
- required signatures: community server, both login servers
### how it comes together with model we have
- user id would not be his email but username@gradido-group-name
- gradido node server would keep:
- gradido group blockchains, which are associated with its login server (then it would be primary gradido node for particular gradido group)
- other blockchains - such as those which are necessary often, or needed to support network with backups (then it would be support gradido node for particular group)
- when reading blockchain data from a gradido node, random nodes are picked from each of the three buckets:
- primary gradido nodes
- support gradido nodes
- trusted gradido nodes: maintained by us
- growing of the cluster
- we could maintain some basic infrastructure to which it would be possible to add new nodes by other players
- existing login servers could be reused, for example; this way groups could be set up quickly
### known weaknesses
- hedera and flood
- cannot deny write access
- if blockchain is public, then a participant can find out public key of its recent partner in transfer
- maybe that can be classified with time; but if we use Hedera, all data is public
### development
- it is possible to have basic version quickly
- only one way of joining a gradido group: by invitation
- only one type of gradido group: dictatorship (single person makes decisions)
- prototyping
- demo in Erlang
- within this model it is possible to ensure fault tolerance, resilience against flooding, resilience against timeout attacks, rollbacks, migration procedures; we can focus on main features in the beginning
### other
- each node could have credibility rating, built over time
- if gradido node gets corrupted, login server node may get ban as well
- all requests are signed by issuing node's private key; those can be used as evidence to track down source of hacker activity
- consider the model described in this file as an "umbrella" for existing ideas of community server, login server, node server
- possibility to have gradido organization badge for identified groups / individuals
- user migration from group to group may involve two login servers
- login server is actually a group of replicas
- anyone can create a gradido cluster for his own needs; it is not mandatory to join our cluster
- good practice would be to store memo along with gradido creations, always
- gradido groups could have ratings
- only management nodes can write to TB
- only login server nodes may write to their primary group blockchains
- clusters could be merged (gradido blockchains would migrate along with gradido nodes / login servers)
- management nodes are considered primary nodes for TB
- different programming languages could be used to implement various types of nodes, to improve safety and security
- most of nodes are simple by themselves, easy to make
- transaction ids are generated on sender's side

102
docu/gradido_architecture.md Normal file
View File

@ -0,0 +1,102 @@
# Gradido Architecture
## Theory
### General requirements
- scalable to the point that it can be used by the whole world for their financial transactions
- subdivided into sub-networks which each belong to a group of people, e.g. a community
- secured against hackers and shutdown
- for the user as easy as paypal
### Approach
- Structured in several layers, similar to the OSI model
- Use of public-key signatures for transactions similar to Bitcoin
- Use of the Hedera Hashgraph Consensus Service for the chronological sorting of transactions
- Use of google protobuf to be able to exchange transactions with each other platform-independently
- Use of C++ based servers for the critical system areas for maximum security and performance
- Use of php and javascript for good usability and faster development of new comfort functions.
### Layers
#### Transaction protocol
- defined as google protocol buffers
- is stored like a block chain
- should not contain personal data
- based on the Hedera Hashgraph transactions format
- signed with ed25519 signatures
#### Blockchain
- temporal sorting of the transaction in a chain per group, e.g. from Hedera
- make the transactions publicly available, store and verify them
- secured against subsequent modification, deletion and loss due to server failure
#### User accounts
- encrypted storage of private keys for the users
- only with the correct e-mail-password combination the private keys can be decrypted
- Account recovery/change password using a passphrase from which the private key can be calculated
- (Optional) Store the user's passphrase encrypted with Server Admin Key(s) if the user did not note his passphrase when opening the account. Security risk!
- Signing of user transactions
#### User interface
- Caching and displaying the transactions belonging to the user
- Creating transactions
- Comfort functions such as friend lists for fast transfers
## Implementation & Software Components
### Community-Server
#### Layer 4, user interface
- based on cakephp
- Modern
- User-friendly
- Communicates a lot with the sign-up server
- One instance per group
- Could also be hosted on a simple webspace with php and mysql
### Sign-up-Server
#### Layer 3, user accounts
- C++ with Poco
- relevant to security
- Communicates via json-ajax-request with the Community-Server
- Communicates via jsonrpc-request with the Sign-up-Server
- Maximum one Sign-up-Server per group
- can manage several groups
- Hosting requires ssh access e.g. a VPS or root server
- Server-Admin must be reliable and should know something about server security
- Sends signed transactions to the Hedera network
### Node-Server
#### Layer 2, Blockchain
- C++ with Poco
- high-performance
- one node server can manage many groups
- stores the block chain of each group in a separate folder
- connection to the Hedera network as mirror node
- receives transactions from the Hedera network
- provides transaction data for Sign-up- and Community-Servers
- there should be more than one per group in case one fails.
- should be able to be used for a Supernode, which receives, checks and stores all transactions of the world (currently about 40 transactions per ms, about 650 GByte per day)
### GDT-Server
For the transition phase to project funding
- cakephp
- Connection to Elopage and Digistore
- Manages GDT for all who support the Gradido project
- Communicates with the Community-Server via json-ajax requests
- Currently only one instance
- Should not play a role in the system later
![](./graphics/gradido_architecture.jpg)

BIN
docu/graphics/gradido_architecture.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 23 KiB

0
docu/graphics/hederavsiota.drawio Normal file
View File

BIN
docu/other/Documentation Backups/Documentation of the Gradido platform 2020-09-03.docx Normal file
View File

Binary file not shown.

BIN
docu/other/Documentation Backups/Dokumentation der Gradido-Plattform 2020-09-03.docx Normal file
View File

Binary file not shown.

15
docu/other/Documentation Backups/Readme.md Normal file
View File

@ -0,0 +1,15 @@
This folder contains only backups.
The original documentation is being written in german and english on Google Docs:
German:
<https://docs.google.com/document/d/1Vd-k94S423wP7_CafUJaCyJ7oz1vMCcThof2rWmFr9k/edit?usp=sharing>
English:
<https://docs.google.com/document/d/1OOtW84KmgRC3ZqXgr-GxSytQ0mFemoiBBYVEwbg_Lmw/edit?usp=sharing>
The docs ar protected.
Please ask @BerndHueckstedt for access.

BIN
docu/other/Documentation of the Gradido platform.pdf Normal file
View File

Binary file not shown.

132
docu/other/api interfaces/filled_sample-blockchain.json Normal file
View File

@ -0,0 +1,132 @@
[
{
"record_type":"GRADIDO_TRANSACTION",
"transaction":{
"version_number":1,
"signature":{
"pubkey":"LtKKHPXhFtg2FUBrxXcVIiHC93SlZW9moOdUD3V21xs=",
"signature":"rtZyW6rKv5A+UfklA9Sfp+a5PGQC1W2eN4S+mjNmp3RZIT2FivRrV5KHq6ixtj0gb+vOGLyAzsb6Y9piieVkAw=="
},
"signature_count":1,
"hedera_transaction":{
"consensusTimestamp":{
"seconds":1604392811,
"nanos":172812
},
"runningHash":"f9ccf04137be418c3117a28bb5add6dced9745bcab74b7a2f46c182c8c98eeabf0127c131d15ebea7d0ac376f5d2de45",
"sequenceNumber":25,
"runningHashVersion":3
},
"transaction_type":"ADD_USER",
"add_user":{
"user":"LtKKHPXhFtg2FUBrxXcVIiHC93SlZW9moOdUD3V21xs="
},
"result":"result",
"parts":1,
"memo":""
}
},
{
"record_type":"GRADIDO_TRANSACTION",
"transaction":{
"version_number":1,
"signature":{
"pubkey":"gZC9pYXuXx2fv30G6B5p7BjhM3YQTP9Ut0V+t9PvcQ0=",
"signature":"MTStzWy8zuF8LbOY+Rtra90Ji2MG+y+iE+uetaMir5B4rMpNiwOD1OkG8xOeszaefB7w86xf7HJL4NCFukSvCw=="
},
"signature_count":2,
"hedera_transaction":{
"consensusTimestamp":{
"seconds":1604392886,
"nanos":1528
},
"runningHash":"e1df5526331e3def11d6b652b8f248d20c250739b6eb98f1fe7b338901753d9d573a14601ba84f61318a48940b3c237a",
"sequenceNumber":26,
"runningHashVersion":3
},
"transaction_type":"ADD_USER",
"add_user":{
"user":"gZC9pYXuXx2fv30G6B5p7BjhM3YQTP9Ut0V+t9PvcQ0="
},
"result":"result",
"parts":2,
"memo":""
}
},
{
"record_type":"SIGNATURES",
"signature":[
{
"pubkey":"LtKKHPXhFtg2FUBrxXcVIiHC93SlZW9moOdUD3V21xs=",
"signature":"QBcX52hhfA8zEZMcNKYeZqs2JZmg4qSK58SVVkWuxlc3c5hdr7hKEb+vK8EhQMMLL4yO4JS8NdYJvFbRW06fBA=="
}
]
},
{
"record_type": "GRADIDO_TRANSACTION",
"transaction":{
"version_number":1,
"signature":{
"pubkey":"LtKKHPXhFtg2FUBrxXcVIiHC93SlZW9moOdUD3V21xs=",
"signature":"mWZd7p8rR15Cai9EnQ2uYZJPbPAlkDZm/3Lyx+8a8nUj681ftoTReBP+eQay+M/l70vbsmTr8++ANjSR2bhoBw=="
},
"signature_count":1,
"hedera_transaction":{
"consensusTimestamp":{
"seconds":1604392904,
"nanos":798541
},
"runningHash":"f1fd03610a9788e9bac01e1efb8b99bafae450f9088cb940db954842e0799235c57d842be83d998e6c21786f77f967a7",
"sequenceNumber":27,
"runningHashVersion":3
},
"transaction_type":"GRADIDO_CREATION",
"gradido_creation":{
"user":"gZC9pYXuXx2fv30G6B5p7BjhM3YQTP9Ut0V+t9PvcQ0=",
"new_balance":10000000,
"prev_transfer_rec_num":0,
"amount":10000000
},
"result":"result",
"parts":1,
"memo":""
}
},
{
"record_type": "GRADIDO_TRANSACTION",
"transaction":{
"version_number":1,
"signature":{
"pubkey":"gZC9pYXuXx2fv30G6B5p7BjhM3YQTP9Ut0V+t9PvcQ0=",
"signature":"kBJeDPzmE5fVDtm6bF30zU4M9v7osQxw/uKJh2WYJXDZoSCMIimBQprjwinj/TbCvyMzUYzQpPBRWTeCLkmdCw=="
},
"signature_count":1,
"hedera_transaction":{
"consensusTimestamp":{
"seconds":1604392929,
"nanos":52539
},
"runningHash":"a4be8f54be4f806b61d31f6bd770d7742822f14f03ffe09c07f08bac3031a06d12de5e38fec5c307149c7faf6e9879b8",
"sequenceNumber":28,
"runningHashVersion":3
},
"transaction_type":"LOCAL_TRANSFER",
"local_transfer":{
"sender":{
"user":"gZC9pYXuXx2fv30G6B5p7BjhM3YQTP9Ut0V+t9PvcQ0=",
"new_balance":9825500,
"prev_transfer_rec_num":0
},
"receiver":{
"user":"LtKKHPXhFtg2FUBrxXcVIiHC93SlZW9moOdUD3V21xs=",
"new_balance":174500,
"prev_transfer_rec_num":0
},
"amount":174500
},
"result":"result",
"parts":1,
"memo":""
}
}
]

132
docu/other/api interfaces/filled_sample-blockchain_hex.json Normal file
View File

@ -0,0 +1,132 @@
[
{
"record_type":"GRADIDO_TRANSACTION",
"transaction":{
"version_number":1,
"signature":{
"pubkey":"2ed28a1cf5e116d83615406bc577152221c2f774a5656f66a0e7540f7576d71b",
"signature":"aed6725baacabf903e51f92503d49fa7e6b93c6402d56d9e3784be9a3366a77459213d858af46b579287aba8b1b63d206febce18bc80cec6fa63da6289e56403"
},
"signature_count":1,
"hedera_transaction":{
"consensusTimestamp":{
"seconds":1604392811,
"nanos":172812
},
"runningHash":"f9ccf04137be418c3117a28bb5add6dced9745bcab74b7a2f46c182c8c98eeabf0127c131d15ebea7d0ac376f5d2de45",
"sequenceNumber":25,
"runningHashVersion":3
},
"transaction_type":"ADD_USER",
"add_user":{
"user":"2ed28a1cf5e116d83615406bc577152221c2f774a5656f66a0e7540f7576d71b"
},
"result":"result",
"parts":1,
"memo":""
}
},
{
"record_type":"GRADIDO_TRANSACTION",
"transaction":{
"version_number":1,
"signature":{
"pubkey":"8190bda585ee5f1d9fbf7d06e81e69ec18e13376104cff54b7457eb7d3ef710d",
"signature":"3134adcd6cbccee17c2db398f91b6b6bdd098b6306fb2fa213eb9eb5a322af9078acca4d8b0383d4e906f3139eb3369e7c1ef0f3ac5fec724be0d085ba44af0b"
},
"signature_count":2,
"hedera_transaction":{
"consensusTimestamp":{
"seconds":1604392886,
"nanos":1528
},
"runningHash":"e1df5526331e3def11d6b652b8f248d20c250739b6eb98f1fe7b338901753d9d573a14601ba84f61318a48940b3c237a",
"sequenceNumber":26,
"runningHashVersion":3
},
"transaction_type":"ADD_USER",
"add_user":{
"user":"8190bda585ee5f1d9fbf7d06e81e69ec18e13376104cff54b7457eb7d3ef710d"
},
"result":"result",
"parts":2,
"memo":""
}
},
{
"record_type":"SIGNATURES",
"signature":[
{
"pubkey":"2ed28a1cf5e116d83615406bc577152221c2f774a5656f66a0e7540f7576d71b",
"signature":"401717e768617c0f3311931c34a61e66ab362599a0e2a48ae7c4955645aec6573773985dafb84a11bfaf2bc12140c30b2f8c8ee094bc35d609bc56d15b4e9f04"
}
]
},
{
"record_type": "GRADIDO_TRANSACTION",
"transaction":{
"version_number":1,
"signature":{
"pubkey":"2ed28a1cf5e116d83615406bc577152221c2f774a5656f66a0e7540f7576d71b",
"signature":"99665dee9f2b475e426a2f449d0dae61924f6cf025903666ff72f2c7ef1af27523ebcd5fb684d17813fe7906b2f8cfe5ef4bdbb264ebf3ef80363491d9b86807"
},
"signature_count":1,
"hedera_transaction":{
"consensusTimestamp":{
"seconds":1604392904,
"nanos":798541
},
"runningHash":"f1fd03610a9788e9bac01e1efb8b99bafae450f9088cb940db954842e0799235c57d842be83d998e6c21786f77f967a7",
"sequenceNumber":27,
"runningHashVersion":3
},
"transaction_type":"GRADIDO_CREATION",
"gradido_creation":{
"user":"8190bda585ee5f1d9fbf7d06e81e69ec18e13376104cff54b7457eb7d3ef710d",
"new_balance":10000000,
"prev_transfer_rec_num":0,
"amount":10000000
},
"result":"result",
"parts":1,
"memo":""
}
},
{
"record_type": "GRADIDO_TRANSACTION",
"transaction":{
"version_number":1,
"signature":{
"pubkey":"8190bda585ee5f1d9fbf7d06e81e69ec18e13376104cff54b7457eb7d3ef710d",
"signature":"90125e0cfce61397d50ed9ba6c5df4cd4e0cf6fee8b10c70fee2898765982570d9a1208c222981429ae3c229e3fd36c2bf2333518cd0a4f0515937822e499d0b"
},
"signature_count":1,
"hedera_transaction":{
"consensusTimestamp":{
"seconds":1604392929,
"nanos":52539
},
"runningHash":"a4be8f54be4f806b61d31f6bd770d7742822f14f03ffe09c07f08bac3031a06d12de5e38fec5c307149c7faf6e9879b8",
"sequenceNumber":28,
"runningHashVersion":3
},
"transaction_type":"LOCAL_TRANSFER",
"local_transfer":{
"sender":{
"user":"8190bda585ee5f1d9fbf7d06e81e69ec18e13376104cff54b7457eb7d3ef710d",
"new_balance":9825500,
"prev_transfer_rec_num":0
},
"receiver":{
"user":"2ed28a1cf5e116d83615406bc577152221c2f774a5656f66a0e7540f7576d71b",
"new_balance":174500,
"prev_transfer_rec_num":0
},
"amount":174500
},
"result":"result",
"parts":1,
"memo":""
}
}
]

90
docu/other/api interfaces/login server api interface.txt Normal file
View File

@ -0,0 +1,90 @@
/login
{"session_id":<from login server session cookie>}
return: {
"state":"success",
"clientIP":"<client ip string from login>",
"user":
{
"first_name": "<user first name>",
"last_name": "<user last name>",
"email": "<user email>",
"created": "<date of user creating account on login server>",
"email_checked": <true if user has clicked link in activation email>,
"ident_hash": "<currently not used>",
"disabled": <true if user account was disabled and cannot login or doing anything>,
"role": "<'admin' if user is server admin and can do anything>"
"public_hex": "<user public key in hex format>"
},
"Transaction.pending":<number of transaction of user which are prepeared for sign>,
"Transaction.executing":<number of transaction of user which are signed and are sended to hedera, waiting on confirmation from nodes>
}
/checkTransaction
DEPRACTED
/createTransaction
{
"session_id":<from login server session cookie>,
"transaction_type":"<transfer|creation|groupMemberUpdate>",
"memo" : "<additional infos for transaction, maybe encrypt later>"
if transfer:
"amount": <GDD amount in GDD cent for transfer>,
"target_group": "<target group alias>"
"target_email": "<target user email>"
OR
"target_username": "<target username>"
OR
"target_pubkey":"<target user public key in hex format>"
if creation:
"amount": <GDD amount in GDD cent for transfer>,
"target_date": "<target date for creation, only 1.000 GDD per month, max. 3 month in past>"
"target_email": "<target user email>"
OR
"target_username": "<target username>"
OR
"target_pubkey":"<target user public key in hex format>"
if groupMemberUpdate:
"target_group": "<target group alias>"
}
return:
if request contain unknown parameter format, shouldn't happen't at all
{"state": "error", "msg": "parameter format unknown"}
if json parsing failed
{"state": "error", "msg": "json exception", "details":"exception text"}
if session_id is zero or not set
{"state": "error", "msg": "session_id invalid"}
if session id wasn't found on login server, if server was restartet or user logged out (also per timeout, default: 15 minutes)
{"state": "error", "msg": "session not found"}
if session hasn't active user, shouldn't happen't at all, login-server should be checked if happen
{"state": "code error", "msg":"user is zero"}
if transaction type not known
{"state": "error", "msg":"transaction_type unknown"}
only by groupMemberUpdate, if target_group is empty or alias wasn't found on Login-Server
{"state": "error", "msg": "target_group not found"}
if receiver wasn't known to Login-Server
{"state": "not found", "msg":"receiver not found"}
if receiver account disabled, and therefor cannto receive any coins
{"state": "disabled", "msg":"receiver is disabled"}
if user hasn't joined group yet
{"state":"error","msg":"receiver user hasn't group"}
if receiver user isn't in target group by transfer transaction
{"state":"error","msg":"user not in group","details":"receiver user isn't in target group"}
if amount is invalid in creation
{"state": "invalid parameter", "msg":"invalid amount", "details":"GDD amount in GDD cent ]0,10000000]"}
if transaction was okay and will be further proccessed
{"state":"success"}
/getRunningUserTasks
/getUsers
/createUser
/adminEmailVerificationResend
/getUserInfos
/updateUserInfos
/search

63
docu/other/api interfaces/node server api interface.txt Normal file
View File

@ -0,0 +1,63 @@
two types of requests:
authorized and open request
authorized requests use ManageNodeRequest.proto and ManageNodeBody.proto (maybe better name later) which use
the same strategy like Hedera Transactions with signMap
Node server check if he knows signer
signer must put there public key at first in node server config
message ManageNodeGroupAdd {
string group_name = 1;
string group_alias = 2;
HederaID hedera_topic_id = 3;
//string parent_group_alias = 4;
}
- add blockchain to node server
- sync with neigbhor node server
- discover new neighbor if known neighbor hasn't blockchain
- ask hedera for last transaction of this topic to know if sync
Open request:
open for everyone, no need to check sender
but don't sending personal data like e-mail address (which shouldn't be on blockchain anyway)
only read access
access via json-rpc?
method: "checkPubkeysBelongToGroup"
params: {"pubkeys": [<publicKeys>], "groupAlias": "<group alias string>"}
check for every pubkey in array if user belong to group
- user belong only to group if he was added to group
- OR moved into group from another group
- AND wasn't moved out of group
return: [<true|false>]
return array in same order as input with true for every existing pubkey and false for every not existing pubkey
method: "getBalance"
params: {"groupAlias": "<group alias string>", "pubkey": "<user account public key>"}
return: {"balance":<balance as int, GDD Cent>, deflationTime:<timestamp in seconds>}
- if user is currently in group
return current balance from user with deflation calculated on request time
- if group wasn't known or user public key wasn't know to group at all
return error
- if user isn't any longer in group
return balance with deflation at time of moving out
method: "getTransactions"
params: {"groupAlias": "<group alias string>", "lastKnownSequenceNumber": <sequence number>}
return transactions with sequence number bigger as input sequence number
return: already implemented json dump format
method: "getCreationSum"
params: {"groupAlias": "<group alias string>", "month": <month 1-12>, "year":<year>, "pubkey": "<user account public key>"}
return: {"balance": <balance as int, GDD Cent>}
calculate and return creation sum from all creation transaction from user with targetDate in month and year

31
docu/other/api interfaces/sample-blockchain.json Normal file
View File

@ -0,0 +1,31 @@
[
{
"transaction": {
"version_number": 1,
"signature": {
"pubkey": "00000000000000000000000000000000",
"signature": "00000000000000000000000000000000"
},
"signature_count": 1,
"hedera_transaction": {
"consensusTimestamp": {
"seconds": 7,
"nanos": 11,
},
"runningHash": "00000000000000000000000000000000",
"sequenceNumber": 13,
"runningHashVersion": 3
},
"transaction_type": "GRADIDO_CREATION",
"gradido_creation": {
"user": "00000000000000000000000000000000",
"new_balance": 100,
"prev_transfer_rec_num": 0,
"amount": 100
},
"result": result,
"parts": 1,
"memo": ""
}
}
]

BIN
docu/other/cluster.dia Normal file
View File

Binary file not shown.

BIN
docu/other/cluster.png Normal file
View File

Binary file not shown.

0
docu/comment_dario.md → docu/other/comment_dario.md
View File

0
docu/other/communication logs/add_group.txt Normal file
View File

101
docu/other/communication logs/add_to_group.txt Normal file
View File

@ -0,0 +1,101 @@
LoginServer HTTP-Interface ActionsPage /addToGroup
select: on Login Server registered groups with short description
if user is already in a group:
// check if birth hash and user public key haven't changed
call to node server registered with login-server containing current group of user:
{"jsonrpc": "2.0", "method": "checkBirthHash", "params": {
"groupAlias":<from db group[user.group_id]>,
"birthHash": <from db user.birth_hash>,
"pubkey":<from db user.pubkey>,
"apiKey": <unique per Login Server>
}, "id": rand()}
Node Server
search for birthHash in StateUserChangeGroup transactions in group[groupAlias]
if found as last StateUserChangeGroup with birthHash and pubkey are correct:
return {"jsonrpc": "2.0", "result": {"state": "success"}, "id": <id from call>}
if not found:
check if a StateUserChangeGroup transaction for pubkey can be found
if found:
return {"jsonrpc": "2.0", "result": {"state": "not same", "msg": "birth hash is different", "details": {"birthHash": <found birth hash>}}, "id": <id from call>}
else:
return {"jsonrpc": "2.0", "result": {"state": "not found", "msg": "birth hash not found"}, "id": <id from call>}
if birth hash and pubkey from last StateUserChangeGroup not the same:
return {"jsonrpc": "2.0", "result": {"state": "not same", "msg": "pubkey is different", "details": {"pubkey":<found pubkey>}, "id": <id from call>}
LoginServer
cancel process if user is in group and request return not same or not found
show error message
if user isn't already in a group:
// check if birth hash is unique
call all registered Nodes:
{"jsonrpc": "2.0", "method": "checkBirthHash", "params": {
"groupAlias":<from db group[user.group_id]>,
"birthHash": <from db user.birth_hash>,
"pubkey":<from db user.pubkey>,
"apiKey": <unique per Login Server>
}, "id": rand()}
Node Server
getting discovery transaction from mirror node
searching for birth hash in global blockchain
if found calling model.messages.gradido.DiscoverIfExist.answearUrl with:
{
"birthHash": model.messages.gradido.DiscoverIfExist.value,
"pubkey" : <pubkey from youngest found transaction>
"groupAlias": <group alias from youngest found transaction>
"received" : <received from youngest found transaction>
}
LoginServer
Waiting at least 2 minutes for answear(s)
collect answears
cancel if birthHash was discovered with another pubkey and this has the biggest received value
show error message
else save group alias as parent
If not canceled
Hedera::ConsensusService::ConsensusSubmitMessage
proto.ConsensusSubmitMessageTransactionBody.topicID = <choosen group topic id>
proto.ConsensusSubmitMessageTransactionBody.message =
model.messages.gradido.Transaction
id = <left empty>;
received = <left empty>;
sigMap = model.messages.gradido.SignatureMap
if user is group founder:
sigPair =
model.messages.gradido.SignaturePair
pubKey = <public root key of user and group founder>
signature = ed25519 = <bodyBytes signed with user and group founder private key>
else
sigPair = [
model.messages.gradido.SignaturePair
pubKey = <public root key of user>
signature = ed25519 = <bodyBytes signed with user private key>
for i = 0, i < n, i++
model.messages.gradido.SignaturePair
pubKey = <public root key of group member>
signature = ed25519 = <bodyBytes signed with group member private key>,
],
txHash = <left empty>;
bodyBytes = model.messages.gradido.TransactionBody serialized
memo = <empty>
created = model.messages.gradido.TimestampSeconds
seconds = <current timestamp>
data = model.messages.gradido.StateCreateGroup
name = <group name>
alias = <group alias>
parentGroupAlias = <parent group alias or empty>
hederaTopicId = <from hedera answear>
serialized
Node Server(s)
receiving message, validate, put into blockchain of group

73
docu/other/communication logs/create_group.txt Normal file
View File

@ -0,0 +1,73 @@
Note to Hedera and Gradido Transactions:
- A Transaction contain TransactionBody serialized
- TransactionBody contains the actual transaction
- Hedera has namespace proto, gradido has namespace model.messages.gradido
LoginServer
register NodeServer with (username and password) or API key
LoginServer get called with data from http form:
- 1 group name
- 1 group alias
- x registered node server(s), evt. with API key if not saved
Hedera::ConsensusService::createTopic
get TransactionReceipt with TopicID (if succeed)
// TopicID consists of three int64: shardNum, realmNum, topicNum
Hedera::ConsensusService::ConsensusSubmitMessage
proto.ConsensusSubmitMessageTransactionBody.topicID = gradido_discover_topicid // global, must obtained before first node server can go online, maybe hardcoded?
proto.ConsensusSubmitMessageTransactionBody.message = model.messages.gradido.DiscoverIfExist serialized
Gradido Node receive from Hedera Mirror Node: DiscoverIfExist
Check if group alias known to gradido node
If not, doing nothing, not saving message
If found, call answearUrl with HTTP POST Request, not saving message in json format
{
"TransactionID":<found in hedera transaction>,
"thingToFind":model.messages.gradido.DiscoverIfExist.thingToFind,
"value":model.messages.gradido.DiscoverIfExist.value
}
LoginServer wait at least 2 minutes to answears (async) and if no answear was received, proceed
json-rpc http request createGroup with APIKey and TopicID to choosen noder server
{"jsonrpc": "2.0", "method": "createGroup", "params": {"APIKey": <saved or from form>, "TopicID": <from hedera answear>}, "id": rand()}
//send TopicID to Node Server(s) (choose from http-interface)
Gradido Node
create group folder, register for listening on topic from hedera
LoginServer
Hedera::ConsensusService::ConsensusSubmitMessage
proto.ConsensusSubmitMessageTransactionBody.topicID = <from hedera answera>
proto.ConsensusSubmitMessageTransactionBody.message =
model.messages.gradido.Transaction
id = <left empty>;
received = <left empty>;
sigMap = model.messages.gradido.SignatureMap
sigPair = model.messages.gradido.SignaturePair
pubKey = <public root key of group founder>
signature = ed25519 = <bodyBytes signed with group founder private key>
txHash = <left empty>;
bodyBytes = model.messages.gradido.TransactionBody serialized
memo = <empty>
created = model.messages.gradido.TimestampSeconds
seconds = <current timestamp>
data = model.messages.gradido.StateCreateGroup
name = <group name>
alias = <group alias>
parentGroupAlias = <parent group alias or empty>
hederaTopicId = <from hedera answear>
signed from user, he is the group founder now and can sign group related messages, as long as no other was voted
Gradio Node receive message from hedera mirror node,
save it to blockchain
validate: sequenze nr must be 1,
call again discoveryIfExist for group alias to make sure, no one has get the alias in between

82
docu/other/communication logs/create_group_v2.txt Normal file
View File

@ -0,0 +1,82 @@
Note to Hedera and Gradido Transactions:
- A Transaction contain TransactionBody serialized
- TransactionBody contains the actual transaction
- Hedera has namespace proto, gradido has namespace model.messages.gradido
LoginServer
register NodeServer with (username and password) or API key
LoginServer get called with data from http form:
- 1 group name
- 1 group alias
- x registered node server(s), evt. with API key if not saved
check if alias in unique with choosen NodeServer
{"jsonrpc": "2.0", "method": "checkAlias", "params": {"alias": <from form>, "apiKey": <optional, unique per Login Server>}, "id": rand()}
Gradido Node return result with 0 or 1 and memorize if apiKey is given (only in memory) by 0 request for 10 minutes
0 = alias unknown
1 = alias known
2 = has blockchain for group of alias
Hedera::ConsensusService::createTopic
get TransactionReceipt with TopicID (if succeed, alias unknown)
// TopicID consists of three int64: shardNum, realmNum, topicNum
Hedera::ConsensusService::ConsensusSubmitMessage
proto.ConsensusSubmitMessageTransactionBody.topicID = gradido_discover_topicid // global, must obtained before first node server can go online, maybe hardcoded?
proto.ConsensusSubmitMessageTransactionBody.message =
model.messages.gradido.Transaction
id = <left empty>;
received = <left empty>;
sigMap = model.messages.gradido.SignatureMap
sigPair = model.messages.gradido.SignaturePair
pubKey = <public root key of group founder>
signature = ed25519 = <bodyBytes signed with group founder private key>
txHash = <left empty>;
bodyBytes = model.messages.gradido.TransactionBody serialized
memo = <empty>
created = model.messages.gradido.TimestampSeconds
seconds = <current timestamp>
data = model.messages.gradido.StateCreateGroup
name = <group name>
alias = <group alias>
parentGroupAlias = <parent group alias or empty>
hederaTopicId = <from hedera answear>
serialized
signed from user, he is the group founder now and can sign group related messages
Gradido Node receive from Hedera Mirror Node: model.messages.gradido.Transaction with model.messages.gradido.StateCreateGroup
validate and save create Group Transaction in state-chain
if checkAlias Request for this alias is memorized:
create blockchain for this group,
register for listen to topic of this group
send HTTP POST Request in json format to login server(s) how called checkAlias with this alias 10 minutes or less before {
/group_created {
"alias":StateCreateGroup.alias,
"topicID": StateCreateGroup.hederaTopicId,
"name": StateCreateGroup.name
}
LoginServer
Show succeed
-------------------------------------------------------------------------
if node server already know group
LoginServer
{"jsonrpc": "2.0", "method": "addGroup", "params": {"alias": <from form>, "apiKey": <unique per Login Server>}, "id": rand()}
GradidoNode
return {"jsonrpc": "2.0", "result": {"state": "not found", "msg":"group alias not known"}, "id": <id from call>}
create blockchain for this group,
register for listen to topic of this group
return {"jsonrpc": "2.0", "result": {
"alias":StateCreateGroup.alias,
"topicID": StateCreateGroup.hederaTopicId,
"name": StateCreateGroup.name
}, "id": <id from call>}

BIN
docu/other/db/LoginServer.dia Normal file
View File

Binary file not shown.

BIN
docu/other/db/LoginServer.dia.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 212 KiB

6
docu/other/db/address_types.sql Normal file
View File

@ -0,0 +1,6 @@
CREATE TABLE `address_types` (
`id` INT NOT NULL AUTO_INCREMENT,
`name` VARCHAR(25) NOT NULL,
`text` VARCHAR(255) NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

528
docu/other/db/cake_gradido_single_dev_node-1.sql Normal file
View File

@ -0,0 +1,528 @@
-- phpMyAdmin SQL Dump
-- version 4.6.6deb5
-- https://www.phpmyadmin.net/
--
-- Host: localhost:3306
-- Erstellungszeit: 12. Nov 2019 um 09:12
-- Server-Version: 10.1.41-MariaDB-0ubuntu0.18.04.1
-- PHP-Version: 7.2.24-0ubuntu0.18.04.1
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
--
-- Datenbank: `cake_gradido_single_dev_node`
--
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `operators`
--
CREATE TABLE `operators` (
`id` int(11) NOT NULL,
`username` varchar(50) COLLATE utf8_bin NOT NULL,
`user_pubkey` binary(32) NOT NULL,
`data_base64` varchar(255) COLLATE utf8_bin NOT NULL,
`modified` datetime NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `operator_types`
--
CREATE TABLE `operator_types` (
`id` int(11) NOT NULL,
`name` varchar(25) COLLATE utf8_bin NOT NULL,
`text` varchar(255) COLLATE utf8_bin NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
--
-- Daten für Tabelle `operator_types`
--
INSERT INTO `operator_types` (`id`, `name`, `text`) VALUES
(1, 'hedera', 'Hedera Keys for sign and pay hedera transactions'),
(2, 'gradido-user', 'default gradido user keys'),
(3, 'gradido-group', 'default gradido group root keys, other address are derived');
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `pending_transactions`
--
CREATE TABLE `pending_transactions` (
`id` int(11) NOT NULL,
`transactionID` varchar(25) COLLATE utf8_bin NOT NULL,
`service` varchar(20) COLLATE utf8_bin NOT NULL,
`method` varchar(20) COLLATE utf8_bin NOT NULL,
`h_server_id` int(11) NOT NULL,
`timeout` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `server_users`
--
CREATE TABLE `server_users` (
`id` int(11) NOT NULL,
`username` varchar(50) COLLATE utf8_bin NOT NULL,
`password` varchar(255) COLLATE utf8_bin NOT NULL,
`email` varchar(50) COLLATE utf8_bin NOT NULL,
`role` varchar(20) COLLATE utf8_bin NOT NULL DEFAULT 'admin',
`activated` tinyint(1) NOT NULL DEFAULT '0',
`last_login` datetime DEFAULT NULL,
`created` datetime NOT NULL,
`modified` datetime NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `state_balances`
--
CREATE TABLE `state_balances` (
`id` int(11) NOT NULL,
`state_user_id` int(11) NOT NULL,
`modified` datetime NOT NULL,
`amount` bigint(20) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `state_created`
--
CREATE TABLE `state_created` (
`id` int(11) NOT NULL,
`transaction_id` int(11) NOT NULL,
`month` tinyint(4) NOT NULL,
`year` smallint(6) NOT NULL,
`state_user_id` int(11) NOT NULL,
`created` datetime NOT NULL,
`short_ident_hash` int(11) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `state_errors`
--
CREATE TABLE `state_errors` (
`id` int(11) NOT NULL,
`state_user_id` int(11) NOT NULL,
`transaction_type_id` int(11) NOT NULL,
`created` datetime NOT NULL,
`message_json` text NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `state_group_addresses`
--
CREATE TABLE `state_group_addresses` (
`id` int(11) NOT NULL,
`group_id` int(11) NOT NULL,
`public_key` binary(32) NOT NULL,
`address_type_id` int(11) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `state_group_relationships`
--
CREATE TABLE `state_group_relationships` (
`id` int(11) NOT NULL,
`group1_id` int(11) NOT NULL,
`group2_id` int(11) NOT NULL,
`state_relationship_id` int(11) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `state_relationship_types`
--
CREATE TABLE `state_relationship_types` (
`id` int(11) NOT NULL,
`name` varchar(25) COLLATE utf8_bin NOT NULL,
`text` varchar(255) COLLATE utf8_bin DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `state_users`
--
CREATE TABLE `state_users` (
`id` int(11) NOT NULL,
`index_id` smallint(6) NOT NULL,
`group_id` int(11) NOT NULL,
`public_key` binary(32) NOT NULL,
`email` varchar(255) COLLATE utf8_bin DEFAULT NULL,
`first_name` varchar(255) COLLATE utf8_bin DEFAULT NULL,
`last_name` varchar(255) COLLATE utf8_bin DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `transactions`
--
CREATE TABLE `transactions` (
`id` bigint(20) NOT NULL,
`group_id` int(11) NOT NULL,
`transaction_type_id` int(11) NOT NULL,
`tx_hash` binary(32) NOT NULL,
`memo` varchar(255) COLLATE utf8_bin NOT NULL,
`received` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `transaction_creations`
--
CREATE TABLE `transaction_creations` (
`id` int(11) NOT NULL,
`transaction_id` int(11) NOT NULL,
`state_user_id` int(11) NOT NULL,
`amount` bigint(20) NOT NULL,
`ident_hash` binary(32) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `transaction_group_addaddress`
--
CREATE TABLE `transaction_group_addaddress` (
`id` int(11) NOT NULL,
`transaction_id` int(11) NOT NULL,
`address_type_id` int(11) NOT NULL,
`public_key` binary(32) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `transaction_group_allowtrades`
--
CREATE TABLE `transaction_group_allowtrades` (
`id` int(11) NOT NULL,
`transaction_id` int(11) NOT NULL,
`remote_group_id` varbinary(64) NOT NULL,
`allow` tinyint(1) NOT NULL DEFAULT '0'
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `transaction_group_creates`
--
CREATE TABLE `transaction_group_creates` (
`id` int(11) NOT NULL,
`transaction_id` int(11) NOT NULL,
`group_public_key` binary(32) NOT NULL,
`group_id` varchar(64) COLLATE utf8_bin NOT NULL,
`name` varchar(64) COLLATE utf8_bin NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `transaction_send_coins`
--
CREATE TABLE `transaction_send_coins` (
`id` int(11) NOT NULL,
`transaction_id` int(11) NOT NULL,
`state_user_id` int(11) NOT NULL,
`receiver_public_key` binary(32) NOT NULL,
`receiver_user_id` varbinary(64) NOT NULL,
`amount` bigint(20) NOT NULL,
`sender_final_balance` bigint(20) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `transaction_signatures`
--
CREATE TABLE `transaction_signatures` (
`id` int(11) NOT NULL,
`transaction_id` int(11) NOT NULL,
`signature` binary(64) NOT NULL,
`pubkey` binary(32) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `transaction_types`
--
CREATE TABLE `transaction_types` (
`id` int(11) NOT NULL,
`name` varchar(24) COLLATE utf8_bin NOT NULL,
`text` varchar(255) COLLATE utf8_bin NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
--
-- Daten für Tabelle `transaction_types`
--
INSERT INTO `transaction_types` (`id`, `name`, `text`) VALUES
(1, 'creation', 'Aktives oder Bedingsungsloses Grundeinkommen.'),
(2, 'transfer', 'Einfache Überweisung');
--
-- Indizes der exportierten Tabellen
--
--
-- Indizes für die Tabelle `operators`
--
ALTER TABLE `operators`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `operator_types`
--
ALTER TABLE `operator_types`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `pending_transactions`
--
ALTER TABLE `pending_transactions`
ADD PRIMARY KEY (`id`),
ADD UNIQUE KEY `transactionID` (`transactionID`);
--
-- Indizes für die Tabelle `server_users`
--
ALTER TABLE `server_users`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `state_balances`
--
ALTER TABLE `state_balances`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `state_created`
--
ALTER TABLE `state_created`
ADD PRIMARY KEY (`id`),
ADD KEY `short_ident_hash` (`short_ident_hash`);
--
-- Indizes für die Tabelle `state_errors`
--
ALTER TABLE `state_errors`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `state_group_addresses`
--
ALTER TABLE `state_group_addresses`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `state_group_relationships`
--
ALTER TABLE `state_group_relationships`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `state_relationship_types`
--
ALTER TABLE `state_relationship_types`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `state_users`
--
ALTER TABLE `state_users`
ADD PRIMARY KEY (`id`),
ADD UNIQUE KEY `public_key` (`public_key`);
--
-- Indizes für die Tabelle `transactions`
--
ALTER TABLE `transactions`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `transaction_creations`
--
ALTER TABLE `transaction_creations`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `transaction_group_addaddress`
--
ALTER TABLE `transaction_group_addaddress`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `transaction_group_allowtrades`
--
ALTER TABLE `transaction_group_allowtrades`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `transaction_group_creates`
--
ALTER TABLE `transaction_group_creates`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `transaction_send_coins`
--
ALTER TABLE `transaction_send_coins`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `transaction_signatures`
--
ALTER TABLE `transaction_signatures`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `transaction_types`
--
ALTER TABLE `transaction_types`
ADD PRIMARY KEY (`id`);
--
-- AUTO_INCREMENT für exportierte Tabellen
--
--
-- AUTO_INCREMENT für Tabelle `operators`
--
ALTER TABLE `operators`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `operator_types`
--
ALTER TABLE `operator_types`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=4;
--
-- AUTO_INCREMENT für Tabelle `pending_transactions`
--
ALTER TABLE `pending_transactions`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `server_users`
--
ALTER TABLE `server_users`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=2;
--
-- AUTO_INCREMENT für Tabelle `state_balances`
--
ALTER TABLE `state_balances`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=11;
--
-- AUTO_INCREMENT für Tabelle `state_created`
--
ALTER TABLE `state_created`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `state_errors`
--
ALTER TABLE `state_errors`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `state_group_addresses`
--
ALTER TABLE `state_group_addresses`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `state_group_relationships`
--
ALTER TABLE `state_group_relationships`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `state_relationship_types`
--
ALTER TABLE `state_relationship_types`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `state_users`
--
ALTER TABLE `state_users`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=7;
--
-- AUTO_INCREMENT für Tabelle `transactions`
--
ALTER TABLE `transactions`
MODIFY `id` bigint(20) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=2;
--
-- AUTO_INCREMENT für Tabelle `transaction_creations`
--
ALTER TABLE `transaction_creations`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=11;
--
-- AUTO_INCREMENT für Tabelle `transaction_group_addaddress`
--
ALTER TABLE `transaction_group_addaddress`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `transaction_group_allowtrades`
--
ALTER TABLE `transaction_group_allowtrades`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `transaction_group_creates`
--
ALTER TABLE `transaction_group_creates`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `transaction_send_coins`
--
ALTER TABLE `transaction_send_coins`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `transaction_signatures`
--
ALTER TABLE `transaction_signatures`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=2;
--
-- AUTO_INCREMENT für Tabelle `transaction_types`
--
ALTER TABLE `transaction_types`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=3;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;

528
docu/other/db/cake_gradido_single_node.sql Normal file
View File

@ -0,0 +1,528 @@
-- phpMyAdmin SQL Dump
-- version 4.6.6deb5
-- https://www.phpmyadmin.net/
--
-- Host: localhost:3306
-- Erstellungszeit: 12. Nov 2019 um 09:12
-- Server-Version: 10.1.41-MariaDB-0ubuntu0.18.04.1
-- PHP-Version: 7.2.24-0ubuntu0.18.04.1
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
--
-- Datenbank: `cake_gradido_single_dev_node`
--
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `operators`
--
CREATE TABLE `operators` (
`id` int(11) NOT NULL,
`username` varchar(50) COLLATE utf8_bin NOT NULL,
`user_pubkey` binary(32) NOT NULL,
`data_base64` varchar(255) COLLATE utf8_bin NOT NULL,
`modified` datetime NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `operator_types`
--
CREATE TABLE `operator_types` (
`id` int(11) NOT NULL,
`name` varchar(25) COLLATE utf8_bin NOT NULL,
`text` varchar(255) COLLATE utf8_bin NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
--
-- Daten für Tabelle `operator_types`
--
INSERT INTO `operator_types` (`id`, `name`, `text`) VALUES
(1, 'hedera', 'Hedera Keys for sign and pay hedera transactions'),
(2, 'gradido-user', 'default gradido user keys'),
(3, 'gradido-group', 'default gradido group root keys, other address are derived');
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `pending_transactions`
--
CREATE TABLE `pending_transactions` (
`id` int(11) NOT NULL,
`transactionID` varchar(25) COLLATE utf8_bin NOT NULL,
`service` varchar(20) COLLATE utf8_bin NOT NULL,
`method` varchar(20) COLLATE utf8_bin NOT NULL,
`h_server_id` int(11) NOT NULL,
`timeout` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `server_users`
--
CREATE TABLE `server_users` (
`id` int(11) NOT NULL,
`username` varchar(50) COLLATE utf8_bin NOT NULL,
`password` varchar(255) COLLATE utf8_bin NOT NULL,
`email` varchar(50) COLLATE utf8_bin NOT NULL,
`role` varchar(20) COLLATE utf8_bin NOT NULL DEFAULT 'admin',
`activated` tinyint(1) NOT NULL DEFAULT '0',
`last_login` datetime DEFAULT NULL,
`created` datetime NOT NULL,
`modified` datetime NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `state_balances`
--
CREATE TABLE `state_balances` (
`id` int(11) NOT NULL,
`state_user_id` int(11) NOT NULL,
`modified` datetime NOT NULL,
`amount` bigint(20) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `state_created`
--
CREATE TABLE `state_created` (
`id` int(11) NOT NULL,
`transaction_id` int(11) NOT NULL,
`month` tinyint(4) NOT NULL,
`year` smallint(6) NOT NULL,
`state_user_id` int(11) NOT NULL,
`created` datetime NOT NULL,
`short_ident_hash` int(11) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `state_errors`
--
CREATE TABLE `state_errors` (
`id` int(11) NOT NULL,
`state_user_id` int(11) NOT NULL,
`transaction_type_id` int(11) NOT NULL,
`created` datetime NOT NULL,
`message_json` text NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `state_group_addresses`
--
CREATE TABLE `state_group_addresses` (
`id` int(11) NOT NULL,
`group_id` int(11) NOT NULL,
`public_key` binary(32) NOT NULL,
`address_type_id` int(11) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `state_group_relationships`
--
CREATE TABLE `state_group_relationships` (
`id` int(11) NOT NULL,
`group1_id` int(11) NOT NULL,
`group2_id` int(11) NOT NULL,
`state_relationship_id` int(11) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `state_relationship_types`
--
CREATE TABLE `state_relationship_types` (
`id` int(11) NOT NULL,
`name` varchar(25) COLLATE utf8_bin NOT NULL,
`text` varchar(255) COLLATE utf8_bin DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `state_users`
--
CREATE TABLE `state_users` (
`id` int(11) NOT NULL,
`index_id` smallint(6) NOT NULL,
`group_id` int(11) NOT NULL,
`public_key` binary(32) NOT NULL,
`email` varchar(255) COLLATE utf8_bin DEFAULT NULL,
`first_name` varchar(255) COLLATE utf8_bin DEFAULT NULL,
`last_name` varchar(255) COLLATE utf8_bin DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `transactions`
--
CREATE TABLE `transactions` (
`id` bigint(20) NOT NULL,
`group_id` int(11) NOT NULL,
`transaction_type_id` int(11) NOT NULL,
`tx_hash` binary(32) NOT NULL,
`memo` varchar(255) COLLATE utf8_bin NOT NULL,
`received` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `transaction_creations`
--
CREATE TABLE `transaction_creations` (
`id` int(11) NOT NULL,
`transaction_id` int(11) NOT NULL,
`state_user_id` int(11) NOT NULL,
`amount` bigint(20) NOT NULL,
`ident_hash` binary(32) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `transaction_group_addaddress`
--
CREATE TABLE `transaction_group_addaddress` (
`id` int(11) NOT NULL,
`transaction_id` int(11) NOT NULL,
`address_type_id` int(11) NOT NULL,
`public_key` binary(32) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `transaction_group_allowtrades`
--
CREATE TABLE `transaction_group_allowtrades` (
`id` int(11) NOT NULL,
`transaction_id` int(11) NOT NULL,
`remote_group_id` varbinary(64) NOT NULL,
`allow` tinyint(1) NOT NULL DEFAULT '0'
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `transaction_group_creates`
--
CREATE TABLE `transaction_group_creates` (
`id` int(11) NOT NULL,
`transaction_id` int(11) NOT NULL,
`group_public_key` binary(32) NOT NULL,
`group_id` varchar(64) COLLATE utf8_bin NOT NULL,
`name` varchar(64) COLLATE utf8_bin NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `transaction_send_coins`
--
CREATE TABLE `transaction_send_coins` (
`id` int(11) NOT NULL,
`transaction_id` int(11) NOT NULL,
`state_user_id` int(11) NOT NULL,
`receiver_public_key` binary(32) NOT NULL,
`receiver_user_id` varbinary(64) NOT NULL,
`amount` bigint(20) NOT NULL,
`sender_final_balance` bigint(20) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `transaction_signatures`
--
CREATE TABLE `transaction_signatures` (
`id` int(11) NOT NULL,
`transaction_id` int(11) NOT NULL,
`signature` binary(64) NOT NULL,
`pubkey` binary(32) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `transaction_types`
--
CREATE TABLE `transaction_types` (
`id` int(11) NOT NULL,
`name` varchar(24) COLLATE utf8_bin NOT NULL,
`text` varchar(255) COLLATE utf8_bin NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
--
-- Daten für Tabelle `transaction_types`
--
INSERT INTO `transaction_types` (`id`, `name`, `text`) VALUES
(1, 'creation', 'Aktives oder Bedingsungsloses Grundeinkommen.'),
(2, 'transfer', 'Einfache Überweisung');
--
-- Indizes der exportierten Tabellen
--
--
-- Indizes für die Tabelle `operators`
--
ALTER TABLE `operators`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `operator_types`
--
ALTER TABLE `operator_types`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `pending_transactions`
--
ALTER TABLE `pending_transactions`
ADD PRIMARY KEY (`id`),
ADD UNIQUE KEY `transactionID` (`transactionID`);
--
-- Indizes für die Tabelle `server_users`
--
ALTER TABLE `server_users`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `state_balances`
--
ALTER TABLE `state_balances`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `state_created`
--
ALTER TABLE `state_created`
ADD PRIMARY KEY (`id`),
ADD KEY `short_ident_hash` (`short_ident_hash`);
--
-- Indizes für die Tabelle `state_errors`
--
ALTER TABLE `state_errors`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `state_group_addresses`
--
ALTER TABLE `state_group_addresses`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `state_group_relationships`
--
ALTER TABLE `state_group_relationships`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `state_relationship_types`
--
ALTER TABLE `state_relationship_types`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `state_users`
--
ALTER TABLE `state_users`
ADD PRIMARY KEY (`id`),
ADD UNIQUE KEY `public_key` (`public_key`);
--
-- Indizes für die Tabelle `transactions`
--
ALTER TABLE `transactions`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `transaction_creations`
--
ALTER TABLE `transaction_creations`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `transaction_group_addaddress`
--
ALTER TABLE `transaction_group_addaddress`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `transaction_group_allowtrades`
--
ALTER TABLE `transaction_group_allowtrades`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `transaction_group_creates`
--
ALTER TABLE `transaction_group_creates`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `transaction_send_coins`
--
ALTER TABLE `transaction_send_coins`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `transaction_signatures`
--
ALTER TABLE `transaction_signatures`
ADD PRIMARY KEY (`id`);
--
-- Indizes für die Tabelle `transaction_types`
--
ALTER TABLE `transaction_types`
ADD PRIMARY KEY (`id`);
--
-- AUTO_INCREMENT für exportierte Tabellen
--
--
-- AUTO_INCREMENT für Tabelle `operators`
--
ALTER TABLE `operators`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `operator_types`
--
ALTER TABLE `operator_types`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=4;
--
-- AUTO_INCREMENT für Tabelle `pending_transactions`
--
ALTER TABLE `pending_transactions`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `server_users`
--
ALTER TABLE `server_users`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=2;
--
-- AUTO_INCREMENT für Tabelle `state_balances`
--
ALTER TABLE `state_balances`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=11;
--
-- AUTO_INCREMENT für Tabelle `state_created`
--
ALTER TABLE `state_created`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `state_errors`
--
ALTER TABLE `state_errors`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `state_group_addresses`
--
ALTER TABLE `state_group_addresses`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `state_group_relationships`
--
ALTER TABLE `state_group_relationships`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `state_relationship_types`
--
ALTER TABLE `state_relationship_types`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `state_users`
--
ALTER TABLE `state_users`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=7;
--
-- AUTO_INCREMENT für Tabelle `transactions`
--
ALTER TABLE `transactions`
MODIFY `id` bigint(20) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=2;
--
-- AUTO_INCREMENT für Tabelle `transaction_creations`
--
ALTER TABLE `transaction_creations`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=11;
--
-- AUTO_INCREMENT für Tabelle `transaction_group_addaddress`
--
ALTER TABLE `transaction_group_addaddress`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `transaction_group_allowtrades`
--
ALTER TABLE `transaction_group_allowtrades`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `transaction_group_creates`
--
ALTER TABLE `transaction_group_creates`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `transaction_send_coins`
--
ALTER TABLE `transaction_send_coins`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
--
-- AUTO_INCREMENT für Tabelle `transaction_signatures`
--
ALTER TABLE `transaction_signatures`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=2;
--
-- AUTO_INCREMENT für Tabelle `transaction_types`
--
ALTER TABLE `transaction_types`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=3;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;

75
docu/other/db/community_db.txt Normal file
View File

@ -0,0 +1,75 @@
operator_types
id name text
operators
id username operator_type_id data_base64
server_users
id username password email role activated last_login created modified
transaction_types
id name text
state_groups
varbinary(64)
id index_id name root_public_key user_count
address_types
id name text
state_group_addresses
id group_id public_key address_type
state_users
short
id index group_id public_key email first_name last_name
state_errors
id state_user_id transaction_type_id created message_json
state_balances
id state_user_id modified amount
state_relationship_types
id name text
(1 allow_trade "erlaubt Handel zwischen Gruppen")
state_group_relationships
id group1_id group2_id state_relationship_id
state_created
id transaction_id month year state_user_id created short_ident_hash
transaction_signatures
varbinary(64) varbinary(32)
id transaction_id signature pubkey
transactions
int64
id state_group_id transaction_type_id tx_hash received
transaction_send_coins
id transaction_id state_user_id receiver_public receiver_user_id amount sender_final_balance
transaction_group_allowtrades
id transaction_id remote_group_id allow
transaction_group_addAddress
id transaction_id address_type_id public_key
transaction_group_creates
id transaction_id group_public_key state_group_id name
transaction_creations
id transaction_id state_user_id amount ident_hash
mirror_nodes
id name ip port
group_mirror_nodes
id mirror_node_id group_id

143
docu/other/db/gradido_login.sql Normal file
View File

@ -0,0 +1,143 @@
-- phpMyAdmin SQL Dump
-- version 4.5.1
-- http://www.phpmyadmin.net
--
-- Host: 127.0.0.1
-- Erstellungszeit: 12. Nov 2019 um 10:13
-- Server-Version: 10.1.19-MariaDB
-- PHP-Version: 5.6.28
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
--
-- Datenbank: `gradido_login`
--
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `elopage_buys`
--
CREATE TABLE `elopage_buys` (
`id` int(11) NOT NULL,
`affiliate_program_id` int(11) NOT NULL,
`publisher_id` int(11) NOT NULL,
`order_id` int(11) NOT NULL,
`product_id` int(11) NOT NULL,
`product_price` int(11) NOT NULL,
`payer_email` varchar(255) NOT NULL,
`publisher_email` varchar(255) NOT NULL,
`payed` tinyint(1) NOT NULL,
`success_date` datetime NOT NULL,
`event` varchar(255) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `email_opt_in`
--
CREATE TABLE `email_opt_in` (
`id` int(11) NOT NULL,
`user_id` int(11) NOT NULL,
`verification_code` bigint(25) UNSIGNED NOT NULL,
`created` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `users`
--
CREATE TABLE `users` (
`id` int(11) NOT NULL,
`email` varchar(255) NOT NULL,
`first_name` varchar(150) NOT NULL,
`last_name` varchar(255) DEFAULT '',
`password` bigint(25) UNSIGNED NOT NULL,
`pubkey` binary(32) DEFAULT NULL,
`privkey` binary(80) DEFAULT NULL,
`created` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
`email_checked` tinyint(1) NOT NULL DEFAULT '0'
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `user_backups`
--
CREATE TABLE `user_backups` (
`id` int(11) NOT NULL,
`user_id` int(11) NOT NULL,
`passphrase` text NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
--
-- Indizes der exportierten Tabellen
--
--
-- Indizes für die Tabelle `elopage_buys`
--
ALTER TABLE `elopage_buys`
ADD PRIMARY KEY (`id`),
ADD UNIQUE KEY `order_id` (`order_id`);
--
-- Indizes für die Tabelle `email_opt_in`
--
ALTER TABLE `email_opt_in`
ADD PRIMARY KEY (`id`),
ADD UNIQUE KEY `verification_code` (`verification_code`);
--
-- Indizes für die Tabelle `users`
--
ALTER TABLE `users`
ADD PRIMARY KEY (`id`),
ADD UNIQUE KEY `email` (`email`);
--
-- Indizes für die Tabelle `user_backups`
--
ALTER TABLE `user_backups`
ADD PRIMARY KEY (`id`);
--
-- AUTO_INCREMENT für exportierte Tabellen
--
--
-- AUTO_INCREMENT für Tabelle `elopage_buys`
--
ALTER TABLE `elopage_buys`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=8;
--
-- AUTO_INCREMENT für Tabelle `email_opt_in`
--
ALTER TABLE `email_opt_in`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=16;
--
-- AUTO_INCREMENT für Tabelle `users`
--
ALTER TABLE `users`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=76;
--
-- AUTO_INCREMENT für Tabelle `user_backups`
--
ALTER TABLE `user_backups`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=37;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;

17
docu/other/db/login_db.txt Normal file
View File

@ -0,0 +1,17 @@
hedera_ids
id shardNum realmNum num
crypto_keys
id private_key public_key crypto_key_type_id
hedera_topics
id topic_hedera_id auto_renew_account_hedera_id auto_renew_period group_id admin_key submit_key current_timeout sequence_number updated
hedera_accounts
id user_id account_hedera_id account_key balance updated
groups
id alias name description
node_servers
id url port group_id server_type last_live_sign

20
docu/other/db/mirror_db.txt Normal file
View File

@ -0,0 +1,20 @@
groups
varbinary(64)
id index name public
transaction_signatures
varbinary(64) varbinary(32)
id transaction_id signature pubkey
transactions
int64
id group_id timestamp transaction_type_id hash received
transaction_bins
id transaction_id filename start size
state_created
id transaction_id month year short_ident_hash
Für mehr Performance, jeweils eine transactions, transaction_bins und transaction_signatures
Tabelle pro Gruppe

65
docu/other/db/operator_types.sql Normal file
View File

@ -0,0 +1,65 @@
-- phpMyAdmin SQL Dump
-- version 4.5.1
-- http://www.phpmyadmin.net
--
-- Host: 127.0.0.1
-- Erstellungszeit: 16. Sep 2019 um 10:07
-- Server-Version: 10.1.19-MariaDB
-- PHP-Version: 5.6.28
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
--
-- Datenbank: `cake_gradido_node`
--
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `operator_types`
--
CREATE TABLE `operator_types` (
`id` int(11) NOT NULL,
`name` varchar(25) COLLATE utf8_bin NOT NULL,
`text` varchar(255) COLLATE utf8_bin NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
--
-- Daten für Tabelle `operator_types`
--
INSERT INTO `operator_types` (`id`, `name`, `text`) VALUES
(1, 'hedera', 'Hedera Keys for sign and pay hedera transactions'),
(2, 'gradido-user', 'default gradido user keys'),
(3, 'gradido-group', 'default gradido group root keys, other address are derived');
--
-- Indizes der exportierten Tabellen
--
--
-- Indizes für die Tabelle `operator_types`
--
ALTER TABLE `operator_types`
ADD PRIMARY KEY (`id`);
--
-- AUTO_INCREMENT für exportierte Tabellen
--
--
-- AUTO_INCREMENT für Tabelle `operator_types`
--
ALTER TABLE `operator_types`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=4;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;

58
docu/other/db/operators.sql Normal file
View File

@ -0,0 +1,58 @@
-- phpMyAdmin SQL Dump
-- version 4.5.1
-- http://www.phpmyadmin.net
--
-- Host: 127.0.0.1
-- Erstellungszeit: 17. Sep 2019 um 10:00
-- Server-Version: 10.1.19-MariaDB
-- PHP-Version: 5.6.28
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
--
-- Datenbank: `cake_gradido_node`
--
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `operators`
--
CREATE TABLE `operators` (
`id` int(11) NOT NULL,
`username` varchar(50) COLLATE utf8_bin NOT NULL,
`user_pubkey` binary(32) NOT NULL,
`data_base64` varchar(255) COLLATE utf8_bin NOT NULL,
`modified` datetime NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
--
-- Indizes der exportierten Tabellen
--
--
-- Indizes für die Tabelle `operators`
--
ALTER TABLE `operators`
ADD PRIMARY KEY (`id`);
--
-- AUTO_INCREMENT für exportierte Tabellen
--
--
-- AUTO_INCREMENT für Tabelle `operators`
--
ALTER TABLE `operators`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;

13
docu/other/db/server_users.sql Normal file
View File

@ -0,0 +1,13 @@
CREATE TABLE `server_users` (
`id` int(11) NOT NULL,
`username` varchar(50) COLLATE utf8_bin NOT NULL,
`password` varchar(255) COLLATE utf8_bin NOT NULL,
`email` varchar(50) COLLATE utf8_bin NOT NULL,
`role` varchar(20) COLLATE utf8_bin NOT NULL DEFAULT 'admin',
`activated` tinyint(1) NOT NULL DEFAULT '0',
`last_login` datetime DEFAULT NULL,
`created` datetime NOT NULL,
`modified` datetime NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

7
docu/other/db/state_balances.sql Normal file
View File

@ -0,0 +1,7 @@
CREATE TABLE `state_balances` (
`id` int(11) NOT NULL,
`state_user_id` int(11) NOT NULL,
`modified` datetime NOT NULL,
`amount` bigint(20) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

10
docu/other/db/state_created.sql Normal file
View File

@ -0,0 +1,10 @@
CREATE TABLE `state_created` (
`id` int(11) NOT NULL,
`transaction_id` int(11) NOT NULL,
`month` tinyint(4) NOT NULL,
`year` smallint(6) NOT NULL,
`state_user_id` int(11) NOT NULL,
`created` datetime NOT NULL,
`short_ident_hash` int(11) NOT NULL,
PRIMARY KEY (`id`), INDEX(`short_ident_hash`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

7
docu/other/db/state_group_addresses.sql Normal file
View File

@ -0,0 +1,7 @@
CREATE TABLE `state_group_addresses` (
`id` int(11) NOT NULL,
`state_group_id` int(11) NOT NULL,
`public_key` binary(32) NOT NULL,
`address_type_id` int(11) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

7
docu/other/db/state_group_relationships.sql Normal file
View File

@ -0,0 +1,7 @@
CREATE TABLE `state_group_relationships` (
`id` int(11) NOT NULL,
`state_group1_id` int(11) NOT NULL,
`state_group2_id` int(11) NOT NULL,
`state_relationship_id` int(11) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

8
docu/other/db/state_groups.sql Normal file
View File

@ -0,0 +1,8 @@
CREATE TABLE `state_groups` (
`id` INT NOT NULL AUTO_INCREMENT,
`index_id` VARBINARY(64) NOT NULL,
`name` VARCHAR(50) NOT NULL,
`root_public_key` BINARY(32) NOT NULL,
`user_count` SMALLINT NOT NULL DEFAULT '0',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

6
docu/other/db/state_relationship_types.sql Normal file
View File

@ -0,0 +1,6 @@
CREATE TABLE `state_relationship_types` (
`id` int(11) NOT NULL,
`name` varchar(25) COLLATE utf8_bin NOT NULL,
`text` varchar(255) COLLATE utf8_bin DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

7
docu/other/db/state_users.sql Normal file
View File

@ -0,0 +1,7 @@
CREATE TABLE `state_users` (
`id` int(11) NOT NULL,
`index_id` smallint(6) NOT NULL,
`state_group_id` int(11) NOT NULL,
`public_key` binary(32) NOT NULL,
PRIMARY KEY (`id`);
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

10
docu/other/db/transaction_creations.sql Normal file
View File

@ -0,0 +1,10 @@
CREATE TABLE `transaction_creations` (
`id` int(11) NOT NULL,
`transaction_id` int(11) NOT NULL,
`state_user_id` int(11) NOT NULL,
`amount` bigint(20) NOT NULL,
`ident_hash` binary(32) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

8
docu/other/db/transaction_group_addAddress.sql Normal file
View File

@ -0,0 +1,8 @@
CREATE TABLE `transaction_group_addaddress` (
`id` int(11) NOT NULL,
`transaction_id` int(11) NOT NULL,
`address_type_id` int(11) NOT NULL,
`public_key` binary(32) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

8
docu/other/db/transaction_group_allowtrades.sql Normal file
View File

@ -0,0 +1,8 @@
CREATE TABLE `transaction_group_allowtrades` (
`id` int(11) NOT NULL,
`transaction_id` int(11) NOT NULL,
`group_id` int(11) NOT NULL,
`allow` tinyint(1) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

9
docu/other/db/transaction_group_creates.sql Normal file
View File

@ -0,0 +1,9 @@
CREATE TABLE `transaction_group_creates` (
`id` int(11) NOT NULL,
`transaction_id` int(11) NOT NULL,
`group_public_key` binary(32) NOT NULL,
`state_group_id` int(11) COLLATE utf8_bin NOT NULL,
`name` varchar(64) COLLATE utf8_bin NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

11
docu/other/db/transaction_send_coins.sql Normal file
View File

@ -0,0 +1,11 @@
CREATE TABLE `transaction_send_coins` (
`id` int(11) NOT NULL,
`transaction_id` int(11) NOT NULL,
`state_user_id` int(11) NOT NULL,
`receiver_public_key` binary(32) NOT NULL,
`receiver_user_id` varbinary(64) NOT NULL,
`amount` bigint(20) NOT NULL,
`sender_final_balance` bigint(20) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

7
docu/other/db/transaction_signatures.sql Normal file
View File

@ -0,0 +1,7 @@
CREATE TABLE `transaction_signatures` (
`id` int(11) NOT NULL,
`transaction_id` int(11) NOT NULL,
`signature` binary(64) NOT NULL,
`pubkey` binary(32) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

6
docu/other/db/transaction_types.sql Normal file
View File

@ -0,0 +1,6 @@
CREATE TABLE `transaction_types` (
`id` INT NOT NULL AUTO_INCREMENT,
`name` VARCHAR(24) NOT NULL,
`text` VARCHAR(255) NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

9
docu/other/db/transactions.sql Normal file
View File

@ -0,0 +1,9 @@
CREATE TABLE `transactions` (
`id` bigint(20) NOT NULL,
`state_group_id` int(11) NOT NULL,
`transaction_type_id` int(11) NOT NULL,
`tx_hash` binary(32) NOT NULL,
`received` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

1
docu/other/einhornimmond working temp/Container.txt Normal file
View File

@ -0,0 +1 @@
https://multipass.run

16
docu/other/einhornimmond working temp/Fragen.txt Normal file
View File

File diff suppressed because one or more lines are too long

BIN
docu/other/einhornimmond working temp/Frontend_stage1.odt Normal file
View File

Binary file not shown.

BIN
docu/other/einhornimmond working temp/Hedera Related Work.odt Normal file
View File

Binary file not shown.

BIN
docu/other/einhornimmond working temp/MVP_Breakdown.odt Normal file
View File

Binary file not shown.

1
docu/other/einhornimmond working temp/Notizen.txt Normal file
View File

@ -0,0 +1 @@
Systemisches Konsensieren

BIN
docu/other/einhornimmond working temp/PreHederaKonzept.odt Normal file
View File

Binary file not shown.

BIN
docu/other/einhornimmond working temp/TODO.odt Normal file
View File

Binary file not shown.

BIN
docu/other/einhornimmond working temp/Transaktionsarten.odt Normal file
View File

Binary file not shown.

BIN
docu/other/einhornimmond working temp/WebAppClient.odt Normal file
View File

Binary file not shown.

BIN
docu/other/einhornimmond working temp/debugging/gn_debugging.zip Normal file
View File

Binary file not shown.

BIN
docu/other/einhornimmond working temp/debugging/staging1.0.block Normal file
View File

Binary file not shown.

BIN
docu/other/einhornimmond working temp/debugging/transaction_log_base64.txt Normal file
View File

Binary file not shown.

148
docu/other/einhornimmond working temp/debugging/transactions_log.txt Normal file
View File

@ -0,0 +1,148 @@
22.12.20 13:07:47
{
"sigMap": {
"sigPair": [
{
"pubKey": "qqBtMhHTLoUg6mXsedlD7O5GHbfsIE1VIpoq7eYQgZA=",
"ed25519": "cugS2Ero8Zu6y1fu1LCTByXtLVzSrsWyCp3r0s7m0+GbmxTGjUT9EnI83xiFsZJVPOO2QNzLy0Jz8ECIz4qdAg=="
}
]
},
"bodyBytes": {
"memo": "",
"versionNumber": "0",
"groupMemberUpdate": {
"userPubkey": "qqBtMhHTLoUg6mXsedlD7O5GHbfsIE1VIpoq7eYQgZA=",
"memberUpdateType": "ADD_USER",
"targetGroup": "staging1"
}
}
}
22.12.20 13:11:45
{
"sigMap": {
"sigPair": [
{
"pubKey": "xd+K1LQHl1ehSYg5A87brkqyhOqlF8x1umOf9WOKJns=",
"ed25519": "Bg9WsvU03d12YClE1mGmRoh9SVeKIxJI3ruI782WatLYM/KR8yPW32U8Ct72r54qf+u0/+HAxKI+yhOY5PktCw=="
},
{
"pubKey": "qqBtMhHTLoUg6mXsedlD7O5GHbfsIE1VIpoq7eYQgZA=",
"ed25519": "4WTB/NEca48JfX4wKGDeCUdJFyEj60pplWWg59E1p7eYP9jR7vlWS4+UTLHYnRLFJVVBgVmehn3nl0KoVoSEBA=="
}
]
},
"bodyBytes": {
"memo": "",
"versionNumber": "0",
"groupMemberUpdate": {
"userPubkey": "xd+K1LQHl1ehSYg5A87brkqyhOqlF8x1umOf9WOKJns=",
"memberUpdateType": "ADD_USER",
"targetGroup": "staging1"
}
}
}
22.12.20 13:13:00
{
"sigMap": {
"sigPair": [
{
"pubKey": "qqBtMhHTLoUg6mXsedlD7O5GHbfsIE1VIpoq7eYQgZA=",
"ed25519": "pJxQiSBQCiFkzu6dKfhCsfMis1UA1thzhpE4PMWR+z7Kqdjf5RZ14TFstD270fuK9QVjBubqokxFCnPBXqZdBA=="
}
]
},
"bodyBytes": {
"memo": "test AGE 1",
"versionNumber": "0",
"creation": {
"receiver": {
"pubkey": "xd+K1LQHl1ehSYg5A87brkqyhOqlF8x1umOf9WOKJns=",
"amount": "10000000"
},
"targetDate": {
"seconds": "1604188800"
}
}
}
}
========= removed blockchain, restarted gradido node ======================
22.12.20 13:15:35
{
"sigMap": {
"sigPair": [
{
"pubKey": "qqBtMhHTLoUg6mXsedlD7O5GHbfsIE1VIpoq7eYQgZA=",
"ed25519": "qVGOxSPYJPJSt7EFkvG/BpZC7eeQDna5ryZM0upLDuuZXg6VH2mRKW8r7EHRcvie/G/OMdB0wNYLFGmPbwUPAQ=="
}
]
},
"bodyBytes": {
"memo": "AGE2 TEST",
"versionNumber": "0",
"creation": {
"receiver": {
"pubkey": "xd+K1LQHl1ehSYg5A87brkqyhOqlF8x1umOf9WOKJns=",
"amount": "10000000"
},
"targetDate": {
"seconds": "1604188800"
}
}
}
}
22.12.20 13:19:28
{
"sigMap": {
"sigPair": [
{
"pubKey": "xd+K1LQHl1ehSYg5A87brkqyhOqlF8x1umOf9WOKJns=",
"ed25519": "PFaU4UAbnsKDmX3E3nsbo4efLb8NsVCYWK5xPhJqUZbQrhj3Bw1YCBgMb7s7JEcWW/10t1+TS6CEvtbKeNAPCQ=="
}
]
},
"bodyBytes": {
"memo": "test transfer 2 shasadsa",
"versionNumber": "0",
"transfer": {
"local": {
"sender": {
"pubkey": "xd+K1LQHl1ehSYg5A87brkqyhOqlF8x1umOf9WOKJns=",
"amount": "1000100"
},
"receiver": "qqBtMhHTLoUg6mXsedlD7O5GHbfsIE1VIpoq7eYQgZA="
}
}
}
}
22.12.20 13:21:50
{
"sigMap": {
"sigPair": [
{
"pubKey": "xd+K1LQHl1ehSYg5A87brkqyhOqlF8x1umOf9WOKJns=",
"ed25519": "AD87aOAVS/OZjX9kgPsdDPOlKAggtWEqHETmxNGJyB3CHBNiNr+fyH/S10+8A3jd8KOW1ACyiu+GChUCN0q8DA=="
}
]
},
"bodyBytes": {
"memo": "test aslkdjaslkd alksdj lasdkkdlsaldjk alsakdj ",
"versionNumber": "0",
"transfer": {
"local": {
"sender": {
"pubkey": "xd+K1LQHl1ehSYg5A87brkqyhOqlF8x1umOf9WOKJns=",
"amount": "1000000"
},
"receiver": "qqBtMhHTLoUg6mXsedlD7O5GHbfsIE1VIpoq7eYQgZA="
}
}
}
}

BIN
docu/other/einhornimmond working temp/en_Voting.odt Normal file
View File

Binary file not shown.

11
docu/other/einhornimmond working temp/entwurf/cross-group-login.txt Normal file
View File

@ -0,0 +1,11 @@
Login-Server login
if group_id != 0
call group_server and send access-token, client ip
community server
state_login_server_access
id access_code client_ip created
2.
state_user/login?session_id=<session_id>
return 404 if unknown than fail2ban work

BIN
docu/other/einhornimmond working temp/gdd1.0.block Normal file
View File

Binary file not shown.

35
docu/other/elopage/db.txt Normal file
View File

@ -0,0 +1,35 @@
gdt_entries
id amount date email comment coupon_code gdt_entry_type_id factor amount2 factor2
gdt_entry_types
id name description
gdt_entries_elopage_transactions
id gdt_entry_id elopage_transaction_id
gdt_entries_elopage_transactions_publishers
id gdt_entry_id elopage_transaction_id publisher_id publisher_deep
publishers
id first_name last_name email
contacts
id first_name last_name email publisher_id
contact_emails
id contact_id email
validate_contacts
id first_name last_name email
elopage_transactions
// not unique
id order_id email publisher_id amount fee revenue vat_rate vat_amount coupon_code created_date created_at success_date event action payment_state
elopage_comments
id body date sender_first_name sender_last_name discussion_name product_id
users
id username password

91
docu/other/gradido-distributed-overhaul.md Normal file
View File

@ -0,0 +1,91 @@
\--- in short
\- system becomes as distributed as possible
* gradido transfers are not routed via login server
* all parts are open-sourced
* ofc, not main private key, not user database
* added benefit of probably having open source development going on
* there always can be some more things to add; we can allow ppl to
do anything in unverified network
* unverified-with-gradido-organization groups and transactions can do
whatever they want
\- two levels of gradido
* verified with gradido organization
* unverified (or verified with other entities)
\- login server disappears (or is "reprofiled" big time)
* instead, we have services which would offer authorised signatures
for various transactions
* new group in group blockchain
* group update (becoming verified)
* befriending verified groups
* adding / moving user inside verified group
* probably will use some 3rd party services for that
* multiple strategies
* visual ID card photos
* face photos
* "invited by" trusted person
* creating gradidos inside verified group
* those transactions would be sent to hedera by community server
* which implies community server holds submit key
* which in turn implies there has to be a certain level of security
* those signatures have a semantics of "gradido organization authorizes
this or that transaction"; it doesn't guarantee any success; some
transactions may take signatures other parties
* some of those services may take days to return result
* for "unverified" gradido community server + node server those
services are not needed
\- community server
* accesses hedera + node servers directly
* therefore, it keeps hedera submitKey to itself
* hbar payment is done through there
* knows about node servers, their endpoints
\- users keep private keys to themselves
* less risk with someone attacking and compromising them
* check "questions" section, though
\- so, gradido organization provides:
* signature services for verified (need to pick a better word? more
like gradido-organization-verified) transactions
* open-sourced node + community server
* setup instructions
* maybe scripts
* maybe already deployed components with whom to start
* community server? nodes?
* for unverified as well, to promote popularity?
\- questions
* multiple group chains are possible; should they be supported?
* which would mean multiple authorities (same like gradido
organization)
* who administrates community server? hedera submitKey is located there
* also, hedera account in mainnet requires a person which is verified
with them
* there has to be some "admins" therefore
* maybe could still have a "standalone login server" which would
keep the keys in encrypted format for users, without doing anything
else
* it is not that important; main thing is to decide overall system
design

114
docu/other/gradido_login_server.ger.md Normal file
View File

@ -0,0 +1,114 @@
# Login Server
## Hauptaufgabe
Sicheres Verwahren der private Keys.
Die Private Keys werden mit E-Mail und Passwort verschlüsselt gespeichert, sodass nur der Benutzer selbst Zugang zu seinem Private Key hat und damit Transaktionen signieren kann.
Um einem Datenverlust vorzubeugen wird dem Benutzer beim Konto anlegen eine Passphrase angezeigt, aus welcher der Seed für die Private Key Generierung berechnet wird.
Da nicht alle Nutzer sich die Passphrase notieren, wird sie noch als Backup gespeichert, ebenfalls verschlüsselt. Sie soll mit dem Public Key des Server-Admin-Keys verschlüsselt werden, so dass nur der private-key Besitzer die Passphrase entschlüsseln und bei Bedarf an den Benutzer senden kann. Ursprünglich hatte ich die Idee die Daten noch zusätzlich mit einem symmetrischen Server-Key zu verschlüsseln aber ich glaube nicht das es die Sicherheit weiter steigern kann.
## Technik
### Poco
Es wird C++ verwendet zusammen mit der Poco Bibliothek. Sie ist dafür entwickelt Netzwerk- und Internetbasierte C++ Programme zu unterstützen.
Sie bringt u.a. HTTP und HTTPS Server und Clients mit, Multithreading, SMTP und Datenbankzugriff.
### Crypto
Für die cryptografischen Funktionen wird libsodium verwendet sowie eine modifizierte iroha-ed25519 Bibliothek. Sie benutzt für ihre random Function den gleichen Namen wie libsodium, daher ist dies in der modifizierten Version auskommentietr.
Die iroha-ed25519 wird verwendet da die ed25519 Signaturen von libsodium nicht mit Hedera Hashgraph kompatibel sind.
### Mysql
Für die Datenbank wird mariadb verwendet. Dies ist eine Weiterentwicklung von mysql vom ursprünglichen Gründer, welches performanter läuft als mysql.
Für den Verbindungsaufbau wird der mariadb-connector-c benutzt und eine leicht modfizierte Version der mysql Klassen von Poco. Sie befinden sich direkt im Quellcode Verzeichnis.
### Passphrase
Die Wörter der Passphrase wollte ich ungern im Klartext im Binary speichern, daher sind sie komprimiert. Um sie zu entpacken wird **tinf** verwendet.
### Localization
Für die Übersetzung wird spirit-po benutzt welche das Standard po Format versteht und einliest.
spirit-po setzt auf boost libs was dazu führt das zum kompilieren mehr als 1 GB Arbeitsspeicher verfügbar sein muss.
### Protobuf
Um die Transaktionen entpacken zu können wird auch protobuf benötigt und der entsprechende Compiler in der gleichen Version. Im git-Repository werden nur die protobuf Messages gespeichert, nicht die daraus kompilierten C++-Klassen.
### Build-System
Als Build-System kommt CMake in Verbindung mit Conan zum Einsatz.
Damit lassen sich einfach Makefiles oder Projectfiles (z.B. für Visual Studio) für verschiedene Plattformen generieren.
Conan ist ein Packetmanager für C++ Bibliotheken, ist aber noch nicht so ausgereift.
## Architektur
Es wird als Orientierung grob das MVC System verwendet.
Modelle werden für alles verwendet was mit Daten zu tun hat.
Zum Beispiel zum Abbilden der Daten aus der Datenbank oder auch für die E-Mails.
Controller werden verwendet für die die Funktionen die auf Daten basieren.
Der View gliedert sich in HTTPInterface und JSONInterface und definiert wie die Daten nach außen gebracht werden. Für jeden HTTP oder Json Request wird dabei ein eigener Thread aus einem Threadpool verwendet.
Das HTTPInterface enthält darüber hinaus auch den Workflow der Benutzer Prozesse wie neues Konto erstellen oder Passwort zurücksetzen.
SingletonManager enthält alle Klassen welche als Singleton definiert sind und sich um Verwaltungsaufgaben kümmern, die den gesamten Server betreffen.
In Crypto befinden sich alle Klassen die sich mit Verschlüsseln und der Passphrase beschäftigen.
In lib befinden sich kleine eigenständige Klassen, zum Teil aus anderen Projekten.
In tasks befinden sich alle Klassen die mit dem CPU Scheduler zu tun haben der einzelne Aufgaben in Form von Tasks von verschiedenen Worker-Threads abarbeiten lässt. Es soll die Reaktionszeit des Servers erhöhen um einer Überlastung vorzubeugen. Aufgaben deren Ergebnis der Benutzer nicht oder nicht unmittelbar benötigt werden im Hintergrund weiter ausgeführt, während der Benutzer schon eine Rückmeldung erhält und schon was anderes machen kann.
test enthält Unit-Test um einzelne Teile automatisch testen zu können.
## Session-Management
Der SessionManager speichert alle aktuellen Sessions im Arbeitsspeicher und ist eine Singleton-Klasse.
Das Session-Objekt enthält vor allem den Benutzer. Im Augenblick in doppelter Ausführung, da ich dabei bin das Benutzer-Objekt zu überarbeiten.
Die neue Version ist stärker Objektorientiert aufgebaut.
Das Session Objekt behält noch laufende Transaktionen des Benutzers im Blick.
Die meisten Interface-Funktionen holen sich zu erst die aktuelle Session über die session_id die im Session-Cookie gespeichert ist.
Das Session-Objekt wird zurückgesetzt wenn es nicht mehr benötigt wird (timout oder logout) und bekommt eine neue Session id.
Ich habe an manchen Stellen Objekte recycelt um die Speicherfragmentierung auf ein minimum zu halten. Denn der Login-Server soll ja dauerhaft laufen.
## HTTP-Interface
Arbeitet mit cpsp Dateien, das sind C++-Server-Pages.
Diese sind im Ordner src/cpsp zu finden.
Poco hat einen Compiler der dafür der daraus C++ Klassen macht.
Die compilierten C++-Server-Pages sind im Ordner src/cpp/HTTPInterface zu finden und sind im git-Repository eingecheckt.
Der zentrale Einstiegspunkt bei jedem HTTP-Request ist die Klasse PageRequestHandlerFactory.
Hier findest das Routing statt in der Funktion createRequestHandler.
## New User
HTTPInterface: RegisterPageDirect
- Benutzer in Datenbank speichern
- Passphrase generieren
- Schlüssel generieren
- auf Community Server kopieren (push)
Datenbank anpassen:
- bool hinzufügen für Benutzer Passphrase gezeigt
Community Server:
- JsonRequestHandler erweitern um addUser | eigentlich müsste es auch so gehen, denn nach dem redirect auf den Community Server kopiert der sich ja den Benutzer.
- eintragen bei Klick Tipp
**Hinweis**: Im Augenblick ist die Passhrase noch nicht verschlüsselt gespeichert, kann also jederzeit abgerufen werden.
Wenn sie verschlüsselt gespeichert wird, ändert sich die Abfrage und das Passwort zurücksetzen, weil da vorher ein Admin die Passphrase freigeben muss (sein Privat Key eingeben, damit sie entschlüsselt werden kann) und dann wird sie im Arbeitsspeicher gehalten bis sie benötigt wird oder der Server neugestartet wurde.
## Bestehende Benutzer
Beim einloggen prüfen ob ein public key vorhanden, sonst generieren
Auch wenn sie über Email verification code sich einloggen
Setze Wert für passphrase_shown auf 1 falls es einen Eintrag in user_backups gibt.
## Transaktion
Gradidos können erst versendet werden, wenn die E-Mail bestätigt wurde.
In Transfer prepare also prüfen ob die E-Mail aktiviert ist und wenn nicht eine Fehlermeldung anzeigen. Den Signieren Knopf ausblenden und die Aktion Serverseitig nicht zulassen.
Beim neuladen neu prüfen, eventuell hat der Benutzer in der Zwischenzeit sein Konto aktiviert.

33
docu/other/gradido_node.ger.md Normal file
View File

@ -0,0 +1,33 @@
# Gradido Node
Zweite Schicht von Gradido, die Blockchain, verwaltet durch Gradido Node Server.
Es sollte mehrere Gradido Node Server für jede Gruppe geben.
Dabei kann ein Gradido Node Server problemlos für mehrere Gruppen zuständig sein.
Oberste Priorität: Performance, lauffähig auf kleinen Servern, z.B. Mini-VPS oder Raspberry Phi ähnlichen Computern, und Super-Nodes die viele oder sogar alle Gruppen betreuen können
## Node Synchronisieren
Da Hedera die Nachrichten nur für kurze Zeit zur Verfügung stellt, müssen neue Nodes erstmal die bisherigen Transaktionen anfragen, wie bei Bitcoin und Co.
Dazu fragen sie bei benachbarten Gradido Node Servern die Transaktionen ab.
Benachbart heißt in diesem Fall das sie für dieselben Gruppen zuständig sind.
## Transaktionen empfangen
Der Gradido Node empfängt die Transaktionen aus dem Hedera Netzwerk über Mirror-Server.
Er lauscht auf alle Hedera Consensus Topics die mit die für ihn registrierten Gradido Gruppen übereinstimmen. Er überprüft die Transaktion und speichert sie dann auf der Festplatte ab.
## Transaktionen überprüfen
Insbesondere für die Überprüfung der Schöpfungstransaktionen kann es einiges zu tun geben, denn es müssen alle Transaktionen mit dem gleichen IdentHash aus dem gleichen Monat überprüft werden.
## Transaktionen speichern
Die im Protobuf format überreichten Transaktionen werden serialisiert und die aktuelle Block Datei der Gruppe für die die Transaktion war, geschrieben.
Für alle Public Keys für die es noch keine kto index Einträge gibt, werden welche angelegt.
Ein Eintrag im Block Index wird angelegt.
## Transaktionen zur Verfügung stellen
Er stellt via jsonrpc ein schnelles Interface zum durchsuchen der Blockchains zur Verfügung damit der Community-Server effizient auf alle Transaktionen zugreifen kann, die für ihn interessent sind.
Nur eine Verbindung pro IP zulassen um DDos angreifern das Leben schwer zu machen.
[Slow Loris](http://en.wikipedia.org/wiki/Slowloris) Bekämpfen (Timeout für partiale HTTP-Requests)

9
docu/other/identity.md Normal file
View File

@ -0,0 +1,9 @@
# Identity
## Birth hash
- every human should have the possibility to get a active or passive basic income in Gradido
- but only once per human
- identify human by birth-hash containing first name, birth name, birth date, birth city, birth country, first and birth name from mother and father
- humans with missing names for vather and/or mother and later discover get an new birth hash, invalidate the old one
- check by new birth hash, if similar hash without parents exist (without both, without father, without mother)

48
docu/other/login_server_community_server_communication.md Normal file
View File

@ -0,0 +1,48 @@
# Login Server – Community Server - Communication
Register account take place on Login-Server HTTP Form or via webhook called from elopage every time someone make a donation to Gradido.
By webhook call check if account for email exist, if not create account and send email verification code to user.
Emails are sended via SMTP.
By visiting checkEmail Page with valid email verification code, check if user has already a password, if not (if he was auto-registered via webhook) ask for password.
After that or by first login and user hasn't key pair: generate ed25519 key pair and save the private key encoded with user password and email in db, save public key in db, save passphrase in db.
In Future, passphrase must be encrypted with server admin public key, so only server admin can decyrpt saved passphrase, if user has forgetten it. Maybe different server admins, one for technical, other for decyrpt passphrases.
Save Login-Cookie after login was successfully.
After login, redirect to community-server dashboard.
Community Server use Login Cookie from Login-Server to get data for logged in user.
He call via Json HTTP Request in Community Server src/Controller/AppController::requestLogin with this line: $response = $http->get($url . '/login', ['session_id' => $session_id]);
If user will transfer Gradidos Community Server create transaction, send it to Login-Server and then redirect user to login-server checkTransaction Page for signing transaction. In Future it will check if current ip is the same as by login and ask for password, if some time passed by since the last time.
After user has checked Transaction and click on sign, currently Login-Server sends signed transaction back to Community-Server. But in Future he will send it to Hedera and Community Server get the infos about success async from his registered nodes servers.
For that Community Server should get a ping request every minute from login-server and with that ask at least one node server for new transactions, sending him the last transaction nr he knows.
If admin will create GDDs he can not only create one transaction at a time, he can also create some in a row and than go to checkTransaction Page on Login-Server an sign them one after another.
If user change his first name, last name or language on community server it will be send to Login-Server.
If user like to change his passwort he will redirected to passwort change page on Login-Server.
In Future he should be also checked the ip and how long user has tipped in his password and ask maybe again, if it was to long.
On Konto -Overview the Community Server ask also the GDT Server for current GDT balance of user (identified by email).
Much later we need a way to get GDT balance in Blockchain, because user can exchange there GDT for GDD, but only to some extends, rules will be clarified later. For example depending on GDD Sum in Group, not more than 1% of GDD Sum per user per month or whatever.
Login Server use a http-Server on Port 1200 and a additional http-Server for json request on default port 1201. Currently Configured that nginx forward every request starting with /account to port 1200.
Community Server call Login-Server via Port 1201.
The Interface from Login-Server which can be called from Community-Server lives in Login-Server: src\cpp\JSONInterface\*
Starting with JsonRequestHandlerFactory.cpp you see which functions can be called.
login: return currently logged in user with public key and other data
checkTransaction: send transaction for signing from community server to Login Server, only TransactionBody
getRunningUserTasks: return count of pending transactions for user to sign, or in processing
getUsers: (only for admin) search for user first_name or last_name or email
createUser: (only for admin) create user from admin, user gets email verification email with differnet text as by registered via webhook
adminEmailVerificationResend: (only for admin) trigger resend of email verification email for target user
getUserInfos: get specific infos about user choosen by ask parameter
updateUserInfos:update first_name and/or last_name, and/or language, and/or disabled
The Interface from Community-Server which can be called from Login-Server lives in
Community-Server src/Controller/JsonRequestHandlerController.php
Functions are:
putTransaction: Login-Server send signed transaction to Login-Server, will later be removed, after transaction go over hedera
moveTransaction: Create Transfer Transaction, only used from RepairDefectPassphrase in Login-Server HTTP-Interface
checkUser: check if Community Servers knows user (email and last_name are same)
getUsers: return uses paginated for GDT-Server
getUserBalance: get user balance for user
errorInTransaction: called from login server if transaction he has get couldn't decoded

7
docu/other/login_server_hedera.md Normal file
View File

@ -0,0 +1,7 @@
# Login Server and Hedera
Login Server should be the part of the system which sends the most if not every message to hedera which should go over hedera.
To use Consensus Service topic IDs a needed, so Login Server should also manage Hedera Topic IDs.
For every group there is a topic id and also one global topic id for the whole gradido network for alias and birth hash blockchain.
Topic id must be created and they didn’t exist until end of days, for the existence there must be paid with Hedera Hashbars. So Login Server must update topics regulary with funded hedera accounts.
And maybe it is good if it can also show the current state of topic id, how long they paid and how many hashbars left on account. But every get balance request cost also hashbars.

63
docu/other/mvp_group_transaction.ger.md Normal file
View File

@ -0,0 +1,63 @@
# MVP transaction from one group to another
## All the things that are needed if I it should go according to my plan
### Login-Server:
- [x] Create user
- [x] Check user email
- [x] Generate key pair for users
- [x] Private Key encrypted with user save password
- [-] Store passphrase encrypted with Server Admin Key, if user forgets password (currently stored unencrypted)
- [ ] Transaction to associate users with group
- [ ] Create transaction that links email to user-account/key pair
- [-] Create group and Hedera Topic and communicate to the node server
- [ ] Send users to the right community server depending on the group
- [x] enter existing Hedera account optionally encrypted/unencrypted
- [-] create new Hedera account as payment account for transactions
- [ ] implement cross-group transaction missing
### Community-Server
- [x] Gradidos creation by privileged person
- [x] general transfer interface
- [x] Listing transactions
- [ ] Friend with other group (transaction on block chain)
- [ ] View current configuration of other groups
- [ ] public key of a user of another group to find the e-mail
- [ ] regular querying of transactions from one or more node servers
- [ ] implement cross-group transaction
### Node-Server
- Create blockchains for each group/topic
- receive and store Hedera's transactions per group/topic
- verify transactions
- Query for users of another group via email hash
- Providing an interface for the Community Server to query the transactions
- Synchronization with other node servers
- Find other node servers via special Hedera transaction
Design the format of the cross-group transaction in detail, or check Paul's variant to see if it is suitable
## A variant for quick success
### Login-Server
- Install cross-group transaction
- Save your main Hedera account as a payment account unencrypted, I would only provide my Testnet account for this
### Communtiy-Server
- manual querying of transactions from the node server by button
- Implement cross-group transaction
- Save login server of other groups in config
- Request for publickey to e-mail simply to all known login servers with existing interface
### Node-Server
- Providing an interface for the community server to query the transactions
- Manual creation of the group (e.g. json-config)
- Creating a topic with Paul's python script
- Design the format of the cross-group transaction in detail, or check Paul's variant to see if it is suitable
- Set up a separate login server for each group
- Node servers must not fail, as Hedera saves each message for a maximum of 10 minutes

27
docu/other/node/FileFormat.txt Normal file
View File

@ -0,0 +1,27 @@
group.index // txt file poco propertie format
group hash = folder name (group_1 -> ...) uint32
group_folder
// binary, konto hash = kto index uint32 (first in transaction, getting 1), sorted by hash
// hash at end of file
// sort in memory, file is unordered, maybe for small files linear search is faster
// put last used in cache
pubkeys_<first hash byte hex>
_<second hash byte hex>.index
// contain group states
// like last kto index
// using leveldb
.state
// lowest kto index, highest kto index
// kto index = count, [file positions where transaction which contain kto starts]
// sorted
// write out after block finished, until than exist only in memory
// hash at end
blk0000000X.index
// size, serialized transaction [loop]
// hash at end
blk0000000X.data

15
docu/other/node/SizeCalculations.txt Normal file
View File

@ -0,0 +1,15 @@
522 Billion Transactions cash per year
726 Billion Transactions online per year
Summe: 3,5 Billion Transaction per day
200 Byte per Transaction
= 651,925 GByte per Day
~ 8 Billion Humans on Earth
~ 134 MB per Block File/ ~ 700.000 Transaction per Block File
~ 5.000 Block Files per Day
~ 1.780.000 Block Files per Year
~ 2.412 years until uint32 block nr overflow

5
docu/other/node/entwurf.txt Normal file
View File

@ -0,0 +1,5 @@
get pubkey index per group
cache in group?
ask pubkey: -> at first in cache
-> when not found in cache load index file

8
docu/other/node/interface.txt Normal file
View File

@ -0,0 +1,8 @@
HTTP:
JSONP or command line:
getShortLivingAPIKey
with username and password (define in config)
createGroup
with APIKey and TopicID

17
docu/other/node/validationTypes.txt Normal file
View File

@ -0,0 +1,17 @@
Basic:
simply find last transaction of konto and check if matching
Single-Strain:
go through all transaction of konto and revalidate from lower to higher transaction id
Multi-Strain:
validate also last of cash inflow from another kontos
Multi-Strain-Complete:
revalidate all transaction of konto and linked kontos
Full-Group:
revalidate all transactions of group
Full:
revalidate all transactions of group and all linked groups

148
docu/other/project-considerations.md Normal file
View File

@ -0,0 +1,148 @@
# how to speed up progress?
- proposal is to have few priority scenarios, then analyze them, going deeper into details; detailization would be team work, but implementation of necessary bits would be individual responsibility
- prototyping can be used where things are not yet finished (login server, for example); GUI doesn't have to look great, no high- performance expectations, etc.
- example
- we want to see people from two different groups exchanging gradidos
- one community server, one login server, one node server is
set up for this test
- all on the same server, probably on Dario's dev server
- need detailed description of the procedure
- login server has to have hedera account private key, from
where to get it? if we want to go mainnet, account owner
has to be verified; we need a clear procedure of setting up
this server
- ...
- groupA, groupB are set up
- community / login servers configured for that
- - necessary topics are created by hosting login server
- need detailed description of the procedure
- at this point, people can register in community server and
do transfers
- ...
- userA (in groupA) and userB (in groupB) is set up
- registration via community server
- community server -> login server -> hedera -> node server
chain is working
- ...
- groupA and groupB are befriended
- ...
- transfer occurs
- ...
- ...
- example has to get deeper and deeper detailization, until it is ready
and we know hardest challenges; then we just implement it, as each
part of the system - one of our three services - has a clear list
of what to do
- in many cases we are developing procedures instead of code
- system security / usability analysis, most important conclusions
- - blockchain cannot be considered valid without a message, originating
from hedera, which gives a hash to test with
- problem is that we cannot predict when the message comes, so it
would be good to know latest hashed beforehand (this is important
only when starting up node server; once existing chain is compliant
with hash of newly received hedera message, all chain is considered
valid)
- if chain is not validated by direct message from hedera, it is
inadvisable to use the data from related blockchain
- data could be valid on other node servers, so maybe longer node
start time is acceptable, if there are enough other nodes
- current hash would be most useful for group blockchain, as it will
change slowly, and (depending on data included there) that could
prevent node from functioning for long time after it is started
- hedera-related problems
- sudden changes (such as a new hashing algorithm version; this did
occur recently; if such thing happens in mainnet, then our system is
just instantly broken on global scale, hedera don't store messages
longer than 10 minutes; we would need to store messages in raw form
outside blockchain, until we have support for new hashing algorithm,
then replay them and insert into blockchain)
- outages (already have seen them with testnet)
- account verification may fail without possibility to proceed in any
direction
- also, it requires verification of my photo and ID card (driver's
licence); is it acceptable for login server needs?
- it has to be somehow encrypted, otherwise it can be easily spoofed
- changing sequence number, timestamp, adjusting hash, thus creating
different valid blockchains
- it is not that important, if a node can get current hash from
other, trusted source; it would be good also to allow
considerably faster node start
- idea is to have "hash server" with SSL certificate from a valid
authority; it would serve current hash for all needed topics;
internally, it would just listen topics and keep track of latest
hash; login server could demand that node server verifies its
current hashes, if there is a discrepancy
- yes, it would be global for all system, the same way as hedera
is; we are fixing their lack of important feature here
- do they have VPN on their mainnet? I don't have main account, cannot
contact them, they simply don't verify my account for some reason
- there can be bugs in data they are sending
- one idea is to consider possibility to migrate data to a different
topic, if certain topic gets broken down on hedera side
- something akin to system restart; data is kept, but instance is
a new one
- hashes would change, as timestamps change; all other stuff is
replay-able
- both peer and login server don't need to be reliable for node server;
only reliable, trustful source of data is considered hedera
# Answer Dario
With scenarios do you mean something like:
user alex from group 1 send 100 GDD to user Paul from group 2?
With Prototyping would you like to replace the working login-server with
a python prototype version or only support not finished features with a python-prototype?
For example creating a new hedera account with few hashbars for automatic fee paying.
Write the prototype then directly in the same db or do we need than also a separat interface between
working and prototype login-server?
The Community Server are planned to support only one group, Login Server planned to support multiple groups,
but not implemented yet.
For fastet success we could use a setup with two Community Servers and two Login Servers.
But setup the servers currently need also some time
Do you mean detailed description of the setup procedure?
We can use the staging server for that, which Bernd has rentet for this purpose.
I have a verified hedera account.
One solution is that at least every login-server operator need a hedera account or we from Gradido
have an account an can create sub-accounts with some hashbars for login server operator, specially for
people which support gradido already with donations.
The plan is later to operate a hedera node and stake hashbars on it to earn enough hashbars to pay the fee for gradido transactions.
Current functions of Login-Server and Community-Server:
People can register, get email verification code sended, can activate account.
System Security:
yes, only messages from hedera are trusted
I think we can give node server also a small hedera account to pay fees for transactions like that to
get last hash of topic by startup
especially because I have planned to use also hedera for node discovery (at least at first, I know
most crypto use central dns seeder for that)
hedera related problems:
in my original node server code I have planned to store the proto messages serialized (raw)
plus additional indices for faster lookup, how do you save the transactions in your node server implementation?
Outages: User should be informed and must try it again later, or we must keep his private keys in memory
to try again later, but I recommend against it.
I think we can assume than hedera mainnet will be keept online most of the time, else it would loose value
man-in-the middle between hedera and node-server:
My assumption and understanding from hedera consensus service is, that I get transactions with a running hash.
A running hash is calculated from the previous transaction and the current transaction.
I can check the running hash to make sure nobody has changed the transaction on there way.
Every Time I can check the last running hash by hedera.
So to successfully manipulate the attacker must not only change one message, he must change every next.
And intercept also every consensus get topic info query call to hedera.
Or he able to change the message such that the new calculated running hash is the same like the original.
Broken Topic:
move to new topic
normally moving transaction go to old and new topic but in this case, if topic is not reachable any longer on hedera,
maybe we can put the outbount moving transaction instead to the old topic to the global topic.
But only if we have only occasionally broken topics.
I don't think it is a good idea to replay all transactions from one topic to another, to much room for manipulation.

45
docu/other/protobuf/BasicTypes.proto Normal file
View File

@ -0,0 +1,45 @@
syntax = "proto3";
package gradido;
message Key {
oneof key {
bytes ed25519 = 2; // ed25519 signature (libsodium default)
bytes ed25519_ref10 = 3; // ed25519 ref10 signature
}
}
message SignaturePair {
bytes pubKey = 1; // 32 Byte
oneof signature {
bytes ed25519 = 2; // ed25519 signature (libsodium default), 64 Byte
bytes ed25519_ref10 = 3; // ed25519 ref10 signature
}
}
message SignatureMap {
repeated SignaturePair sigPair = 1; // Each signature pair corresponds to a unique Key required to sign the transaction.
}
/* An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https://github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto) */
message Timestamp {
int64 seconds = 1; // Number of complete seconds since the start of the epoch
int32 nanos = 2; // Number of nanoseconds since the start of the last second
}
/* An exact date and time, with a resolution of one second (no nanoseconds). */
message TimestampSeconds {
int64 seconds = 1; // Number of complete seconds since the start of the epoch
}
message SenderAmount {
bytes ed25519_sender_pubkey = 1;
sint64 amount = 2;
sint64 senderFinalBalance = 3; // sender balance after transaction, including perishability
}
message ReceiverAmount {
bytes ed25519_receiver_pubkey = 1;
sint64 amount = 2;
}

15
docu/other/protobuf/StateCreateGroup.proto Normal file
View File

@ -0,0 +1,15 @@
syntax = "proto3";
package gradido;
import "BasicTypes.proto";
// need signature from this group and from parent (if it isn't zero)
message StateCreateGroup {
string name = 1;
Key groupPublicKey = 2;
Key parentGroupPublicKey = 3;
reserved "hederaConsensusId";
reserved 4;
}

12
docu/other/protobuf/StateGroupChangeParent.proto Normal file
View File

@ -0,0 +1,12 @@
syntax = "proto3";
package gradido;
import "BasicTypes.proto";
// need signature from this group and from both parents (if it isn't zero)
message StateGroupChangeParent {
Key groupPublicKey = 1;
Key newParentGroupPublicKey = 2;
Key oldParentGroupPublicKey = 3;
}

19
docu/other/protobuf/Transaction.proto Normal file
View File

@ -0,0 +1,19 @@
syntax = "proto3";
package gradido;
import "BasicTypes.proto";
/*
id will be set by Node server
txHash will be also set by Node server,
calculated from previous transaction txHash and this id, sigMap and received;
*/
// at least 232 Byte for a transfer without memo
message Transaction {
uint64 id = 1; // 8
TimestampSeconds received = 2; // 8
SignatureMap sigMap = 3; // 96 Byte
bytes txHash = 4; // 32 Byte
bytes bodyBytes = 5;
}

18
docu/other/protobuf/TransactionBody.proto Normal file
View File

@ -0,0 +1,18 @@
syntax = "proto3";
package gradido;
import "Transfer.proto";
import "StateCreateGroup.proto";
import "StateGroupChangeParent.proto";
import "TransactionCreation.proto";
message TransactionBody {
string memo = 1; // max 150 chars
oneof data {
StateCreateGroup createGroup = 2;
StateGroupChangeParent groupChangeParent = 3;
Transfer transfer = 4; // at least 88 Byte
TransactionCreation creation = 5; // 44 Byte
}
}

14
docu/other/protobuf/TransactionCreation.proto Normal file
View File

@ -0,0 +1,14 @@
syntax = "proto3";
package gradido;
import "BasicTypes.proto";
// need signature from group admin or
// percent of group users another than the receiver
message TransactionCreation {
ReceiverAmount receiverAmount = 1;
// TODO: Change to collision resistent type
sint32 ident_hash = 2;
}

11
docu/other/protobuf/Transfer.proto Normal file
View File

@ -0,0 +1,11 @@
syntax = "proto3";
package gradido;
import "BasicTypes.proto";
// at least 88 Byte
message Transfer {
repeated SenderAmount senderAmounts = 1; // je 48 Byte
repeated ReceiverAmount receiverAmounts = 2; // je 40 Byte
}

41
docu/other/subcluster.md Normal file
View File

@ -0,0 +1,41 @@
% blockchain structure
% - header
% - subclaster name
% - initial key type (ca_signed, self_signed)
% - list of public keys, representing CA chain (if type is ca_signed,
% chain is verified with CA_MASTER_PUB, which is hardcoded)
% - one or more initial admins (preferrably, 3)
% - email
% - name
% - public key
% - signature with initial key
% - ordering node (it is associated with subclaster blockchain in 1:1
% relationship)
% - type (ordering node)
% - endpoint
% - public key
% - signature with any of admins
%
% from this point all other nodes follow in arbitrary order; admins can
% be added or removed by majority of admins signing the record (majority
% of 2 is 2); most of the nodes are described by their type, endpoint,
% public key
%
% data in subclaster blockchain is used for gradido blockchains
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% typical launch process of a node
% - node is started, providing AdminKeyPub to it
% - it creates its own key pair (PrivKey, PubKey)
% - it stands ready for incoming request for its public key
% - request has been signed by AdminKeyPriv
% - it returns its PubKey, signed by PrivKey
% - it waits for signed response, by AdminKeyPriv
% - for ordering node
% - it puts record into blockchain, registering itself
% - for non-ordering node
% - it sends record to ordering node

89
docu/other/system-notes.md Normal file
View File

@ -0,0 +1,89 @@
- understanding of the system
- abstract, conceptual model
- levels
- a ledger with user transfers (userA, userB, amount) and money
creations (user, amount)
- each ledger has certain rules (for example, transfer cannot
happen if sender doesn't have enough funds; or creation sum for
single user cannot exceed certain amount); by applying those
rules all transfers in the ledger can be replayed and ledger can
be deemed "plausible"
- this alone is NOT enough to confirm that transfers actually
happened, there has to be more to that (transfers have to be
authorized in one or another way)
- multiple such ledgers (blockchains, groups), each maintaining set
of users inside group
- groups can befriend each other, allowing cross group transfers
between users
- users can migrate from group to group
- so, a set of rules exist for a group (for example, user has to
be inside of the group to participate in that group's transfer;
groups have to be friends for cross-group transfer to happen;
etc.); this allows full replay and checking if ledger is
plausible
- such model could be implemented in various ways, for example, single
server, single thread database application, or even with hand-written
ledger, served by an accountant
- idea is to put that together with concept of distributed network,
with nodes, messages, etc.
- from that comes choice to use Hedera, then Protobuf, C++
- any solution should involve user authentication of some sort;
public/private key signatures is a convenient choice
- hedera: pros and cons
- pros (some are essentially needed features):
- ordering of transactions
- transaction sender is authorized
- defense against flood with help of HBARs (their currency)
- transactions are distributed
- emerging industry standard
- cons:
- risk of sudden changes; for example, if Hedera decides to use
different running hash calculation algorithm without prior notice,
all network goes down
- not all features are good, some are missing
- their server uptime is not guaranteed
- future is not guaranteed as well; what if after 5 years Hedera is
shut down?... at that point there could be million transfer
blockchains, built on top of it
- that could be solved, though, by replaying transfers into new
ledgers, etc.; still worth to consider
- when connecting to hedera network only way to get current sequence
id and running hash is to use getTopicInfo() call, which costs
HBARs
- gradido node
- hosts ledger data, therefore most important part of the system
(kind of backend database)
- performs data checks before insert, replays blockchains on restart
- exchanges information with other nodes, requesting and sending
blockchain data when necessary
- provides blockchain data in convenient way for node users
- listens to transaction data coming via Hedera network
- all transactions are therefore stored in blockchain, regardless if
they are possible and correct or not; hedera message sequence id
list won't have holes in it
- calculates fields when it is necessary (such as transaction result
or "verdict"; for example, transfer may fail if user doesn't have
enough funds
- in its validation procedures implements all blockchain rules
- transaction format allows format / rule versioning
- can host multiple blockchains
- actually, needs to host multiple blockchains for cross-group
transfers
- expects node user to provide other node endpoints and list of
blockchains to maintain
- otherwise, not conceptually strongly bound to user; it can be
anything, for now there are two services, login server and
community server
- data is kept on hdd in a binary, yet simple, struct-like format;
it is split in same sized blocks; all records have same length
- problems
- user authentication
- if a user can have more than one account, it opens way for creating
of bot networks, essentially robbing honest players
- user migration and cross group transfers would allow many ways
to create bots
- on the other hand, hardcore user authentication may scare off
people
- conclusions
- set of rules, allowing blockchain to be replayed, has to be very
clearly defined (and considered)

171
docu/other/transactions.md Normal file
View File

@ -0,0 +1,171 @@
# Transactions
The different transaction types and how they are defined in protobuf.
These form the lowest layer for Gradido.
## So far available
### Transaction
A container for all transactions.
Inspired by Hedera Hashgraph transactions.
Contains mainly the data for sorting in the block chain.
```
message Transaction {
uint64 id = 1;
TimestampSeconds received = 2;
SignatureMap sigMap = 3;
bytes txHash = 4;
bytes bodyBytes = 5;
}
```
**id**: This is where Hedera's topicSequenceNumber comes in or, in mode without Hedera, an id that starts at 1 and increases by 1 with each transaction.
**received**: Here comes the Hedera consensus timestamp or without Hedera the date + time when the transaction has reached the server that performs the sorting (single node).
**sigMap**: Contains all signatures and associated public keys. The signature is created from the public key's private key and bodyBytes.
**txHash**: Contains the topicRunningHash of Hedera or without Hedera the running hash of the sort server (Single Node). This is created from the hash of the last transaction, the id, the date and the serialized sigMap.
**bodyBytes**: Contains the serialized TransactionsBody
### TransactionBody
Contains data that applies to all transactions and the actual, specific transaction.
```
message TransactionBody {
string memo = 1; // max 150 chars
TimestampSeconds created = 2;
oneof data {
StateCreateGroup createGroup = 6;
StateGroupChangeParent groupChangeParent = 7;
Transfer transfer = 8;
TransactionCreation creation = 9;
}
}
```
**memo**: comment or purpose, optional, maybe should be encrypted
**created**: Date + time of creation of the transaction
**data**: The specific transaction
### TransactionCreation
Creation transaction, here the Gradido creation takes place.
Is most expensive in verification.
Among other things, it must be ensured that only a maximum of 1,000 GDD per month can be created, or a total of 3,000 per month distributed over all three recipients.
The three recipients are the private account of the human being, the group account (i.e. public budget including health care) and the compensation and environmental fund belonging to the group.
In addition, the target month for which a transaction was created may not be more than 3 months in the past.
```
message TransactionCreation {
ReceiverAmount receiverAmount = 1; // 40 Byte
sint32 ident_hash = 2; // 4 Byte
TimestampSeconds target_date = 3; // 8 Byte
ReceiverAmount groupOfficialAmount = 4;
ReceiverAmount groupEcoFondsAmount = 5;
}
```
**receiverAmount**: Public-Key and GDD amount for the private account of the person
**ident_hash**: A short hash of the identification of the human being for a faster assignment
**target_date**: The target date for which month the money was created.
**GroupOfficialAmount**: Public key and GDD amount for the public budget (usually 1,000 GDD)
**groupEcoFondsAmount**: Public-Key and GDD amount for the equalization and environment fund (usually 1,000 GDD)
### Transfer
Simple bank transfer to transfer GDD from one account to another.
Can contain many senders and receivers, but the total balance of the senders must equal the total balance of the receivers.
During the check only the senders have to be checked if they have enough GDD on their account at the time of the transaction with the transient. There are no negative GDD amounts.
```
message Transfer {
repeated SenderAmount senderAmounts = 1;
repeated ReceiverAmount receiverAmounts = 2;
}
```
**SenderAmounts**: Contains one sender public key, the GDD amount that is sent and the account balance of the sender after sending. This way you don't have to search the whole block chain every time to calculate the balance, but only look up to the last transfer.
**ReceiverAmounts**: Contains one receiver public key and the GDD amount received.
## To be defined
### Create Group
- Hedera Topic ID
- name
- root public-key of the new group and parent public-key
### Add to group
- previous group can be zero
- previous group is important to check at creation time whether the beneficiary
has already received GDD for the corresponding month
- signed by account holder
- signed also by group admin or council according to the group configuration
- public-key of the group
- Root public-key of the human being
- Proof of identity
- public-key of the previous group
### Add subaccount
- name is only stored on Sign-up-Server
- name hash is used for key derivation
- name is unique per person
- root public-key of the account holder
- public-key of the new account
- hash of the name
### Add Email
- signed by account holder
- email hash
- public key of the account to which the e-mail should belong
- Sign-up-Server host + port
### Remove Email
- signed by account holder
- email hash
### Remove from group
- signed by account holder
- public-key of the group
- root public-key of the account holder
- public-key of the new group
### Add a council member
- signed by the new council member
- signed also by the group admin or the council member according to the configuration of the group
- public-key of the council member
- public-key of the group
### Remove a council member
- signed by the council member to be deleted
- may only allowed if there is a minimum number of council members left to approve different tasks according to group configuration
- public-key of the council member
- public-key of the group
### Connect groups
- must be signed by both groups, according to the respective configurations
- only if two groups are connected, the individual members can send GDD to each other across the group boundaries.
- by connecting, all subgroups (childs) are also considered to be connected to each other
- public-key of both groups
## Further
### configuration
Transactions to configure the council, i.e. how many people have to agree, or veto to perform a certain action, or only by the group admin.
In addition the question which possibilities should there be?
Should it affect all actions equally, or should it be configurable differently from action to action? Maybe work with bit-operators to enable both?
### GDT
Transaction to credit the GDT, Central Instance, hard coded public key as signature?
Transaction that redeem GDT, 1:1 for Gradido but limited by certain rules to prevent inflation. But the rules are not yet fixed. Dynamic rules per group as configuration transactions?

BIN
docu/other/uml/Deployment_Verbindungsart.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 23 KiB

BIN
docu/other/uml/Login Server Hedera Related Classes.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 4.2 MiB

BIN
docu/other/uml/gradido.vpp Normal file
View File

Binary file not shown.

BIN
docu/presentation/Team Gradido.pdf Normal file
View File

Binary file not shown.

BIN
docu/presentation/Team Gradido.pptx Normal file
View File

Binary file not shown.