gradido/docu/other/transactions.md

# 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?