child of #45

child of #32

Server-client API for communicating with Tari base nodes

Describe the necessary extensions to Mimblewimble enabling time-locked transactions (as opposed to time-locked outputs) which allow the development of time locked contracts (useful for e.g. Atomic Swap contracts)

Base Node service that receives candidate blocks and checks that the block is valid according to this node.

BlockValidation doesn't do much beyond TransactionValidation. Essentially:

• Proof of Work Validation (#301)
• Other header-data checks (Cumulative excess checks, MMR roots, coinbase transaction checks

Several definitions on public key and secretkey are repeated. These should be factored out

Describe how a Validator Node registers itself on the base layer.

child of #34

From RFC-150:

Different methods for recovering the wallet state of the Tari software wallet:

• It MUST be able to reconstruction the wallet state from a manually entered master seed key.
• It MUST have a mechanism to systematically search through the Tari blockchain and mempool for unspent and unconfirmed transactions using the keys derived from the master key.

child of #34

Provides functionality for a wallet to build, sign and verify transactions to be sent to the network

from RFC-150:

• It MUST be able to send and receive Tari coins using Mimblewimble transactions.
• It SHOULD be able to... negotiate the construction of a transaction and the signing of multi signature transactions.

Describe how clients can discover which assets are being managed on the network and the basic ways of interacting with them.

child of #41

• A User must be able to provide a set of seed words to derive a master key
• A user should be able to import a master key directly
• A master key can be generated randomly in a cryptographically secure manner
• A set of seed words can be generated from a known word list in a cryptographically secure manner

child of #34

From Wallet RFC:
It MUST be able to establish a connection to a Base Node to submit transactions and monitor the Tari blockchain [for transaction relevant to me]

Create RFC taking on node syncing

Describe the mechanism for Asset Checkpoints. To make up for the fact that the DAN has no proof-of-work and therefore has lower degrees of trustlessness and decentralisation; VN committees must provide checkpoints on the base layer from time to time. These checkpoints are, amongst other things, immutable commitments to the state of an asset at a point in time.

child of #41

KeyManager must deterministically generate keypairs based on the master key.

Keys generated this way should be tracked in an array / lookup table

TBH I think HD keys are overrated. They produce a huge search space if conventional paths aren't used; and I've never spoken to anyone who actually uses them. Unless there are good arguments to the contrary, I propose a linear deterministic pattern (e.g. just hashing the last key used).

child of #32

Base Node UTXO manager for the Tari UTXO set. The UTXO set describes all spendable Tari coins and along with the block headers and transaction kernels, is sufficient to describe and verify the full Tari state

provide a general, easy to use API for building aggregated signatures

Provide one Implementation using Schnorr signatures

We should have automated test coverage tooling built into out CircleCI automation

Validate new transactions when nodes receive them.

Transaction already has internal consistency code (commitments sum to the excess, range proofs hold, signatures are valid etc).

This issue requires blockchain validation:

• All inputs are in the current UTXO set.
• Spending locks are satisfied
• Any other feature checks

Provide an easy-to-use API for generating n-of-n multisig operations

Related to #199
Child of #42

Provide an easy-to-use m-of-n multisig API (it may make sense to unify this into #64)

And provide an implementation

child of #32

Implementation of the Tari unconfirmed transaction pool

child of #45

Basic structs and traits for Tari blocks

Set up the UTXOManager type that essentially exposes an API for handling UTXOs. Most of this functionality will already be handled by the underlying MRR:

• Check whether a given UTXO is in the given set.
• Rewind the UTXO set to a given block height (requires #288)
• Prune the set beyond the pruning horizon
• "Delete" UTXOs when they get spent
• Filter UTXO set according to specific features (VN node registration / Coinbase whatever)

Provide an easy-to-use API for range proofs

Since there are several implementations of range proofs, the implementation should be generic, with at least one (preferably bulletproofs) implementation being provided

Following a good discussion on #tari-dev, we need a proposal for all the network communication protocols in the Tari network. Based on the #tari-dev chat, it seems like we could potentially build the entire
network on:

• A single kademlia-like DHT for discoverability; with P2P comms using zMQ/Curve (as previously discussed), optionally
  wrapped in Tor (at node's discretion)
• A Tor/Dandelion privacy-preserving feature for base layer TX propagation feeding into a standard gossip protocol (with
  a BNs maintaining a large list of peers. Alternatively also use a DHT for building this list)

Specifically, actor <-> actor comms might look like

BN = Base Node
W = Tari Coin Wallet
VN = Validator node on DAN
AM = asset manager on DAN

In general all the P2P comms could optionally be tunneled through something like Tor to hide your IP from peers

However, there's a lot of detail missing here and plenty of unanswered questions that could benefit form the rigour of an RFC document

child of #44

• Write abstraction layer to easily allow exporting of wallet data to any given format (likely dup of part of #55).
• Exported files should be password protected
• Write a JSON format export implementation. All byte arrays should be converted to hex strings

Tari Base Node implementation

Describe the details of the DAN VN consensus algorithm.

Create RFC detailing what is required of an archive mode

child of #34

Provides functionality for Key generation, storage, and reconstruction

Tari-Monero merge mining implementation

Base layer wallet software

Metadata

This proposal is (tick applicable):

• A new feature
• An extension to an existing RFC/proposal
• An alternative approach to an existing RFC or proposal

Change log

Goals

This document will propose the functionality and techniques required by the base layer Tari software wallet.

Assumptions

• A working implementation of a base layer full node.
• A Tari blockchain implemented using Mimblewimble.

Abstract

The Wallet software is responsible for constructing and negotiating transactions for transferring and receiving Tari coins on the base layer. It should also provide functionality to generate, store and recover a master seed key and derived cryptographic key pairs that can be used for base layer addresses and signing of transactions.

Description

A detailed description of the required functionality of the Tari software wallet is provided in three parts: basic functionality, maintaining of private keys and wallet recovery.

Basic functionality required of the Tari software wallet:

• It must be able to send and receive Tari coins using mimblewimble transactions.
• It should be able to establish a connection between different user wallets to negotiate:
  - the construction of a transaction and
  - the signing of multi signature transactions.
• The Tari software wallet should be implemented as a library or API so that GUI or CLI applications can be constructed on it.
• It requires a local or remote connection to a base layer full node to submit transactions and monitor the Tari blockchain.
• It should maintain an internal ledger to keep track of the Tari coin balance of the wallet.
• It should be able to estimate and calculate transaction fees taking into account:
  - transaction byte size,
  - network congestion and
  - the desired transaction priority.
• It needs to monitor and display the states (Spent, Unspent or Unconfirmed) of previously submitted transactions and wallet addresses by querying information from the connected full node.
• The wallet software should be able to update its software to patch potential security vulnerabilities. Automatic updating will be selected by default, but users can decided to opt out.
• Wallet features requiring querying a full node for information, should have caching capabilities to reduce bandwidth consumption.

Required functionality related to the maintaining of the master seed key and derived private cryptographic keys:

• It should be able to generate a master seed key for the wallet by using:
  - the manual input from a user such as letting the user use a visual randomisation tool to generate the seed or
  - an entropy seeded random number generator.
• It should be able to generate derived transactional cryptographic key pairs from the master seed key using Hierarchical Deterministic key pair generation.
• It should store the wallet state using a password or passphrase encrypted persistent Key-value database.
• It should provide the ability to backup the wallet state to a single encrypted file to simplify wallet recovery and reconstruction at a later stage.
• It may provide the ability to export the master seed key or wallet state as a printable paper wallet using coded markers.

Different methods for recovering the wallet state of the Tari software wallet:

• It should be able to reconstruction the wallet state from a manually entered master seed key.
• The master seed key should be derivable from mnemonic word sequences using known word lists.
• It should enable the reconstruction of the master seed key by scanning a coded marker of a paper wallet.

child of #45

Describe the details of the multi-party contracts that VN committees enter into to allow them to register new asset multiparty contracts on the base layer.

Provide an easy-to-use API for "messages".

Messages are anything that can be represented as a byte string (blobs, text strings, numbers).

Messages can be concatenated

Messages must be hashed (the actual hash function is decoupled from the message implementation) into a Challenge before being used in signatures etc.

child of #33

Provide a HomomorphicCommitment type/trait.

Implement a PedersenCommitment with a composable backend (i.e. the Curve and Generator points should be easily configurable)

child of #32

Outlining the structure and architecture for the Tari base node. See RFC-0110

Do it already!!!

A high-level overview of Validator Nodes' responsibilities on the DAN

child of #34, child of #44

• Write abstraction layer for wallet persistence
• Add LMDB support for wallet persistence
  • Keys
  • UTXOs

child of #45

Basic struct & traits for Tari Transactions

Describe the process for Top Level Digital asset Issuer (TLDI) registration on the Tari base layer.

Tari base layer (Tari Coin) wallet implementation

Provide a easy-to-use API for Schnorr Signatures, independent of underlying EC

child of #33`

Provide a easy-to-use API for partial signature generation, verifying and aggregating

PeerManager

As per RFC-0172:

The PeerManager's responsibility is to manage the list of peers that the node has previously interacted with. This list is called a routing table and is made up of Peers.

The PeerManager can

• add a peer to the routing table,
• search for a peer given a public key or NetAddress,
• delete a peer from the list,
• persist the peer list using a storage backend,
• restore the peer list from the storage backend,
• maintain lightweight views of peers; using a filter criterion; e.g. a list of peers that * have been banned (i.e. a blacklist),
• prune the routing table based on a filter criterion (e.g. last date seen)

child of #32
child of #135

The peer manager for Tari base nodes

Implement MuSig as an aggregated signature scheme.

Requires #64, requires #62