Hallo, Gast
Sie müssen sich registrieren bevor Sie auf unserer Seite Beiträge schreiben können.



Durchsuche Foren

(Erweiterte Suche)

» Mitglieder: 627
» Neuestes Mitglied: olytovuv
» Foren-Themen: 41
» Foren-Beiträge: 53


Aktive Themen
MCP05 - Workflow
Forum: MCP
Letzter Beitrag: FireMail
28.10.2017, 15:10:56
» Antworten: 0
» Ansichten: 175
[MC] BTT Ankündigung
Forum: Neuigkeiten
Letzter Beitrag: FireMail
24.10.2017, 12:14:13
» Antworten: 0
» Ansichten: 487
[MC] BTT Announcement
Forum: News
Letzter Beitrag: FireMail
24.10.2017, 12:13:04
» Antworten: 0
» Ansichten: 423
[DEV] CW 39/17
Forum: News
Letzter Beitrag: FireMail
29.09.2017, 12:06:04
» Antworten: 0
» Ansichten: 192
Forum: Neuigkeiten
Letzter Beitrag: FireMail
29.09.2017, 12:01:31
» Antworten: 0
» Ansichten: 177
MCP04 - Proof of Process
Forum: MCP
Letzter Beitrag: FireMail
22.09.2017, 12:49:12
» Antworten: 0
» Ansichten: 205
MCP03 - Blocks and Transa...
Forum: MCP
Letzter Beitrag: FireMail
22.09.2017, 12:47:34
» Antworten: 0
» Ansichten: 128
[DEV] CW 37/17
Forum: News
Letzter Beitrag: FireMail
15.09.2017, 17:49:22
» Antworten: 0
» Ansichten: 143
MCP02 - MetaChain and Sub...
Forum: MCP
Letzter Beitrag: FireMail
15.09.2017, 17:39:28
» Antworten: 0
» Ansichten: 175
[DEV] CW 36/17
Forum: News
Letzter Beitrag: FireMail
09.09.2017, 13:07:43
» Antworten: 0
» Ansichten: 109

  MCP05 - Workflow
Geschrieben von: FireMail - 28.10.2017, 15:10:56 - Forum: MCP - Keine Antworten


Every SubChain needs to have some kind of workflow - otherwise the SubChain is without functionality and useless. The different workflows can range from currency based transaction, voting, alias, messaging service and so on. Below you find a categorization in which the different workflow modules can be split up.
The workflows are loaded like the MCP04 PoPs in a factory design pattern. In order to launch a new subchain, the requested workflows from the genesis block must be present, otherwise this subchain will not synchronize. Workflows can be added later into an existing subchain by issuing a special command through the TCT Blockchain by the subchain owner.

Every SubChain must have a category 1 workflow present in order for the MCP04 PoP to work. Every MCP05 registers their categories and network bits into the SubChain Manager to be able to receive and send network commands.
A SubChain can contain 1,n Workflows

List of categories:

  1. Chain Entity (e.g. transaction based currency)
  2. Voting
  3. Alias
  4. Messaging Services
  5. Smart Contract Engines
  6. tba
  7. tba
  8. tba
  9. other
MCP05 is under heavy development and information / implementation can change. More information about development and stubs will be posted here soon

Drucke diesen Beitrag

  [MC] BTT Ankündigung
Geschrieben von: FireMail - 24.10.2017, 12:14:13 - Forum: Neuigkeiten - Keine Antworten

Grüß euch,

wir haben gestern auf Bitcointalk unsere MetaChain Technologie angekündigt. Ihr könnt den Beitrag dort unter folgender Adresse finden: https://bitcointalk.org/index.php?topic=2308773.0

Wir freuen uns schon auf angeregte Diskussionen

Drucke diesen Beitrag

  [MC] BTT Announcement
Geschrieben von: FireMail - 24.10.2017, 12:13:04 - Forum: News - Keine Antworten

Hey guys,

we published our Bitcointalk Announcement for the MetaChain Technology yesterday. You can always review it here: https://bitcointalk.org/index.php?topic=2308773.0

Looking forward to great discussions

Drucke diesen Beitrag

  [DEV] CW 39/17
Geschrieben von: FireMail - 29.09.2017, 12:06:04 - Forum: News - Keine Antworten

Last week we didn't publish a DEV news, since there was too much going on and we wanted to make sure that the development is finished before releasing these big news.

Zitat:2017-09-28 14:33:23: [INFO]  [SCM] Registering new proof of process: PoMC
2017-09-28 14:33:23: [INFO]  [SCM] Registering new proof of process: PoS
2017-09-28 14:33:23: [INFO]  [SCM] Registering new proof of process: PoT
2017-09-28 14:33:23: [INFO]  [SCM] Generating MetaChain genesis block
2017-09-28 14:33:23: [INFO]  [SCM] MetaChain genesis block hash is: b7495d27e05eea0c718db9bad093af4f8fec8870f8eb5a80097f33be1116e6a2
2017-09-28 14:33:23: [DEBUG]  [SCM] MetaChain Genesis block contents: Block (Hash=b7495d27e05eea0c718db9bad093af4f8fec8870f8eb5a80097f33be1116e6a2, Version=0x00000001, hashPrevBlock=0000000000000000000000000000000000000000000000000000000000000000, hashMerkleRoot=ee2af5bf597b0ca2ed7266b614293d118986b2cf17cc2609ff63ea4f79c52050, Time=1506343480, Byte=00000051)
  mcTransaction(Hash=575b541b79, Version=1)
    mcTxIn(Action 1
Params(caChainName MC, caPoP PoMC, uint64tMaxCoins 0)

The MetaChain has now officially generated its genesis block!

Furthermore the papers MCP03 and MCP04 have been finalized and updated. These are big news since we're now able to attach new SubChains into the MetaChain and can fully concentrate on the development of the SubChains.

Changes in the MetaChain repository: https://github.com/TrustChainTechnologie...9-29-17%7D

Drucke diesen Beitrag

Geschrieben von: FireMail - 29.09.2017, 12:01:31 - Forum: Neuigkeiten - Keine Antworten

Dank der Community ist das Whitepaper nun auch auf Deutsch übersetzt auf unserer Homepage unter https://www.tct.io in der Kategorie Downloads verfügbar

Drucke diesen Beitrag

  MCP04 - Proof of Process
Geschrieben von: FireMail - 22.09.2017, 12:49:12 - Forum: MCP - Keine Antworten


This MCP defines the individual handling of special subchain needs and their creation.
When talking about "special needs" we refer to Proof of Process and special implementation in those proof algorithms.

A stub file is available as implementation reference:

namespace MCP04
    // this is just a stub for reference
    // if you want to build your own proof of process, use this stub as a template
    // never use this class directly
#error Never include stub.h directly or use it!

    class STUB : public ChainInterface
            static const std::string            m_strName;

            static bool                            registerFactory() { return ::MetaChain::getInstance().getStorageManager()->getSubChainManager()->registerFactory(m_strName, &createInstance); };
            static bool                            registerFactory(MCP02::SubChainManager *ptr) { return ptr->registerFactory(m_strName, &createInstance); };
            static ChainInterface                *createInstance() { return new STUB(); };

            MCP03::Transaction*                    createTXElement() { return new MCP03::crTransaction(); };
            MCP03::Block*                        createBlockElement() { return new MCP03::crBlock(); };

Use the newest stub.h file from the repository when developing a new PoP algorithm. The mentioned functions in the stub override two pure virtual functions from ChainInterface and add static functions. All these functions must be present in order for the new PoP to work!

The PoP uses a function factory design in order to achieve dynamic addition and creation of PoP through the SubChainManager.
Block- and Transactionelements will be created through the overridden functions createTXElement() and createBlockElement() in order for every PoP to have custom Blocks and Transaction implementations.

m_strName: initialize the name of this PoP. This must be unique, otherwise the SubChainManager will not load this PoP.

Standard implementations of PoS, PoW and PoT can be found in the repository. A special implementation for PoMC (Proof of MetaChain) is also available and shows how heavily this system can be changed by providing unique Blocks, Transactions and references.

Drucke diesen Beitrag

  MCP03 - Blocks and Transactions
Geschrieben von: FireMail - 22.09.2017, 12:47:34 - Forum: MCP - Keine Antworten


This MCP defines the standard handling of blocks, transactions, in and outcoming data.
MCP03 consists of the definitions of interfaces for block and transaction handling, as well as a default implementation for currency transactions.
This post is just a reference, please look at the files directly since they may contain new implementations or comments.

By using interfaces and not fixed implementations we allow future developers to use these interfaces and abstract their own Blocks and Transactions since they may not need coins or currency values. An example would be mcBlock.h and mcTransaction.h from MCP04::MetaChain, which is an implementation of a coinless blockchain where every transaction results in a forged block.

Currency based implementation (crBlock.h and crTransaction.h) use the known principle of incoming and outgoing TX per transaction with refs to old TX in order to achieve blockchain like behaviour.
One Block consists of n Transactions. One Transaction consists of n Input TX and n Output TX. Every Input TX has a reference to an old Output TX.

Block Interface

namespace MCP03
    class Block
                                                                Block(uint16_t Version)
                                                                    uint16tVersion = Version;
                                                                    nTime = 0;
                                                                    uint32tByte = 0;

            // general settings for all blocks
            uint16_t                                            uint16tVersion;
            uint256                                                hashPrevBlock;
            uint256                                                hashMerkleRoot;
            uint256                                                hash;
            uint32_t                                            nTime;
            uint32_t                                            uint32tByte;

            // calculation functions
            virtual void                                        calcMerkleRoot() = 0;
            virtual void                                        calcSize() = 0;
            virtual void                                        calcHash() = 0;
            virtual void                                        calcAll() { calcSize(); calcMerkleRoot(); calcHash(); };

            // simple getter and setter
            virtual bool                                        isEmpty() { return (uint32tByte == 0); };
            virtual std::string                                    toString() = 0;
All derivered blocks need to be based on MCP03::Block!
The Block interface consists of a few variables that are needed to be processed as well as virtual functions that require implementation.
In this interface the block has no transaction vector - this needs to be implemented in the derivered class.
Also a serialization method needs to be implemented in order for the block to be stored.
See crBlock.h as implementation example for a currency based block.

Transaction Interface

namespace MCP03
    class Transaction
                                                Transaction(uint16_t Version) { uint16tVersion = Version; };

            // general settings for this transaction
            uint16_t                            uint16tVersion;

            // simple getter and setter
            virtual uint256                        getHash() = 0;
            virtual bool                        isEmpty() = 0;
            virtual uint64_t                    getValueOut() = 0;
            virtual uint32_t                    getTotalSize() = 0;
            virtual std::string                    toString() = 0;

All derivered transactions need to be based on MCP03::Transaction!
See crTransaction.h for an example as implementation for currency based transactions.

Drucke diesen Beitrag

Information [DEV] CW 37/17
Geschrieben von: FireMail - 15.09.2017, 17:49:22 - Forum: News - Keine Antworten

Changes in the metachain repository: https://github.com/TrustChainTechnologie...9-15-17%7D
Changes in the metachain-utils repository: https://github.com/TrustChainTechnologie...9-15-17%7D


  • improved network communication by expanding the protocol with TESTNET, MODE and LISTENING SOCKET flags
  • improved communication with FN (which are configured through their .ini)
  • storing of incoming connections of FN
  • added MCP01, MCP39 into the node including connection between a base wallet and the node (required for staking etc.)
  • some linux compability changes and improved autobuild scripts
  • started implementing MCP02 (MetaChain and SubChains) into the node.
  • added serialized Meta Database storage of SC within MC
  • KeyGen: reimported changes in the implementation made when adding MCP01 and MCP39 into the node
  • SHA3: added unix build scripts and compability changes
  • added new developer "crowi"
  • started developing deploy script for binary releases
Due to these heavy changes the node.ini has now following options:

Zitat:; INI file for configuration of the TrustChainTechnologies MetaChain node
daemonize = true
; CAUTION: when [testnet] is true, the port from [network].[listening_port] will be increased by 100 to ensure a different port from the mainnet
testnet = true
; fn is full node (storing all blockchain data), cl is client (storing only lightweight information)
mode = fn
; [wallet] is the connection between a node and a wallet. This needs to be a base wallet (subchain identifier = MC). All Po* (PoS, PoT etc.) will work with this address and send the rewards to this wallet
wallet =

log_to_stdout = true
log_to_file = true
log_file = output.log

listening_ip = *
listening_port = 5634
peer_file = peers.dat
ban_file = bans.dat
connect_timeout = 5000
max_outgoing_connections = 1000
max_incoming_connections = 1000
time_between_unsuccessfull_connects = 30

; will be overridden by [general].[testnet] to 1
ticks_until_update_triggered = 10
enable = false
autoupdate_on_start = false
cdn_url    = https://cdn.tct.io/
; can be relative or absolute path
tmp_dir = tmp

; can be relative or absolute path
data_dir = data

; only required when mode = fn, path relative to [data].[data_dir]
raw_dir = raw
raw_filesplit = 100

; rdb = rocks db, mysql = mysql db
storage_engine = rdb

; the following is only needed for [data].[storage_engine] = rdb
; dir relative to [data].[data_dir]
dir = rdb

; the following is only needed for [data].[storage_engine] = mysql
; the database needs to be initialized with the mysql data structure provided
; the user needs to be setup and have the full rights for this database
; "socket" for socket connection, "tcp" for [host]:[port] tcp/ip connection
connection_type = socket
socket = /var/lib/mysql/mysql.sock
host = localhost
port = 3306
username = trustchaintechnologies
password = Sup3r$3cr3tPw
database = metachain

Drucke diesen Beitrag

  MCP02 - MetaChain and SubChains
Geschrieben von: FireMail - 15.09.2017, 17:39:28 - Forum: MCP - Keine Antworten


MCP02 describes the technical handling of the MetaChain (MC) and the SubChains (SC).
Since this is currently under heavy development, we'll update this document frequently.

Workflow of MC and SC

The MetaChain itself has no proof of process but changes in the MC are stored in their own blocks. The only SC that can make changes in the MC is the TCT SC. This means that with the Proof of Trust, actions can be set, processed and proven that reflect directly on the MC. Changes from other SC will be disregarded - modifying of this hardcoded process so that other SC modify MC parameters will result in a fork.

Whenever a command from TCT is processed in the MC a new MC block is forged and linked against the last blocks to ensure integrity of the MC chain. The MC commands are limited to the following:

  • creation of a new subchain
  • closing of an existing subchain*
  • changing of certain parameters of a subchain*
* ... this can only be done by the owner of the SC, which is linked with his credentials upon creation

SC Creation process

After the creation command with specified parameters is processed through TCT and PoT, the SC will be created. The creation process triggers new entries in the MetaDB followed by a genesis block for this SC. The SC will then continue to run in the MC with their own blockfiles and metainformations. On creation the proof of process must be selected - this can range from standard proof concepts which will be delivered and enabled by default, or with custom modules. A naming convention on how to create a custom process with custom modules will be released later.

If a special module is required to run the SC, the information will be spread through the network to all FN, but the FN will not participate in this SC until the custom module is loaded. This has to be done manually to ensure the security of the FN.

SC specific communication

This is only valid for custom modules, since regular modules will use standard calls and communication flags as described in their implementation.
As taken from the file src/network/netMessage.h:

* we use a hex coding scheme to categorize our actions for easier splitting into groups.
* the following binary scheme will be used globally and updated every single time we add new categories and subjects
* the first bit in the category is reserved for special communications within the SC modules. To use special communications set the first bit to 1
* 0 0 0 0        0 0 0 0        0 0 0 0        0 0 0 0
*    8bit CATEGORY         |    8bit SUBJECT
This means that if a module requires special communication, the netMessage header category bitfield must be set accordingly.
For Example: 1 0 0 0 as the first 4 bits.
This enables the SC developers to use a full range of 128 categories with each 256 subject lines - or if the category<->subject splitting is overridden to a different mapping technique, a full range of 32.768 custom commands can be adressed. Standard commands, like sending, checking etc. can be used from the standard implementations and therefore these are not needed to be implemented manually.

Process of a FN sync

When a new FN is started, a standard MC genesis block and TCT genesis block will be created and checked for consistancy. After connecting to enough other FN to ensure a stable sync the following process will be done:

Drucke diesen Beitrag

Information [DEV] CW 36/17
Geschrieben von: FireMail - 09.09.2017, 13:07:43 - Forum: News - Keine Antworten

Changes in the metachain repository: https://github.com/TrustChainTechnologie...9-09-17%7D
Changes in the metachain-utils repository: No changes


  • Implemented and tested AutoUpdate functionality for Windows and Linux
  • Linux compability changes
  • autoconf and automake updates for dynamic and static linking
This might seem as a minor and small weekly progress but in fact this one is huge. We've now officially started our testnet, which status can be found here: https://status.tct.io
Right now this is a small network of trusted systems that we need to debug and work with. Please don't build your own nodes and connect them to our testnet - as soon as this is helpfull and sensefull, we'll publish tutorials on how to use or build your own nodes.

Drucke diesen Beitrag