IETF RFC writeup of Trustchain

[synctext]

Goal: facilitate broader uptake of Multi-Chain

Approach: have a detailed, complete and accurate protocol description of Multi-Chain in IETF RFC format

Tribler team at Delft created before: https://datatracker.ietf.org/doc/rfc7574/
Example RFCs which mention currency, credit or gossip :

• https://datatracker.ietf.org/doc/draft-ietf-trans-gossip/
• 4 reputation RFCs
• https://datatracker.ietf.org/doc/rfc1898/
• https://datatracker.ietf.org/doc/rfc5578/?include_text=1
• https://datatracker.ietf.org/doc/draft-ietf-manet-credit-window/

Team Multi-chain: @pimveldhuisen @pimotte @Captain-Coder
Side-affect: a nice thesis chapter.

[pimotte]

@synctext just explained his intended scope to me: Up to and including the crawling protocol. I agree that this is a good idea and there is value to document the protocol in a rigid way. Feel free to poke me for input and/or proofreading.

[synctext]

https://github.com/Tribler/tribler/wiki/Multichain-specifications ongoing work

[synctext]

IETF cut-off dates: https://www.ietf.org/meeting/important-dates.html

[synctext]

Internet Engineering Task Force                         J. Pouwelse, Ed.
Internet-Draft                            Delft University of Technology
Intended status: Informational                          January 17, 2017
Expires: July 21, 2017


                          TrustChain protocol
                      draft-pouwelse-trustchain-01

Abstract

   TrustChain is a blockchain specifically designed to create trust.
   The structure and communications protocol version 0.1 are described.
   It is specifically designed to created trusted transactions among
   strangers without central control.  This version includes recording
   transactions in an ordered list using blockchain structure.  Unique
   approach of TrustChain is that each participant creates their own
   genesis block.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 21, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Pouwelse                  Expires July 21, 2017                 [Page 1]

Internet-Draft             Trustchain protocol              January 2017


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Trustchain Architecture . . . . . . . . . . . . . . . . . . .   3
   3.  Trustchain data structure . . . . . . . . . . . . . . . . . .   4
   4.  Acknowledgements to Brussels  . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Additional Stuff . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   We present TrustChain, blockhain technology specifically designed to
   help create trust.  The only mechanism we use is recording
   transactions and signatures.  By using records of historical
   transactions it is possible to calculate reputations.

   In essence, trust is a feeling of security, based on the belief that
   someone or something is knowledgeable, reliable, good, honest, and
   effective.  The blockchain is an approach which holds the promise of
   reducing the cost of establishing and maintaining trust for both
   individuals and organizations.  The blockchain lets people who have
   no particular confidence in each other collaborate without having to
   go through a neutral central authority.  The main TrustChain design
   principle is having entities that would otherwise not trust each
   other agree on a common record of events in a continuous growing
   process.  We use cryptographically signed records of events to create
   an unbroken, irrefutable, and sequential chain of evidence.  It is
   then possible to combine this chain-of-evidence with proven
   approaches to create trust, such as reputation systems.

   The TrustChain work contributes to an ambitious goal: establishing a
   generic method to create trust.  A generic method can be re-used in a
   wide range of contexts, can be applied in varying fields of
   applications, and provides a shared common infrastructure.

   An Open Source implementation of TrustChain is available.  It is used
   in an operational setting for a distributed video streaming system.
   Specifically, it is used to record the bandwidth exchanges in




Pouwelse                  Expires July 21, 2017                 [Page 2]

Internet-Draft             Trustchain protocol              January 2017


   Bittorrent swarms and relaying in an onion routing setting with the
   goal of prevent freeriding.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Trustchain Architecture

   TrustChain is a simple blockchain-based data structure.  It can be
   used to record transactions and to make these transactions tamper-
   proof.  The design specifically strives for simplicity and avoids
   complexity.  TrustChain gives each node in the network their own
   chain of transactions.  Using what are essentially parallel chains
   yields inherent scalability, removes the need for a proof-of-work
   mechanism, global transaction broadcasts, leadership elections,
   forks, or permissions.

   The general architecture of TrustChain is illustrated in
   Figure~\ref{fig:multi-chain}.  Each element in the data structure
   represents a transaction between two participants.  When initiating
   new transactions, each participant includes the hash of their last
   interaction, creating a chain of temporally ordered interactions.  In
   addition, each record is provided with a sequence number that is
   unique in the chain.  TrustChain records are cryptographically signed
   by both parties and together form a directed graph.

   This agreement by \emph{both parties} is a key novelty of TrustChain
   and a fundamental difference between our approach and related
   blockchain work.  The remarkable simplicity of TrustChain is a direct
   consequence of the hard requirement for agreement by both
   participating parties.  TrustChain records are tamper-proof and
   irrefutable since modification of a specific record can be detected
   by verification of the cryptographic signature.  This removes the
   need for Bitcoin-like global consensus mechanisms and competing forks
   which may invalidate transactions.  The vulnerability of existing
   blockchains to the 51~\% attack is also addressed.  The validity of a
   block of transactions is easy to establish and immediate,
   confirmation time is avoided.  We call this a \emph{bottom-up
   consensus model}.

   In a directed graph representation each historical encounter in
   TrustChain has two incoming edges and two outgoing edges.  Violations
   of these rules can be efficiently detected, for instance, signing two
   records with the same prior record pointer (see Section
   \ref{sec:vulnerability-analysis}).



Pouwelse                  Expires July 21, 2017                 [Page 3]

Internet-Draft             Trustchain protocol              January 2017


3.  Trustchain data structure

   +----------------------+
   |                      |
   | Transaction A with B |
   |                      |
   |                      |
   +----------------------+
   | sequence number A: 0 |
   +----------------------+
   | signed by A          |
   +----------------------+
   | sequence number B: 11|
   +----------------------+
   | signed by B          |
   +---------+------------+
             ^
             |
             |
   +---------+------------+
   |                      |
   | Transaction A with C |
   |                      |
   |                      |
   +----------------------+
   | sequence number A: 1 |
   +----------------------+
   | signed by A          |
   +----------------------+
   | sequence number C: 4 |
   +----------------------+
   | signed by C          |
   +---------+------------+
             ^
             |
             |
   +---------+------------+
   |                      |
   | Transaction A with D |
   |                      |
   |                      |
   +----------------------+
   | sequence number A: 2 |
   +----------------------+
   | signed by A          |
   +----------------------+
   | sequence number D: 49|
   +----------------------+
   | signed by D          |
   +---------+------------+

Pouwelse                  Expires July 21, 2017                 [Page 5]

Internet-Draft             Trustchain protocol              January 2017


        Cross-references allowed in pre- and postamble. [min_ref].

                                 Figure 1

4.  Acknowledgements to Brussels

   We very much thank the EU for providing us the required funding.  An
   estimated 3.4 million Euro has been granted through .

5.  IANA Considerations

   This memo includes no request to IANA.

   All drafts are required to have an IANA considerations section (see
   Guidelines for Writing an IANA Considerations Section in RFCs
   [RFC5226] for a guide).  If the draft does not require IANA to do
   anything, the section contains an explicit statement that this is the
   case (as above).  If there are no requirements for IANA, the section
   will be removed during conversion into an RFC by the RFC Editor.

6.  Security Considerations

   All drafts are required to have a security considerations section.
   See RFC 3552 [RFC3552] for a guide.  See RFC min_ref [min_ref] for a
   guide.  See RFC DOMINATION [DOMINATION] for a guide.

7.  References

[pimveldhuisen]

msc_thesis_WIP_18-01.pdf

Table 3.1 on page 12 describes the current packet format.

[Captain-Coder]

This is the true half block format. In the half blocks situation we need a value to indicate an unknown link sequence number on a request block, and since we use unsigned numbers we can't use -1 (and using 0xff...fff makes the logic slightly more complex). So I choose 0 for the invalid sequence number. This however means that sequence number for genesis blocks should be 1, not 0 as described in the rfc ascii art example above.

[synctext]

ToDo for next meeting:

• first writeup using existing initial draft (with too much marketing and scientific language, from a Journal submission) XML xml2rfc sources:
  pouwelse-trustchain-01.xml.txt

[synctext]

ToDo: new storyline and focus "transitive trust exchange protocol" for usability in 8-bit processors and hostile networks ?

[pimveldhuisen]

• In the ascii art, the blockchain has its genesis at the top and grows downwards. In existing diagrams, this is usually the other way around; the chain grows upwards. We should be consistent is this.

• 8-bit processors do not seem very relevant IMHO, I don't think they will be very prevalent as 16- and 32-bit microcontrollers are very cheap anyways. There might be a niche for very basic devices, but when you want to do any kind of crypto 8-bit seems to me as a poor choice.

[svanschooten]

Internet Engineering Task Force                         J. Pouwelse, Ed.
Internet-Draft                            Delft University of Technology
Intended status: Informational                           October 2, 2017
Expires: April 5, 2018


                          TrustChain protocol
                      draft-pouwelse-trustchain-01

Abstract

   TrustChain is a novel implementation of blockchain technology
   specifically designed to create trust.  The structure and
   communications protocol version 0.1 are described.  It is
   specifically designed to created trusted transactions among strangers
   without central control.  This version includes recording
   transactions in an ordered list using blockchain structure.  The
   unique approach of TrustChain is that each participant creates their
   own genesis block, resulting in seamless scalability.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 5, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Pouwelse                  Expires April 5, 2018                 [Page 1]

Internet-Draft             Trustchain protocol              October 2017


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Trustchain Architecture . . . . . . . . . . . . . . . . . . .   3
   3.  Trustchain data structure . . . . . . . . . . . . . . . . . .   4
   4.  Block format  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  A true half block . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Half block fields . . . . . . . . . . . . . . . . . . . .   6
     4.3.  Asynchronicity  . . . . . . . . . . . . . . . . . . . . .   7
   5.  Consensus protocol  . . . . . . . . . . . . . . . . . . . . .   7
   6.  Attack resistance . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Sybil attacks . . . . . . . . . . . . . . . . . . . . . .   8
     6.2.  Double spending attack resistance . . . . . . . . . . . .   8
     6.3.  Replay attack resistance  . . . . . . . . . . . . . . . .   9
     6.4.  Whitewashing attack resistance  . . . . . . . . . . . . .   9
   7.  Discovering the network using Random Walk . . . . . . . . . .   9
   8.  Acknowledgements to Brussels  . . . . . . . . . . . . . . . .   9
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   9
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     11.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Appendix A.  Additional Stuff . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   We present TrustChain, blockhain technology specifically designed to
   help create trust.  The only mechanism used is recording transactions
   and signatures in a multi-chain manner.  By using ordered records of
   historical transactions it is possible to calculate reputations and
   be tamper-proof.

   In essence, trust is a feeling of security, based on the belief that
   someone or something is knowledgeable, reliable, good, honest, and
   effective.  And since humans have a tendency to trust, the changing
   notion of trust (due to influences of technology, such as the wold
   wide public domain) has a major impact on our daily lives.  The
   Trustchain is an approach which holds the promise of reducing the
   cost of establishing and maintaining trust for both individuals and
   organizations.  This blockchain implementation lets people who have
   no particular confidence in each other collaborate without having to
   go through a neutral central authority.  The main TrustChain design



Pouwelse                  Expires April 5, 2018                 [Page 2]

Internet-Draft             Trustchain protocol              October 2017


   principle is having entities that would otherwise not trust each
   other agree on a common record of events in a continuous growing
   process, either by direct trust analysis or by using transitive
   trust.  Cryptographically signed records of events are used to create
   an unbroken, irrefutable, and sequential chain of evidence.  It is
   then possible to combine this chain-of-evidence with proven
   approaches to create trust, such as reputation systems.

   The TrustChain work contributes to an ambitious goal: establishing a
   generic method to create trust, whilst bein resitant against sybil
   attacks and providing methods of coping with freeriding.  A generic
   method can be re-used in a wide range of contexts, can be applied in
   varying fields of applications, and provides a shared common
   infrastructure.

   An Open Source implementation of TrustChain is available.  It is used
   in an operational setting for a distributed video streaming system.
   Specifically, it is used to record the bandwidth exchanges in
   Bittorrent swarms and relaying in an onion routing setting with the
   goal of prevent freeriding.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Trustchain Architecture

   TrustChain is a novel, simpel and extendible blockchain-based data
   structure.  It can be used to record transactions (append only) and
   to make these transactions tamper-proof.  The design specifically
   strives for simplicity and avoids complexity, and as such is
   application neutral.  TrustChain gives each node in the network their
   own chain of transactions, or genesis block.  Using what are
   essentially parallel chains yields inherent seamless scalability,
   removes the need for a proof-of-work mechanism, global transaction
   broadcasts, leadership elections, forks, or permissions.

   The general architecture of TrustChain is illustrated in Figure 1.
   Each element in the data structure represents a transaction between
   two participants, which can be extended with little effort.  When
   initiating new transactions, each participant includes the hash of
   their last interaction, creating a chain of temporally ordered
   interactions, or essentially a Directed Acyclic Graph.  In addition,
   each record is provided with a sequence number that is unique in the
   chain of each participant.  TrustChain records are cryptographically
   signed by both parties and together form a directed acylic graph.



Pouwelse                  Expires April 5, 2018                 [Page 3]

Internet-Draft             Trustchain protocol              October 2017


   This agreement by *both parties* is a key novelty of TrustChain and a
   fundamental difference between our approach and related blockchain
   work.  The remarkable simplicity of TrustChain is a direct
   consequence of the hard requirement for agreement by both
   participating parties.  TrustChain records are tamper-proof and
   irrefutable since modification of a specific record can be detected
   by verification of the cryptographic signature or sequence numbers.
   This removes the need for Bitcoin-like global consensus mechanisms
   and competing forks which may invalidate transactions.  The
   vulnerability of existing blockchains to the 51% attack is also
   addressed.  The validity of a block of transactions is easy to
   establish and immediate, and as such, confirmation time is avoided.
   We call this a *bottom-up consensus model*, resulting in a lineair
   scaling blockchain implementation, with high (nier unlimited)
   transaction throughput..

   In a directed graph representation each historical encounter in
   TrustChain has two incoming edges and two outgoing edges.  Violations
   of these rules can be efficiently detected, for instance, signing two
   records with the same prior record pointer or hiding a record by
   using the same pointer with another chain (see Section 6).  This is
   due to the agents publishing their own unique chains, which can then
   be analysed and the immutable structure of the chain itself.  In
   combination with a global identity (such as a distributed global
   ledger, not discussed here) lock in of this trust mechanism can be
   avoided, and with having digital ostacism (banning) as a consequence,
   malpractices will be discouraged.

3.  Trustchain data structure

   As is mentioned, Trustchain depends on signatures from both
   participants in a transaction, creating a 2-to-2 multi-chain system.
   This system is extedible, as mentioned before, by extending the
   transaction description, and adding signatures and block ID pointers.
   Each transaction is stored in a block, signed and sequenced so that
   each sequence number is unique in both chains.  This general
   structure can be seen below.


       +---------+--+---------+
       |                      |
       | Transaction A with D |
       |                      |
       |                      |
       +----------------------+
       | sequence number A: 3 |
       +----------------------+
       | signed by A          |



Pouwelse                  Expires April 5, 2018                 [Page 4]

Internet-Draft             Trustchain protocol              October 2017


       +----------------------+
       | sequence number D: 49|
       +----------------------+
       | signed by D          |
       +---------+--+---------+
                 |  |
                 |  +----------------------+
                 |                         |  |
       +---------+--+---------+  +---------+--+---------+
       |                      |  |                      |
       | Transaction A with C |  | Transaction D with B |
       |                      |  |                      |
       |                      |  |                      |
       +----------------------+  +----------------------+
       | sequence number A: 2 |  | sequence number D: 48|
       +----------------------+  +----------------------+
       | signed by A          |  | signed by D          |
       +----------------------+  +----------------------+
       | sequence number C: 4 |  | sequence number B: 12|
       +----------------------+  +----------------------+
       | signed by C          |  | signed by B          |
       +---------+--+---------+  +---------+--+---------+
                 |                         |  |
                 |  +----------------------+
                 |  |
       +---------+--+---------+
       |                      |
       | Transaction A with B |
       |                      |
       |                      |
       +----------------------+
       | sequence number A: 1 |
       +----------------------+
       | signed by A          |
       +----------------------+
       | sequence number B: 11|
       +----------------------+
       | signed by B          |
       +---------+--+---------+


                                 Figure 1

4.  Block format

   The Trustchain is designed to be a non-blocking multichain format for
   peer that supports simultaeous interactions with other peers.  Non-
   blocking is a requirement rooted in the immutability of the chain and



Pouwelse                  Expires April 5, 2018                 [Page 5]

Internet-Draft             Trustchain protocol              October 2017


   the strict ordering of the blocks.  To support this, the blocks are
   designed as half blocks, as is described in this section.

4.1.  A true half block

   Using the true half block format means singing the blocks on the
   current views of the respective parties: the requester and the
   responder.  Each party signs and fills the block with the information
   that it has at that specific point in time.  The requester fills the
   structure with his own previous hash and his own part of the
   transaction data, signs it and sends it to the responder, which in
   turn construct the other half of the block, if it agrees with the
   content before sending it back.  This nullifies any ordering and
   asynchronicity issues, since the requester constructs the block with
   the information that he has, and keeps it in memory while it waits on
   the responder to send the finished block back.

4.2.  Half block fields

   The current half block format used for Tribler is used as reference,
   including their type and size:

   +--------+------------------------+-----------------+--------------+
   | Number |      Description       |       Type      | Size (bytes) |
   +--------+------------------------+-----------------+--------------+
   |        |     *Transaction:*     |                 |              |
   |   1    |     Bytes uploaded     |   Unsigned int  |      8       |
   |   2    |    Bytes downloaded    |   Unsigned int  |      8       |
   |   3    |  Total Bytes uploaded  |   Unsigned int  |      8       |
   |   4    | Total Bytes downloaded |   Unsigned int  |      8       |
   |        |     *Own dentity:*     |                 |              |
   |   5    |       Public key       | Character array |      74      |
   |   6    |    Sequence number     |   Unsigned int  |      4       |
   |        |   *Other identity:*    |                 |              |
   |   7    |   Linked public key    | Character array |      74      |
   |   8    | Linked sequence number |   Unsigned int  |      4       |
   |        |     *Validation:*      |                 |              |
   |   9    |     Previous hash      | Character array |      32      |
   |   10   |       Signature        | Character array |      64      |
   |        |        *Total:*        |                 |     284      |
   +--------+------------------------+-----------------+--------------+

                TODO reference Pim Veldhuisens' msc thesis

                  Table 1: Half block fields description






Pouwelse                  Expires April 5, 2018                 [Page 6]

Internet-Draft             Trustchain protocol              October 2017


4.3.  Asynchronicity

   Because there is the need to communicate between the requester and
   responder, there will be a delay which may be significant.  To have a
   high level of asynchronicity and enable multiple peers interacting
   simultaneously, extending the chain should be able while waiting for
   a response.  In order to do this, the block refers to the previous
   block using the hash of the requesters part, since this is the only
   stable reference at that point.  The other hash reference (the
   "previous hash responder") can then be either the "hash requester" or
   "hash responder" part of the head-block of the responder chain.
   Which one is used depends on whether the responder was the requester
   or responder in its previous interaction.  This mechanic is also used
   for the "previous hash requester" field, but this reference is known
   when the block is created.  In effect, this results to theoretically
   unlimited horizontal scalability: the more actors are active on the
   chain, the more throughput can be achieved.  Though this is in fact
   limited by the memory speed, or database slowdown when the chain
   grows.

   One of the drawbacks of this mechanic is when the responders does not
   sign and respond, whether because it will/can not, there will be an
   orphan block.  While this is not a vulerability on itself, it might
   be the starting point of a certain type of attack (the other "normal"
   types of attacks used for blockchains can be mitigated, at elast to a
   certain level, as is described in Section 6.).  The adversary might
   let someone initiate a transaction an block creation, after which he
   will have to sign it.  But when he does not, it will create an
   orphan.  Doing this multiple times in a short timespan will force the
   requester to use a considerable amount of processing power and
   memory, all the while injecting orphan block into his chain.  As
   mentioned before, this is not a vulnerability in itself, but might be
   a launchpad for a more elaborate attack.  Though one coping method
   could be to split larger, more vulnerable transactions up into
   multiple smaller transactions.  This way the consequences stay the
   same for the malicious actor, but the losses are smaller.

5.  Consensus protocol

   To detect tampering or malicious practices, blockchain
   implementations rely on a consensus protocol, a method to verify the
   validity of transactions.  Most traditional blockchain
   implementations, such as Bitcoin (CITATION), rely on a so-called
   Proof of Work (PoW) to establish the validity before appending the
   block to the blockchain.  However, horizontal scaling has always
   remained an issue; creating a slowdown, or at least no speedup, when
   the number of nodes in the system grows.  Using the novel




Pouwelse                  Expires April 5, 2018                 [Page 7]

Internet-Draft             Trustchain protocol              October 2017


   architecture and its innate properties, there has been a development
   for a blockchain consensus protocol with horizontal scalability.

   TODO

6.  Attack resistance

   When dealing with trust, especially in an self-managed and peer-to-
   peer environment, unsupervised attack resistance is an important
   requirement.  Because Trustchain is a blockchain implementation, it
   will have to cope with the same difficulties and attacks that other
   blockchain implementations have to.  Some attacks and Trustchains
   resistance to them is detailed below, to give an insight how this
   novel approach can deal with attacks.

6.1.  Sybil attacks

   One of the most difficult attacks to repel for a blockchain is the
   sybil attack.  In a sybil attack, many peers are injected into the
   chain (where authenticity cannot easily be verified) to subvert a
   large portion of the systems trust.  Usually peer verification is
   used to cope with these attacks, such as proof-of-work validation by
   other peers, usually resulting in slow systems.  But when the
   influence of the attacker is large enough, even these methods will
   not be able to stop such an attack.

   Trustchain deal with this problem by having an inherently different
   structure, where each peer has its own chain.  On top of that,
   transaction injection can only be done with two valid signatures,
   meaning a sybil attacker can only create trust with himself.  This
   results in a network of interconnected chains that contains clusters,
   and outliers can easily be identified.  Even when the sybils acquire
   some degree of trust outside of their cluster, using accounting
   mechanisms the profit from such an attack can only be weakly
   profitably benficial with bounded profit (using Netflow, not
   discussed in this paper).

6.2.  Double spending attack resistance

   Using control over the blockchain to create a fork and creating two
   different transaction branches is called double spending.  This kind
   of attack can be applied with relative ease to single chain
   implementations of the blockchain.  Trustchain deals with this kind
   of attack by having the chain verified with each transaction, during
   with the hidden transaction can be easily found.  By broadcasting
   both block as a proof-of-fraud the malicious agent will have
   decreased trust and can be blacklisted or refused service.




Pouwelse                  Expires April 5, 2018                 [Page 8]

Internet-Draft             Trustchain protocol              October 2017


6.3.  Replay attack resistance

   Using the transaction signature of the counterparty, a malicious
   agent can try to replay a transaction on the blockchain.  The
   motivation for this can be increased trust since it has been in
   multiple transactions with a trusted party.  Trustchain copes with
   this attack by making it trivial to find the conflicting blocks when
   verifying the counterparties chain.  The two blocks with the same
   outgoing pointer together make the proof-of-fraud which then can be
   used to decrease the trust in the malicious party.

6.4.  Whitewashing attack resistance

   Abusing the permissionless structure of Trustchain to create
   additional identities at any given point can negate the effect of
   having trust.  When an agent suffers from reputation loss, it can
   simply discard his current identity and take on a new one.  Since
   refusing service to agents with little trust will affect usability
   and willingness to join the network, and adequate solution can be
   prioritizing strategies.  TODO maybe include allocation policy using
   netflow?

7.  Discovering the network using Random Walk

   TODO

8.  Acknowledgements to Brussels

   We very much thank the EU for providing us the required funding.  An
   estimated 3.4 million Euro has been granted through.

9.  IANA Considerations

   This memo includes no request to IANA.

   All drafts are required to have an IANA considerations section (see
   Guidelines for Writing an IANA Considerations Section in RFCs
   [RFC5226] for a guide).  If the draft does not require IANA to do
   anything, the section contains an explicit statement that this is the
   case (as above).  If there are no requirements for IANA, the section
   will be removed during conversion into an RFC by the RFC Editor.

10.  Security Considerations

   From a security perspective, the usage of novel structures such as
   Trustchain might lead to new kind of attacks.  We consider this risk
   of less importance for a private and consortium network, where all




Pouwelse                  Expires April 5, 2018                 [Page 9]

Internet-Draft             Trustchain protocol              October 2017


   participants are known to the operator and authentication mechanisms
   are used to restrict access to the network.

   For the public blockchain networks, the usage of Trustchain might
   lead to new kind of attacks.  For instance, an attacker might be able
   to pollute the chain with refusal to sign attacks to decrease trust.
   The scope of such attacks and security violations needs to be
   investigated and is not part of this draft.

   All drafts are required to have a security considerations section.
   See RFC 3552 [RFC3552] for a guide.  See RFC min_ref [min_ref] for a
   guide.  See RFC DOMINATION [DOMINATION] for a guide.

11.  References

11.1.  Normative References

   [min_ref]  authSurName, authInitials., "Minimal Reference", 2006.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

11.2.  Informative References

   [DOMINATION]
              Mad Dominators, Inc., "Ultimate Plan for Taking Over the
              World", 1984, <http://www.example.com/dominator.html>.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,
              <https://www.rfc-editor.org/info/rfc3552>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <https://www.rfc-editor.org/info/rfc5226>.

Appendix A.  Additional Stuff

   This becomes an Appendix.








Pouwelse                  Expires April 5, 2018                [Page 10]

Internet-Draft             Trustchain protocol              October 2017


Author's Address

   Dr. J.A. Pouwelse (editor)
   Delft University of Technology
   Delft
   Netherlands

   Phone: +44 7889 488 335
   Email: elwynd@dial.pipex.com










































Pouwelse                  Expires April 5, 2018                [Page 11]

[synctext]

We need a storyline focused on identity wallets+key attestation (self-sovereign ID). Out of scope: generic transactions, checkpoints, also perhaps distributed PageRank for spam/DDoS...

2017-06-02 (Friday): Cut-off date for BOF proposal requests to Area Directors at UTC 23:59. To request a BOF, please see instructions on Requesting a BOF. Full procedure

Oops:

        It cannot be emphasized enough that, for
         the BOF, drafts relating to understanding the problem space are
         much more valuable than drafts proposing specific solutions.
                                                 -RFC5434

[synctext]

correct, first part of doc would be BoF scheduling related: why and what. Second our solution plus protocol layout format.

[pimveldhuisen]

Could I please be unassigned from this issue, as I no longer intend to work on the RFC.

[synctext]

Goal is to document in IETF format what our architecture is and our running code.
Does not need to be accepted or lead at this stage to an RFC. After IETF specification we need to focus on uptake and maturity full-time. Document stack, related work, only bit-level specs for IPv8 and Trustchain. Checo not at bit-level.

• Introduction section is based on existing clean-slate work. Framing of our IPv8 and Trustchain plus CHECO approach is a new networking architecture. Like this Content-Centric Networking using PARC Research Fellow Van Jacobson 2006 ideas.

   This document describes the principles of the CCNx architecture.  It
   describes the network protocol based on two message types: Interests
   and Content Objects.  The description is not dependent on a specific
   wire format or particular encodings.  This section introduces the
   main concepts of CCNx, which are further elaborated in the remainder
   of the document.
[...]
   Protocol Overview
   CCNx is a request and response protocol to fetch chunks of data using
   a name.  The integrity of each chunk may be directly asserted through
   a digital signature or message authentication code (MAC), or,
   alternatively, indirectly via hash chains. 

• direction of storyline: protocol stacks are evolving for the past decades towards the business layers. Protocols such as {name non-blockchain protocols}, R3 Corda, and IOTA. This architecture covers the complete range of long-lived private identity, throw away personas, NAT traversal, onion routing, reputation tracking and decentralised bid/ask orderbooks. In short, creating new datagram delivery protocol up to open alternatives for eBay, Uber, and Airbnb rating and reputation.
• self-sovereign identity with zero-out ability of privacy sensitive info. Long-lived.
• persistent directory service and reputation tracking without platform-lockin. Result, spoofing, MITM protection when communicating. Plus end-point uncertainty using onion routing ability.
• Tamper-proof identity traffic graph. Count bytes exchanged or other metric to build a ledger of identity-to-identity traffic. Use this to calculate reputations and estimate reliability using transitive trust.
• A (single page?) description of active relevant working groups. Including both their maturity (HIP WG is 10 years old) in terms of documentation and code, possible openness to blockchain and our IPv8 code.

Copied from Padma IETF draft:
Some initiatives do not focus on re-architecting the Internet, but merely a DNS 2.0 service, as seen in this problem statement: support identity services in addition to enhancing existing identifier/location mapping and resolution services. However, this workgroup seems in severe trouble and will not be formed.

5.1.  LISP WG

   The LISP WG has been working on multiple mapping systems (ALT, DDT)
   for the LISP control plane and the primary function of this mapping
   system is to map and resolve the IDf to IP addresses (EID/RLOC
   mapping).  LISP WG is also looking at Casssandra and blockchain.
   Though some requirements are common,GRIDS has new specific
   requirements described in [IDEAS-REQ].

5.2.  HIP WG

   The HIP WG has based its IDy to IDf resolution service on DNS.
   Operational IDf to Loc for fast mobility with low latency is handled
   by HIP-RVS [RFC8005] and specific HIP Mobility Notification messaging
   [RFC8046].

5.3.  NVO3 WG

   The NV03 WG has been working on a mapping of VN names to VN IDs in
   the network virtualization space and their requirements differ from
   the wireless broadband requirements and cross-silo communications
   that have been mentioned in this document.

• Understanding and processing the comments of well known experts. For instance, this strong opposition against the fundamentals which will require documenting the "throw-away persona" approach and Tor-like onion routing integration.

group on the basis that it enables and seemingly encourages
embedding identifiers for humans as addresses. Doing so
would have significant privacy downsides, would enable
new methods for censorship and discrimination```

[svanschooten]

@synctext while writing I'm faced with some issues I thought we discussed:

• A different name for TrustChain (since we're using it for trust indexing, but it actually is implementation agnostic)
• This RFC is not really the place for either NAT traversal, onion routing, nor the tracking/decentralized market story.
• I thought we decided to drop entering a IETF workgroup since we don't really need the IETF, as long as we have our RFC?
• Should I move the implicit attack resistances to their own section or into the Security Considerations section?

[svanschooten]

At the moment my revised idea for the outline is:

1. Introduction
   1.1 Requirements Language
   1.2 Protocol Overview
   1.3 IPv8 Overview
   1.4 CHECO Overview
2. Block format
   2.1 A true half block
   2.2 Asynchronicity
3. Security
   3.1 Structural attack resistance
   3.2 Network attack resistance
   3.3 Reputation mechanism

I included the first writeup of these sections.
1-introduction.txt
2-block-format.txt
3-security.txt

[svanschooten]

Revised structure and rewritten story, current status:

• 1. Introduction
• 1.1 Requirements Language
• 1.2 Protocol Overview
• 1.3 IPv8 Overview
• 1.4 CHECO Overview
• 2. Block format
• 2.1 A true half block (needs updated block spec)
• 2.2 Asynchronicity
• 3. Security
• 3.1 Structural attack resistance
• 3.2 Network attack resistance
• 3.3 Reputation mechanism

1-introduction.txt
2-block-format.txt
3-security.txt
trustchain-ietf-rfc-v2.txt
trustchain-ietf-rfc-v2.xml.txt

[synctext]

IPv8 storyline inspiration text; copied from the David Irvine, Maidsafe paper:

Today’s overlay networks are based on operating
without hindrance of real world issues regarding connectivity
between nodes. This is not a problem when operating in a private
or controlled environment, but in the transition to peer to peer
or fully distributed networks, it becomes a major headache.
[...]
INTERNET technology allows the interconnect of every
device to every other device, in principle. In practice, this is
not the case and for many reasons devices tend to be behind
routers that allow them to go unnoticed or at least act as a
proxy device. This helps connect multiple devices to a single
publicly addressable IP location. The devices behind the router
may have private or classified private addresses and number in
thousands all connected to the Internet and appearing as one
single identity. The router will proxy requests and responses
in many cases to hide the devices.
NAT is a good solution for the lack of publicly available
IP addresses with the current incumbent scheme of IP version
4, IP version 6 will allow more than enough public addresses
to exist and in fact provide several addresses for every square
meter of the planet. Even with IP6, however there will still be
NAT devices around and NAT traversal will still be required.

Perhaps call it:

• Trustchain stack (overall ecosystem)
• Trustchain fabric (the core internal datastructure)

design idea: our security model is based on the following security assumption; repeated interaction with a public key owner creates a web-of-trust. This form of opportunistic encryption (RFC7435) comes for free, offers protection most of the time, and optional strong public key validation is highly encouraged.

1. introduction
2. architecture/layering/modules of Trustchain stack discussion:

• IPv8: overlay for identity, discovery and trust
• CHECO
• Trustchain fabric
• self-sovereign identity

3. Trustchain fabric block format specification
4. IPv8 overlay specification
   also reputation mechanism
5. Discussion of possible attacks

[svanschooten]

After re-structuring and re-writing a major portion of it, this is the latest version.
I'm still very much confused what I should write on IPv8 since I still have no clear vision of the inner workings or what it actually can do...

trustchain-ietf-rfc-v3.txt
trustchain-ietf-rfc-v3.xml.txt

[devos50]

@svanschooten please take a look at our technology stack/portfolio:

[qstokkink]

Your TrustChain information seems to be a bit out-of-date. I also have some low-level information available in IPv8 about TrustChain: https://github.com/qstokkink/py-ipv8/blob/master/doc/trustchain.md

Also, IPv8 does a lot of things. You should probably limit your scope to (1) using TrustChain to establish identity, (2) DHT-like peer discovery, (3) PKI and (4) peer-to-peer cryptographically signed messaging.

[svanschooten]

@devos50 @qstokkink Thanks a lot! I guess I was swamped with the plethora of new info, and lost sight of my target. I will look into this tonight.

Also, @qstokkink what do you mean exactly about being out of date?

[qstokkink]

@svanschooten the current block format is the following:

tribler/Tribler/community/trustchain/database.py

Lines 124 to 146 in f0dc3b3

	def get_schema(self):
	"""
	Return the schema for the database.
	"""
	return u"""
	CREATE TABLE IF NOT EXISTS blocks(
	tx TEXT NOT NULL,
	public_key TEXT NOT NULL,
	sequence_number INTEGER NOT NULL,
	link_public_key TEXT NOT NULL,
	link_sequence_number INTEGER NOT NULL,
	previous_hash TEXT NOT NULL,
	signature TEXT NOT NULL,
	insert_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL,
	block_hash TEXT NOT NULL,
	PRIMARY KEY (public_key, sequence_number)
	);
	CREATE TABLE option(key TEXT PRIMARY KEY, value BLOB);
	INSERT INTO option(key, value) VALUES('database_version', '%s');
	""" % (str(self.LATEST_DB_VERSION))

This uses generic transactions instead of the old bytes_up/bytes_down format. Serializing generic transactions is done by this file: https://github.com/Tribler/tribler/blob/devel/Tribler/Core/Utilities/encoding.py.

The wire format for the block payload also fits this (256 bytes fixed + variable block):

• 74 byte length string: (serialized) public key
• 4 byte unsigned int: sequence number
• 74 byte length string: (serialized) link public key
• 4 byte unsigned int: link sequence number
• 32 byte string: previous hash
• 64 byte string: signature
• 4 byte unsigned int: length in bytes of transaction block
• transaction block (of the length specified by the preceding int)

[synctext]

Comments:

• "3.2. A true half block", rename to micro-blocks, TxBlock or something. Section '3.2 TxBlock structure specification'?
• "2. Trustchain Stack", try to see if you are able to write a "2. Engineering trust" intro chapter on the re-volution taking place around trust enabling platforms. From Craigslist, Ebay to Uber and AirBnB. Central entities which create trust and rules for punishment of fraud and abuse. This draft defines a public non-profit open infrastructure alternative for these proven commercial platforms. This draft is meticulously designed to be trustless, avoids any single point-of-failure, and lacks any central authority, directory server or any other centrality in any form.
• "3.4 Consensus protocol and block format" CHECO, BFT, in (less than) a page.

[svanschooten]

@synctext revised section 2:

2.  Trustchain Stack: Engineering trust

   In essence, trust is a feeling of security, based on the belief that
   someone or something is knowledgeable, reliable, good, honest, and
   effective.  And since humans have a tendency to trust, the changing
   notion of trust, due to influences of technologies such as
   Craigslist, Ebay, Uber and AirBnB, has a major impact on our daily
   lives.  This draft defines a public non-profit open infrastructure
   alternative for these proven commercial platforms, called Trustchain.
   This draft is meticulously designed to be trustless, avoids any
   single point-of-failure, and lacks any central authority, directory
   server or any other centrality in any form.

   Trustchain is based upon a set of novel technologies that, when
   acting together, can create a new platform on which completely new
   ecosystems can be built.  The basis of this is the new architecture
   for the multichain stack, but in collaboration with other new
   technologies this is a truly novel and self-sufficient platform.  To
   simplify, the Trustchain is separated into the Stack; the overall
   ecosystem with all the layers and components which work together, and
   the Fabric; the actual trustchain structure.

   The basis for this Stack is how the platform is built from the ground
   up, to support the necessary methods and functionality to operate in
   a new and self-sufficient ecosystem.  First and foremost is the
   concept of a Self-Sovereign Identity (REF), which means that agents
   have full control over their identity data.  Based upon the
   assumption that these identities are persistent and secure, the new
   architecture (or Fabric) is designed to use Peer-to-Peer
   communication the increase the transaction throughput.  This
   communication is then based on the new networking overlay; IPv8,
   which handles peer discovery, making connections with them and peer-
   to-peer cryptographically signed messaging.  And to finally, to
   ensure that the network always is in a valid state, a new, seamlessly
   horizontal scaling, consensus protocol; CHECO.

[svanschooten]

I have revised a lot of the sections, but am still unclear how I should approach the IPv8 section. I don't think I know enough of how IPv8 works internally to create a clear explanation of how the PKI is organised or how peer identities are organised for DHT-ish discovery.

trustchain-ietf-rfc-v4.txt
trustchain-ietf-rfc-v4.xml.txt

[synctext]

Comments:

• make it almost as boring and extensive as our https://tools.ietf.org/html/rfc7574
• 3.2. TxBlock specification: what hash, what public key?
• Our IPv8 is a generic overlay. Feel free to recycle their storyline, it is similar to libp2p is the product of a long, and arduous quest of understanding -- a deep dive into the internet's network stack, and plentiful peer-to-peer protocols from the past. Building large scale peer-to-peer systems has been complex and difficult in the last 15 years, and libp2p is a way to fix that. It is a "network stack" -- a protocol suite -- that cleanly separates concerns, and enables sophisticated applications to only use the protocols they absolutely need, without giving up interoperability and upgradeability. libp2p grew out of IPFS, but it is built so that lots of people can use it, for lots of different projects.
• intro can use a re-write.
• 1.1 section, but 1.2 is missing
• Read their stack: http://news.ycombinator.com/item?id=15816729
• add "spam attack" + DDoS.
• terminology: personal blockchain, our 2012 idea is rediscovered by https://www.skycoin.net/whitepapers/

[svanschooten]

I have completed a (almost) complete rewrite of the draft after diving a bit deeper in IPv8.

trustchain-ietf-rfc-v5.txt
trustchain-ietf-rfc-v5.xml.txt

[synctext]

Quick scan... Becoming quite mature, nice.
TxBloxk message types, TeustChain, noetworking ? :-)

First and foremost is the concept of a Self-Sovereign Identity (SSI)
Then again, repeat of entire paragraph.
First and foremost is the concept of a Self-Sovereign Identity (SSI)

true half block format, more of an internal ugly name. Please do us the honor and give a nice name to this block format in your IETF text?

The overview could use something more high-level. Feel free to adjust&copy this text:

We are fans of Bitcoin, but also showed in [an early analysis](http://www.pds.ewi.tudelft.nl/~victor/bitcoin.html) the flaws in this concept.
Our approach to digital signatures is the essential difference which sets us apart from others.
Mono-signatures form the foundation of all other projects we have seen in the past decade.
Meaning, in systems such as Bitcoin a transaction is already valid with a single signature.
Our Trustchain design does not permit transactions with merely a single signature.
Trustchain only supports multi-party agreement recording, others are not valid.
We believe that we created a more powerful system by removing single-signature transactions. 
Only time can tell the usefullness of this academically-pure and minimal design.

[svanschooten]

@synctext Thanks for the quick reply! Will put it through a spellcheck this evening after a bit of rewriting. Any suggestions for the true half block format renaming?

[svanschooten]

Having done another retouching and rewrite of some sections based on the feedback:

trustchain-ietf-rfc-v5.txt
trustchain-ietf-rfc-v5.xml.txt

Have not had a brilliant idea about renaming the true half block format but that will come.

[svanschooten]

And another round of rewriting and had an idea about renaming the true half block format to CoopBlock format since it defines the need to cooperate with all participating parties to complete a signed and valid block. Added the exerpt on our motivation in the intro, after a light retouch.
Also added an attestations subsection after reading the paper on Attestations (thanks for including it @qstokkink !).

trustchain-ietf-rfc-v5.txt
trustchain-ietf-rfc-v5.xml.txt

[synctext]

Came up with something which has the ring of even less importance and validity: block-proposal and with valid signatures block-pair. It is intuitive that a mere proposal has no standing and validity, exactly what we want to convey. Please update the docs if possible. btw first citation use pouwelse2017trustlaws, not pauwelse2017trustlaws.
IETF Upload check also goes OK, only minor issues, https://tools.ietf.org/tools/idnits/idnits.pyht

We might want to upload it officially at 14:00 today.

[svanschooten]

In my opinion block-pair indicates that it applies to two participants, whereas there could be more, but it does apply better to the situation. Anyhow:

draft-pouwelse-trustchain-05.txt
draft-pouwelse-trustchain-05.xml.txt

[synctext]

agreement-block?

ToDo: Add decentral market layer.
This layer is optional in our stack and could be replaced with a layer to count bytes within a manet

1.  Introduction
   We are fans of Bitcoin,

Replace chapter 1 this with multi-page trust intro sent by email.
Chapter 2 can remain same, just shorten the 1st paragraph a bit then. Not repeat the Craiglist, eBay point.

Next meeting: upload to IETF.org ?

Thesis brainstorm: channel editor, fake news, smartphone vloggers, "channel has 8005 votes, 0 fakes reports"; Scientific challenge: produce trustworthy metadata by using crowdsourcing, channel moderations and channel votes with trustchain PageRank-something. Clickbait thesis title: "Trustworthy metadata in the age of fake news". MvP: channel-vote setting (on/off): "ignore channel votes X hops away in Trustchain traffic graph".
Warning: we need this in 2019.

[svanschooten]

Done with quoting and references, introduction and sec. 1 from chp. 2 are reformatted.
Application layer added.

draft-pouwelse-trustchain-06.txt
draft-pouwelse-trustchain-06.xml.txt

[svanschooten]

Faulty syncing and non-spellchecked version aside:

draft-pouwelse-trustchain-07.txt
draft-pouwelse-trustchain-07.xml.txt

[synctext]

Official IETF publication: https://datatracker.ietf.org/doc/draft-pouwelse-trustchain/?include_text=1

.xml sources

[arvidn]

Interesting read! I spotted a few typos:
page 7: "verify the correctness of the transaction in stead of a central" (should be "instead")
section 3.4: " as wel as an extension" (should be "well")
section 3.4: "protocol, after which te results are broadcast" (should be "the")

[xoriole]

Added a sub section under Trustchain Fabric: internal data structure in the RFC to include the double signature scheme to prevent double spending.

3.4. Double signature scheme

   TrustChain employs a double signature mechanism using two different
   curves for transaction validation and double spending prevention.  A
   transaction block is only valid if it includes valid signatures from
   the participating parties.  For this, the validity of the transaction
   block is checked by the signature based on Curve25519 curve
   [curve25519].  The Secp256k1 curve [sec2-v2] signature is used to
   enforce a punishing mechanism for fraudulent signers who commit
   double spending.  The choice of Curve25519 curve was made to benefit
   from its high performance and deterministic nature while Secp256k1
   curve was chosen specifically to exploit the vulnerability of ECDSA
   using deterministic signing secret.

   ECDSA signatures [ECDSA] are probabilistic and multiple signatures
   can be generated for a single message from a single private key (d)
   if signed with different signing secrets (k).  A signature is
   represented as a tuple (r, s) where the value of r is deterministically
   derived from the signing secret k.

   In TrustChain, the signing secret is generated deterministically
   using the SHA256 hash of the signer private key and the block
   sequence number as k = SHA256(private_key|block_sequence_number).
   This implies that a double spent transaction block will have the same 
   signing secret and thus the same 'r' value of the signature as that of the 
   original transaction block.

   Consider two double spent transaction blocks with the hash values t1 and
   t2, then the generated signature for the blocks look like (r,s1) and
   (r,s2) given a common signing secret k and the private key d.  

   From these signatures, one can efficiently recover the signing secret and
   the signer private key using these simple equations: 
                         k = (t1 - t2)/(s1 - s2); 
                         d = (s1 * k - t1)/r

   This double signature scheme acts as a nuclear backdoor for enforcing
   honest participation and preventing users from committing frauds as
   they essentially risk leaking their own private keys upon double
   spending.

xml-sources

[DanGraur]

Extended the IETF standard with section 4.2.1. Technical view of Attestations and Verifications. This section has many subsections, which might require that it be moved upwards to make the referencing more understandable. Moreover, I've written this over the official IETF publication, so it does not have the 3.4. Double signature scheme. This might need to be added manually.

draft-pouwelse-trustchain-08.txt
draft-pouwelse-trustchain-08.xml.txt

[synctext]

Thnx Dan. Bumped version number and published at: https://datatracker.ietf.org/doc/draft-pouwelse-trustchain/

Decided to ignore these:

WARNING: artwork outdented 3 characters to avoid overrunning right margin around input line 539)
WARNING: Output line (from source around line 540) is 84 characters; longer than 72.  Excess characters: '-----------+':
  '+--------+---------------------------------+----------------------+----------------+'

WARNING: Output line (from source around line 806) is 84 characters; longer than 72.  Excess characters: '-----------+':
  '+--------+-----------------------------------+----------------------+--------------+'

Created file pouwelse-trustchain-02.txt

[DanGraur]

Extended the IETF standard with section 4.2.1.4 Attestation Challenge. This section focuses on the Attestation Challenge interaction, which follows after the Attestation Verification.

draft-pouwelse-trustchain-01.txt
draft-pouwelse-trustchain-01.xml.txt

[qstokkink]

@ichorid could you give section 4 of the IETFv1 (draft-pouwelse-trustchain-01.txt) a review, if/when you have time?

[synctext]

Scalability related we should add at some point: OmniLedger: A Secure, Scale-Out, Decentralized Ledger via Sharding

[synctext]

Easy to read definition:
Trustchain facilitates tamper-proof and secure cross-organizational data sharing via a simple append-only datastructure.
(Thnx Nucypher for inspiration)

[synctext]

ONLINE: https://tools.ietf.org/id/draft-pouwelse-trustchain-01.html

This is now an expired Internet Draft and could use an update. That would be for a fresh Github issue, closing this one now.