Crypto glossary


#41

Great point @iaculch.

There’s two ways to handle this in the real app:

  1. Request @brunocecchini23 to update his claim.

Or

  1. Clone @brunocecchini23’s claim and draft an updated version off it.

Which would you do in this case? :slight_smile:


#42

I’ll run with 1.) since it should only require minor updates from @brunocecchini23.

Can it be updated it to say “Solidity is an object oriented, high-level programming language” as per the Solidity docs: https://solidity.readthedocs.io/en/v0.5.1/

While we’re making changes, “the ability to define custom data structures” isn’t very descriptive, I’d expect any useful high level programming language to have this feature. Could we change this to, “It’s a strongly typed language influenced by C++, Python and JavaScript”


#43

I favor cloning the claim, is the fastest way to improve the glossary.


#44

interesting. why do you feel its “fastest” @brunocecchini23? is updating your post too burdensome?


#45

I think I agree with @brunocecchini23 in this case, having a claim updated will work better in the real TruStory but feels clumsy in Discourse because it won’t read in a logical progression anymore


#46

The faster, the better or else it will take too much time to have a TruGlossary…


#47

Solidity is an object oriented, high-level programming language used to code smart contracts on the Ethereum platform. It compiles into a bytecode format that is understood by the Ethereum Virtual machine (EVM). The language is strongly typed and was influenced by C++, Python and JavaScript.

Source:
https://blockgeeks.com/introduction-to-solidity-part-1/
https://solidity.readthedocs.io/en/v0.5.1/


#48

I’m also in favor of cloning a claim. Then you aren’t dependent on the creator of the initial claim to update it. This way, the best version of a claim should filter to the top. There should be some kind of link back to the original claim though. I’m getting ahead of myself here, but we could even have merging of claims, where the original creator can pull in updates from clones (but then we should probably call them forks).


#49

Unspent Transaction Output - UTXO: A bitcoin transaction has three things: a transaction input, a transaction output and an amount. In Cryptocurrencies, an unspent transaction output (UTXO) is an output of a blockchain transaction that has not been spent, i.e. output not used as an input in a new transaction. Bitcoin is the most famous example of a cryptocurrency that uses the UTXO model. In the case of a valid blockchain transaction, only unspent outputs may be used to effect further transactions. The requirement that only unspent outputs may be used in further transactions is necessary to prevent double spending and fraud. For this reason, inputs on a blockchain are deleted when a transaction occurs, whilst at the same time, outputs are created in the form of UTXOs. These unspent transaction outputs may be used (by the holders of private keys; for example, persons with cryptocurrency wallets) for the purpose of future transactions. In Bitcoin blockchain UTXO’s are stored in the RAM of a node. UTXO’s which are older than one year means bitcoins which are not spent in over a year.[source]


#50

Circulating supply: The approximate number of coins available for trading and spending. This differs from total and max supply as coins can be out of circulation for several reasons. Non-circulating coins include those reserved for future release (such as by mining), burned coins (purposely lost by the company or community to reduce supply), or accidentally lost coins (by sending to incorrect addresses, losing private key access, etc.).
[source]


#51

Distributed system: A group of components that communicate and coordinate by passing messages between each other in order to achieve a common goal. Although the components are separate, the system appears as a single component to the end-user(s).


#52

Simple fault-tolerance: In a simple fault-tolerant distributed system, we assume that all parts of the system do one of two things: they either follow the protocol exactly or they fail. This type of system should definitely be able to handle nodes going offline or failing. But it doesn’t have to worry about nodes exhibiting arbitrary or malicious behavior.


#53

Byzantine fault-tolerance: In a Byzantine fault-tolerant distributed system, we assume that all parts of the system do one of three things: they either follow the protocol exactly, fail or be malicious. In a decentralized system that has nodes controlled by independent actors communicating on the open, permissionless internet, we need to design for nodes that choose to be malicious or “Byzantine.”


#54

Replicated state machine: A deterministic state machine that is replicated across many computers but functions as a single state machine. Any of these computers may be faulty, but the state machine will still function. In a replicated state machine, if a transaction is valid, a set of inputs will cause the state of the system to transition to the next transaction. A transaction is an atomic operation on a database.


#55

FLP impossibility result: In the 1985 paper “Impossibility of Distributed Consensus with One Faulty Process,” researchers Fischer, Lynch, and Paterson (aka FLP) show how even a single faulty process makes it impossible to reach consensus among deterministic asynchronous processes. Because processes can fail at unpredictable times, it’s also possible for them to fail at the exact opportune time that prevents consensus from occurring.


#56

Stablecoin: Stablecoin refers to a class of cryptocurrencies which offer price stability and/or are backed by reserve assets. Designers of stablecoins use different designs to achieve price stability. Fiat-collateralized stablecoins maintain a fiat currency reserve, like the U.S. dollar, as collateral to issue a suitable number of cryptocoins. Other forms of collateral can include precious metals like gold or silver, as well as commodities like oil, but most of the present-day fiat-collateralized stablecoins use dollar reserves. Stablecoins can be centralized where they can be backed by fiat and exchange-traded commodities directly, or in a decentralized fashion via leveraging other cryptocurrency projects in different ways.


#57

Node: A computer that is connected to a blockchain’s network and participates in validating the ledger.


#58

Simple Payment Verification: Simple Payment Verification (SPV) is a technique described in Satoshi Nakamoto’s paper. SPV allows a lightweight client to verify that a transaction is included in the Bitcoin blockchain, without downloading the entire blockchain. The SPV client only needs to download the block headers, which are much smaller than the full blocks. To verify that a transaction is in a block, an SPV client requests a proof of inclusion, in the form of a Merkle branch.SPV clients offer more security than web wallets because they do not need to trust the servers with the information they send. Simplified Payment Verification, Lightweight Client, Thin Client are synonymously used with this term.


#59

Merkle Tree: A Merkle tree is a data structure and binary hash tree which is used in computer applications and involves taking large amounts data and making it more manageable to process. Various blockchain networks have different implementations of Merkle trees serving differing purposes. For E.g. In Bitcoin’s blockchain, a Merkle tree is used for block verification. A block of transactions is run through an algorithm to generate a hash, which is a string of numbers and letters that can be used to verify that a given set of data is the same as the original set of transactions, but not to obtain the original set of transactions. Rather than each transaction is hashed, each pair of transactions is concatenated and hashed together, and so on until there is one hash for the entire block. (If there is an odd number of transactions, one transaction is duplicated and its hash is concatenated with itself.)
Visualizing Merkle tree will look a tree with the root at the top and branches and leaves further down. “TA” represents a normal transaction, like the one described above. These transactions are hashed individually to give their corresponding hash value. For example, “TD” is put through a hash function to give its corresponding hash value of “HD“. After each transaction has been individually hashed to produce its corresponding hash value, the new hash values are combined with an adjacent partner to be hashed once again. For example, the hash values “HC” and “HD” are combined and hashed to produce the hash “HCD“. In the above example, there are 8 transactions with their own corresponding hash values. However, if there had been an odd number of hash values, such as 7, then the 7th hash is simply paired with itself and hashed to produce a new hash value. That is, “HH” and “HH” would be combined to give “HHH“. This process is repeated until the last hash value is obtained. This value is known as the merkle root. In the above example, the merkle root is labeled “HABCDEFGH“. The merkle root is 32 bytes in size and is then taken to be placed inside the block header; it represents a summary of all transaction data.
merkle


#60

@sijo0703, thank for providing the visual aid w/the definition.