-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathRFC.txt
83 lines (60 loc) · 10.3 KB
/
RFC.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
----------
Abstract
--------
----------------
Table of Contents
---------------
------------
Introduction
------------
An essential problem in functioning of open distributed system is the allocation of reputation and thrust to the different nodes. Internet based systems that allow users to join without verification suffer from various types of users that do not behave properly, i.e. the do not further the common goals of the system. The users may be faulty, lazy, persueing their own goals, or actively trying to undermine the system. For the network to function in spite of these bad users, in most cases it needs some way to distnguish between 'good' and 'bad' users.
Since information is by definition distributed over multiple nodes in the network, no single node is guaranteed to have a complete overview of the information in the network. Protocols to aquire the global state exist, but these may be relatively costly\cite{}. An \emph{open} distributed network, where anonymous nodes may freely join over the internet, provides additional challenges, since not all nodes may be loyal to network; instead of furthering the overall goal of the network, they may strife to achieve their own individual goals. While some of such open systems have shown to be effective \cite{}, they have trouble mantaining consistent records of their users \cite{} in a dsitributed manner, and often use centralized mechanisms to acheive this \cite{}.\\
----------
Goal
----------
Multichain is a distributed accounting system for peer to peer network interactions. It records interactions between peers that have taken place in a verifiable and consistent manner. This means that it is impossible for any of involved parties to later deny that a transaction has taken place, and that it is hard for any peer to hide a specific selection of his interactions. The system should function without any centralized party, without the requirement of full knowledge of the global state of the network, and limited network and computational resources, while at the same time being able to process a large number of interactions. The system should also be scalable: the number of total users in the network should not significantly impact the system strain for a node after a certain point.
The system can be used to account many different types of interaction data. However it is of course important that within a network, peers store the same type of data. An implementation of this general protocol should therefor specify the actual data that is to be exchanged.
--------
Overview
--------
Interaction between peers are stored in blocks. The blocks contains the transaction data that is meant to be stored. This tranaction data will be signed by both peers using public-key cryptography, and hence the public keys of each peer is also included. Since the protocol distuinghuishes between a requester and a responder of a block, this distinction can be used for the specification of assymetric aspects of interactions.
The peers also keep track of some aggregate over all their interaction. The integretity of is aggregate is backed by the whole body of transactions, and provides no additional information from the total of all transactions of that peer. However the aggregate provides an overview of the peers history when only a limited amount of blocks is available. The aggregate field and the total block history form points on a spectrum that represents the trade-off between confidence of the history of a peer and the cost of calculating the history. Validating the aggregate of a peer by iterating over all blocks of that peer is costly, in terms of the bandwidth required to transfer all blocks, the storage costs required to store all the blocks, and the computing power required to process all the blocks. This method of total validation does however provide maximum confidence of the history of the repective peer. On the other end of the spectrum, the aggregate field of the last known block directly provides some aggregate of the history, without involving validation data or calculations. However, this field does not provide a lot of confidence in and of itself, and could easily be faked. However, the systems provides strong incentives not to lie; when an aggregate does not match that of the previous block, this is easily detected by just collecting and checking the two consecutive blocks. Since all blocks are signed by both parties, the lying party cannout deny his lie, and we have irrefutable proof of lying. To check for such lies, a peer can validate an certain amount of recent blocks, from the most recent backwards by an arbitrary amount. This represents the other point on the spectrum; by validating more blocks we get closer to the point of maxmium confidence, by validating fewer blocks the validation is less costly.
To prevent people from hiding some of their blocks, and thereby their history, the blocks are chained together to form a blockchain. This means that for each peer there exists a unique, ordered sequence of blocks. This order is indicated by a sequence number for each peer that is included in the block. To prevent peers from replacing blocks in the chain, each block contains a hash that refers to the previous block.
The idea is to operate on two levels. First of all, each peer has some reputation based on its interaction history. Other peers can evaluate this reputation using the information in the multichain and provide or refuse services based on this reputation. The second level consists of some peers that are lying about their history using the multichain. When evidence of such lies are aquired, this can be proved irrefutable by conflicting messages signed by the same peer. (The evidence is irrefutable assuming that the cryptography used to sign messages can not be broken, and the private key of the peers remains private.) This proof can then be broadcasted allong the peers in the network. Peers that are found lying should immedatly be refused any service for which the multichain is used, both because no reputation can be reliably assertained form the multichain, and to discourage lying in general.
---------------
Data format
-------------
The transaction part, which both peers always have:
0 1 7 8
0 1 2 3 4 5 6 7 8 9 0 1 2 === 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+===+-+-+-+-+-+-+-+-+-+-+-+
| Up | Down | === public key requester |
+-+-+-+-+-+-+-+-+-+-+-+-+-+===+-+-+-+-+-+-+-+-+-+-+-+
| public key responder === |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit Inc |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- transaction data (up 4 + down 4) (unsigned int)
- public key requester (74) (char[])
- public key responder (74) (char[])
The requester part, that contains the multichain status of the requester, and its signature. This is initially only guaranteed to be known for the requester:
- agrregate requester (total up 8 + td 8) (unsigned long long)
- sequence number requester (4 int)
- previous hash requester (32 char[])
- signature requester (signs all fields above it) (64) (char[])
- [Stored, but not send] hash_requester (hashes all fields above it) (32 char[])
The responder part, same as above, but for the responder.
- total up responder
- total down responder
- sequence number responder
- previous hash responder
- signature responder (signs all fields above it (expect hash_requester))
- [Stored, but not send] hash_responder (hashes all fields above it (expect hash_requester))
-----------
Message protocol
-------------
----
Attacks & Defences
---
When a malicous peer wants to hide certain transactions that somehow reflect badly upon him, this is already hindered by the existence of sequence numbers. Imagine a peer with a history of a 100 blocks that wants to hide the 42nd block from the people he interacts with. Sequence numbers prevent the peer from presenting a consistent history without a 42nd block. The sequence numbers clearly indicate that a block is missing. To avoid this the malicous peer would have to modify the sequence number of all blocks from the 43rd upward, but this results in two problems. First of all, the counterparty signatures of all blocks were the malicous peer is the requester will now be invalid. Secondly, all modified blocks will now conflict with the blocks that previously had these sequence numbers, making it very likely that some peer in the network will find two conflicting blocks, making him able to produce irrefutable proof of lying. A better strategy would therefore be to create a new block with sequence number 42. This block can have valid signatures by the malicous peer and some other peer, being either wilfully cooperating, tricked, or a sybil. With this block, the malicous peer can the present a consistent history that does not include the problematic transaction. There are now however still 2 blocks with sequence number 42, both signed by the malicous peer. This means that it is still possible to provide irrefutable proof of lying if both blocks are found by the same peer. This is possible since this block is know by the counterparty in the original transaction, who can gossip it. The inclusion of the previous hash complicates this (already risky) attack even further. Since block 42 is replaced in this attack, the hash of the block changes (assuming of course there are no known collison attacks for the hashing algorithm used.). This means that the previous hash of block 43 now mismatches with the hash of block 42, making the history of the malicous peer internatlly inconsistent. To prevent this, the attacker must change the previous hash field of block 43, but this will make the previous hash of block 44 invalid. To remedy this, the whole chain upto the most recent block must be rewritten. This rewriting will however fail on the first block where the attacker is a requester, because in this case changing the previous hash will invalidate the signature
of the counterparty. Another strategy is to branch the multichain, discarding the 42nd block and all following blocks, and continuing to build a history from the 41st block onward. This enables the attacker to present a consistent history, but there will be always at least one sequence number for which conflicting blocks can be found. Branching is more viable when it is done soon after the transaction to be hidden has taken place, limiting the amount of blocks that will conflict.