tari-project / rfcs Goto Github PK
View Code? Open in Web Editor NEWRFC documents for the Tari protocol
RFC documents for the Tari protocol
In RFC-0313, there is mixed notation. Both V
and P
(possibly with indexes) are used to represent validator node public keys. This should be fixed so the notation is consistent.
The emoji id for a wallet should not change when a restore is done. If the seed words are removed, then the restored wallet will have a different emoji id.
I suggest storing the secret key for the emoji id in stage 1b, or at least mentioning that it should be explicitly removed
Under blocks
* each [transaction input](https://rfc.tari.com/Glossary.html#transaction) MUST:
* spend an existing valid [UTXO](https://rfc.tari.com/Glossary.html#unspent-transaction-outputs)
* have a maturity greater than the current block height
* be in a canonical order (see [Transaction ordering](https://rfc.tari.com/RFC-0120_Consensus.html#transaction-ordering)
The maturity check should surely be in the output section.
There are checks done on Tariscript that are missing
Adding this here, so it's not forgotten:
In RFC-0313, validator node registration binds a locked UTXO to a validator node public key through the use of a Schnorr signature, with the intent that the node operator signals its willingness to participate as a validator node.
Because this signature only binds the UTXO commitment and not an epoch, block producers can influence if and when the registration takes effect, as long as the registration transaction remains valid. It should be asserted that this is intended behavior.
Therefore, the threshold for moving from this stage to Stage 3, STAGE_TWO_THRESHOLD_BALANCE is relatively low; somewhere in the region of 10to50.
What are the units of 10to50
Possibly the Dollar sign is converting this to latex
In this RFC, the FTL section has this statement:
The FTL is calculated as (T*N)/20 with T and N defined as: T: Target time - This is the ideal time that should pass between blocks that have been mined. N: Block window - This is the number of blocks used when calculating difficulty adjustment
I'd like to know what the basis is for this being the ideal time. It is currently 9 minutes, which is 4.5 blocks, which would mean that N
is 90, which seems ok, so I would want to know where the formula comes from
If a user's seed words are stored in the unencrypted database on the cloud and the user's cloud is compromised, the attacker can steal future funds because they have the seed words.
I don't have a solution right now, but potentially: making a change to remove the seed words from the unencrypted db and maybe generating new seed words for recovery.
For example, RFC 201 references the Clacks sidechain which will not be implemented
It looks like the RFC's use a multitude of different date formats.
I have spotted: MMDDYY, DDMMYY, DD Month YY etc.
We need to pick one and update all dates to the specified one
The one-sided payment example in RFC-0204 is out of date. It references the use of RFC-0180 Bulletproof range proof rewinding. In addition to Bulletproofs being superseded by Bulletproofs+ for range proving and mask recovery, value communication is now done using a separate encryption.
This should be changed to reflect the work-in-progress PR for Bulletproofs+ range proving.
In RFC-0313, an algorithm is specified for determining when a validator node's shard key is reassigned (the terminology used is shuffled, but that's not quite what happens). In particular, if a node's public key is V
, then for a given epoch
and a fixed ShufflePeriod
, the node's shard key is reassigned if and only if the modular equivalence V + epoch mod ShufflePeriod == 0
. This ensures that a node's shard key is reassigned precisely once per ShufflePeriod
, but with the assumed design goal that the alignment of this reassignment is uniformly distributed across nodes in a manner that nodes should not be able to control.
However, the design means nodes can manipulate their reassignment alignment. Because ShufflePeriod
is small, and because the modular equivalence is independent of chain and validator set state, a node can trivially generate its public key V
by brute force to set its alignment prior to registration. This is almost certainly not desirable.
One alternative design is to uniformly sample and fix a hash function H
, and use the equivalence test H(V, B) + epoch mod ShufflePeriod == 0
, where B
is the hash of the block where the registration of V
occurs. This shifts control of the alignment from the node to the block producer and, in the absence of influence at that level, ensures that alignment is uniformly distributed.
in https://rfc.tari.com/RFC-0313_VNRegistration.html#validator-node-set-definition
The function get_vn_set(ϵstart,ϵend)→S⃗ that returns an ordered vector S⃗ of VN_Shard_Keys that are registered for the epoch ϵn. As all UTXOs are already ordered in the base layer, we can rely on deterministic ordering based on order the registration [UTXO](https://rfc.tari.com/Glossary.html#unspent-transaction-outputs)s are placed in the blockchain.
This should read "The order is based on the VN_Shard_Key"
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.