Mcsh-creation:: {2025-09-15}
description::
it.nfo is part of it.nfo.
name::
* McsEngl.conceptIt1016,
* McsEngl.Blockchain-Network@cptIt,
* McsEngl.FvMcs.Blockchain-Network@cptIt,
* McsEngl.synagonism.net'dirMiwMcs'dirTchInf'filMcsBcnnet@cptIt, {2017-03-21}
* McsEngl.bcnnet@cptIt, {2017-03-05}
* McsEngl.blockchain-based-system@cptIt,
* McsEngl.blockchain-ecosystem@cptIt,
* McsEngl.blockchain-framework@cptIt,
* McsEngl.blockchain-network@cptIt,
* McsEngl.blockchain-technology@cptIt,
* McsEngl.consensus-technology@cptIt,
* McsEngl.cryptoeconomic-network@cptIt,
* McsEngl.decentralized-consensus-based-transaction-system@cptIt,
* McsEngl.decentralized-consensus-network@cptIt,
* McsEngl.distributed-ledger-technology@cptIt,
* McsEngl.DLT@cptIt,
* McsEngl.netBcn@cptIt, {2016-03-25}
====== lagoGreek:
* McsElln.αλυσιδωτών-μπλοκ-δίκτυο@cptIt, {2017-01-25}
* McsElln.δίκτυο-αλυσιδωτών-μπλοκ@cptIt, {2017-01-25}
* McsElln.δίκτυο-αλυσίδας-μπλοκ@cptIt,
_DESCRIPTION:
Blockchain-network is a-peer-to-peer-network that stores in a-chain-of-blocks UNMODIFIABLE, TRANSPARENT transactions-of-information among its nodes#ql:idBcnnod#.
[hmnSngo.2017-03-18]
===
Bcnnet is a young and fluid technology.
Our view about it is double fluid.
Do-NOT-expect my view to cover all its attributes and to-have a-small-amount of mistakes.
[hmnSngo.2017-03-26]
_DESCRIPTION:
The blockchain is a recent development in the field of computer science, which uses a global peer-to-peer network to provide an open platform that can deliver neutrality, reliability and security.
[https://www.provenance.org/whitepaper]
_DESCRIPTION:
These cryptoeconomic networks come in many flavors — ASIC-based PoW, GPU-based PoW, naive PoS, delegated PoS, hopefully soon Casper PoS — and each of these flavors inevitably comes with its own underlying philosophy.
[https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51#.gwuvm0m26]
_DESCRIPTION:
Blockchain technology is the technological basis of Bitcoin, first described by its mysterious author Satoshi Nakamoto#ql:idBtchmnSnt# in his white paper “Bitcoin: A Peer-to-Peer Electronic Cash System”, published in 2008.
While the use of blockchains for more general uses was already discussed in the original paper, it was not until a few years later that blockchain technology emerged as a generic term.
A blockchain is a distributed computing architecture where every network node executes and records the same transactions, which are grouped into blocks.
Only one block can be added at a time, and every block contains a mathematical proof that verifies that it follows in sequence from the previous block. In this way, the blockchain’s “distributed database” is kept in consensus across the whole network.
Individual user interactions with the ledger (transactions) are secured by strong cryptography.
Nodes that maintain and verify the network are incentivized by mathematically enforced economic incentives coded into the protocol.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#a-next-generation-blockchain]
name::
* McsEngl.bcnnet'Protocol (bcnprl)@cptIt,
* McsEngl.bcnnet'protocol@cptIt,
* McsEngl.bcnprl@cptIt,
* McsEngl.blockchain-protocol@cptIt,
_DESCRIPTION:
Protocol is A-DESCRIPTION of the-communication-process of the-network#ql:idMcsBcnnet#.
[hmnSngo.2017-03-18]
===
Algorithm usually is-called a-description of info processing.
[hmnSngo.2017-04-03]
_GENERIC:
* p2p-network-protocol#ql:p2p_protocol#
name::
* McsEngl.bcnprl'White-paper (bcnwpr)@cptIt,
* McsEngl.bcnprl'white-paper@cptIt,
* McsEngl.bcnprlwpr@cptIt,
* McsEngl.bcnwpr@cptIt, {2017-03-26}
* McsEngl.blockchain-white-paper@cptIt,
_DESCRIPTION:
Usually, PDF-files that DESCRIBE the-protocol in natural-language.
[hmnSngo.2017-03-18]
_SPECIFIC:
* Bitcoin-white-paper#ql:idBtcwpr#,
* BitShares-white-paper#ql:idBtswpr#,
* Ethereum-white-paper#ql:idEthprl#,
* ChronoBank-white-paper#ql:idChbwpr#
name::
* McsEngl.bcnprl'Implementation-language@cptIt,
* McsEngl.bcnnet'coding-language@cptIt,
* McsEngl.bcnnet'implementation-language@cptIt,
* McsEngl.bcnnet'source-code-language@cptIt,
* McsEngl.bcnprl'implementation-language@cptIt,
* McsEngl.blockchain-implementation-language@cptIt,
_DESCRIPTION:
The-computer-language used to write the-protocol.
[hmnSngo.2017-03-18]
name::
* McsEngl.bcnprl.specific@cptIt,
* McsEngl.bcnprl.specific@cptIt,
_SPECIFIC:
* bitcoin-protocol#ql:idBtcprl#,
* ethereum-protocol#ql:idEthprl#
name::
* McsEngl.bcnnet'Node (bcnnod)@cptIt,
* McsEngl.bcnnet'network-node@cptIt,
* McsEngl.bcnnet'node@cptIt,
* McsEngl.bcnnod@cptIt,
* McsEngl.blockchain-node@cptIt,
_DESCRIPTION:
A blockchain is a distributed computing architecture where every network node executes and records the same transactions#ql:idbcntx#, which are grouped into blocks#ql:idBcnblk#.
Only one block can be added at a time, and every block contains a mathematical proof that verifies that it follows in sequence from the previous block. In this way, the blockchain’s “distributed database” is kept in consensus across the whole network.
Individual user interactions with the ledger (transactions) are secured by strong cryptography.
Nodes that maintain and verify the network are incentivized by mathematically enforced economic incentives coded into the protocol.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#a-next-generation-blockchain]
name::
* McsEngl.bcnnod.specific@cptIt,
* McsEngl.bcnnod.specific@cptIt,
_SPECIFIC:
* full-node#ql:idBcnnodFul#,
* light-node,
* miner-node#ql:idBcnnodeMnr#
name::
* McsEngl.bcnnod.FULL@cptIt,
* McsEngl.bcnnod.full@cptIt,
* McsEngl.blockchain-full-node@cptIt,
_DESCRIPTION:
Full nodes are servers running on a p2p network, that allow peers to use them to receive updates about the events on the network.
These nodes require significant amounts of traffic and other resources that carry substantial cost.
[idDashwpr2]
name::
* McsEngl.bcnnod.MINER@cptIt,
* McsEngl.bcnnet'node.miner@cptIt,
* McsEngl.bcnnodeMnr@cptIt,
* McsEngl.netBct'miner-node@cptIt,
====== lagoGreek:
* McsElln.εξoρύκτης-αλλυσίδας-μπλοκ-κόμβος@cptIt,
name::
* McsEngl.bcnnodMnr'Human.Miner (bcnmnr)@cptIt,
* McsEngl.bcnhmn.miner@cptIt,
* McsEngl.bcnminer-human@cptIt,
* McsEngl.bcnnet'miner-human@cptIt,
name::
* McsEngl.bcnnodMnr'Mining (bcnmng)@cptIt,
* McsEngl.bcnmining@cptIt,
* McsEngl.bcnminting@cptIt,
* McsEngl.bcnmng@cptIt,
* McsEngl.bcnnet'mining@cptIt,
* McsEngl.bcnnet'Forging@cptIt,
* McsEngl.bcnnet'Harvesting@cptIt,
* McsEngl.blockchain-mining@cptIt,
_DESCRIPTION:
In NEM harvesting is the act of forming blocks (mining/forging).
[http://wiki.nem.io/index.php/Harvesting]
_SPECIFIC:
* Bitcoin-mining,
* Ethereum-mining#ql:idEthmng#,
* Lisk-mining#ql:idLskmng#
name::
* McsEngl.bcnnodMnr'Pre-mining@cptIt,
* McsEngl.blockchain-pre-mining@cptIt,
* McsEngl.bcnpre-mining@cptIt,
_DESCRIPTION:
Pre-mining:
The mining of coins by a cryptocurrency’s founder before that coin has been announced and details released to others who may wish to mine the coin.
Pre-mining is a common technique used with scamcoins, although not all pre-mined coins are scamcoins (see Scamcoins).
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.bcnnodMnr'CLOUD-MINING@cptIt,
* McsEngl.blockchain-cloud-mining@cptIt,
name::
* McsEngl.bcnnodMnr'MINING-POOL (bcnmgpl)@cptIt,
* McsEngl.bcnnet'mining-pool@cptIt,
* McsEngl.bcnmgpl@cptIt,
name::
* McsEngl.bcnmgpl.MinerGate@cptIt,
* McsEngl.MinerGate@cptIt,
* McsEngl.minergate@cptIt,
_DESCRIPTION:
MinerGate is a mining pool created by a group of cryptocoin enthusiasts.
It is the first pool which provides service for merged mining. This means that while mining on our pool you can mine different coins simultaniously without decrease of hashrate for major coin.
[https://minergate.com/faq/about]
===
Changelly was developed by MinerGate, one of the oldest mining pools on the market, that has
about two mln users all over the world.
[https://cointelegraph.com/news/with-charlie-shrem-as-advisor-shangelly-is-set-to-outperform-shapeshift]
name::
* McsEngl.bcnnet'Blockchain (bcnbcn)@cptIt,
* McsEngl.bcnbcn@cptIt,
* McsEngl.bcnledger@cptIt,
* McsEngl.bcnlgr@cptIt, {2017-03-19}
* McsEngl.blockchain@cptIt,
* McsEngl.blockchain-database@cptIt,
* McsEngl.blockchain-ledger@cptIt,
* McsEngl.blockchain-record@cptIt,
* McsEngl.bcnnet'blockchain@cptIt,
* McsEngl.bcnnet'distributed-database@cptIt,
* McsEngl.consensus-ledger@cptIt,
* McsEngl.distributed-database-of-bcnnet@cptIt,
* McsEngl.mnyBcn'blockchain-ledger@cptIt,
* McsEngl.mnyBcn'ledger@cptIt,
* McsEngl.sihCrypto'ledger@cptIt,
* McsElln.βάση-δεδομέων-αλυσιδωτών-μπλοκ@cptIt, {2017-01-25}
* McsElln.καθολικό-αλυσιδωτών-μπλοκ@cptIt, {2017-01-25}
* McsElln.μητρώο-αλυσιδωτών-μπλοκ@cptIt, {2017-01-25}
* McsElln.μπλοκ-αλυσίδα@cptIt,
* McsElln.μπλοκτσέιν@cptIt, {2017-04-10}
_DESCRIPTION:
A blockchain is essentially just a record, or ledger, of digital events — one that’s “distributed,” or shared between many different parties.
It can only be updated by consensus of a majority of the participants in the system.
And, once entered, information can never be erased.
The bitcoin blockchain contains a certain and verifiable record of every single bitcoin transaction ever made.
[http://recode.net/2015/07/05/forget-bitcoin-what-is-the-blockchain-and-why-should-you-care/]
_DESCRIPTION:
A blockchain is fundamentally a public record of state changes.
[https://media.consensys.net/time-sure-does-fly-ed4518792679#.rjkzhxgwo]
_DESCRIPTION:
The security of cryptocurrency ledgers is based on the assumption that the majority of miners are honestly trying to maintain the ledger, having financial incentive to do so.
[https://en.wikipedia.org/wiki/Cryptocurrency]
_DESCRIPTION:
The blockchain is a state-machine and every time a transaction takes place the state is updated.
So, you can always see at which block what transaction took place.
[https://www.newscombinator.com/article/7/ethereum-dapp-essentials-part-1]
_DESCRIPTION:
blockchain Μία λίστα επικυρωμένων μπλοκ. Το κάθε ένα συνδέεται με το προκάτοχο του μέχρι το «genesis block».
[Mastering Bitcoin, Adonopoulos, https://www.bitcoinbook.info/translations/el/book.pdf]
_DESCRIPTION:
Blockchain is a decentralized database shared among a network of computers, all of which must approve an exchange before it can be recorded. There’s no need for a trusted intermediary like a bank because the information is held securely and transparently on a digital ledger for all users on the network to see.
[https://www.weforum.org/agenda/2016/12/fighting-human-trafficking-tracing-blood-diamonds-and-other-surprising-uses-for-blockchain??]
_DESCRIPTION:
A blockchain in all it’s incarnations is a database type designed specifically for use in a DCN.
It can hold any information, and can set rules on how information is updated.
Its primary feature is that it is updated in discrete chunks called ‘blocks’ which are ‘chained’ together using hashes of the previous blocks content.
A blockchain contains not only the information that is currently stored in the database, but also every change made to the database in its history.
Known as the state and transactions respectively it makes for a database with a complete custodial history that cannot be altered without altering every subsequent block.
A private key always signs ‘Transactions’ or requests to change the state of the database, and the signature is stored in the blockchain.
[https://dappsforbeginners.wordpress.com/tutorials/introduction-to-development-on-ethereum/]
_DESCRIPTION:
blockchain: Μία λίστα επικυρωμένων μπλοκ. Το κάθε ένα συνδέεται με το προκάτοχο του μέχρι το «genesis block».
[Mastering Bitcoin, Adonopoulos, https://www.bitcoinbook.info/translations/el/book.pdf]
===
The major story from 2015 is undoubtedly the increasing focus on bitcoin's underlying technology, commonly referred to as blockchain or distributed ledger technology (DLT). Many parties, from government authorities to financial institutions, began to examine potential applications of DLT for securities transaction settlement and other use cases.
[http://www.coindesk.com/state-of-bitcoin-blockchain-2016/]
===
Nxt’s innovation is built on the idea of the blockchain: a public, secure record of every transaction that has ever occurred between any two parties within the network. Whilst the blockchain is completely transparent and anyone can access it, once an entry has been added it is impossible to change or remove it. The blockchain allows anyone to prove ownership and exchange of anything that has been agreed between two parties: money, property, rights, IP and more. The revolution that this enables cannot be underestimated.
[http://nxt.org/about/how-nxt-change-world/]
===
Blockchain technology, introduced by Satoshi Nakamoto#ql:idBtchmnSnt# with the proof-of-concept implementation of a simple value transfer system known as bitcoin, represents the best digital system we have (after the internet itself) for administering multi-user interactions without any need for centralized coordination or oversight.
[http://ethereum.gitbooks.io/frontier-guide/content/ethereum.html]
===
Satoshi Nakamoto's#ql:idBtchmnSnt# development of Bitcoin in 2009 has often been hailed as a radical development in money and currency, being the first example of a digital asset which simultaneously has no backing or "intrinsic value" and no centralized issuer or controller.
However, another, arguably more important, part of the Bitcoin experiment is the underlying blockchain technology as a tool of distributed consensus, and attention is rapidly starting to shift to this other aspect of Bitcoin.
Commonly cited alternative applications of blockchain technology include using on-blockchain digital assets to represent custom currencies and financial instruments ("colored coins"), the ownership of an underlying physical device ("smart property"), non-fungible assets such as domain names ("Namecoin"), as well as more complex applications involving having digital assets being directly controlled by a piece of code implementing arbitrary rules ("smart contracts") or even blockchain-based "decentralized autonomous organizations" (DAOs). What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create "contracts" that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code.
[https://github.com/ethereum/wiki/wiki/White-Paper]
name::
* McsEngl.bcnbcn'Block (bcnblk)@cptIt,
* McsEngl.bcnblk@cptIt,
* McsEngl.bcnnet'block@cptIt,
* McsEngl.block-of-blockchain@cptIt,
_DESCRIPTION:
Block is a-package of transactions#ql:idBcntx#.
[hmnSngo.2017-04-21]
===
A blockchain is a distributed computing architecture where every network node executes and records the same transactions, which are grouped into blocks.
Only one block can be added at a time, and every block contains a mathematical proof that verifies that it follows in sequence from the previous block.
In this way, the blockchain’s “distributed database” is kept in consensus across the whole network.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#a-next-generation-blockchain]
name::
* McsEngl.bcnblk'Height@cptIt,
* McsEngl.bcnblock-height@cptIt,
* McsEngl.bcnblock-number@cptIt,
* McsEngl.bcnnet'Block-height@cptIt,
_DESCRIPTION:
The number of blocks preceding a particular block on a block chain.
For example, the genesis block has a height of zero because zero block preceded it.
[https://bitcoin.org/en/glossary/block-height]
name::
* McsEngl.bcnblk'Reward@cptIt,
* McsEngl.bcnnet'Block-reward@cptIt,
name::
* McsEngl.bcnblk'Time (bcnblktim)@cptIt,
* McsEngl.bcnblktime@cptIt,
* McsEngl.bcnblk'time@cptIt,
* McsEngl.bcnnet'Block-time@cptIt,
_DESCRIPTION:
Time related with a-block#ql:idBcnblk#.
name::
* McsEngl.bcnblktim.Age@cptIt,
* McsEngl.bcnblk'age@cptIt,
* McsEngl.bcnnet'age-of-Block@cptIt,
_DESCRIPTION:
How long ago a-block was-added to a-blockchain.
name::
* McsEngl.bcnblktim.Timestamp@cptIt,
* McsEngl.bcnblk'timestamp@cptIt,
* McsEngl.bcnnet'Block-timestamp@cptIt,
name::
* McsEngl.bcnblktim.Generation@cptIt,
* McsEngl.bcnblk'blocktime@cptIt,
* McsEngl.bcnnet'Blocktime@cptIt,
* McsEngl.block-generation-time@cptIt,
* McsEngl.block-interval-of-blockchain@cptIt,
* McsEngl.blockchain-block-interval@cptIt,
* McsEngl.blocktime-of-blockchain@cptIt,
name::
* McsEngl.bcnblk'Transaction@cptIt,
* McsEngl.bcnblk'transaction@cptIt,
* McsEngl.bcnblktx@cptIt,
* McsEngl.bcnnet'Block-transaction@cptIt,
_DESCRIPTION:
Any transaction#ql:idBcntx# included in a-block#ql:idBcnblk#.
BLOCK-NUMBER-OF-TRANSACTIONS:
The-number of transactions contained in a-block#ql:idBcnblk#.
name::
* McsEngl.bcnblk'Hash@cptIt,
* McsEngl.blockchain-block-hash@cptIt,
* McsEngl.blockchain-hash-of-block@cptIt,
* McsEngl.bcnhash-of-block@cptIt,
name::
* McsEngl.bcnblk'Size@cptIt,
* McsEngl.bcnblksize@cptIt,
* McsEngl.bcnnet'Block-size@cptIt,
name::
* McsEngl.bcnblk.specific@cptIt,
* McsEngl.bcnblkSpc@cptIt,
_SPECIFIC:
* bitcoin-block#ql:idBtcblk#,
* ethereum-block#ql:idEthblk#
name::
* McsEngl.bcnblk.GENESIS@cptIt,
* McsEngl.bcnblk.genesis@cptIt,
* McsEngl.bcnblkGns@cptIt,
_DESCRIPTION:
The-first block, height 0, written programatically into the-blockchain.
name::
* McsEngl.bcnbcn'Block-Explorer (bcnbex)@cptIt,
* McsEngl.bcnblock-explorer@cptIt,
* McsEngl.bcnnet'block-explorer@cptIt,
* McsEngl.bcnnet'explorer@cptIt,
* McsEngl.block-explorer-of-blockchain@cptIt,
* McsEngl.blockchain-block-explorer@cptIt,
* McsEngl.blockchain-explorer@cptIt,
_DESCRIPTION:
Website that presents information about the-parts of a-blockchain-network#ql:idMcsBcnnet#.
_SPECIFIC:
* https://chainz.cryptoid.info//
* bitcoin-block-explorer#ql:idBtcblkexr#,
* ethereum-block-explorer#ql:idEthblkexr#
name::
* McsEngl.bcnbcn'Consensus-algorithm (bcncsa)@cptIt,
* McsEngl.bcnnet'block-verification-method@cptIt,
* McsEngl.bcnnet'consensus-algorithm@cptIt,
* McsEngl.bcnnet'mining-system@cptIt,
* McsEngl.bcnnet'model-of-security@cptIt,
* McsEngl.bcnnet'transaction-verification-method@cptIt,
* McsEngl.block-validation-algorithm-of-bcnnet@cptIt,
* McsEngl.consensus-algorithm-of-bcnnet@cptIt,
_DESCRIPTION:
The-consensus-algorithm is an-algorithm describing how to UPDATE the-blockchain.
How the next block will-be-added with consensus.
[hmnSngo.2017-03-30]
_DESCRIPTION:
The consensus algorithm is core to any blockchain based currency or system.
The algorithm attempts to answer the question, ‘how can we prove with confidence that all distributed databases hold the same set of information?’
[idBoswpr3a]
_DESCRIPTION:
Ethereum Frontier like all blockchain technologies uses an incentive-driven model of security.
Consensus is based on choosing the block with the highest total difficulty.
[https://github.com/ethereum/wiki/blob/master/Mining.md]
_DESCRIPTION:
We have chosen the Proof-of-Stake protocol as a consensus algorithm for WAVES.
[https://wavesplatform.com/whitepaper_v0.pdf]
_DESCRIPTION:
Distributed timestamping protocols were first applied to decentralizing a financial network in the ground-breaking paper on Bitcoin by Nakamoto1. The field has seen explosive research follow-up from both amateurs and professionals, competing to offer extensions, adjustments, improvements, and refinements of the existing protocol. Notable implementations of new ideas include Ethereum2, which extended scripting, CryptoNote3, which refined privacy, and Sidechains4, which investigated two-way pegs with 1:1 Bitcoin tokens. These protocols all utilize proof-of-work (PoW) as originally described in the Bitcoin whitepaper.
A common extension to the Bitcoin protocol modifies the consensus mechanism to either completely or partially use proof-of-stake (PoS), or the use of one’s stake (tokens) rather than one’s computational power to participate in the timestamping process. The first proof-of-stake blockchain based on the Bitcoin protocol was implemented in 2012 by King and Nadal5, and includes both PoW and PoS that gradually skew towards complete PoS over time. Criticisms of pure PoS consensus systems have themselves been abundant6 7, with the most vehement opposition coming from those working with purely PoW blockchains. The most common argument against PoS for distributed timestamping is “nothing-at-stake” or “costless simulation”, describing the systematic instability resulting from stakeholders being able to generate alternatively timestamped histories with no cost to themselves.
Despite the controversy, it is apparent that systems who have a PoS overlay dependent on a PoW timestamping system may be able to independently achieve consensus. This is mathematically explored by Bentov and colleagues8 in a paper on their scheme, proof-of-activity (PoA), and appears to be a viable extension to the PoW protocols that may enable some interesting new properties. A similar design called MC2 was earlier proposed by Mackenzie in 20139. Here we describe the construction and implementation of a similar consensus system that we have named “Decred”.
1.Nakamoto S. 2008. Bitcoin: A peer-to-peer electronic cash system. ?
2.Buterin V. 2014. A Next-generation smart contract and decentralized application platform. ?
3.von Saberhagen N. 2013. CryptoNote v2.0. ?
4.Back A., Corallo M., Dashjr L., Friedenbach M., Maxwell G., Miller A., Poelstra A., Timon A., Wuille P. 2014. Enabling Bitcoin innovations with pegged sidechains. ?
5.King S. and Nadal S. 2012. PPCoin: Peer-to-peer crypto-currency with proof-of-stake. ?
6.Bentov I., Gabizon A., Mizrahi A. 2015. Cryptocurrencies without proof-of-work. ?
7.Poelstra A. 2015. On stake and consensus. ?
8.Bentov I., Lee C., Mizrahi A., Rosenfeld M. 2014. Proof-of-activity: Extending Bitcoin’s proof-of-work via proof-of-stake. ?
9.Mackenzie A. 2013. MEMCOIN2: A hybrid proof-of-work, proof-of-stake crypto-currency. ?
[https://docs.decred.org/research/overview/]
_DESCRIPTION:
Timestamping
Cryptocurrencies use various timestamping schemes to avoid the need for a trusted third party to timestamp transactions added to the blockchain ledger.
Proof-of-work schemes
The first timestamping scheme invented was the proof-of-work scheme. The most widely used proof-of-work schemes are based on SHA-256, which was introduced by bitcoin, and scrypt, which is used by currencies such as Litecoin.[22] The latter now dominates over the world of cryptocurrencies, with at least 480 confirmed implementations.[42]
Some other hashing algorithms that are used for proof-of-work include Blake, SHA-3, and X11.
Proof-of-stake and combined schemes
Some cryptocurrencies use a combined proof-of-work/proof-of-stake scheme,[22][43] The Proof-of-stake is a method of securing a cryptocurrency network and achieving distributed consensus through requesting users to show ownership of a certain amount of currency. It is different from proof-of-work systems that run difficult hashing algorithms to validate electronic transactions. The scheme is largely code dependent on the coin, and there's currently no standard form of it.
[https://en.wikipedia.org/wiki/Cryptocurrency]
name::
* McsEngl.bcncsa.SPECIFIC@cptIt,
SPECIFIC:
The consensus of the Blockchain network is achieved utilizing the unique environmental and energy friendly algorithm “POI” (Proof of Importance). POI is a technologically advanced algorithm compared to the earlier established PoW (Proof of Work) and PoS (Proof of Stake).
[https://blog.nem.io/nem-mijin-blockchain-technology-briefing-january-2017/]
SPECIFIC:
Distributed timestamping protocols were first applied to decentralizing a financial network in the ground-breaking paper on Bitcoin by Nakamoto1. The field has seen explosive research follow-up from both amateurs and professionals, competing to offer extensions, adjustments, improvements, and refinements of the existing protocol. Notable implementations of new ideas include Ethereum2, which extended scripting, CryptoNote3, which refined privacy, and Sidechains4, which investigated two-way pegs with 1:1 Bitcoin tokens. These protocols all utilize proof-of-work (PoW) as originally described in the Bitcoin whitepaper.
A common extension to the Bitcoin protocol modifies the consensus mechanism to either completely or partially use proof-of-stake (PoS), or the use of one’s stake (tokens) rather than one’s computational power to participate in the timestamping process. The first proof-of-stake blockchain based on the Bitcoin protocol was implemented in 2012 by King and Nadal5, and includes both PoW and PoS that gradually skew towards complete PoS over time. Criticisms of pure PoS consensus systems have themselves been abundant6 7, with the most vehement opposition coming from those working with purely PoW blockchains. The most common argument against PoS for distributed timestamping is “nothing-at-stake” or “costless simulation”, describing the systematic instability resulting from stakeholders being able to generate alternatively timestamped histories with no cost to themselves.
Despite the controversy, it is apparent that systems who have a PoS overlay dependent on a PoW timestamping system may be able to independently achieve consensus. This is mathematically explored by Bentov and colleagues8 in a paper on their scheme, proof-of-activity (PoA), and appears to be a viable extension to the PoW protocols that may enable some interesting new properties. A similar design called MC2 was earlier proposed by Mackenzie in 20139. Here we describe the construction and implementation of a similar consensus system that we have named “Decred”.
References
Nakamoto S. 2008. Bitcoin: A peer-to-peer electronic cash system. ?
Buterin V. 2014. A Next-generation smart contract and decentralized application platform. ?
von Saberhagen N. 2013. CryptoNote v2.0. ?
Back A., Corallo M., Dashjr L., Friedenbach M., Maxwell G., Miller A., Poelstra A., Timon A., Wuille P. 2014. Enabling Bitcoin innovations with pegged sidechains. ?
King S. and Nadal S. 2012. PPCoin: Peer-to-peer crypto-currency with proof-of-stake. ?
Bentov I., Gabizon A., Mizrahi A. 2015. Cryptocurrencies without proof-of-work. ?
Poelstra A. 2015. On stake and consensus. ?
Bentov I., Lee C., Mizrahi A., Rosenfeld M. 2014. Proof-of-activity: Extending Bitcoin’s proof-of-work via proof-of-stake. ?
Mackenzie A. 2013. MEMCOIN2: A hybrid proof-of-work, proof-of-stake crypto-currency. ?
[https://docs.decred.org/research/overview/]
name::
* McsEngl.bcncsa.Proof-of-stake (bcnpos)@cptIt,
* McsEngl.bcnnet'proof-of-stake@cptIt,
* McsEngl.bcnpos@cptIt,
* McsEngl.proof-of-stake@cptIt,
* McsEngl.proof-of-stake-security@cptIt,
_DESCRIPTION:
proof-of-work (majority of computing power says which transactions settle) for
proof-of-stake (majority of coin wealth says which transactions settle)
[https://lykke.com/Whitepaper_LykkeExchange.pdf]
_DESCRIPTION:
Proof-of-stake is a method by which a cryptocurrency blockchain network aims to achieve distributed consensus.
While the more mainstream proof-of-work method asks users to repeatedly run difficult hashing algorithms to validate electronic transactions,[1] proof-of-stake asks users to prove ownership of a certain amount of currency (their "stake" in the currency).
Peercoin[2] was the first cryptocurrency to launch using Proof-of-Stake.
Other prominent implementations are found in BitShares, Nxt, BlackCoin, NuShares/NuBits and Qora.
[https://en.wikipedia.org/wiki/Proof-of-stake]
===
The proof-of-stake approach means that the security of the network is maintained by every existing holder of Nxt, who earn transaction fees in proportion to the number of coins they already own – rather than the network being maintained by the relatively small number of miners who can afford the expensive hardware required.
Improved security. This property also protects the network from the problems of mining power being concentrated in a few big pools or organisations, which renders it vulnerable to a ‘51 percent’ attack. Nxt’s proof-of-stake means that even if one person owns 90 percent of all the coins available, the network remains secure.
[http://nxt.org/about/what-is-nxt/]
===
Proof-of-stake (PoS) is a type of algorithm by which a cryptocurrency blockchain network aims to achieve distributed consensus. Unlike Proof-of-Work (PoW) based cryptocurrencies (such as bitcoin), where the algorithm rewards participants who solve complicated cryptographical puzzles in order validate transactions and create new blocks (i.e. mining), in PoS-based cryptocurrencies the creator of the next block is chosen in a deterministic (pseudo-random) way, and the chance that an account is chosen depends on its wealth (i.e. the stake). In PoS cryptocurrencies the blocks are usually said to be forged (in the blacksmith sense of this word), or minted, rather than mined. Also, usually all the coins are created in the beginning and the total number of coins never changes afterwards (although there are some other versions of PoS where new coins can be created). Therefore, in the basic version of PoS there are no block rewards (e.g. as in bitcoin); so, the forgers take only the transaction fees.[1]
Peercoin[2] was the first cryptocurrency to launch using proof-of-stake. Other prominent implementations are found in ShadowCash, Nxt, BlackCoin, NuShares/NuBits, Qora and Nav Coin.[3] Ethereum has planned a hard fork transition from PoW to PoS consensus. Both Peercoin and Decred[4] hybridize PoW with PoS and combine elements of both consensus approaches in an attempt to garner the benefits of the two systems and create a more robust notion of consensus.
[https://en.wikipedia.org/wiki/Proof-of-stake {2017-01-29}]
name::
* McsEngl.bcncsa.Proof-of-work (bcnpow)@cptIt,
* McsEngl.bcnnet'pow@cptIt,
* McsEngl.bcnpow@cptIt,
* McsEngl.proof-of-work@cptIt,
* McsElln.αλγόριθμος-απόδειξης-εργασίας@cptIt,
* McsElln.απόδειξη-εργασίας-σε-μπλοκτσέιν-δίκτυο@cptIt,
* McsElln.μπλοκτσέιν-απόδειξη-εργασίας@cptIt,
_DESCRIPTION:
proof-of-work (majority of computing power says which transactions settle) for
proof-of-stake (majority of coin wealth says which transactions settle)
[https://lykke.com/Whitepaper_LykkeExchange.pdf]
_DESCRIPTION:
Originally envisioned as a spam prevention system proof of work is a simple method for proving that you have *probably* performed a large number of mathematical operations.
It is implemented in the majority of cases using a cryptographic hash function; given an arbitrary piece of data, (like a list of transactions and the header of a block) you must find a second piece of data which, when combined with the first, produces a hash that has certain characteristics (like a number of trailing zeros).
Because it is impossible to predict what second piece of data will produce the required hash, you must randomly iterate through possible data until you find one that produces the hash you require.
[https://dappsforbeginners.wordpress.com/tutorials/introduction-to-development-on-ethereum/]
===
HashCash {1997} Antispam mechanism: you have to do some work in order to send a message.
This work for ONE message is almost nothing.
For a spammer of 1000000 messages is huge.
===
In 2009, a decentralized currency was for the first time implemented in practice by Satoshi Nakamoto#ql:idBtchmnSnt#, combining established primitives for managing ownership through public key cryptography with a consensus algorithm for keeping track of who owns coins, known as "proof of work".
The mechanism behind proof of work was a breakthrough in the space because it simultaneously solved two problems. First, it provided a simple and moderately effective consensus algorithm, allowing nodes in the network to collectively agree on a set of canonical updates to the state of the Bitcoin ledger. Second, it provided a mechanism for allowing free entry into the consensus process, solving the political problem of deciding who gets to influence the consensus, while simultaneously preventing sybil attacks. It does this by substituting a formal barrier to participation, such as the requirement to be registered as a unique entity on a particular list, with an economic barrier - the weight of a single node in the consensus voting process is directly proportional to the computing power that the node brings. Since then, an alternative approach has been proposed called proof of stake, calculating the weight of a node as being proportional to its currency holdings and not computational resources; the discussion of the relative merits of the two approaches is beyond the scope of this paper but it should be noted that both approaches can be used to serve as the backbone of a cryptocurrency
[https://github.com/ethereum/wiki/wiki/White-Paper]
===
A proof-of-work (POW) system (or protocol, or function) is an economic measure to deter denial of service attacks and other service abuses such as spam on a network by requiring some work from the service requester, usually meaning processing time by a computer. The concept may have been first presented by Cynthia Dwork and Moni Naor in a 1993 journal article.[1] The term "Proof of Work" or POW was first coined and formalized in a 1999 paper by Markus Jakobsson and Ari Juels.[2]
A key feature of these schemes is their asymmetry: the work must be moderately hard (but feasible) on the requester side but easy to check for the service provider. This idea is also known as a CPU cost function, client puzzle, computational puzzle or CPU pricing function. It is distinct from a CAPTCHA, which is intended for a human to solve quickly, rather than a computer. Proof of space (PoS) proposals apply the same principle by proving a dedicated amount of memory or disk space instead of CPU time. Proof of bandwidth approaches have been discussed in the context of cryptocurrency. Proof of ownership aims at proving that specific data are held by the prover.
[https://en.wikipedia.org/wiki/Proof-of-work_system]
_DESCRIPTION:
A proof-of-work (POW) system (or protocol, or function) is an economic measure to deter denial of service attacks and other service abuses such as spam on a network by requiring some work from the service requester, usually meaning processing time by a computer. The concept may have been first presented by Dwork and Naor in a 1993 journal.[1] The term "Proof of Work" or POW was first coined and formalized in a 1999 paper.[2]
A key feature of these schemes is their asymmetry: the work must be moderately hard (but feasible) on the requester side but easy to check for the service provider. This idea is also known as a CPU cost function, client puzzle, computational puzzle or CPU pricing function. It is distinct from a CAPTCHA, which is intended for a human to solve quickly, rather than a computer.
[https://en.wikipedia.org/wiki/Proof-of-work_system]
_SPECIFIC:
* CryptoNote
* Dash
* Primecoin
* Scrypt
* SHA-256
* Zerocoin
name::
* McsEngl.bcnpow.CryptoNote@cptIt,
* McsEngl.bcnmny'proof-of-work.CryptoNote@cptIt,
name::
* McsEngl.bcnpow.Scrypt@cptIt,
* McsEngl.bcnpow.scrypt@cptIt,
* McsEngl.bcnscrypt-pow@cptIt,
_DESCRIPTION:
In cryptography, scrypt is a password-based key derivation function created by Colin Percival, originally for the Tarsnap online backup service.[1]
The algorithm was specifically designed to make it costly to perform large-scale custom hardware attacks by requiring large amounts of memory.
In 2012, the scrypt algorithm was published by IETF as an Internet Draft, intended to become an informational RFC.[2]
A simplified version of scrypt is used as a proof-of-work scheme by a number of cryptocurrencies first implemented by Litecoin.[3]
[https://en.wikipedia.org/wiki/Scrypt]
===
Scrypt:
An alternative proof of work system to SHA-256, designed to be particularly friendly to CPU and GPU miners, while offering little advantage to ASIC miners.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.bcnpow.SHA-256@cptIt,
* McsEngl.bcnnet'pow.SHA-256@cptIt,
name::
* McsEngl.bcnpow.X11@cptIt,
_DESCRIPTION:
Dash uses a chained hashing algorithm approach called X11 for the proof-of-work. Instead of using the SHA-256 (from well-known Secure Hash Algorithm family) or scrypt it uses 11 rounds of different hashing functions.[3]
[https://en.wikipedia.org/wiki/Dash_%28cryptocurrency%29]
name::
* McsEngl.bcnbcn'Address (bcnads)@cptIt,
* McsEngl.bcnads@cptIt,
* McsEngl.bcnnet'address@cptIt,
* McsEngl.blockchain-address@cptIt,
_DESCRIPTION:
Address is a-sequence of symbols a-blockchain uses to denote ownership of crypto-info in the-blockchain.
[hmnSngo.2017-04-03]
_SPECIFIC:
* bitcoin#ql:idBtcads#: 1DSrfJdB2AnWaFNgSbv3MZC2m74996JafV,
* ethereum#ql:idEthads#: 0x0998c9a0c7224Ec4ED782A4Ecfef53A0e25fA9FC,
name::
* McsEngl.bcnbcn'Transaction (bcntx)@cptIt,
* McsEngl.bcntransaction@cptIt,
* McsEngl.bcntsn@cptIt,
* McsEngl.bcntx@cptIt,
* McsElln.συναλλαγή-μπιτκόιν@cptIt,
_DESCRIPTION:
Transactions are documents that broadcasted to the-network and change THE-STATE of the-blockchain.
Information on the-blockchain (exchange-value, programs, etc) is-stored cryptographically with public-private-keys.
Blockchain-addresses are unique-names of blockchain-info[1] which[1] can-be-managed only by the-owners of its[1] private-key.
[hmnSngo.2017-04-02]
_DESCRIPTION:
A blockchain is a globally shared, transactional database. This means that everyone can read entries in the database just by participating in the network. If you want to change something in the database, you have to create a so-called transaction which has to be accepted by all others. The word transaction implies that the change you want to make (assume you want to change two values at the same time) is either not done at all or completely applied. Furthermore, while your transaction is applied to the database, no other transaction can alter it.
As an example, imagine a table that lists the balances of all accounts in an electronic currency. If a transfer from one account to another is requested, the transactional nature of the database ensures that if the amount is subtracted from one account, it is always added to the other account. If due to whatever reason, adding the amount to the target account is not possible, the source account is also not modified.
Furthermore, a transaction is always cryptographically signed by the sender (creator). This makes it straightforward to guard access to specific modifications of the database. In the example of the electronic currency, a simple check ensures that only the person holding the keys to the account can transfer money from it.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#transactions]
_DESCRIPTION:
Transaction: a transaction is a document authorizing some particular action associated with the blockchain. In a currency, the dominant transaction type is sending currency units or tokens to someone else; in other systems actions like registering domain names, making and fulfilling trade offers and entering into contracts are also valid transaction types.
[https://github.com/ethereum/wiki/wiki/Glossary#blockchains]
name::
* McsEngl.bcntx'Creator (sender)@cptIt,
* McsEngl.bcntx'creator@cptIt,
* McsEngl.bcntx'sender@cptIt,
name::
* McsEngl.bcntx'Fee@cptIt,
_DESCRIPTION:
As blocks began to fill up in 2015, it became clear that the best practice is to use a dynamic fee algorithm because it can respond to changing conditions on the network.
Bitcoin Core started calculating dynamic fee estimates as of the 0.10 release in February 2015, and Alex Morcos has been steadily improving them since then. Core's fee estimate algorithm is rather complex; you can view its code here and the english explanation here.
[http://www.coindesk.com/building-better-bitcoin-fee-market/]
name::
* McsEngl.bcntx'Number-per-second@cptIt,
* McsEngl.bcnnet'Number-of-transactions-per-second@cptIt,
* McsEngl.bcnnet'Transactions-per-second@cptIt,
* McsEngl.bcnnet'Transaction-speed@cptIt,
_SPECIFIC:
Bitcoin: 7tx/sec
Ethereum: 25tx/sec
BOSnet: 1,000tx/sec (target)
name::
* McsEngl.bcntx.specific@cptIt,
* McsEngl.bcntx.specific@cptIt,
_SPECIFIC:
* Bitcoin-transaction#ql:idBtctx#,
* Ethereum-transaction#ql:idEthtx#
SPECIFIC:
Ethereum is at its heart based on the same fundamental technology as Bitcoin, and even shares many of the same principles, but with Ethereum we can create almost any conceivable type of transaction, opening new opportunities to automate industry verticals that previously were impossible.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
name::
* McsEngl.bcntx.MICROTRANSACTION@cptIt,
* McsEngl.blockchain-microtransaction@cptIt,
* McsEngl.bcnmicrotransaction@cptIt,
_DESCRIPTION:
Microtransaction:
Paying a tiny amount for an asset or service, primarily online.
Micro-transactions are difficult to perform under conventional payment systems, because of the heavy commissions involved.
It is difficult to pay two cents to read an online article using your credit card, for example.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.bcnbcn'Crypto (bcncrpt)@cptIt,
* McsEngl.blockchain-cryptography@cptIt,
* McsEngl.bcncryptography@cptIt,
_DESCRIPTION:
Cryptography:
The use of mathematics to create codes and ciphers that can be used to conceal information.
Used as the basis for the mathematical problems used to verify and secure bitcoin transactions.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.bcncrpt'Algorithm (cipher)@cptIt,
* McsEngl.blockchain-algorithm.cryptography@cptIt,
* McsEngl.blockchain-cipher@cptIt, /'saifer/
* McsEngl.blockchain-cypher@cptIt,
* McsEngl.blockchain-encryption-algorithm@cptIt,
* McsEngl.bcncipher@cptIt,
_DESCRIPTION:
In cryptography, a cipher (or cypher) is an algorithm for performing encryption or decryption—a series of well-defined steps that can be followed as a procedure.
An alternative, less common term is encipherment.
To encipher or encode is to convert information from plain text into code or cipher.
[http://en.wikipedia.org/wiki/Cipher]
name::
* McsEngl.bcncrpt'Cryptographic-hash-funciton (bcnchf)@cptIt,
* McsEngl.blockchain-cryptographic-hash-function@cptIt,
* McsEngl.blockchain-hash-function@cptIt,
* McsEngl.bcncryptographic-hash-function@cptIt,
* McsEngl.bcnhash-function@cptIt,
_DESCRIPTION:
Cryptographic hash functions are a third type of cryptographic algorithm.
They take a message of any length as input, and output a short, fixed length hash which can be used in (for example) a digital signature.
For good-hash-functions, an attacker cannot find two messages that produce the same hash.
MD4 is a long-used hash function which is now broken;
MD5, a strengthened variant of MD4, is also widely used but broken in practice.
The U.S. National Security Agency developed the Secure Hash Algorithm series of MD5-like hash functions:
SHA-0 was a flawed algorithm that the agency withdrew;
SHA-1 is widely deployed and more secure than MD5, but cryptanalysts have identified attacks against it;
the SHA-2 family improves on SHA-1, but it isn't yet widely deployed, and the U.S. standards authority thought it "prudent" from a security perspective to develop a new standard to "significantly improve the robustness of NIST's overall hash algorithm toolkit."[25]
Thus, a hash function design competition is underway and meant to select a new U.S. national standard, to be called SHA-3, by 2012.
[http://en.wikipedia.org/wiki/Cryptography#Symmetric-key_cryptography]
name::
* McsEngl.bcnchf'Hash (output)@cptIt,
* McsEngl.blockchain-hash@cptIt,
* McsEngl.bcncryptographic-has@cptIt,
* McsEngl.bcndigest@cptIt,
* McsEngl.bcnhash@cptIt,
* McsEngl.bcnhash-function-output@cptIt,
* McsEngl.bcnhash-value@cptIt,
====== lagoGreek:
* McsElln.κατακερματισμός-μπλοκτσέιν@cptIt,
* McsElln.κρυπτογραφικός-κατακερματισμός-μπλοκτσέιν@cptIt,
* McsElln.μπλοκτσέιν-κατακερματισμός@cptIt,
_DESCRIPTION:
Hash is-called the-output of a-hash-function#ql:idBcncrptchf#.
[hmnSngo.2017-04-08]
name::
* McsEngl.bcnchf'Hashing@cptIt,
* McsEngl.blockchain-hashing@cptIt,
* McsEngl.bcnhashing@cptIt,
_DESCRIPTION:
Hashing is-called THE-PROCESS of using a-hash-function#ql:idBcncrptchf# on input-data[1] and producing its[1] hash.
[hmnSngo.2017-04-08]
name::
* McsEngl.bcncrpt.Public-key-cryptography@cptIt,
* McsEngl.blockchain-asymmetric-cryptography@cptIt,
* McsEngl.blockchain-publickey-cryptography@cptIt,
_DESCRIPTION:
Public key cryptography, or asymmetric cryptography, is any cryptographic system that uses pairs of keys: public keys which may be disseminated widely, and private keys which are known only to the owner.
This accomplishes two functions:
- authentication, which is when the public key is used to verify that a holder of the paired private key sent the message, and
- encryption, whereby only the holder of the paired private key can decrypt the message encrypted with the public key.
[https://en.wikipedia.org/wiki/Public-key_cryptography]
name::
* McsEngl.bcnbcn'Hash-rate (bcnhhr )@cptIt,
* McsEngl.bcnnet'hash-rate@cptIt,
* McsEngl.bcnnet'hashing-power@cptIt,
* McsEngl.blockchain-hash-rate@cptIt,
* McsEngl.blockchain-hashing-power@cptIt,
* McsEngl.blockchain-hashing-rate@cptIt,
_DESCRIPTION:
The hash rate is the measuring unit of the processing power of the Bitcoin network. The Bitcoin network must make intensive mathematical operations for security purposes. When the network reached a hash rate of 10 Th/s, it meant it could make 10 trillion calculations per second.
[https://bitcoin.org/en/vocabulary#hash-rate]
===
Hash (Rate) ~ A hash is the output of a-hash-function#ql:hash_function@cptIt# and, as it relates to Bitcoin, the Hash Rate is the speed at which a compute is completing an operation in the Bitcoin code. A higher hash rate is better when mining as it increases your opportunity of finding the next block and receiving the reward.
[http://bitcoinsimplified.org/definitions/]
name::
* McsEngl.bcnbcn'State-of-blockchain@cptIt,
* McsEngl.bcnbcnstate@cptIt,
* McsEngl.blockchain-state@cptIt,
_DESCRIPTION:
A blockchain contains not only the information that is currently stored in the database, but also every change made to the database in its history.
Known as the state and transactions respectively it makes for a database with a complete custodial history that cannot be altered without altering every subsequent block.
[https://dappsforbeginners.wordpress.com/tutorials/introduction-to-development-on-ethereum/]
name::
* McsEngl.bcnbcn.SPECIFIC@cptIt,
_SPECIFIC:
* bitcoin-blockchain#ql:idBtcbcn#,
* ethereum-blockchain#ql:idEthbcn#
name::
* McsEngl.bcnnet'Exchange-Value-TOKEN (bcnevt)@cptIt,
name::
* McsEngl.bcnevt'DESCRIPTION@cptIt,
_DESCRIPTION:
'def.Blockchain-Exchange-Value-Token-(bevtkn)' is digital-information recorded on the-blockchain that REPRESENTS units of exchange-value (= no double-spending).
Information can-represents anything.
IF this bevtkn represents AND a-commodity, we say that this bevtkn IS-BACKED with this commodity.
Generally, there-are two theories about the-exchange-value of a-commodity.
1) the-supply-demand-theory (capitalism advocating):
the supply and demand of a-commodity defines its exchange-value.
2) the-average-work-TIMES-the-supply-demand-theory (sosialism advocating):
when there-is equilibrium between supply and demand the-exchange-value is the-average-work needed to produce a-commodity (= an-entity we exchange, not an-entity we use).
No matter what theory we accept, when we exchange commodities we accept|set an-exchange-value.
The-problem is to use A-FAIR-ONE.
Blockchain-DAOs can define a-fair-exchange-value and use it automatically.
[hmnSngo.2017-04-02]
===
'def.Exchange-value-token-(bcnevt)' is digital-information recorded on the-blockchain that REPRESENTS exchange-value.
Information can-represents anything.
IF this bcnevt represents AND a-commodity, we say that this bcnevt IS-BACKED with this commodity.
Generally, there-are two theories about the-exchange-value of a-commodity.
1) the-supply-demand-theory (capitalism advocating):
the supply and demand of a-commodity defines its exchange-value.
2) the-average-work-TIMES-the-supply-demand-theory (sosialism advocating):
when there-is equilibrium between supply and demand the-exchange-value is the-average-work needed to produce a-commodity (= an-entity we exchange, not an-entity we use).
Societies have to choose which view serves better their interests, because they have to correlate exchange-values to their commodities, fair or not.
[hmnSngo.2017-03-29]
===
exchange-value-of-commodity = average-work-measure TIMES demand / supply.
[hmnSngo.2017-04-15]
===
No matter what theory we accept, when we exchange commodities we accept|set an-exchange-value.
The-problem is to use A-FAIR-ONE.
Blockchain-DAOs can define a-fair-exchange-value and use automatically.
[hmnSngo.2017-04-01]
===
Satoshi Nakamoto#ql:idBtchmnSnt# solved the-double-spending-problem WHITHOUT a-central trust entity.
So blockchain is ideal for holding information representing exchange-value, ie any financial-product.
[hmnSngo.2017-03-30]
===
Blockchain-money is money a-bcnnet needs to operate or issued by it.
[hmnSngo.2017-03-27]
_DESCRIPTION:
Ether is a necessary element -- a fuel -- for operating the distributed application platform Ethereum.
[https://www.ethereum.org/ether]
DESCRIPTION
A cryptocurrency (or crypto currency) is a medium of exchange using cryptography to secure the transactions and to control the creation of new units.[1] Cryptocurrencies are a subset of alternative currencies, or specifically of digital currencies. Bitcoin became the first decentralized cryptocurrency in 2009.[2] Since then, numerous cryptocurrencies have been created. These are frequently called altcoins, as a blend of bitcoin alternative.[3][4]
Cryptocurrencies typically feature decentralized control[citation needed] (as opposed to a centralized electronic money system, such as PayPal) and a public ledger[citation needed] (such as bitcoin's block chain) which records transactions.
[https://en.wikipedia.org/wiki/Cryptocurrency] {retrieved 2015-08-12},
_DESCRIPTION:
A cryptocurrency is a type of digital currency (which in turn is a type of alternative currency) that relies on cryptography, usually alongside a proof-of-work scheme, in order to create and manage the currency.[1][2] Cryptocurrencies are peer-to-peer and decentralized, and are currently all based on the first cryptocurrency, Bitcoin.[1][2][3][4][5][6] They are generally designed to have no inflation (once all the currency has been produced), in order to keep scarcity and hence value.[7][8] However, a few cryptocurrencies, such as PPCoin, do have a small amount of inflation. Cryptocurrencies are also designed to ensure that funds can neither be frozen nor seized.[7][9] Existing cryptocurrencies are all pseudonymous, though additions such as Zerocoin have been suggested, which would allow for anonymity.[10][11][12][13]
[http://en.wikipedia.org/wiki/Cryptocurrency]
_DESCRIPTION:
Digital currencies or cryptocurrencies are a way of transferring money over the internet. These combine cutting-edge encryption with far-reaching developments in social networking. The resulting advantages that cryptocurrencies offer over traditional methods of payment are truly remarkable.
We have used the same way of transferring money for centuries. Even with the advent of the internet, these methods didn’t really change much. Cryptocurrency is something completely new – so new that it cannot be described in terms of these traditional means of payment.
Instead, it’s easier to understand cryptocurrencies in terms of what they can do. For the first time in history, it is possible to send money anywhere on the planet within a few minutes, directly between individuals and completely securely, without relying on any banks, payment companies or other third parties, and virtually free of cost.
[http://nxt.org/about/what-is-nxt/]
_DESCRIPTION:
Cryptocurrency:
A form of currency based on mathematics alone.
Instead of fiat currency, which is printed, cryptocurrency is produced by solving mathematical problems based on cryptography.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.bcnevt'NAME@cptIt,
* McsEngl.bcnevt@cptIt, {2017-04-14}
* McsEngl.bcnevtkn@cptIt, {2017-03-29}
* McsEngl.bcnnet'exchante-value-token@cptIt, {2017-03-29}
* McsEngl.bevtkn@cptIt, {2017-04-02}
* McsEngl.blockchain-exval-token@cptIt, {2017-03-30}
* McsEngl.blockchain-exchante-value-token@cptIt, {2017-03-29}
* McsEngl.exchante-value-token-of-bcnnet@cptIt, {2017-03-29}
* McsEngl.altcoin@cptIt, [http://nxt.org/about/what-is-nxt/]
* McsEngl.bcnmny@cptIt,
* McsEngl.bcnnet'currency@cptIt,
* McsEngl.bcnnet'money@cptIt,
* McsEngl.bcnnet'token@cptIt,
* McsEngl.blockchain-currency@cptIt,
* McsEngl.blockchain-money@cptIt,
* McsEngl.blockchain-token@cptIt,
* McsEngl.cryptocoin@cptIt, {2017-01-31}
* McsEngl.cryptocurrency@cptIt,
* McsEngl.decentralized-currency@cptIt,
* McsEngl.decentralized-trust-currency@cptIt, {2018-05-19}
* McsEngl.mnyAltcoin@cptIt,
* McsEngl.mnyBcn@cptIt, {2016-04-08}
* McsEngl.mnyBlockchain@cptIt,
* McsEngl.mnyCrypto@cptIt,
* McsEngl.money.blockchain@cptIt, {2016-04-08}
* McsEngl.money.decentralized@cptIt, {2016-06-01}
* McsEngl.netBcn'currency@cptIt,
* McsEngl.netBcn'money@cptIt,
* McsEngl.netBcn'token@cptIt,
====== lagoGreek:
* McsElln.μπλοκτσέιν-παα@cptIt,
* McsElln.μπλοκτσέιν-πληροφορία-ανταλλακτικής-αξίας@cptIt, {2017-04-10}
* McsElln.κρυπτονόμισμα@cptIt,
_INTERNET_CURRENCY:
* including internet currencies such as Bitcoin and Ven,
[http://en.wikipedia.org/wiki/Ripple_monetary_system]
name::
* McsEngl.bcnevt'Exchange-rate (bcnexr|value)@cptIt,
* McsEngl.bcnevt'exchange-rate@cptIt,
* McsEngl.bcnevt'foreign-exchange-rate@cptIt,
* McsEngl.bcnevt'forex@cptIt,
* McsEngl.bcnevt'rate@cptIt,
* McsEngl.bcnevt'value@cptIt, {2017-04-02}
* McsEngl.bcnevt'forex@cptIt,
* McsEngl.bcnexr@cptIt, {2017-04-15}
* McsElln.ισοτιμία-μπλοκτσέιν-παα@cptIt,
_DESCRIPTION:
Exchange-rate (value) of a-blockchain-token#ql:idBcnevtkn# is its exchange-value measured with another UNIT of exchange-value.
[hmnSngo.2017-04-02]
_ADDRESS.WPG:
* https://coinmarketcap.com//
* https://www.cryptonator.com/rates,
* http://coincap.io/?gclid=CjwKEAiAn7HEBRDHwNqitoWqsQcSJAADWmI2M6lbOoLnHXb5LZupGEOI0UmFYokrLGFyNNJ1vGnktBoC3nLw_wcB,
name::
* McsEngl.bcnevt'Volatility@cptIt,
* McsEngl.volatility-of-evu@cptIt,
====== lagoGreek:
* McsElln.διακύμανση-κρυπτονομίσματος@cptIt,
name::
* McsEngl.bcnevt'Market-cap@cptIt,
* McsEngl.bcnmarket-cap-of-bcnevt@cptIt,
* McsEngl.blockchain-market-cap-of-bcnevt@cptIt,
* McsEngl.market-cap-of-bcnevt@cptIt,
_DESCRIPTION:
The-product of aggregate-tokens times its idBcnevtexr.
name::
* McsEngl.bcnevt'BACKNESS@cptIt,
_DESCRIPTION:
All bcnevt REPRESENT (as digital-info) exchange-value.
Backness is A-SECOND-REPRESENTATION with a-commodity.
Some are-backed with gold or other precious-metals.
Other are-backed with fiat-money, us-dollars, euros, etc.
Any commodity, financial or not can-be-used.
[hmnSngo.2017-04-19]
name::
* McsEngl.bcnevt'Distribution@cptIt,
_DESCRIPTION:
So, as of Dec. 3. [{2013}], using a price of $1,000 (which is basically where we are now), and assuming 12 million Bitcoins in circulation, here's the breakdown: 47 individuals own 28.9% of the approximately 12 million Bitcoins in existence so far.
Another 880 own 21.5%, meaning 927 people control half of the entire market cap of the digital currency.
Another 10,000 individuals control about a quarter.
And the rest of us (around a million of us) get the crumbs (500,000 are out of circulation, whether through government seizure or people losing their passwords).
[http://www.businessinsider.com/927-people-own-half-of-the-bitcoins-2013-12]
===
- NEM relatively large egalitarian distribution
[http://wiki.nem.io/index.php/About:_General]
name::
* McsEngl.bcnevt'Evaluation@cptIt,
_DESCRIPTION:
Evaluating an Alt Coin
With so many alt coins out there, how does one decide which ones are worthy of attention?
Some alt coins attempt to achieve broad distribution and use as currencies.
Others are laboratories for experimenting on different features and monetary models.
Many are just get-rich-quick schemes by their creators.
To evaluate alt coins, I look at their defining characteristics and their market metrics.
Here are some questions to ask about how well an alt coin differentiates from bitcoin:
- Does the alt coin introduce a significant innovation?
- Is the difference compelling enough to attract users away from bitcoin?
- Does the alt coin address an interesting niche market or application?
- Can the alt coin attract enough miners to be secured against consensus attacks?
Here are some of the key financial and market metrics to consider:
- What is the total market capitalization of alt coin?
- How many estimated users/wallets does the alt coin have?
- How many merchants accept the alt coin?
- How many daily transactions (volume) are executed on the alt coin?
- How much value is transacted daily?
[https://github.com/bitcoinbook/bitcoinbook/blob/first_edition/ch09.asciidoc#evaluating-an-alt-coin]
_DESCRIPTION:
Without mentioning Litecoin, he ranks Bitcoin, Monero and Decred as his highest coins citing that Decred spent a year doing coding to improve its consensus and governance system, and Monero which didn’t have a GUI wallet. Ethereum is close, he adds, but the decision to hardfork and go back on the “uncensorable transaction” promise really hurts.
[https://cointelegraph.com/news/what-to-watch-out-for-before-investing-in-altcoins-litecoin-creator]
name::
* McsEngl.bcnevt'Fungibility@cptIt,
_DESCRIPTION:
FUNGIBLE CRYPTOCURRENCY
In order to remain equally interchangeable, units of cryptocurrency must be unlinked from their history so that one unit is as good as any other unit.
Zcash brings fungibility to cryptocurrency by unlinking shielded coins from their history on the blockchain.
[https://z.cash/]
name::
* McsEngl.bcnevt'Human@cptIt,
name::
* McsEngl.bcnevthmn.Creator@cptIt,
* McsEngl.bcnevt'creator@cptIt,
* McsEngl.bcnevt'founder@cptIt,
name::
* McsEngl.bcnevthmn.User-base@cptIt,
* McsEngl.bcnevt'adoption@cptIt,
* McsEngl.bcnevt'usage@cptIt,
* McsEngl.bcnevt'user-base@cptIt,
* McsEngl.bcnevt'adoption@cptIt,
* McsEngl.bcnevt'usage@cptIt,
name::
* McsEngl.bcnevt'Law@cptIt,
_ADDRESS.WPG:
* http://cointelegraph.com/news/russian-law-enforcement-considers-further-criminalizing-cryptocurrencies,
_DESCRIPTION:
As of 2013 cryptocurrencies were illegal in Iceland, due to its freeze on foreign exchange.[28] Controversy over the misuse of cryptocurrency has also led to restrictions in certain countries – regulators in China banned the handling of bitcoins by financial institutions during an extremely fast adoption period in early 2014.[29] In Russia, though cryptocurrencies are legal, it is illegal to actually purchase goods with any currency other than the Russian ruble.[30]
On March 25, 2014, the United States Internal Revenue Service (IRS) ruled that bitcoin will be treated as property for tax purposes as opposed to currency. This means bitcoin will be subject to capital gains tax. One benefit of this ruling is that it clarifies the legality of bitcoin. No longer do investors need to worry that investments in or profit made from bitcoins are illegal or how to report them to the IRS.[31] In a paper published by researchers from Oxford and Warwick it was shown that Bitcoin has some characteristics similar to the precious metals market more than to traditional currencies, hence in agreement to the IRS decision even if based on different reasons.[32]
Some cryptocurrency have legal issues such as Coinye, an altcoin that used, without permission, rapper Kanye West as its logo. This altcoin has been compared to the popular Dogecoin. Upon hearing of the release of Coinye, originally called Coinye West, attorneys for Kanye West sent a cease and desist letter to the email operator of Coinye, who since revealed himself as David P. McEnery Jr. The letter stated that Coinye was willful trademark infringement, unfair competition, cyberpiracy, and dilution and instructed Coinye to stop using the likeness and name of Kanye West.[33]
[https://en.wikipedia.org/wiki/Cryptocurrency]
name::
* McsEngl.bcnevt'Organization (bcnevtogn)@cptIt,
name::
* McsEngl.bcnevtogn.EDUCATING@cptIt,
_ADDRESS.WPG:
* http://digitalcurrency.unic.ac.cy/?utm_source=Twitter&utm_medium=Banner&utm_campaign=MScDigital,
name::
* McsEngl.bcnevt'Security@cptIt,
_DESCRIPTION:
Reliable wallet/service for storage of your altcoins is the most important thing for you.
Every owner of cryptocurrency can tell their own story of how they failed to rescue their PC flooded with beer, on which wallet files were stored, or could not restore access to the online wallet linked to their lost mobile phone.
[http://cointelegraph.com/news/tips-for-revamping-your-cryptocurrency-job-search-in-2016]
name::
* McsEngl.bcnevt'Time@cptIt,
name::
* McsEngl.bcnevt'Time.release@cptIt,
* McsEngl.date-of-introduction-of-bcnevt@cptIt,
* McsEngl.bcnevt'introduction@cptIt,
name::
* McsEngl.bcnevt'Resource@cptIt,
_ADDRESS.WPG:
* http://www.coinwarz.com// How frequently is the information updated on CoinWarz?
The current difficulty, exchange rate, exchange volume, and current profit ratio versus BTC are updated every 5 minutes. All other information, including the difficulty charts, exchange rate charts, and profit ratio versus BTC charts are updated every hour.
* http://cointelegraph.com/news/auroracoin-sterlingcoin-scotcoin-national-cryptocurrencies-provide-alternative-to-central-banking,
* http://cointelegraph.com/news/central-banking-is-broken-solution-is-bitcoin-panama-papers-reveal,
* http://www.links.org/files/decentralised-currencies.pdf,
* 2015-03-10: Masters joins cryptocurrency start-up http://www.ft.com/intl/cms/s/0/e29808a8-c744-11e4-9e34-00144feab7de.html?siteedition=intl#axzz3U5OWaspl,
name::
* McsEngl.bcnevt'env.OTHER-VIEW@cptIt,
* McsEngl.money.math-based@cptIt,
* McsEngl.mny.math-based@cptIt,
_DESCRIPTION:
XRP: Math-Based Currency
Feb 20, 2015 | Julian Martinez
A math-based currency, also referred to as a cryptocurrency, is a digital asset with verifiable mathematical properties, similar to how we can reliably verify gold as a substance made of atoms with 79 protons. Math-based currencies exist as digital assets in their own right and can be transferred directly between users (as fiat cash can be) without relying on a centralized protocol operator. XRP exists as a math-based currency on the Ripple protocol.
The supply of a math-based currency is governed by mathematics. There is no human intervention after the creation & implementation of the protocol rules. This is in contrast to the many “virtual currencies” that can be issued without restriction by companies and people (such as airline miles, reward points, etc.). In this example, XRP cannot be ‘devalued’ by the creation of additional XRP.
Bitcoin was the first example of a math-based currency. Bitcoin exists natively as a digital asset. On the network, it is not a balance that is redeemable at a central point of failure, and does not carry risk from a counterparty as “digital fiat” currencies do (as with an online balance from a bank that is not FDIC insured). You could hand someone a thumb drive with Bitcoin on it, and in doing so, you are transferring the asset itself, like handing over cash, as opposed to transferring an IOU or someone’s promise to pay. It does not require trust in any third party.
XRP exists natively within the Ripple protocol as a counterparty-free currency, as Bitcoin does on the Blockchain. Because XRP is an asset, as opposed to a redeemable balance, it does not require that users trust any specific financial institution to trade or exchange it. All other currencies on Ripple do require some amount of trust, as they each have an issuer, from whom that currency can be redeemed (this includes BTC on the Ripple network).
Users of the Ripple protocol are not required to use XRP as a medium of exchange or as a store of value. The Ripple protocol is currency agnostic. Users can use their preferred currency, whether that’s USD, BTC, XRP, or any other currency. Similarly, users may freely choose to trust any issuers they find reliable; this includes the trust implied by users trading in an issued non-XRP currency.
[https://ripple.com/knowledge_center/math-based-currency-2/]
name::
* McsEngl.bcnevt'DOING@cptIt,
name::
* McsEngl.bcnevt'Acquiring@cptIt,
* McsEngl.bcnevt'acquiring@cptIt,
* McsEngl.bcnevt'obtaining@cptIt,
* McsEngl.bcnevt'acquiring@cptIt,
* McsEngl.bcnevt'obtaining@cptIt,
_SPECIFIC:
* exchanging,
* mining,
* selling-goods-and-services,
name::
* McsEngl.bcnevt'Issuing@cptIt,
* McsEngl.bcnevt'creating@cptIt,
* McsEngl.bcnevt'issuing@cptIt,
* McsEngl.bcnevt'issuance@cptIt,
_DESCRIPTION:
- NEM zero monetary inflation (fixed supply, all 9 billion coins released at launch).
[http://wiki.nem.io/index.php/About:_General]
name::
* McsEngl.bcnevt.specific@cptIt,
* McsEngl.bcnevtSpc@cptIt,
* McsEngl.bcnevt.specific@cptIt,
SPECIFIC:
This is a list of notable cryptocurrencies. There were more than 530 cryptocurrencies available for trade in online markets as of 5 January 2015 and more than 740 in total[1] but only 10 of them had market capitalizations over $10 million.[2]
[https://en.wikipedia.org/wiki/List_of_cryptocurrencies]
SPECIFIC:
* AMP,
* Ardor-ARDR,
* Augur-REP,
* AuroraCoin-AUR,
* Bitcoin-BTC#ql:idBtcmny#,
* BitShares-BTS,
* Bytecoin-BCN,
* BlackCoin, BLK,
* Counterparty,
* CureCoin-CURE,
* Darkcoin-DRK,
* Dash,
* Dogecoin-DOGE,
* Ether-ETH,
* Factom-FCT,
* Faircoin-FAIR,
* Freicoin
* Gulden-NLG,
* HellasCoin-HLC,
* Lisk-LSK#ql:idLskcet#,
* Litecoin-LTC,
* MaidSafeCoin-MAID,
* Mastercoin,
* Monero -XMR,
* Namecoin-NMC,
* NAV_Coin-NAV,
* Nubits-NBT,
* NXT,
* Peercoin,
* Reddcoin-RDD,
* Ripple-XRP,
* Stellar,
* StorjcoinX,
SPECIFIC:
* SHA-256-based
* Bitcoin Peercoin Namecoin Titcoin
* Scrypt-based
* Auroracoin Dogecoin Litecoin PotCoin
* Zerocoin-based
* Zcash Zcoin ZeroVert
* CryptoNote-based
* Bytecoin Monero
* Other proof-of-work
* Dash Ethereum Primecoin
* Non proof-of-work
* BlackCoin Counterparty Gridcoin Lisk NEM Nxt Ripple Stellar Shadow
* Technology
* Blockchain Cryptocurrency tumbler Proof-of-stake Proof-of-work system Zerocash Zerocoin
[https://en.wikipedia.org/wiki/Monero_(cryptocurrency)]
name::
* McsEngl.bcnevt.SPECIFIC-DIVISION.consensus-algorithm@cptIt,
_SPECIFIC:
* consensus-bcnevt#ql:idBcncevt#,
* consensusNo-bcnevt#ql:idBcncevtNo#
name::
* McsEngl.bcnevt.SPECIFIC-DIVISION.time-of-genesis@cptIt,
_SPECIFIC:
* {2017}:
* {2016}:
* {2015}:
BitShares-BTS,
Ether,
* {2014}:
AuroraCoin,
DASH,
NuBits,
* {2013}:
DogeCoin,
* {2012}:
PPCoin,
* {2011}:
LiteCoin,
* {2010}:
* {2009}:
- Bitcoin,
name::
* McsEngl.bcnevt.SPECIFIC-DIVISION.bitcoin@cptIt,
_SPECIFIC:
* bitcoin,
* bitcoinNo-altcoin,
name::
* McsEngl.blockchain-altcoin@cptIt,
* McsEngl.bcnaltcoin@cptIt,
_DESCRIPTION:
Altcoin:
The collective name for cryptocurrencies offered as alternatives to bitcoin.
Litecoin, Feathercoin and PPcoin are all altcoins.
[http://www.coindesk.com/information/bitcoin-glossary//]
===
Altcoin:
A clone of the protocol with some modifications.
Usually all altcoins have rules incompatible with Bitcoin and have their own genesis blocks.
Most notable altcoins are Litecoin (uses faster block confirmation time and scrypt as a proof-of-work) and Namecoin (has a special key-value storage).
In theory, an altcoin can be started from an existing Bitcoin blockchain if someone wants to support a different set of rules (although, there was no such example to date).
See also Fork#ql:idBtcdngFrk#.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.bcnevt.SPECIFIC-DIVISION.activeness@cptIt,
name::
* McsEngl.bcnevt.ACTIVE@cptIt,
* McsEngl.bcnevt.active@cptIt,
name::
* McsEngl.bcnevt.ACTIVE.NO@cptIt,
* McsEngl.bcnevt.activeNo@cptIt,
* McsEngl.bcnevt.inactive@cptIt,
_DESCRIPTION:
CT: Has CoinMarketCap ever permanently removed a coin from being listed on the site? If so is there a list of delisted coins? How about delisting an exchange?
G: About 40% of the coins ever added to the site are now "inactive" due to failing to meet the basic criteria. In virtually all cases, the reason for delisting is because all exchanges have delisted the coin. There is not currently a list of these coins, but perhaps in the future. Exchanges get delisted when their API fails ceases to work for a significant period of time.
[https://cointelegraph.com/news/coinmarketcap-about-40-of-the-coins-ever-added-to-the-site-are-now-inactive] {2015-08-21}
_SPECIFIC:
* Solocoin-SOL, https://coinmarketcap.com/currencies/solcoin//
name::
* McsEngl.bcnevt.SPECIFIC-DIVISION.mining@cptIt,
name::
* McsEngl.bcnevt.MINABLE@cptIt,
* McsEngl.bcnevt.minable@cptIt,
_SPECIFIC:
* Bitcoin BTC,
* Ethereum ETH,
* Litecoin LTC,
* Dash DASH,
* Monero XMR,
* Ethereum Classic ETC,
* Zcash ZEC,
* Steem STEEM,
* Decred DCR,
* BitConnect BCC,
* Dogecoin DOGE,
* Bytecoin BCN,
* GameCredits GAME,
* Siacoin SC,
* Peercoin PPC,
* Emercoin EMC,
* Komodo KMD,
* Nexus NXS,
* SysCoin SYS,
* ZCoin XZC,
* Creditbit CRBIT,
* Namecoin NMC,
name::
* McsEngl.bcnevt.MINABLE.NO@cptIt,
* McsEngl.bcnevt.minable@cptIt,
_SPECIFIC:
* Ripple-XRP#ql:idXrpcevt#,
* NEM-XEM,
* PIVX-PIVX,
* Stratis-STRAT,
* Waves-WAVES,
* Lisk LSK,
* Stellar Lumens XLM,
* BitShares BTS,
* Ark ARK,
* Nxt NXT,
* Bitcrystals BCY,
* Byteball GBYTE,
* Counterparty XCP,
* AntShares ANS,
* I/O Coin IOC,
* Rubycoin RBY,
* Nexium NXC,
* BlackCoin BLK,
* NAV Coin NAV,
* YbCoin YBC,
* Radium RADS,
* BitBay BAY,
* ION ION,
* Omni OMNI,
name::
* McsEngl.bcnevt.MINABLE.SIGNIFICANTLY-PREMINED@cptIt,
* McsEngl.bcnevt.sigificantly-premined@cptIt,
name::
* McsEngl.bcnevt.AGGREGATE@cptIt,
* McsEngl.bcnevt.supply@cptIt,
* McsEngl.supply-of-bcnevt@cptIt,
_DESCRIPTION:
Most cryptocurrencies are designed to gradually decrease production of currency, placing an ultimate cap on the total amount of currency that will ever be in circulation.
This can mimic the scarcity (and value) of precious metals and avoid hyperinflation.
Compared with ordinary currencies held by financial institutions or kept as cash on hand, cryptocurrencies are less susceptible to seizure by law enforcement.
Existing cryptocurrencies are all pseudo-anonymous, though additions such as Zerocoin and its distributed laundry[13] feature have been suggested, which would allow for true anonymity.
[https://en.wikipedia.org/wiki/Cryptocurrency]
name::
* McsEngl.bcnevt'Market-cap@cptIt,
* McsEngl.market-capitalization-of-bcnevt@cptIt,
name::
* McsEngl.bcnevt.csa.CONSENSUS (bcncevt)@cptIt,
* McsEngl.bcncevt@cptIt, {2017-04-15}
* McsEngl.bcncet@cptIt, {2017-03-31}
* McsEngl.blockchain-CEV-Token@cptIt, {2017-04-04}
* McsEngl.blockchain-Consensus-Exval-Token@cptIt, {2017-03-31}
* McsEngl.bcnctk@cptIt, {2017-03-29}
* McsEngl.blockchain-consensus-token@cptIt, {2017-03-29}
* McsEngl.core-token-of-bcnnet@cptIt,
* McsEngl.basic-blockchain-token@cptIt, [BitShares {2017-03-28}]
* McsEngl.base-token-of-bcnnet@cptIt, [BitShares {2017-03-28}]
* McsEngl.bcncrc@cptIt, {2017-03-28}
* McsEngl.bcnevt.consensus@cptIt,
* McsEngl.bcnevt.main@cptIt,
* McsEngl.bcnevt.currency@cptIt,
* McsEngl.bcnnet'currency@cptIt,
* McsEngl.bcnnet-currency@cptIt,
* McsEngl.blockchain-currency@cptIt, {2017-03-28}
* McsEngl.consensus-money@cptIt, {2017-03-28}
* McsEngl.main-blockchain-token@cptIt,
* McsEngl.main-network-token@cptIt,
* McsEngl.bcnevt.currency@cptIt,
* McsEngl.currency-in-blockchaine-network@cptIt,
_DESCRIPTION:
Blockchain-Consensus-Exval-Token[1] is the main token of a-bcnnet#ql:idMcsBcnnet#, needed to make consensus to upadate the-blocs in a-blockchain#ql:idBcnbcn#.
As long as a-blockchain-network is public, this[1] token is a-commodity with exchange-value the-work needed to exist the-network TIMES demand/supply.
[hmnSngo.2017-04-09]
===
Blockchain-Consensus-Exval-Token is AUTOBACKED.
[hmnSngo.2017-04-04]
_DESCRIPTION:
We believe that Bitcoin is in fact the first ever decentralized job network to exist, if we define jobs on the bitcoin network as actions by network participants who are paid directly and autonomously from a purely decentralized source such as the block reward.
[https://www.dash.org/binaries/evo/DashPaper-v13-v1.pdf, Evan Duffield]
_DESCRIPTION:
Blockchain-currency is the main money of a-bcnnet#ql:idMcsBcnnet#, needed to create the-blockchain#ql:idBcnbcn#.
[hmnSngo.2017-03-28]
_DESCRIPTION:
A-cryptocoin used in a-blochain that transacts money.
[hmnSngo.2017-02-06]
name::
* McsEngl.bcncevt'Exchange-rate@cptIt,
* McsEngl.bcncevt'exchange-rate@cptIt,
_DESCRIPTION:
As long as a-blockchain-network is public, this[1] token is a-commodity with exchange-value the-work needed to exist the-network TIMES demand/supply.
[hmnSngo.2017-04-09]
name::
* McsEngl.bcncevt'Energy-consumption@cptIt,
* McsEngl.bcnnet'energy-consumption@cptIt,
* McsEngl.energy-consumption-of-bcnnet@cptIt,
* McsEngl.blockchain-energy-consumption@cptIt,
_DESCRIPTION:
Low energy consumption.
Many cryptocurrencies rely on a ‘proof-of-work’ model to create new coins and secure the network.
This is an intensive computational process that can only be carried out by highly specialised hardware and requires huge amounts of electricity.
Nxt’s ‘proof-of-stake’ solution needs very little energy by comparison, with the result that the network has a fraction of the carbon footprint of other cryptocurrencies.
[http://nxt.org/about/what-is-nxt/]
name::
* McsEngl.bcncevt.specific@cptIt,
* McsEngl.bcncevt.specific@cptIt,
_SPECIFIC:
* Bitcoin-BTC#ql:idBtccet#,
* Bitshares-BTS,
* DASH#ql:idDashcet#,
* Decred-coin-DCR,
* Ether-ETH#ql:idEthcet#,
* Litecoin-LTC#ql:idLtccet#,
* Monero,
name::
* McsEngl.bcnevt.csa.CONSENSUS.NO (bcncevtNo)@cptIt,
* McsEngl.bcncevtNo@cptIt, {2017-03-31}
* McsEngl.blockchain-consensusNo-exval-token@cptIt, {2017-03-31}
* McsEngl.bcnctkNo@cptIt, {2017-03-29}
* McsEngl.blockchain-consensusNo-token@cptIt, {2017-03-29}
* McsEngl.bcnevt.consensusNo@cptIt,
* McsEngl.bcnevt.secondary@cptIt,
* McsEngl.bcnevt.subcurrency@cptIt,
* McsEngl.bcnnet'subcurrency@cptIt,
* McsEngl.bcnnet-subcurrency@cptIt,
* McsEngl.bcnscrc@cptIt, {2017-03-28}
* McsEngl.custom-blockchain-token@cptIt,
* McsEngl.bcnevt.subcurrency@cptIt,
* McsEngl.subcurrency-in-blockchaine-network@cptIt,
_DESCRIPTION:
A-secondary-cryptocoin created in a-blochain with different MAIN money.
[hmnSngo.2017-02-13]
_SPECIFIC:
* Chronobank-LHT,
* Chronobank-TIME,
name::
* McsEngl.bcncevtNo.Colored-coin@cptIt,
* McsEngl.ColoredCoin@cptIt,
* McsEngl.colored-coin@cptIt,
_DESCRIPTION:
ColoredCoins started in 2013 as method to push metadata to the Bitcoin blockchain, and evolved over the years to a vibrant ecosystem for digital currencies.
As the open source community continues to develop, a consortium of stake-holders has formed with the realization that the blockchain movement will transform the way we do business in the future and that this revolution, much like the internet, will happen after standards will form around every layer of the stack.
The ColoredCoins project taps into the biggest and the most successful crypto-currency ecosystem in the world, Bitcoin, and creates a blockchain agnostic framework for digital-currencies that will apply those best practices to traditional finance.
[http://coloredcoins.org/]
name::
* McsEngl.bcncevtNo.Bitcoin-colored-coin@cptIt,
* McsEngl.bitcoin-ColoredCoin@cptIt,
* McsEngl.bitcoin-colored-coin@cptIt,
* McsEngl.btccolored-coin@cptIt,
_DESCRIPTION:
Colored_coins:
A proposed add-on function for bitcoin that would enable bitcoin users to give them additional attributes.
These attributes could be user-defined, enabling you to mark a bitcoin as a share of stock, or a physical asset.
This would enable bitcoins to be traded as tokens for other property.
[http://www.coindesk.com/information/bitcoin-glossary//]
===
Colored_Coin:
A concept of adding a special meaning to certain transaction outputs.
This could be used to create a tradable commodity on top of Bitcoin protocol.
For instance, a company may create 1 million shares and declare a single transaction output containing 10 BTC (1 bln *satoshis*) as a source of these shares.
Then, some or all of these bitcoins can be moved to other addresses, sold or exchanged for anything.
During a voting process or a dividend distribution, share owners can prove ownership by simply singing a particular message by the private keys associated with addresses holding bitcoins derived from the initial source.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.bcncevtNo.ICO@cptIt,
* McsEngl.bcnico@cptIt,
name::
* McsEngl.bcnevt.protocol.Bitcoin-based@cptIt,
* McsEngl.bitcoin-fork-cryptocurrency@cptIt,
name::
* McsEngl.bcnevt.protocol.CryptoNote-based@cptIt,
_DESCRIPTION:
CryptoNote Phylosophy
CryptoNote is the technology that allows the creation of completely anonymous egalitarian cryptocurrencies. A number of our community members have been focused on research and development for more than a decade. We aim to promote the derived principles to influence the contemporary economic paradigm.
The current power distribution on our planet is the legacy of the world where the economy is controlled by the few. The status quo was shaped throughout centuries, making human beings engage in rat races, detrimental rivalry, and bloodshed. In spite of humanity's hope to overcome local crises through education and internationalization, we still fail to have full control over our lives.
However, state-of-the-art advancements in technology, mathematics, and cryptography may become the key to subvert this paradigm. The advent of cryptocurrencies is the first sign that the new world is coming. It is marked with a hope that the economy will interlace with the technology, that communities will set new transparent principles, and impartial cryptographic algorithms will control its implementation.
It is in our philosophy to encourage enlightenment through breakthrough innovations. Emancipation begins with laymen getting access to financial resources that will give the oppressed the hope for quality education, drinking water, and a better life. CryptoNote is not about creating yet another digital currency. It is the mindset and concepts that represent the first small step to regain the power over ourselves in order to live peacefully and prosper.
[https://cryptonote.org/inside/]
_ADDRESS.WPG:
* https://cryptonote.org//
_SPECIFIC:
* ByteCoin,
* Monero,
name::
* McsEngl.bcnevt.Aeon (AEONcevt {2014-06-06})@cptIt,
* McsEngl.mnyAEON@cptIt,
* McsEngl.AEON-money@cptIt,
_DESCRIPTION:
Aeon AEON
Aeon is a CryptoNote-based anonymous cryptocurrency using the CryptoNight-light algorithm. It offers data protection features, untraceable payments with ring signatures and unlikable transactions to its users. Aeon was launched on 06.06.2014.
[https://changelly.com/supported-currencies]
===
AEON
AEON (Anonymous Electronic On-line CoiN) is a Monero fork and also a privacy focused coin that is aimed towards open-source community to deliver fast and secure payment method while being simple enough to be used by anyone. ?AEON has started as an experiment but then found its supporters and now AEON is fully functional CryptoNote currency.
[https://cryptonote.org/coins/]
===
Aeon (AEON)
$0.235153 (5.35%)
0.00019879 BTC (5.74%) Buy / Sell Instantly
Rank 96
Mineable Currency
Market Cap
$3,280,079
2,773 BTC
Volume (24h)
$10,689
9.04 BTC
Circulating Supply
13,948,703 AEON
[https://coinmarketcap.com/currencies/aeon/] {2017-04-16}
_ADDRESS.WPG:
* https://coinmarketcap.com/currencies/aeon//
* ANN: https://bitcointalk.org/index.php?topic=641696.0, {2014-06-06}
* http://chainradar.com/aeon/blocks,
* BlockH1: http://chainradar.com/aeon/block/1,
name::
* McsEngl.bcnevt.ByteCoin (BCN byncevt {2012-07-04})@cptIt,
* McsEngl.byncevt@cptIt, {2017-04-02}
* McsEngl.ByteCoin-Consensus-Exval-Token@cptIt, {2017-04-02}
* McsEngl.mnyBCN@cptIt,
* McsEngl.mnyByteCoin@cptIt,
_DESCRIPTION:
Bytecoin (BCN)
Bytecoin is the first CryptoNote-based currency, which has reached mass adoption successfully. Bytecoin also possesses one of the largest ecosystems. Bytecoin has been originally created in close cooperation with CryptoNote team. It is the first implementation of CryptoNote technology, with the release dating back to July 2012. Up to this date Bytecoin developers has been making significant contributions to the development of CryptoNote technology.
[https://cryptonote.org/coins/]
===
Bytecoin BCN
Bytecoin is a first CryptoNote-based cryptocurrency. A CPU-mined coin, it's primary advantages are extraordinary transaction untraceability and unlinkability features. BCN is stated to be much more anonymous than Bitcoin and all its existing forks. The developers claim a person’s right to privacy is their primary concern and strictly observe their own privacy. Bytecoin was started on July 4th, 2012.
BCN is based on CryptoNote, an open-source technology for anonymous cryptocurrencies. It utilizes ring signature and one-time addresses for completely anonymous payments. CryptoNote is designed in a way, which makes block chain analysis impossible. CryptoNote is focused on CPU-mining in order to make the special purposes devices useless.
[https://changelly.com/supported-currencies]
===
Bytecoin (BCN)
$0.000153 (10.58%)
0.00000013 BTC (10.99%) Buy / Sell Instantly
Rank 31
Mineable Currency
Market Cap
$27,885,394
23,574 BTC
Volume (24h)
$99,601
84.20 BTC
Circulating Supply
182,759,167,360 BCN
[https://coinmarketcap.com/currencies/bytecoin-bcn/] {2017-04-16}
_ADDRESS.WPG:
* https://bytecoin.org//
* http://chainradar.com/bcn/blocks,
* BlockH1: http://chainradar.com/bcn/block/1,
name::
* McsEngl.bcnevt.DarkNetCoin (DNC )@cptIt,
* McsEngl.mnyDarkNetCoin@cptIt,
* McsEngl.mnyDNC@cptIt,
_DESCRIPTION:
DarkNetCoin (DNC)
DarkNetCoin is the general currency of DarkNetSpace, a platform for anonymous applications such as p2p exchange, on-chain shop, lotto, gambling and bets. It uses Wild Keccak hash function instead of CryptoNight. Starting with the 4550th block 1% of block reward is donated to CryptoNote team and 9% to DarkNetSpace team.
DARKNETSPACE.ORG
[https://cryptonote.org/coins//]
name::
* McsEngl.bcnevt.Dashcoin (DSHcevt {2014-07-05})@cptIt,
* McsEngl.mnyDashcoin@cptIt,
* McsEngl.mnyDSH@cptIt,
_DESCRIPTION:
Dashcoin (DSH)
Dashcoin is a cryptocurrency started on July 5, 2014. Dashcoin is a fork of Bytecoin and it also utilizes CryptoNote algorithm. ?The goal of Dashcoin is to automatically create a perfect mirror image of Bytecoin, the first CryptoNote based cryptocurrency, at any given moment of time. ?The only difference is the supply amount.
[https://cryptonote.org/coins/]
===
Dashcoin DSH
Dashcoin is a Next generation anonymous cryptocurrency and the first automatically mutating cryptocurrency created with CryptoNote technology.
[https://changelly.com/supported-currencies]
===
Dashcoin (DSH)
$0.018697 (-9.18%)
0.00001580 BTC (-8.86%)
Rank 228
Mineable Currency
Market Cap
$322,974
273 BTC
Volume (24h)
$1,508
1.27 BTC
Circulating Supply
17,273,729 DSH
[https://coinmarketcap.com/currencies/dashcoin/] {2017-04-16}
_ADDRESS.WPG:
* http://dashcoin.info//
* BlockH1: http://chainradar.com/dsh/block/1,
name::
* McsEngl.bcnevt.DigitalNote (XDNcevt {2014-05-30})@cptIt,
* McsEngl.DigitalNote@cptIt,
* McsEngl.mnyDigitalNote@cptIt,
* McsEngl.mnyXdn@cptIt,
* McsEngl.xdncevt@cptIt,
_DESCRIPTION:
DigitalNote XDN
DigitalNote is an experimental open-source cryptocurrency based on CryptoNote technology and CryptoNight algorithm. It is a fork of Bytecoin - the very first implementation of CryptoNote. Nobody own or control DigitalNote. It is a scalable decentralized cryptocurrency with strong privacy protection. DigitalNote uses ring signatures, to provide unlinkable and untraceable transactions.
[https://changelly.com/supported-currencies]
===
DigitalNote (XDN)
$0.000155 (3.69%)
0.00000013 BTC (4.04%) Buy / Sell Instantly
Rank 148
Mineable Currency
Market Cap
$1,068,910
903 BTC
Volume (24h)
$21,022
17.77 BTC
Circulating Supply
6,878,755,652 XDN
[https://coinmarketcap.com/currencies/digitalnote/] {2017-04-16}
_ADDRESS.WPG:
* http://digitalnote.org//
* BlockH1: http://chainradar.com/xdn/block/1,
name::
* McsEngl.bcnevt.Fantomcoin (FCNcevt {2014-05-06})@cptIt,
* McsEngl.mnyFantomcoin@cptIt,
* McsEngl.mnyFcn@cptIt,
* McsEngl.mnyFCN@cptIt,
_DESCRIPTION:
Fantomcoin FCN
Unlike other CryptoNote based cryptocurrencies, Fantomcoin supports merged mining. It can be possible with Bytecoin, Monero, QuazarCoin or any CN based coin. New blockchain needs no additional hashpower - it uses Bytecoin, Monero, QuazarCoin blocks or shares as PoW. Miners are free to choose "donor" chain they like. In case other chains based on CryptoNote will appear they also can be used as "donor" chains.
[https://changelly.com/supported-currencies]
===
Fantomcoin (FCN)
Fantomcoin is the first CryptoNote currency with merged mining support. Users who mine Fantomcoin are also able to mine other CryptoNote-based coins without additional hash power. This feature allows user to receive not only FCNs but also any other CryptoNote-based currency. As the result, Fantomcoin encourages fair distribution and stabilization of the cryptocurrency market through diversification.
FANTOMCOIN.ORG
[https://cryptonote.org/coins/]
===
Fantomcoin (FCN)
$0.089940 (3.15%)
0.00007601 BTC (3.50%) Buy / Sell Instantly
Rank 193
Mineable Currency
Market Cap
$508,843
430 BTC
Volume (24h)
$1,159
0.98 BTC
Circulating Supply
5,657,591 FCN
[https://coinmarketcap.com/currencies/fantomcoin/] {2017-04-16}
_ADDRESS.WPG:
* http://fantomcoin.org//
* BlockH1: http://chainradar.com/fcn/block/1,
name::
* McsEngl.bcnevt.Monero (XMRcevt {2014-04-18})@cptIt,
* McsEngl.mnyMonero@cptIt,
* McsEngl.mnyXmr@cptIt,
* McsEngl.monero-cryptocurrency@cptIt,
* McsEngl.mnyMonero@cptIt,
* McsEngl.Monero@cptIt,
* McsEngl.xmrcevt@cptIt,
_DESCRIPTION:
Monero XMR
Monero is a new coin using the CryptoNote protocol. It's based on Bytecoin, which was coded from scratch and is not a descendent of Bitcoin. XMR was launched on April 18, 2014.
[https://changelly.com/supported-currencies]
===
Monero (XMR) is an open-source cryptocurrency created in April 2014 that focuses on privacy, decentralisation and scalability. Unlike many cryptocurrencies that are derivatives of Bitcoin, Monero is based on the CryptoNote protocol and possesses significant algorithmic differences relating to blockchain obfuscation.[1] Monero has ongoing support from the community,[2] and its modular code architecture has been praised by Wladimir J. van der Laan, a Bitcoin Core maintainer.[3] Initially meeting little popularity with the general public, Monero experienced rapid growth in market capitalization (from US$5M to US$185M)[4] and transaction volume[5] during the year 2016, partly due to adoption by major darknet market AlphaBay at the end of summer 2016.[6]
[https://en.wikipedia.org/wiki/Monero_(cryptocurrency)]
===
Monero (XMR)
Monero (previously known as Bitmonero) is one of the first CryptoNote coins. It utilizes the same values every CryptoNote coin does – privacy, decentralization and fungibility. Monero development is community-driven, based on donations and with a focus on decentralization and scalability.
MONERO.CC| BITMONERO.ORG
[https://cryptonote.org/coins/]
===
Monero (XMR)
$20.69 (-0.47%)
0.01746860 BTC (-0.22%) Buy / Sell Instantly
Rank 6
Mineable Currency
Market Cap
$295,879,036
249,864 BTC
Volume (24h)
$4,271,650
3,607 BTC
Circulating Supply
14,303,624 XMR
[https://coinmarketcap.com/currencies/monero/] {2017-04-16}
_ADDRESS:
* https://getmonero.org//
* Block1: http://chainradar.com/xmr/block/1,
name::
* McsEngl.bcnevt.Pebblecoin (XPB)@cptIt,
* McsEngl.mnyQuazarCoin@cptIt,
* McsEngl.mnyQCN@cptIt,
_DESCRIPTION:
Pebblecoin (XPB)
Pebblecoin is a CryptoNote-based coin with certain adjustments. XPB implemented a mining algorithm called Boulderhash that requires 13 GB RAM. This has been the successful attempt to block botnet-controlled computers from mining. XPB has a distinct emission curve: the standard block reward of 300 coins remains unchanged for the whole period of XPB mining.
[https://cryptonote.org/coins/]
name::
* McsEngl.bcnevt.QuazarCoin (QCN {2014-05-08})@cptIt,
* McsEngl.mnyQuazarCoin@cptIt,
* McsEngl.mnyQCN@cptIt,
_DESCRIPTION:
QuazarCoin QCN
QuazarCoin is a new cryptocurrency based on the CryptoNote and uses the CryptoNight algorithm. QCN protects your data and privacy with help of completely anonymous transactions with ring signatures.
[https://changelly.com/supported-currencies]
===
Quazarcoin (QCN)
Quazarcoin is a CryptoNote-based coin, which has been launched as a result of community discussions. It has a flatter emission curve and fair, open launch to attract the wider community. QCN's developers focus on usability aspects of the currency. Its main contribution is the popularization of CryptoNote technology.
QUAZARCOIN.ORG
[https://cryptonote.org/coins/]
===
QuazarCoin (QCN)
$0.009481 (3.45%)
0.00000800 BTC (3.65%) Buy / Sell Instantly
Rank 448
Mineable Currency
Market Cap
$52,191
44 BTC
Volume (24h)
$13
0.01 BTC
Circulating Supply
5,505,034 QCN
[https://coinmarketcap.com/currencies/quazarcoin/] {2017-04-16}
name::
* McsEngl.bcnevt.NATIONAL@cptIt,
* McsEngl.bcnevt.national@cptIt,
* McsEngl.national-cryptocurrency@cptEconomy,
* McsEngl.mnyNational-cryptocurrency@cptEconomy,
_DESCRIPTION:
National cryptocurrencies provide a meaningful alternative to the central banking system, allow a people to gather equity instead of debt, and have a more focused distribution model than general purpose cryptocurrencies such as Bitcoin.
[http://cointelegraph.com/news/could-iceland-embrace-crypto-before-anyone-else]
name::
* McsEngl.eCFA-money@cptIt,
* McsEngl.mnyeCFA@cptIt,
NOV 27, 2016
By Joseph Young
Senegal Introduces Cryptocurrency Based on its National Currency
Senegal Introduces Cryptocurrency Based on its National Currency
Senegalmay become the first country to release a cryptocurrency based on its national currency.
Earlier this month, Senegal introduced eCFA, a digital currency currently in development in collaboration with Banque Regionale de Marches (BRM) and eCurrency Mint Limited. BRM bank, a Senegal-based financial institution specializing in capital markets and the implementation of tailor-made banking solutions, is leading both the development and integration of the digital currency, which the Senegal government states would serve as a legal tender.
Similar to the vision of Norway’s largest bank DNB, Senegal is attempting to secure a significant market share of Africa’s severely underbanked and underserved populations, which are struggling to find access to reliable and cost-efficient financial platforms and networks to settle cross-border transactions.
Interestingly, the development and launch of eCFA is overseen by the West African Economic and Monetary Union (WAEMU), which suggests that once ready for commercial roll-out, eCFA will be made available for other African countries including Benin, Burkina Faso, Cote d’Ivoire, Niger, Togo and more.
Criticisms and future plans
Upon the first announcement of plans to develop eCFA, BRM bank as well as the Senegal government received criticisms from cryptography experts and analysts due to eCFA’s dependence on a centralized banking system. It has been said that if eCFA is based on its national currency, it defeats the purpose of implementing a digital currency.
In spite of these criticisms, BRM bank CEO Alioune Camara, stated earlier this month that it will assist the Senegal government in creating a system which can facilitate interoperability between all financial applications, platforms and networks within the region.
Camara stated:
“An eCFA backed by our banking system and the central bank is the safest and most secure way to enable the digital economy. We can now facilitate full interoperability between all e-money payment systems. This is a great leap forward for Africa.”
Ambiguity in Blockchain specifications
However, BRM and eCurrency Mint Limited have yet to release any technical information and background on their Blockchain-based digital currency. In fact, it is still unknown whether the currency will be based on a permissioned ledger or a decentralized Blockchain network. If the latter, the bank will struggle with existing financial regulations.
If the bank opts for a permissioned ledger, various security consequences will lead to issues with the deployment process, which may turn out increasingly inefficient for both the bank and its future users.
[https://cointelegraph.com/news/senegal-introduces-cryptocurrency-based-on-its-national-currency]
name::
* McsEngl.bcnevt.service.APP@cptIt,
_DESCRIPTION:
A-cryptocoin used in a-blochain that services applications.
[hmnSngo.2017-01-31]
_SPECIFIC:
* Ether##
* Expanse##
name::
* McsEngl.bcnevt.Expanse (EXPcevt {2015})@cptIt,
* McsEngl.Expanse-consensus-exval-token@cptIt,
* McsEngl.expcevt@cptIt,
_DESCRIPTION:
Ethereum fork
===
Expanse EXP
Expanse is a driven by the DAO community smart contract platform, providing tools and services to create intuitive decentralized applications (DAPPs). The platform allows to integrate blockchain technologies and spread decentralized information to different fields. Expanse is powered by EXP, a democratic controlled cryptocurrency.
[https://changelly.com/supported-currencies]
_ADDRESS.WPG:
* http://www.expanse.tech//
Block#1
Time 2015-09-14 00:00:48 (1 year ago)
[http://www.expanse.tech/explorer/block_number/1]
name::
* McsEngl.bcnevt.Stratis (STRATcevt {2016-08-09})@cptIt,
* McsEngl.mnyStratis@cptIt,
* McsEngl.mnySTRAT@cptIt,
_DESCRIPTION:
Stratis STRAT
Stratis is a flexible and powerful Blockchain Development Platform designed for the needs of real-world financial services businesses.
[https://changelly.com/supported-currencies]
_ADDRESS.WPG:
* https://stratisplatform.com//
* Block#1: https://chainz.cryptoid.info/strat/block.dws?1.htm,
name::
* McsEngl.bcnevt.LBRY-Credits (LBCcevt {2016-06-23})@cptIt,
* McsEngl.lbccevt@cptIt,
* McsEngl.lbry-credits@cptIt,
* McsEngl.mnyLBRY-Credits@cptIt,
* McsEngl.mnyLBC@cptIt,
_DESCRIPTION:
LBRY Credits LBC
LBRY is the first digital marketplace to be controlled by the market’s participants rather than a corporation or other 3rd-party.
[https://changelly.com/supported-currencies]
===
LBRY Credits (LBC)
$0.082279 (-4.60%)
0.00006966 BTC (-5.48%)
Rank 71
Mineable Currency
Market Cap
$5,039,968
4,267 BTC
Volume (24h)
$413,316
349.94 BTC
Circulating Supply
61,254,380 LBC
Total Supply
459,154,380 LBC
[https://coinmarketcap.com/currencies/library-credit/] {2017-04-16}
_ADDRESS.WPG:
* https://lbry.io//
* https://explorer.lbry.io//
* BlockH1: https://explorer.lbry.io/block/decb9e2cca03a419fd9cca0cb2b1d5ad11b088f22f8f38556d93ac4358b86c24,
name::
* McsEngl.bcnevt.NAV-Coin (NAVcevt {2016-05-12})@cptIt,
* McsEngl.mnyNAV-Coin@cptIt,
* McsEngl.mnyNAV@cptIt,
_DESCRIPTION:
NAV Coin NAV
NAV Coin is a X13 POS cryptocurrency. Anonymous Technology using Subchains and Community's Foundation
[https://changelly.com/supported-currencies]
===
NAV Coin (NAV)
$0.101782 (15.79%)
0.00008618 BTC (14.79%) Buy / Sell Instantly
Rank 64
Currency
Market Cap
$6,198,229
5,248 BTC
Volume (24h)
$430,299
364.32 BTC
Circulating Supply
60,897,100 NAV
[https://coinmarketcap.com/currencies/nav-coin/] {2017-04-16}
_ADDRESS.WPG:
* http://navcoin.org//
* Block#1: https://chainz.cryptoid.info/nav/block.dws?1.htm,
name::
* McsEngl.bcnevt.Steem (STEEMcevt {2016})@cptIt,
* McsEngl.mnySTEEM@cptIt,
_DESCRIPTION:
Steem STEEM
Steem is the first Reddit-like social media platform based on blockchain technologies. Each worthy content, instead of likes, is rewarded by STEEM, a crypto that fuels the platform. STEEM may also be mined through the p2p network.
[https://changelly.com/supported-currencies]
===
Steem (STEEM)
$0.216145 (9.80%)
0.00018364 BTC (10.63%) Buy / Sell Instantly
Rank 19
Mineable Currency
Market Cap
$51,158,750
43,465 BTC
Volume (24h)
$1,942,640
1,650 BTC
Circulating Supply
236,687,178 STEEM
Total Supply
253,661,272 STEEM
[https://coinmarketcap.com/currencies/steem/] {2017-04-16}
_ADDRESS.WPG:
* https://steem.io//
* ANN: https://bitcointalk.org/index.php?topic=1410943.0, {2016-03-24}
name::
* McsEngl.bcnevt.Factom (FCTcevt {2015-09-01})@cptIt,
* McsEngl.mnyFactom@cptIt,
* McsEngl.mnyFCT@cptIt,
_DESCRIPTION:
Factom FCT
Factom is an open source project implementing blockchain technology for businesses. Entries in the ledger cannot be altered, thus there is no place for fraud and forgery, the system becomes transparent. Factom cryptocurrency is alternatively called Factoids.
Users of the system can exchange them for Entry Credits, in this case the coins are burnt.
Individuals who run FCT Servers pay transaction fees for Bitcoin and get Factoids as an incentive for that.
[https://changelly.com/supported-currencies]
===
Factom (FCT)
$5.84 (18.27%)
0.00494316 BTC (17.05%)
Rank 18
Currency
Market Cap
$51,078,534
43,269 BTC
Volume (24h)
$3,704,120
3,138 BTC
Circulating Supply
8,753,219 FCT
[https://coinmarketcap.com/currencies/factom/] {2017-04-16}
name::
* McsEngl.bcnevt.Radium (RADScevt {2015-05-25})@cptIt,
* McsEngl.mnyRadium@cptIt,
* McsEngl.mnyRADS@cptIt,
_DESCRIPTION:
Radium RADS
Radium and its blockchain serve as a basis for the Radium SmartChain, a foundation for the progressive blockchain development. The ultimate goal is to set up an environment for completely decentralized services. RADS can be sent using traditional addresses or usernames recorded in the blockchain of the coin.
[https://changelly.com/supported-currencies]
===
Radium (RADS)
$1.53 (3.94%)
0.00129289 BTC (3.30%) Buy / Sell Instantly
Website
Explorer
Announcement
Rank 72
Currency
Market Cap
$4,880,240
4,134 BTC
Volume (24h)
$52,415
44.40 BTC
Circulating Supply
3,197,641 RADS
[https://coinmarketcap.com/currencies/radium/] {2017-04-16}
_ADDRESS.WPG:
* http://projectradon.info//
* https://chainz.cryptoid.info/rads//
* Block#1: https://chainz.cryptoid.info/rads/block.dws?1.htm,
name::
* McsEngl.bcnevt.NuBits (USNBTcevt {2014-08-03})@cptIt,
* McsEngl.Nubits@cptIt,
* McsEngl.mnyNuBits@cptIt,
* McsEngl.mnyNBT@cptIt,
_DESCRIPTION:
NuBits NBT
NuBits is a digital currency developed in 2014 by the creators of Peershares. The unique feature of this cryptocurrency is its stable price. NuBits is always equal to $1 and it is the first decentralized cryptocurrency to maintain the $1 peg for over a year. They accomplish it by adjusting the coin supply to match investor demand, the markets don’t control the price.
[https://changelly.com/supported-currencies]
===
Nu is the first decentralized central bank in the world who issue NuBits, the first crypto-dollar with a stable prize 1NBT = 1USD. Value stability is highly desirable in a currency, and we expect more and more users will begin using NuBits for online purchases.
[http://cointelegraph.com/news/beyond-bitcoin-how-stable-are-alternative-cryptocurrencies]
===
NuBits (USNBT)
$0.988734 (1.19%)
0.00083747 BTC (0.51%)
Rank 294
Currency
Market Cap
$134,075
114 BTC
Volume (24h)
$838
0.71 BTC
Circulating Supply
135,603 USNBT
Total Supply
4,845,406 USNBT
[https://coinmarketcap.com/currencies/nubits/] 2017-04-16
_ADDRESS.WPG:
* https://www.nubits.com//
* https://nuexplorer.ddns.net//
* BlockH0: https://nuexplorer.ddns.net/blocks/000003cc2da5a0a289ad0a590c20a8b975219ddc1204efd169e947dd4cbad73f/1,
name::
* McsEngl.bcnevt.MaidSafeCoin (MAIDevt {2014-04-22})@cptIt,
* McsEngl.mnyMAID@cptIt,
* McsEngl.mnyMaidSafeCoin@cptIt,
* McsEngl.mnySafecoin@cptIt,
* McsEngl.MAID-cryptocurrency@cptIt,
* McsEngl.mnyMAID@cptIt,
_DESCRIPTION:
MaidSafeCoin MAID
MaidSafeCoin is a part of MaidSafe network. The developers created SAFE (Secure Access For Everyone) network for invulnerable and private data storage with no governing party. Users of the network who grant their resources are automatically rewarded with the coins. They can exchange the received Safecoins for the services within SAFE Network or trade them as any other cryptocurrency.
[https://changelly.com/supported-currencies]
===
MaidSafeCoin (MAID)
$0.200548 (2.10%)
0.00016979 BTC (1.14%) Buy / Sell Instantly
Rank 11
Asset
Market Cap
$90,758,481
76,838 BTC
Volume (24h)
$424,330
359.25 BTC
Circulating Supply
452,552,412 MAID
[https://coinmarketcap.com/assets/maidsafecoin/] {2017-04-16}
_ADDRESS.WPG:
* http://maidsafe.net//
* ann: https://bitcointalk.org/index.php?topic=579797.0, {2014-04-22}
* http://omnichest.info/lookupsp.aspx?sp=3, {2014-04-22}
name::
* McsEngl.bcnevt.Gulden (NLGcevt {2014-03-29})@cptIt,
* McsEngl.gulden@cptIt,
* McsEngl.mnyGulden@cptIt,
* McsEngl.mnyNLG@cptIt,
_DESCRIPTION:
Gulden NLG
Gulden is the first digital currency with a human approach. It is a Dutch cryptocurrency named after the national defunct currency of Netherlands. The crypto is determined by the demand for gold and silver. Guldens are stored on a mobile or desktop app and can be used anywhere Bitcoin is accepted, including IBAN banks.
[https://changelly.com/supported-currencies]
===
Gulden (NLG)
$0.040189 (12.73%)
0.00003402 BTC (11.60%)
Rank 44
Mineable Premined Currency
Market Cap
$13,817,731
11,698 BTC
Volume (24h)
$67,784
57.39 BTC
Circulating Supply
343,822,145 NLG
Total Supply
445,842,300 NLG
[https://coinmarketcap.com/currencies/gulden/] {2017-04-16}
_ADDRESS.WPG:
* https://gulden.com//
* BlockH1: https://blockchain.gulden.com/block/756e5147f48e143f7468b881571ac947f39950819c82d8d17ee7ceaa8e3a6628,
name::
* McsEngl.bcnevt.BlackCoin (BLKcevt {2014-02-24})@cptIt,
* McsEngl.mnyBlackCoin@cptIt,
_DESCRIPTION:
BlackCoin (BLK)
$0.081931 (12.03%)
0.00006927 BTC (10.84%)
Rank 63
Currency
Market Cap
$6,232,987
5,270 BTC
Volume (24h)
$163,031
137.84 BTC
Circulating Supply
76,076,517 BLK
[https://coinmarketcap.com/currencies/blackcoin/] {2017-04-15}
===
BlackCoin is a peer-to-peer cryptocurrency. BlackCoin uses a proof-of-stake system and is open-source.[3] BlackCoin was created by the developer Rat4, with the goal of proving that BlackCoin’s way of disabling proof-of-work is stable and secure.[4] BlackCoin secures its network through a process called "minting". Transactions in BlackCoin were called "significant" in a Citibank whitepaper.[5]
[https://en.wikipedia.org/wiki/BlackCoin]
_ADDRESS.WPG:
* http://blackcoin.co//
* Block#1 https://chainz.cryptoid.info/blk/block.dws?1.htm,
name::
* McsEngl.bcnevt.Auroracoin (AURcevt {2014-01-24})@cptIt,
* McsEngl.aurcevt@cptIt,
* McsEngl.mnyAUR@cptIt,
* McsEngl.mnyAuroraCoin@cptIt,
* McsEngl.AuroraCoin@cptEconomy,
* McsEngl.mnyAuroraCoin@cptIt,
_DESCRIPTION:
Auroracoin (AUR)
$0.177925 (8.19%)
0.00015040 BTC (7.06%)
Announcement
Rank 130
Mineable Premined Currency
Market Cap
$1,540,499
1,302 BTC
Volume (24h)
$2,686
2.27 BTC
Circulating Supply
8,658,139 AUR
[https://coinmarketcap.com/currencies/auroracoin/] {2017-04-15}
===
Auroracoin is a cryptocurrency launched in February 2014 as an Icelandic alternative to Bitcoin and the Icelandic krona.[1][2][3] Its unknown creator or creators use the pseudonym Baldur Friggjar O?insson (or Odinsson).[1][2][3] They stated that they planned to distribute half of auroracoins that would ever be created to all 330,000 people listed in Iceland's national ID database beginning on March 25, 2014, free of charge, coming out to 31.8 auroracoins per person.[1][3]
Auroracoin was created as an alternative currency to address the government restrictions on Iceland's krona, in place since 2008, which severely restricts movement of the currency outside of the country.[1] Iceland's Foreign Exchange Act also prohibits the foreign exchange of bitcoins from the country, according to a government minister.[4]
[https://en.wikipedia.org/wiki/Auroracoin]
_ADDRESS.WPG:
* http://new.auroracoin.is//
* https://github.com/aurarad/auroracoin,
===
* http://cointelegraph.com/news/saving-icelands-economy-did-auroracoin-fail-its-mission {2016-04-19}
* http://cointelegraph.com/news/could-iceland-embrace-crypto-before-anyone-else,
name::
* McsEngl.bcnevt.Dogecoin (DOGEcevt {2013-12-06})@cptIt,
* McsEngl.dogecevt@cptIt,
* McsEngl.dogecoin@cptIt,
* McsEngl.mnyDogeCoin@cptIt,
* McsEngl.mnyDOGE@cptIt,
_DESCRIPTION:
Dogecoin (DOGE)
$0.000441 (4.92%)
0.00000037 BTC (3.83%)
Rank 21
Mineable Currency
Market Cap
$48,045,918
40,702 BTC
Volume (24h)
$1,411,570
1,196 BTC
Circulating Supply
108,982,504,127 DOGE
[https://coinmarketcap.com/currencies/dogecoin/] {2017-04-16}
===
Dogecoin DOGE
Dogecoin is a cryptocurrency featuring a likeness of the Shiba Inu dog from the "Doge" Internet meme as its logo. Started as a "joke currency" in late 2013, Dogecoin quickly developed its own online community and reached reasonable capitalization nowadays.
[https://changelly.com/supported-currencies]
===
Date of introduction December 8, 2013; 19 months ago
User(s) International
Inflation Approximately 100 billion coins to be mined by early 2015, and 5.256 billion new coins per year.
Symbol ?[1]
Nickname Doge
Plural DOGE, Dogecoins
Dogecoin (/?do??k??n/ DOHZH-koyn,[2] code: DOGE, symbol: ?[1] and D) is a cryptocurrency featuring a likeness of the Shiba Inu dog from the "Doge" Internet meme as its logo.[3][4][5][6] It was introduced on December 8, 2013.[7]
Started as a "joke currency" in late 2013, Dogecoin quickly developed its own online community and reached a capitalization of USD 60 million in January 2014;[8] as of January 2015, it had a capitalization of USD 13.5 million.[9]
Compared with other cryptocurrencies, Dogecoin has a fast initial coin production schedule: 100 billion coins have been in circulation by mid 2015 with an additional 5.256 billion coins every year thereafter. As of 30 June 2015, the 100 billionth Dogecoin has been mined.[10] While there are few mainstream commercial applications, the currency has gained traction as an Internet tipping system, in which social media users grant Dogecoin tips to other users for providing interesting or noteworthy content.[11] Many members of the Dogecoin community, as well as members of other cryptocurrency communities, use the phrase "To the moon!" to describe the overall sentiment of the coin's rising value.[12][13][14]
[https://en.wikipedia.org/wiki/Dogecoin]
name::
* McsEngl.bcnevt.Freicoin (FRCcevt {2012-12-21})@cptIt,
* McsEngl.mnyFreicoin@cptIt,
* McsEngl.Freicoin@cptEconomy,
_DESCRIPTION:
Freicoin is a decentralized, distributed, peer-to-peer electronic currency designed to address the grievances of the working class and re-align financial interests of the wealthy elite with the stability and well-being of the economy as a whole. Whereas inflationary currencies like the U.S. Dollar or Euro are controlled by central bankers under rules that intentionally or not benefit the establishment, Freicoin is completely decentralized and self-regulating, with a-demurrage-fee#ql:trcwp'demurrage_charge# that ensures its circulation and bearers of the currency pay this fee automatically to those community members who contribute work to secure the currency.
Freicoin is an implementation of the accounting concept of a proof-of-work block chain used by Satoshi Nakamoto#ql:idBtchmnSnt# in the creation of Bitcoin. It includes a downloadable client for Mac OS X, Windows, and Linux, and an electronic network for transferring funds denominated in Freicoin world-wide. You can download, review and improve the code of this free software project on Github.
[http://freico.in/about/]
===
Freicoin:
A cryptocurrency based on the inflation-free principles outlined by the economist Silvio Gessell.
[http://www.coindesk.com/information/bitcoin-glossary//]
===
Freicoin (FRC)
$0.001772 (1.05%)
0.00000150 BTC (0.00%)
Rank 335
Mineable Currency
Market Cap
$49,021
41 BTC
Volume (24h)
$1,112
0.94 BTC
Circulating Supply
27,665,859 FRC
Total Supply
100,000,000 FRC
[https://coinmarketcap.com/currencies/freicoin/] {2017-04-16}
name::
* McsEngl.bcnevt.Tether (USDTevt)@cptIt,
* McsEngl.mnyTether@cptIt,
_DESCRIPTION:
We’ve combined the best of both worlds
Get the joint benefits of the Bitcoin blockchain and traditional currency
[https://tether.to//]
===
Add more value to your business
Start reaping the rewards of stable currency on the Blockchain
Custodial Account
Avoid the hassle of the banking system.
Store cash as if it were bitcoin.
Provide a Bitcoin Alternative
Offer your customers stable currency with the benefits and functionality of the Blockchain.
Transact with Digital Currency
Store, send and receive 1-to-1 backed digital currency across exchanges, platforms, and wallets.
[https://tether.to/why-use-tether/]
===
Tether (USDT)
$0.999837 (0.00%)
0.00084977 BTC (0.79%)
Rank 19
Asset
Market Cap
$50,735,502
43,121 BTC
Volume (24h)
$11,925,500
10,136 BTC
Circulating Supply
50,743,773 USDT
Total Supply
54,950,871 USDT
[https://coinmarketcap.com/assets/tether/] {2017-04-16}
_ADDRESS.WPG:
* https://tether.to//
* https://bravenewcoin.com/assets/Whitepapers/Tether-White-Paper.pdf,
* http://omnichest.info/lookupsp.aspx?sp=31,
name::
* McsEngl.bcnevt.SCAM@cptIt,
* McsEngl.blockchain-scamcoin@cptIt,
* McsEngl.bcnscamcoin@cptIt,
* McsEngl.scamcoin@cptIt,
====
_DESCRIPTION:
Scamcoin:
An altcoin produced with the sole purpose of making money for the originator.
Scamcoins frequently use pump and dump techniques and pre-mining together.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.bcnevt.EVOLUTING (bcnevtEvn)@cptIt,
* McsEngl.bcnevtEvn@cptIt,
* McsEngl.bcnevt.evoluting@cptIt,
{time.1998}:
=== GENESIS Wei-Dai:
Bitcoin is the first implementation of a concept called "cryptocurrency", which was first described in 1998 by Wei Dai on the cypherpunks mailing list, suggesting the idea of a new form of money that uses cryptography to control its creation and transactions, rather than a central authority.
The first Bitcoin specification and proof of concept was published in 2009 in a cryptography mailing list by Satoshi Nakamoto#ql:idBtchmnSnt#.
Satoshi left the project in late 2010 without revealing much about himself.
The community has since grown exponentially with many developers working on Bitcoin.
[https://bitcoin.org/en/faq#who-created-bitcoin]
name::
* McsEngl.bcnnet'Statistics (bcnstat)@cptIt,
* McsEngl.bcnnet'statistics@cptIt,
* McsEngl.blockchain-network-statistics@cptIt,
* McsEngl.blockchain-statistics@cptIt,
name::
* McsEngl.bcnnet'Governance-system (bcngov)@cptIt,
* McsEngl.bcngov@cptIt,
* McsEngl.bcnnet'governance-system@cptIt,
* McsEngl.blockchain-governance-system@cptIt,
_DESCRIPTION:
Recently, new blockchains equipped with built in governance system tried to cope with this problem.
Dash is the forerunner to implement governance system in their blockchain.
Dash, who call themselves as the “First Self Governing, Self Funding Protocol”,proposed a decentralized management system based on the masternode voting mechanism in 2015.
Dash has been steadily developed using this governance system.
Recently the price of Dash surpassed over $100 {March 16th, 2017}.
A stable governance structure may be the reason for the increased value.
More and more recent cryptocurrencies have governance systems.
Qtum, a Chinese cryptocurrency, has governance system named the “Judgement Committee”.
Dfinity and Tezos also have governance systems.
Needless to say BOScoin has a governance system as well.
...
If these systems are implemented in blockchain, the blockchain can adjust and evolve itself according to the contemporary environment.
If these systems work successfully, we can build a true DAO(Decentralized Autonomous Organization) self-governing community which is the dream of blockchain enthusiasts.
I believe these kinds of democratic systems are the key to sustaining and growing the cryptocurrency ecosystem.
Cryptocurrencies equipped with a governance structure will be the next wave of blockchain technology.
Myung Sahn Juhn
[http://cryptocentral.info/topic/913/boscoin-bos-a-congressional-cryptocurrency-platform-for-trust-contracts/4]
ATTRIBUTES:
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgBcngov-features.png!#
[http://cryptocentral.info/topic/913/boscoin-bos-a-congressional-cryptocurrency-platform-for-trust-contracts/4]
name::
* McsEngl.bcngov'Builtin@cptIt,
_DESCRIPTION:
whether the-governance-system is built-in or not.
name::
* McsEngl.bcngov'Auto-updating@cptIt,
_DESCRIPTION:
whether a-new-version or policy is applied automatically or manually.
Dash has no auto-updating function so have a penalty policy to urge the masternode to maintain the latest program.
name::
* McsEngl.bcnnet'Program (bcnpgm)@cptIt,
* McsEngl.blockchain-program@cptIt,
SPECIFIC:
* contract-program,
* client-program,
* DAPP#ql:idBcndap#,
* wallet-program,
name::
* McsEngl.bcnpgm.DAPP (bcndap)@cptIt,
* McsEngl.dapp@cptIt,
* McsEngl.decentralized-application@cptIt,
* McsEngl.decentralized-trust-application@cptIt,
_DESCRIPTION:
Dapp or decentralised-app is an-app running on a-decentralised-network.
Dapp CAN-HAVE a-front-end-code or user-interface written on any language.
[hmnSngo.2017-03-23]
===
Definition of a Dapp
For an application to be considered a Dapp (pronounced Dee-app, similar to Email) it must meet the following criteria:
The application must be completely open-source, it must operate autonomously, and with no entity controlling the majority of its tokens. The application may adapt its protocol in response to proposed improvements and market feedback but all changes must be decided by consensus of its users.
The application's data and records of operation must be cryptographically stored in a public, decentralized blockchain in order to avoid any central points of failure.
The application must use a cryptographic token (bitcoin or a token native to its system) which is necessary for access to the application and any contribution of value from (miners / farmers) should be rewarded in the application’s tokens.
The application must generate tokens according to a standard crytptographic algorithm acting as a proof of the value nodes are contributing to the application (Bitcoin uses the Proof of Work Algorithm).
[https://github.com/DavidJohnstonCEO/DecentralizedApplications#definition-of-a-dapp]
name::
* McsEngl.bcnnet'Wallet (bcnwlt)@cptIt,
* McsEngl.bcnwlt@cptIt,
* McsEngl.bcnwallet@cptIt,
* McsEngl.blockchain-wallet@cptIt,
_DESCRIPTION:
Wallets are containers for private keys#ql:idBcncrptPkc#, usually implemented as structured files or simple databases.
[https://github.com/bitcoinbook/bitcoinbook/blob/first_edition/ch04.asciidoc#wallets]
_DESCRIPTION:
A Bitcoin wallet can refer to either a wallet program or a wallet file.
Wallet programs create public keys to receive satoshis and use the corresponding private keys to spend those satoshis.
Wallet files store private keys and (optionally) other information related to transactions for the wallet program.
[https://bitcoin.org/en/developer-guide#wallets]
===
Now that you are connected to the network, the next thing you need to do is create a wallet that will hold your account addresses and DCR balance.
[https://docs.decred.org/getting-started/user-guides/windows/#create-your-wallet]
name::
* McsEngl.bcnwlt'Fee@cptIt,
_DESCRIPTION:
What are transaction fees, and what fees does Jaxx apply?
Fees applied to transaction go to support the networks that run the coin/token - so, for instance, every standard (non-contract) ETH transaction currently applies a fee of .000441 ETH. This fee does not go to us; it goes to reward miners (thereby ensuring that the transaction is logged into the blockchain in a timely fashion) and support the Ethereum network itself. Note that transactions that interact with a contract address will be more costly.
The same is true of Bitcoin - BTC fees applied go to the Bitcoin network. The difference is that the BTC fees applied are dynamic - they are subject to go up or down based on the state of the network. Jaxx lets you specify between three different fee options depending on whether your transaction is time-sensitive or not (as the lower fee may face a longer confirmation period).
As newer coins are implemented, each coin is subjected to their own transaction fee that goes to their respected networks.
[https://decentral.zendesk.com/hc/en-us/articles/225024248-What-are-transaction-fees-and-what-fees-does-Jaxx-apply-]
name::
* McsEngl.bcnwlt'Resource@cptIt,
_ADDRESS.WPG:
* https://wallet.mycelium.com/index.html,
* http://www.walletrecoveryservices.com//
* http://www.coindesk.com/meet-man-will-hack-long-lost-bitcoin-wallet-money//
name::
* McsEngl.bcnwlt'Seed@cptIt,
* McsEngl.bcnwlt'private-key@cptIt,
_DESCRIPTION:
This is the list of words that make up your private key
[https://docs.decred.org/getting-started/user-guides/windows/]
name::
* McsEngl.bcnwlt.PROGRAM@cptIt,
_ADDRESS.WPG:
* https://coinomi.com// Free Secure Open-Source Multi-Coin HD Wallet for Bitcoin and Altcoins
name::
* McsEngl.bcnwlt.BRAIN@cptIt,
* McsEngl.blockchain-brain-wallet@cptIt,
* McsEngl.bcnwlt.brain@cptIt,
_DESCRIPTION:
The-storage of private-key, as a memorable phrase, in once brain.
name::
* McsEngl.bcnwlt.HD@cptIt,
* McsEngl.hierarchical-deterministic-wallet@cptIt,
_DESCRIPTION:
HD (or "hierarchical deterministic") wallets like Jaxx generate a new address every time funds are sent to the current address.
All addresses generated from the same wallet can be used to receive funds, and all funds sent to any of these addresses will show up in your Jaxx balance.
The balance you see on your main wallet screens represent the total sum between those addresses.
[https://decentral.zendesk.com/hc/en-us]
name::
* McsEngl.bcnwlt.HD.NO (static)@cptIt,
* McsEngl.bcnwlt.HD.no@cptIt,
* McsEngl.bcnwlt.static@cptIt,
_DESCRIPTION:
Static (non-HD) wallets stick to using a single address for all transactions.
While that's simpler, address reuse greatly undermines your privacy.
[https://decentral.zendesk.com/hc/en-us]
name::
* McsEngl.bcnwlt.ONLINE@cptIt,
_ADDRESS.WPG:
* https://www.cryptonator.com// Online cryptocurrency wallet
Free multi-cryptocurrency accounts with instant exchange
name::
* McsEngl.bcnwlt.WEB@cptIt,
* McsEngl.bcnwlt.web@cptIt,
* McsEngl.blockchain-web-wallet@cptIt,
_DESCRIPTION:
A-web-wallet is A-WEBPAGE using javascript to manage addresses.
It can store your keys locally or online.
[hmnSngo.2017-04-03]
name::
* McsEngl.bcnwlt.Jaxx (jaxwlt)@cptIt,
* McsEngl.jaxwlt@cptIt,
* McsEngl.Jaxx-wallet@cptIt,
_DESCRIPTION:
Your Blockchain Interface.
Bye-bye gatekeepers. With Jaxx, you have the keys to control the new digital world.
[https://jaxx.io//]
name::
* McsEngl.jaxwlt'Exchange-value-token@cptIt,
_DESCRIPTION:
Jaxx currently supports:
Bitcoin
Ether
TheDAO
Dash (not available for iOS wallets)
Ethereum Classic
Augur REP
Litecoin
Zcash (not available for iOS wallets)
Rootstock Testnet (not available for iOS wallets)
[https://decentral.zendesk.com/hc/en-us]
name::
* McsEngl.jaxwlt'Fee@cptIt,
_DESCRIPTION:
What are transaction fees, and what fees does Jaxx apply?
Fees applied to transaction go to support the networks that run the coin/token - so, for instance, every standard (non-contract) ETH transaction currently applies a fee of .000441 ETH.
This fee does not go to us; it goes to reward miners (thereby ensuring that the transaction is logged into the blockchain in a timely fashion) and support the Ethereum network itself.
Note that transactions that interact with a contract address will be more costly.
The same is true of Bitcoin - BTC fees applied go to the Bitcoin network. The difference is that the BTC fees applied are dynamic - they are subject to go up or down based on the state of the network. Jaxx lets you specify between three different fee options depending on whether your transaction is time-sensitive or not (as the lower fee may face a longer confirmation period).
As newer coins are implemented, each coin is subjected to their own transaction fee that goes to their respected networks.
[https://decentral.zendesk.com/hc/en-us/articles/225024248-What-are-transaction-fees-and-what-fees-does-Jaxx-apply-]
name::
* McsEngl.jaxwlt'Doing@cptIt,
What can Jaxx do?
Jaxx can perform the following functions:
Send currencies to another currency address
Receive currency from another currency address
Manage your DAO Tokens
Convert between currencies through the in-app ShapeShift integration
Pair from or to another device's Jaxx wallet so that you can access that same wallet across all devices (mobile, desktop, tablet, or browser extension format)
Transfer funds from a paper wallet / private key, including encrypted paper wallets
Send to contract addresses
Use your device's camera to scan addresses in QR code form (mobile only) for sending and receiving bitcoin and ether, as well as pairing wallets and transferring funds from a paper wallet
Scan websites for valid addresses (browser extensions only)
Split ETH/ETC
[https://decentral.zendesk.com/hc/en-us]
name::
* McsEngl.jaxwlt'Updating@cptIt,
How do I update Jaxx on desktop? (iOS / Windows)
Please visit Jaxx.io to find and download the latest version of Jaxx. Please make sure you write down your 12-word Backup Phrase in the exact sequence prior to updating.
[https://decentral.zendesk.com/hc/en-us]
name::
* McsEngl.bcnnet'Problem (bcnpbm)@cptIt,
* McsEngl.bcnnet'problem@cptIt,
* McsEngl.bcnpbm@cptIt,
* McsEngl.blockchain-issue@cptIt,
* McsEngl.blockchain-problem@cptIt,
name::
* McsEngl.bcnpbm.Security@cptIt,
* McsEngl.bcnnet'security@cptIt,
* McsEngl.bcnscrt@cptIt,
* McsEngl.bcnsecurity@cptIt,
* McsEngl.blockchain-security@cptIt,
_DESCRIPTION:
Bcnnet solved the-problem of information-security.
And this is THE-TRANSPARENCY.
All security-systems are-created by humans and other humans broke them.
Our history shows that.
Transparency destroys the-need for security.
[hmnSngo.2017-03-26]
name::
* McsEngl.bcnscrt'51-percent-attack@cptIt,
* McsEngl.bcnnet'51-percent-attack@cptIt,
name::
* McsEngl.bcnscrt'Resource@cptIt,
* McsEngl.bcnnet'resource.security@cptIt,
* McsEngl.bcnnet'security-resource@cptIt,
_ADDRESS.WPG:
* https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51#.gwuvm0m26,
name::
* McsEngl.bcnnet'Human (bcnhmn)@cptIt,
* McsEngl.bcnhmn@cptIt,
* McsEngl.bcnnet'human@cptIt,
* McsEngl.blockchain-human@cptIt,
name::
* McsEngl.bcnhmn'Skill@cptIt,
* McsEngl.bcnhmn'skill@cptIt,
_ADDRESS.WPG:
* https://cointelegraph.com/news/what-blockchain-skills-are-in-high-demand-digital-headhunter,
name::
* McsEngl.bcnhmn.specific@cptIt,
* McsEngl.bcnhmn.specific@cptIt,
_SPECIFIC:
* dapp-user-human,
* developer-human#ql:idBcnhmnDvr#,
* miner-human#ql:idBcnmnr#,
* user#ql:idBcnusr#,
* wallet-user-human#ql:idBcnhmnWur#
name::
* McsEngl.bcnhmn.DEVELOPER (bcnhmnDvr)@cptIt,
* McsEngl.bcnhmnDvr@cptIt,
* McsEngl.bcnhmn.developer@cptIt,
* McsEngl.bcnnet'developer@cptIt,
name::
* McsEngl.bcnhmn.USER (bcnusr)@cptIt,
* McsEngl.bcnhmn.user@cptIt,
* McsEngl.bcnusr@cptIt,
* McsEngl.blockchain-user@cptIt,
_DESCRIPTION:
User is a-human who uses the-services#ql:idBcnsvc# of the-network.
name::
* McsEngl.bcnhmn.NODE-OPERATOR (bcnhmnNor)@cptIt,
* McsEngl.bcnhmnNor@cptIt,
* McsEngl.bcnhmn.node-operator@cptIt,
* McsEngl.bcnhmn.node-owner@cptIt,
* McsEngl.bcnnet'node-operator@cptIt,
name::
* McsEngl.bcnhmn.WALLET-USER@cptIt,
* McsEngl.bcnhmn.user@cptIt,
* McsEngl.bcnnet'node-operator@cptIt,
* McsEngl.bcnnet'user@cptIt,
name::
* McsEngl.bcnnet'Organization (bcnogn)@cptIt,
* McsEngl.cryptocurrency-venture@cptIt,
* McsEngl.bcnnet'ogn@cptIt,
* McsEngl.bcnogn@cptIt,
* McsEngl.blockchain-organization@cptIt,
_ADDRESS.WPG:
* http://cryptovalleyzug.net/links.html,
Akasha International, Zug www.akasha.world
Bitcoin Suisse AG, Baar www.bitcoinsuisse.ch
Bitfinitum GmbH, Zug www.bitfinitum.com
Blockchain Source, Zug www.blockchainsource.ch
Crypto AG, Zug www.crypto.ch
Cryptocash AG, Uster www.cryptocash.ch
Ethereum Foundation, Baar www.ethereum.org
IFZ Zug www.ifz.ch
InfoGuard AG, Zug www.infoguard.ch
iprotus, Walchwil www.iprotus.ch
MME Legal, Zug www.mme.ch
Monetas AG, Zug www.monetas.net
Mount10, Baar www.mount10.ch
Netmon GmbH, Zurich www.netmon.ch
Patria Digitalis, Zug www.pd.coop
Sapphire Innovation, Zug www.sapphireinnovation.com
Shapeshift, Zug shapeshift.io
Xapo GmbH, Zug www.xapo.com
name::
* McsEngl.bcnogn'ICO@cptIt,
* McsEngl.bcnico@cptIt,
* McsEngl.bcnogn'ICO@cptIt,
* McsEngl.ICO@cptIt,
* McsEngl.initial-coin-offering@cptIt,
_DESCRIPTION:
DEFINITION of 'Initial Coin Offering (ICO)'
An unregulated means by which funds are raised for a new cryptocurrency venture. An Initial Coin Offering (ICO) is used by startups to bypass the rigorous and regulated capital-raising process required by venture capitalists or banks. In an ICO campaign, a percentage of the cryptocurrency is sold to early backers of the project in exchange for legal tender or other cryptocurrencies, but usually for Bitcoin.
Also called an Initial Public Coin Offering (IPCO).
BREAKING DOWN 'Initial Coin Offering (ICO)'
When a cryptocurrency startup firm wants to raise money through an Initial Coin Offering (ICO), it usually creates a plan on a whitepaper which states what the project is about, what need(s) the project will fulfill upon completion, how much money is needed to undertake the venture, how much of the virtual tokens the pioneers of the project will keep for themselves, what type of money is accepted, and how long the ICO campaign will run for. During the ICO campaign, enthusiasts and supporters of the firm’s initiative buy some of the distributed cryptocoins with fiat or virtual currency. These coins are referred to as tokens and are similar to shares of a company sold to investors in an Initial Public Offering (IPO) transaction. If the money raised does not meet the minimum funds required by the firm, the money is returned to the backers and the ICO is deemed to be unsuccessful. If the funds requirements are met within the specified timeframe, the money raised is used to either initiate the new scheme or to complete it.
Early investors in the operation are usually motivated to buy the cryptocoins in the hope that the plan becomes successful after it launches which could translate to a higher cryptocoin value than what they purchased it for before the project was initiated. An example of a successful ICO project that was profitable to early investors is the smart contracts platform called Ethereum which has Ethers as its coin tokens. In 2014, the Ethereum project was announced and its ICO raised $18 million in Bitcoins or $0.40 per Ether. The project went live in 2015 and in 2016 had an ether value that went up as high as $14 with a market capitalization of over $1 billion.
ICOs are similar to IPOs and crowdfunding. Like IPOs, a stake of the startup or company is sold to raise money for the entity’s operations during an ICO operation. However, while IPOs deal with investors, ICOs deal with supporters that are keen to invest in a new project much like a crowdfunding event. But ICOs differ from crowdfunding in that the backers of the former are motivated by a prospective return in their investments, while the funds raised in the latter campaign are basically donations. For these reasons, ICOs are referred to as crowdsales.
Although there are successful ICO transactions on record and ICOs are poised to be disruptive innovative tools in the digital era, investors are cautioned to be wary as some ICO or crowdsale campaigns are actually fraudulent. Because these fund-raising operatives are not regulated by financial authorities such as the Securities Exchange Commission (SEC), funds that are lost due to fraudulent initiatives may never be recovered.
Read more: Initial Coin Offering (ICO) Definition | Investopedia http://www.investopedia.com/terms/i/initial-coin-offering-ico.asp#ixzz4WU1TYEkA
Follow us: Investopedia on Facebook
name::
* McsEngl.bcnico'Resource@cptIt,
_ADDRESS.WPG:
* https://cointelegraph.com/explained/ico-explained,
* https://cointelegraph.com/explained/how-to-launch-a-successful-ico-explained,
* http://zeus-token.io/eng/ FIRST ECOMINING IN THE WORLD (Totally insecure ICO!),
name::
* McsEngl.bcnogn.SPECIFIC@cptIt,
_SPECIFIC:
* Exchange,
* Foundation,
* Merchant,
* Mining-pool,
* Wallet,
name::
* McsEngl.bcnogn.EXCHANGE (bcnx)@cptIt,
* McsEngl.bcnnet'exchange@cptIt,
* McsEngl.bcnx@cptIt, {2017-02-04}
* McsEngl.blockchainX@cptIt, {2017-02-04}
* McsEngl.crypto-exchange@cptIt,
* McsEngl.exchange-ogn-of-blockchain-currencies@cptIt,
name::
* McsEngl.bcnx'Fee@cptIt,
_SPECIFIC:
* Lykke 0
* Bittrex 0.25%
* Cashilla 1% plus 1€ for fiat deposit.
name::
* McsEngl.bcnx.SPECIFIC@cptIt,
_SPECIFIC:
* BitBay#ql:bitbay_ogn#
* BitStamp#ql:bitstamp_ogn#
* Changenly#linkL#
* Lykke,
name::
* McsEngl.bcnx.BitBay (Polland) {2014}@cptIt,
* McsEngl.BitBay@cptIt,
* McsEngl.BitBay-ogn@cptIt,
* McsEngl.ognBitBay@cptIt,
_DESCRIPTION:
Despite being the first company to offer Bitcoin trading in Poland, Bitbay has not stopped there and has announced the inclusion of Ethereum as a tradable asset.
[http://cointelegraph.com/news/bitbay-brings-ethereum-to-poland]
name::
* McsEngl.bcnx.BitPay {2011}@cptIt,
* McsEngl.BitPay@cptIt,
* McsEngl.ognBtcsvc.BitPay@cptIt,
_DESCRIPTION:
BitPay was founded in 2011, while Bitcoin was still in its infancy. We saw the potential for bitcoin to revolutionize the financial industry, making payments faster, more secure, and less expensive on a global scale.
We started BitPay with the intention of making it easy for businesses to accept bitcoin payments, and we are currently the largest bitcoin payment processor in the world, serving more than 60,000 merchants on six continents.
Payment processing was our first contribution to the Bitcoin ecosystem, but it is not our last. We're building open source software to power the next applications of Bitcoin. Bitcoin's future looks very bright, and we plan on remaining on the forefront of this technology, creating more tools and services for everyone to use in innovative new ways.
[https://bitpay.com/about]
name::
* McsEngl.bitpay'Card@cptIt,
How works:
1.Order
Order your card for $9.95. Once your ID has been verified, your card will arrive within 7-10 business days.
2.Activate
When your card arrives in the mail, activate the card at bitpay.com/card/activate and create a cardholder account.
3.Load
Load your card with dollars using any bitcoin wallet, or via direct deposit through your employer.
4.Spend
Spend dollars anywhere Visa® debit cards are accepted, or withdraw cash from any Visa®-compatible ATM.
[https://bitpay.com/card]
name::
* McsEngl.bcnx.Bitstamp (3rd - EU)@cptIt,
* McsEngl.Bitstamp-ogn@cptIt,
* McsEngl.bitstamp@cptIt,
* McsEngl.ognBtcsvc.Bitstamp@cptIt,
_ADDRESS.WPG:
* https://www.bitstamp.net//
_DESCRIPTION:
Bitstamp is a European Union based bitcoin marketplace. It allows people from all around the world to safely buy and sell bitcoins.
ARE YOU SELLING BITCOINS?
No. We are providing a service. You are always buying bitcoins from another individual, who is selling them. All we do is provide a safe and simple environment to trade. We guarantee that buyers get their bitcoins and sellers get their money at agreed price.
[https://www.bitstamp.net/faq/]
===
This morning, Bitstamp announced that it has received a license from the Luxembourg Ministry of Finance to operate as a payment institution, and according to the company, this license applies to the European Union as a whole. “With this,” says Dan Morehead, the chairman of Bitstamp and the CEO of Pantera Capital, a firm that specializes in investments related to bitcoin, “Bitstamp is able to do business in all 28 countries of the EU.”
... FIFTEEN MONTHS AGO, hackers lifted more than $5 million from the bitcoin exchange operated by Bitstamp, a Slovenian company that aspired to push the digital currency across Western Europe. The hack wasn’t nearly as large or as devastating as the one that pilfered $460 million from Mt. Gox and sent the Japan-based exchange, then one of the world’s largest, spiraling into bankruptcy. But it was yet another black eye for bitcoin, the digital currency that holds so much promise as an alternative to fiat currencies but has never really broken into the mainstream.
[http://www.wired.com/2016/04/bitcoin-exchange-receives-approval-operate-across-eu/?mbid=social_twitter]
name::
* McsEngl.bitstamp'office@cptIt,
OFFICES
UNITED KINGDOM
Bitstamp Ltd.
5 New Street Square
London EC4A 3TW
United Kingdom
LUXEMBOURG
Bitstamp Europe S.A.
10 rue Antoine Jans
L-1820 Luxembourg
Luxembourg
UNITED STATES
Bitstamp USA Inc.
2930 Magnolia Street
Berkeley, CA 94705
United States
[https://www.bitstamp.net/about_us/]
name::
* McsEngl.bcnx.Blockhain {2011}@cptIt,
* McsEngl.ognBlockchain@cptIt,
* McsEngl.blockchain-service@cptIt,
* McsEngl.ognBtcsvc.Blockhain@cptIt,
_DESCRIPTION:
Blockchain is the world’s most popular Bitcoin wallet. It is often confused with the core innovation that Bitcoin introduced. Founded in 2011, the company is one of the oldest and biggest Bitcoin’s companies.
Experiencing a rapid expansion in the last few years, the company has passed 6.7 million users, and the amount of wallets created on the platform is constantly increasing.
[http://cointelegraph.com/news/our-goal-is-to-replace-your-need-for-a-bank-says-blockchain-co-founder-and-ceo-nicolas-cary]
===
Blockchain is the world’s most popular Bitcoin wallet, and home to the most widely used Bitcoin APIs and trusted block explorer and search engine. It is recognized as the strongest, most trusted brand in Bitcoin.
[https://blockchain.com/about/]
name::
* McsEngl.bcnx.Changenlly-crypto-exchange {2016}@cptIt,
* McsEngl.bcnnet'Changenlly@cptIt,
* McsEngl.ognChangenlly@cptIt,
_DESCRIPTION:
Changelly, an automated cryptocurrency exchange and a relatively new player on the market of cryptocurrency exchanges, made its services available to its users in April 2016 after six months of a successful beta.
[https://cointelegraph.com/news/with-charlie-shrem-as-advisor-shangelly-is-set-to-outperform-shapeshift]
===
https://cointelegraph.com/news/with-charlie-shrem-as-advisor-shangelly-is-set-to-outperform-shapeshift
[https://changelly.com/]
===
Changelly launched in 2013 as an instant exchange app, similar to the well-known ShapeShift. Rather than being a traditional exchange that requires users register before trading against an order book, with variable depth and the problems of slippage that can result, it aggregates rates from the largest trading platforms and offers a single rate. The commission is just 0.5%. By fundamentally rethinking the way cryptocurrencies are exchanged, Changelly aims to remove technical impediments to customers engaging with this critical element of the cryptocurrency world’s infrastructure.
[https://blog.chronobank.io/chronobank-makes-a-strategic-partnership-with-instant-exchange-service-changelly-b4fa39ca243e]
name::
* McsEngl.ognChangelly'Fee@cptIt,
_DESCRIPTION:
Fair
Other cryptocurrency trading services charge you with withdrawal fees and commissions. We have a reasonable fee of 0.5%.
[https://changelly.com/]
name::
* McsEngl.ognChangelly'Exchange-rate-chart@cptIt,
2017-01-30:
1 BTC = 023.69664034 ZEC, {2017-01-30}
1 BTC = 057.98876409 DASH, {2017-01-30}
1 BTC = 072.59264636 XMR, {2017-01-30}
1 BTC = 087.7577885 ETH, {2017-01-30}
1 BTC = 219.63516402 REP, {2017-01-30}
1 BTC = 237.42056798 LTC, {2017-01-30}
1 BTC = 262.5505738 FCT, {2017-01-30}
1 BTC = 706.47412891 ETC, {2017-01-30}
1 BTC = 914.12273926 SBD, {2017-01-30}
1 BTC = 919.07541013 NBT, {2017-01-30}
1 BTC = 002,186.00736684 RADS, {2017-01-30}
1 BTC = 003,086.5626495 EXP, {2017-01-30}
1 BTC = 005,702.06699928 STEEM, {2017-01-30}
1 BTC = 005,749.10888812 LSK#ql:mnylsk#, {2017-01-30}
1 BTC = 006,724.72344574 MAID, {2017-01-30}
1 BTC = 007,403.29446603 AEON#ql:mnyaeon#, {2017-01-30}
1 BTC = 008,836.26402756 STRAT, {2017-01-30}
1 BTC = 018,537.39920289 AMP, {2017-01-30}
1 BTC = 021,466.13716861 NAV, {2017-01-30}
1 BTC = 028,985.50724637 FCN, {2017-01-30}
1 BTC = 030,688.96731624 LBC, {2017-01-30}
1 BTC = 034,387.89546079 NLG, {2017-01-30}
1 BTC = 046,019.3281178 ARDR, {2017-01-30}
1 BTC = 144,927.53623188 NXT, {2017-01-30}
1 BTC = 146,735.14306676 XRP, {2017-01-30}
1 BTC = 179,856.11510791 XEM#ql:mnyxem#, {2017-01-30}
1 BTC = 222,222.22222222 QCN, {2017-01-30}
1 BTC = 257,367.13421696 DSH, {2017-01-30}
1 BTC = 04,444,444.44444444 DOGE, {2017-01-30}
1 BTC = 10,822,510.82251082 XDN, {2017-01-30}
1 BTC = 15,797,788.30963665 BCN#ql:mnyBCN#, {2017-01-30}
name::
* McsEngl.bcnx.Coinbase (USA {2012})@cptIt,
* McsEngl.coinbase@cptIt,
* McsEngl.ognBtcsvc.Coinbase@cptIt,
_ADDRESS.WPG:
* https://coinbase.com//
_DESCRIPTION:
Founded in June of 2012, Coinbase is a bitcoin wallet and platform where merchants and consumers can transact with the new digital currency bitcoin. We're based in San Francisco, California.
Bitcoin is the world's most widely used alternative currency with a total market cap of approximately $5.3 billion. The bitcoin network is made up of thousands of computers run by individuals all over the world.
[https://www.coinbase.com/about?locale=en]
===
Bitcoin, made simple.
Coinbase is an international digital wallet that allows you to securely buy, use, and accept bitcoin currency ›
[https://coinbase.com/]
name::
* McsEngl.coinbase'Exchange@cptIt,
_DESCRIPTION:
Coinbase Exchange is the leading platform to trade bitcoin.
[https://exchange.coinbase.com/]
name::
* McsEngl.coinbase'API@cptIt,
_ADDRESS.WPG:
* https://docs.exchange.coinbase.com/?javascript#introduction,
name::
* McsEngl.coinbase.EVOLUTING@cptIt,
{time.2015}:
Coinbase opens bitcoin exchange in UK
Company targets British enthusiasm for digital currency as it eyes an international expansion
[Financial Times Briefing 2015-04-29]
name::
* McsEngl.bcnx.Kraken-exchange (USA {2011})@cptIt,
* McsEngl.LiteBit@cptIt,
* McsEngl.LiteBit-exchange@cptIt,
_DESCRIPTION:
KRAKEN BITCOIN EXCHANGE PUTS YOU FIRST
Founded in 2011, San Francisco-based Kraken is the largest Bitcoin exchange in euro volume and liquidity and also trading Canadian dollars, US dollars, British pounds and Japanese yen. Kraken is consistently rated the best and most secure Bitcoin exchange by independent news media. Kraken was the first Bitcoin exchange to have trading price and volume displayed on the Bloomberg Terminal, the first to pass a cryptographically verifiable proof-of-reserves audit, and is a partner in the first cryptocurrency bank. Kraken is trusted by hundreds of thousands of traders, the Tokyo government's court-appointed trustee, and Germany's BaFin regulated Fidor Bank.
[https://www.kraken.com/en-us/about]
name::
* McsEngl.bcnx.LakeBTC (CHINA)@cptIt,
* McsEngl.LakeBTC@cptIt,
_ADDRESS.WPG:
* https://www.lakebtc.com//
_DESCRIPTION:
Εδρα τη Σαγγάη Κίνας,
name::
* McsEngl.lakebtc'security@cptIt,
_DESCRIPTION:
Our years of risk management and internal control experience in financial industries build the most solid foundation for ensuring customers' fund and privacy being safe and secure.
To protect your fund, we implemented a number of rigorous mechanisms including SSL encryption, cold storage, 2-step verification, SMS withdrawal confirmation, trade notifications and so on.
High availability and fast trade matches, even under enormouse amount of load, are two attributes that are critical to high liquidity and make us stand out in the crowd.
Besides, we also provide highly-secure market data and trading API's for advanced users who prefer arbitrages, market making, or alogrithm trading.
[https://www.lakebtc.com/]
name::
* McsEngl.bcnx.Liqui ({2016})@cptIt,
* McsEngl.Liqui-exchange@cptIt,
_DESCRIPTION:
Liqui is the latest exchange to add ChronoBank’s TIME token. The exchange launched on 1 September 2016, and is still a relatively new but fast-growing entrant to the cryptocurrency world. Its team of seven are located in various countries and jurisdictions around the world, and in a short period of time have managed to build a strong business that has gained the trust of an increasing number of traders thanks to its user-friendly interface, commitment to user support and rapid listing of some of the most popular and promising Ethereum-based tokens?—?including Iconomi, Golem and Wings.
One of Liqui’s unique features is its deposit accounts that allow users to earn annual interest of 24% for BTC and ETH, within a fixed limit. The exchange’s trading API has recently been implemented, and in the near future a Tether (USDT) market is expected. Liqui has established a reputation for pro-active cooperation with leading market-makers and businesses within the cryptocurrency industry.
[https://blog.chronobank.io/chronobank-announced-partnership-with-liqui-exchange-652140c46d84#.yne3j0tle]
name::
* McsEngl.bcnx.LiteBit-exchange (Netherlands {2013})@cptIt,
* McsEngl.LiteBit@cptIt,
* McsEngl.LiteBit-exchange@cptIt,
_DESCRIPTION:
LiteBit is a young innovative company established in Zoetermeer, The Netherlands. LiteBit exists now more than two year and we, as a team, are very proud of that! LiteBit ensures that you and others can buy & sell bitcoins easily, safely and quickly. All our employees work accurately with a aim for the customer. We provide all kinds of services to make your life with crypto currency easier, quicker and more efficient. Did you try out our price alerts for bitcoin or any other crypto currency? It’s free!
Besides LiteBit we develop new applications that are using Blockchain Technology. We are also known as 2525 Ventures B.V.
Kenny Rokven
CEO
“I started LiteBit on 7th of december in 2013. I am responsible for all general business of LiteBit. ”
[https://www.litebit.eu/en/about]
name::
* McsEngl.bcnx.Poloniex-exchange (USA)@cptIt,
* McsEngl.Poloniex-exchange@cptIt,
* McsEngl.Poloniex-exchange-ogn@cptIt,
_DESCRIPTION:
WELCOME TO POLONIEX
We are a US-based cryptocurrency exchange offering maximum security and advanced trading features.
[https://poloniex.com/]
name::
* McsEngl.bcnx.QuadrigaCX (Canada)@cptIt,
* McsEngl.ognBtcsvc.QuadrigaCX@cptIt,
_DESCRIPTION:
Quadriga CX is a Canadian Cryptocurrency exchange platform, with offices in Vancouver, BC. Our goal is to provide an easy to use platform to simplify the process of buying and selling Bitcoins.
[https://www.quadrigacx.com/about]
name::
* McsEngl.bcnx.ShapeShift@cptIt,
* McsEngl.ShapeShift-ogn@cptIt,
* McsEngl.ShapeShift@cptIt,
_DESCRIPTION:
ShapeShift is a new piece of infrastructure in Bitcoinland. It is how digital currency exchange should work. From start to finish you can change currencies in under ten seconds, no account required.
...
Let's assume you have Bitcoin and you want Litecoin. It goes like this:
1. Select Bitcoin as the input and Litecoin as the output
2. Provide your Litecoin address in the box, then click the Start button
3. ShapeShift will generate a BTC deposit address for you. Please send your BTCs to this generated address. (Don't send more than the Deposit Limit).
That's it. In a few moments, your Litecoin will be sent to you.
No emails or passwords. No lengthy signup process. No accounts. No bid and ask orders. No friction.
[https://info.shapeshift.io/about]
_ADDRESS.WPG:
* https://shapeshift.io/#/coins,
What exchange rate do you use?
Jon April 05, 2016 22:12
The exchange rate is our own, derived from several market sources and based on the amount we feel comfortable exchanging at that fixed rate (whether you do small or large order, the rate stays the same - no slippage).
We earn a profit to the extent we can source coins in other markets for a lower cost to replenish our reserves.
[https://shapeshift.zendesk.com/hc/en-us/articles/202585612-What-exchange-rate-do-you-use-]
What’s your fee structure?
January 08, 2017 11:04
ShapeShift does not charge a per exchange fee, while our exchange rates depend on the depth and spread of particular coin pairs and markets.
This means the amount that ShapeShift makes on any particular transaction varies based on current market conditions.
Depending on the liquidity and spread of a particular coin/coin pair, ShapeShift's spread usually falls in the range of about 0.5-1% or so.
[https://shapeshift.zendesk.com/hc/en-us/articles/202585602-What-s-your-fee-structure-]
name::
* McsEngl.bcnogn.MERCHANT@cptIt,
* McsEngl.bcnogn.merchant@cptIt,
_DESCRIPTION:
Wholesaler or retailer who may buy goods from any or all sources for resale to anyone and everyone for profit, using bitcoins.
name::
* McsEngl.bcnogn.Chain.com@cptIt,
* McsEngl.chain.com@cptIt,
_DESCRIPTION:
The Chain Platform
Our solutions enable institutions to design, deploy, and operate blockchain networks that can power any type of asset in any market.
[http://chain.com//]
name::
* McsEngl.bcnogn.Coin-Center@cptIt,
* McsEngl.Coin-Center@cptIt,
Coin Center, the industry’s leading public policy research and advocacy center.
[http://www.coindesk.com/events/consensus-2016/]
name::
* McsEngl.bcnogn.CoinDesk@cptIt,
* McsEngl.CoinDesk@cptIt,
_DESCRIPTION:
CoinDesk is the world leader in news and information on digital currencies such as bitcoin, and its underlying technology – the blockchain.
We cover news and analysis on the trends, price movements, technologies, companies and people in the bitcoin and digital currency world.
Our per-minute Bitcoin Price Index, a derived measure of bitcoin's value based on an agreed set of criteria, also serves as a point of reference for those involved in the bitcoin industry.
If you're new to bitcoin, read our straightforward guides on the basics of what bitcoin is, why people use it, where to buy bitcoins and how to spend them. We also explain the basics of bitcoin mining, how to set up a bitcoin miner, and how bitcoin transactions work.
Digital currency is a rapidly evolving industry and we believe one of the biggest developments in internet history in the making.
There are bitcoin exchanges, merchants accepting and promoting bitcoin, investors, traders, startups and developers all contributing to the ecosystem. There are also regulatory bodies all over the world trying to understand more about bitcoin, take a stance on it and assign guidelines to companies trading in or otherwise involved with bitcoin.
We strive to cover news accurately, fairly, objectively and responsibly. Obtaining original comment, corroborating information from other sources, and showcasing original opinion are fundamental to this. View our editorial policy here.
CoinDesk is an independent publication with reporters all over the world. If you're interested in writing for us, whether as a freelancer or occasional contributor, get in touch or check out our Jobs page.
If you have a question or a story, send us a tip. Contact us for anything else.
[http://www.coindesk.com/about-us/]
name::
* McsEngl.bcnogn.Digital-Currency-Group@cptIt,
* McsEngl.DCG@cptIt,
_DESCRIPTION:
Digital Currency Group (DCG), the blockchain industry’s most active investor
[http://www.coindesk.com/events/consensus-2016/]
name::
* McsEngl.bcnogn.GBBC@cptIt,
* McsEngl.GBBC@cptIt,
* McsEngl.Global-Blockchain-Business-Council@cptIt,
_DESCRIPTION:
Expanding Blockchain Technology Around the World
The Global Blockchain Business Council (GBBC) brings together the world’s leading businesses and business leaders to highlight the latest innovations and advances in Blockchain technology.
The GBBC is committed to fostering partnerships, raising awareness of the potential of this groundbreaking technology and providing a forum for education, collaboration and partnership.
[http://www.gbbcouncil.org/]
===
By Alicia Naumoff {2017-01-22}
The Blockchain Council Announced in Davos That Bitcoin Price Will Grow as Trump Takes Office
The Bitfury Group that develops Bitcoin mining hardware and operates mining farms has announced that in collaboration with the international law firm Covington it has launched the Global Blockchain Business Council (GBBC).
The announcement was made at the event held alongside the World Economic Forum’s annual meeting in Davos.
It happened just before the new United States President Donald Trump sent jitters down the spine of the world’s political and financial elite announcing at his inauguration: “From this day forward, a new vision will govern our land.” Trump has promised the American people “challenges” and “hardships” on the way of “getting the job done.” The price of Bitcoin took a cue from that message and immediately shot forward.
Top heads sighted
A number of technology, banking and financial experts and thought leaders were spotted at the Davos event where the Blockchain council has been created. They include former Swedish Prime Minister and senior advisor at Covington Carl Bildt, former Estonian President Toomas Hendrik, Dr. Wei Wang, founding chairman of China Mergers & Acquisitions (CMAA), and Don Tapscott the author of the best-seller “Blockchain Revolution”, just to name a few.
The Bitfury Group is a global team of experts in technology, business, communications, security and civil society, who are all big believers in the potential of Blockchain to open new doors for global economic opportunity and prosperity.
The main idea behind the Council is to bring together leading businesses, executives and government authorities to collaborate driving forward development and adoption of Blockchain technology around the globe.
A resource center and an educational forum
Valery Vavilov, the CEO of Bitfury Group, described the newly established Council as “a much-needed forum for businesses, innovators and technologists” to join forces and facilitate the advancement of Blockchain technology.
The GBBC will fulfill the role of a resource center and an educational forum to foster collaboration and partnerships across industries. It will assist companies by raising awareness of the potential of Blockchain technology and help engaging businesses interested in developing within the Blockchain space.
Covington brings to the table its broad-based experience in advising their clients in connection with policies, regulation litigation, enforcement and investigation, privacy and data security, consumer protection and transactional matters related to distributed ledger technology.
Sebastian Vos, Co-Chair of Covington’s global public policy and government affairs practice, said:
“Through advocacy and international engagement, Covington looks forward to working with the Global Blockchain Business Council to unlock the potential of Blockchain technology.”
Blockchain revolution
We saw how the Internet revolutionized many industries. We are now witnessing Blockchain technology steadily changing our approach to commerce, communications, financial services, entertainment industries, and many other spheres.
A lot has been said about the beauty of this technology and how it allows for any asset to be digitized, transferred and recorded on transparent and extremely secure ledgers.
Blockchain is marching across industries sweeping away slow, expensive and hackable intermediaries. When talking about the ways to facilitate this process, many experts often emphasize the need to increase collaboration between businesses and government authorities. Well, some are moving from words to deeds.
To learn more about the Global Blockchain Business Council please visit www.gbbcouncil.org.
[https://cointelegraph.com/news/the-blockchain-council-announced-in-davos-that-bitcoin-price-will-grow-as-trump-takes-office]
name::
* McsEngl.bcnogn.Guardtime@cptIt,
* McsEngl.guardtime@cptIt,
_DESCRIPTION:
About Guardtime
Who we are
We are a team of over 100 cryptographers, network architects, hardware engineers, software developers and security architects, with decades of experience building cybersecurity solutions for enterprise, financial, telecommunications service providers, and military customers among others.
In 2007 we invented Keyless Signature Infrastructure, the first and only blockchain platform for ensuring the integrity of systems, networks and data at industrial scale.
What we do
We build products using our technology that solve problems no one else can solve. Examples include Anti-Tamper hardware designed to resist nation-state reverse engineering, a quantum-immune replacement for RSA digital signatures, cryptographic provenance tracking for software and IOT life cycles, insider threat mitigation and deterministic data loss prevention.
What we believe
We believe that integrity must be the basis for building reliable, resilient and secure systems. For the last 40 years security has come to mean confidentiality and encryption. Integrity has largely been forgotten, primarily because there hasn't been the tools to address it. Our contrarian view is that confidentiality is what you get when your systems have integrity.
If you can guarantee integrity (of systems, of processes, of supply chains) then you can guarantee the absence of compromise and replace a security strategy based on hope (that your security is working) with one based on mathematical certainty.
Office locations
Amsterdam
The Netherlands
Pinnacle Tower, Rapenburgerstraat 177/S,
1011 VM Amsterdam,
The Netherlands
Irvine, CA
United States
5151 California Ave,
Irvine, CA 92617,
United States
Tallinn
Estonia
A. H. Tammsaare tee 60,
Tallinn, 11316,
Estonia
Tartu
Estonia
Kόόni 5b,
Tartu, 51004,
Estonia
Please e-mail us at info@guardtime.com
For press inquiries: pr@guardtime.com and +1 (415) 625-8555
[https://guardtime.com/about]
name::
* McsEngl.bcnogn.HyperLedger-Project (hlp)@cptIt,
* McsEngl.bcnogn.hyperledger@cptIt,
* McsEngl.HLP@cptIt,
* McsEngl.hyperLedger-project@cptIt,
_DESCRIPTION:
The Hyperledger Project is a collaborative effort created to advance blockchain technology by identifying and addressing important features for a cross-industry open standard for distributed ledgers that can transform the way business transactions are conducted globally. The Project is a Linux Foundation Collaborative Project and implements many open source best practices familiar to other leading projects.
To facilitate an open ecosystem, the Hyperledger Project was structured with an open governance model.
The Technical Steering Committee (TSC) will provide leadership regarding the technical direction of the Hyperledger Project.
The Board of Directors will manage business leadership for the Hyperledger Project including governance, marketing and operational decisions.
For more information on the Hyperledger Project's Governance Model, IP Policy, Antitrust Guidelines, and other operational aspects, please read the Hyperledger Project Charter
[https://www.hyperledger.org/about]
_ADDRESS.WPG:
* https://www.hyperledger.org//
* {2017-04-18} https://cointelegraph.com/news/permissible-smart-contracts-machine-moves-to-hyperledger-no-competition-with-ethereum,
name::
* McsEngl.hlp'Project@cptIt,
name::
* McsEngl.hlppjt'Ligecycle@cptIt,
_ADDRESS.WPG:
* https://wiki.hyperledger.org/community/project-lifecycle,
Project Lifecycle
The term “project” within the Hyperledger Project will refer to a collaborative endeavor to deliver a work item. There may be some projects that are intended to produce a document, such as a requirements or use cases document, a whitepaper, or analysis. Others may be to develop a new capability, or refactor (or remove) an existing capability for the Hyperledger technology releases. Such projects may take the form of a new component (e.g. a new repository) or may propose additions, deletions or changes to an existing repository(s).
Many other open source initiatives leverage an incubation process for new work items, and this seems to have a desired effect of encouraging new ideas and tracks of work, while at the same time providing clear guidance to the broader community as to what is real and supported, versus what is still in the exploratory/experimental/developmental phases.
Therefore the Hyperledger Project has adopted a similar lifecycle process as follows:
Projects are in one of five possible states:
Proposal
Incubation
Active
Deprecated
End of Life
Projects may not necessarily move through those states in a linear way and may go through several iterations.
Project Proposals shall be submitted to the TSC for review, using a Proposal Template. Proposals that are approved shall enter into an Incubation state, unless they are of a refactoring nature, in which case they will be turned over to the relevant project maintainer(s) to handle as they deem fit.
A Proposal must:
have a clear description
have a well-defined scope
identify committed development resources
identify initial maintainers
be vendor neutral
Incubation
Approved project proposals enter into Incubation. For new components/modules, a repository will be created under the hyperledger Github org, and optionally under Gerrit and JIRA, if requested. New features/capabilities should be handled through pull requests labeled with tags that identify the project and tag it as “incubator” (and will ideally be capable of being enabled/disabled with feature-flags).
Projects in Incubation may overlap with one another. Entering Incubation is meant to be fairly easy to allow for community exploration of different ideas.
Once a project qualifies to be declared Active, the project’s maintainers can then vote to request a graduation review by the TSC.
Projects seeking to graduate from Incubation must:
have fully functional code base
have test coverage commensurate with other Active projects
have an active and diverse community of developers
have a history of releases that follow the Active release process
Entering Incubation does not guarantee that the project will eventually get to Active state. Projects may never get to Active state.
The criteria to exit Incubation are defined in the Incubation Exit Criteria document.
Projects that have successfully exited the Incubation phase are in the Active phase.
Anyone may propose that a project be deprecated, by submitting a rationale and identifying a substitute project/component (if any). The maintainers of the project shall vote on such a request and if it passes, make that recommendation to the TSC. Members of the community that disagree with the request shall make their case before the TSC. The TSC shall consider all points of view and render a final decision to deprecate or not.
A Deprecated project will be maintained for a six month period by its community, after which it will be removed from any subsequent formal releases. Notice will be given to the public of the project’s deprecation. After the six-month deprecation period, the project will be labeled End of Life.
A project that is no longer actively developed or maintained.
name::
* McsEngl.bcnogn.Livecoin@cptIt,
* McsEngl.Livecoin@cptIt,
_ADDRESS.WPG:
* https://www.livecoin.net/,
_API:
https://api.livecoin.net//exchange/ticker?currencyPair=ETH/USD
{"last":371.00009000,"high":400.00000000,"low":370.00000000,"volume":328.64837216,"vwap":388.6216553850450686,"max_bid":425.55962000,"min_ask":371.00000000,"best_bid":371.00013000,"best_ask":384.97999000}
===
currencyPair:
ABN/BTC
ACN/BTC
ADZ/BTC
ADZ/USD
ARC/BTC
ARC/ETH
ARC/RUR
ARC/USD
ASAFE/BTC
ATX/BTC
BCC/BTC
BIT/BTC
BLK/BTC
BLU/BTC
BLU/USD
BPC/BTC
BSD/BTC
BTA/BTC
BTC/EUR
BTC/RUR
BTC/USD
BTS/BTC
BURST/BTC
CCRB/BTC
CCRB/ETH
CLOAK/BTC
CLOAK/EUR
CLOAK/USD
CRBIT/BTC
CRBIT/ETH
CRBIT/LEO
CREVA/BTC
CURE/BTC
DANC/BTC
DANC/USD
DASH/BTC
DASH/USD
DBIX/BTC
DGB/BTC
DIBC/BTC
DIBC/ETH
DIBC/USD
DIME/BTC
DIME/EUR
DIME/RUR
DIME/USD
DMC/BTC
DMC/USD
DOGE/BTC
DOGE/USD
DOLLAR/BTC
EDR/BTC
EDR/RUR
EDR/USD
EL/BTC
EL/RUR
EL/USD
EMC/BTC
EMC/DASH
EMC/ETH
EMC/RUR
EMC/USD
EMC/XMR
ENT/BTC
ETH/BTC
ETH/RUR
ETH/USD
EUR/USD
FNC/BTC
FNC/ETH
FNC/USD
FORTYTWO/BTC
FORTYTWO/ETH
FORTYTWO/USD
FRST/BTC
FST/BTC
FST/USD
FUNC/BTC
FUNC/ETH
FUNC/USD
GAME/BTC
GB/BTC
GOLOS/BTC
GUP/BTC
GUP/ETH
GYC/BTC
HNC/BTC
ICN/BTC
INCNT/BTC
INSN/BTC
INSN/ETH
INSN/USD
ITI/BTC
ITI/ETH
ITI/EUR
ITI/RUR
KRB/BTC
KRB/RUR
KRB/USD
LDC/BTC
LEO/BTC
LEO/ETH
LEO/RUR
LEO/USD
LSK/BTC
LSK/USD
LTC/BTC
LTC/USD
LUNA/BTC
MAID/BTC
MCO/BTC
MCO/ETH
MCO/USD
MNE/BTC
MNE/ETH
MOIN/BTC
MOJO/BTC
MONA/BTC
MSCN/BTC
MSCN/ETH
MSCN/EUR
MSCN/RUR
MSCN/USD
NMC/BTC
NVC/BTC
NXT/BTC
OBITS/BTC
OBITS/BTS
OBITS/ETH
OBITS/EUR
OBITS/USD
OD/BTC
OTX/BTC
OTX/ETH
OTX/USD
PIVX/BTC
PIVX/DASH
PIVX/ETH
PIVX/EUR
PIVX/RUR
PIVX/USD
PIVX/XMR
POST/BTC
POST/ETH
POSW/BTC
POSW/CRBIT
POSW/DASH
POSW/ETH
POSW/EUR
POSW/ICN
POSW/LTC
POSW/RUR
POSW/USD
POSW/XMR
PPC/BTC
PRES/BTC
PUT/BTC
PUT/ETH
PUT/USD
QAU/BTC
QAU/ETH
QAU/USD
RBIES/BTC
REE/BTC
RLT/BTC
RLT/ETH
RLT/RUR
RLT/USD
SHIFT/BTC
SIB/BTC
SIB/RUR
SLR/BTC
SOAR/BTC
STEEM/BTC
STRAT/BTC
STRAT/ETH
STRAT/USD
SXC/BTC
SYS/BTC
TAAS/BTC
TAAS/USD
THS/BTC
THS/ETH
THS/USD
TIME/BTC
TRUMP/BTC
TRUMP/ETH
TX/BTC
UNC/BTC
UNRC/BTC
UNRC/USD
UNY/BTC
UNY/ETH
UNY/LTC
UNY/USD
USD/RUR
VLTC/BTC
VOX/BTC
VRC/BTC
VRM/BTC
VRM/VRC
VRS/BTC
VRS/USD
VSL/BTC
WAVES/BTC
WINGS/BTC
WINGS/ETH
XAUR/BTC
XMR/BTC
XMR/USD
XMS/BTC
XRC/BTC
XSPEC/BTC
XTO/BTC
YOC/BTC
YOC/RUR
YOC/USD
ZBC/BTC
ZBC/ETH
ZBC/EUR
ZBC/RUR
ZBC/USD
ZBC/XMR
name::
* McsEngl.bcnogn.Lykke-exchange (lkx Swiss)@cptIt,
* McsEngl.Lykke@cptIt,
* McsEngl.Lykke-exchange@cptIt,
* McsEngl.Lykke-exchange-ogn@cptIt,
=== _NOTES: Why did we choose the name Lykke?
Lykke was the surname of Richard's grandmother on his father's side. The word means luck and happiness. His father explained to them that they are Lykke.
[https://lykke.com/city/faq]
_DESCRIPTION:
What is Lykke?
Lykke is a movement to build one global marketplace that is a level playing field where everyone has access.
We start with foreign exchange and expand to equities, fixed income, commodities and other asset classes.
Lykke Corp is incorporated in Switzerland and issued it's shares on the blockchain (Lykke Coins).
[https://lykke.com/city/faq]
name::
* McsEngl.lkx'API@cptIt,
_ADDRESS.WPG::
* https://support.lykke.com/hc/en-us/articles/360000552605-How-do-I-generate-an-API-KEY-Wallet-
name::
* McsEngl.lkx'Fee@cptIt,
_DESCRIPTION:
What is the business-model?
Commissions & fees at Lykke Wallet are essentially zero. Lykke will make money on providing liquidity, issuance services and consulting.
[https://lykke.com/city/faq]
name::
* McsEngl.lkx'Blockchain@cptIt,
name::
* McsEngl.lkx'Block-Explorer@cptIt,
* McsEngl.Lykke-block-explorer@cptIt,
* McsEngl.lkxblk'explorer@cptIt,
* McsEngl.lkxnet'explorer@cptIt,
* McsEngl.lkxblkexr@cptIt,
name::
* McsEngl.lkx'Exchange-Value-Token@cptIt,
_ADDRESS.WPG:
* https://blockchainexplorer.lykke.com/assets,
name::
* McsEngl.lkx'Lykke-coin@cptIt,
_DESCRIPTION:
What is a Lykke coin?
A Lykke coin is a colored coin that is issued by Lykke Corp.
One Lykke colored coin is 0.01 (one one-hundredth) of one share of Lykke Corp. 100 Lykke colored coins are one share of Lykke Corp.
Lykke Corp has committed 2.5 Mio Lykke Corp shares (20% of Lykke's capital) for issuance as Lykke colored coins, which means that a total of 250 Mio Lykke colored coins will be outstanding.
Lykke Corp makes a market for its coins so that citizens can sell their coins and cash out.
See Lykke Coinprism Metadata
[https://lykke.com/city/faq]
What's the total supply of Lykke coins?
Total number of Lykke Coins issued is 1,285,690,000. The ownership structure is stored on the blockchain: https://www.coinprism.info/asset/AXkedGbAH1XGDpAypVzA5eyjegX4FaCnvM/owners
[https://lykke.com/city/faq]
name::
* McsEngl.bcnnet'Evaluation@cptIt,
* McsEngl.bcneln@cptIt,
* McsEngl.bcnevaluation@cptIt,
* McsEngl.bcnnet'evaluation@cptIt,
* McsEngl.blockchain-evaluation@cptIt,
EVALUATION:
Throughout all the years I’ve been working as a software engineer, there has never been a technology breakthrough that I thought had more potential to change people’s lives for the better than Bitcoin.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
EVALUATION:
“Wherever trust is a problem, blockchain can be a solution.”
- Amanda Gutterman
[https://cointelegraph.com/news/podcast-amanda-gutterman-innovators-lab]
EVALUATION:
Blockchain Features
Blockchains have the following properties.
Undeletable
The data that is on the blockchain will exist as long as there is some node in the network still operating. Once data has been put in a block, it can never be removed.
Unmodifiable
Using public-private key cryptography, all data are verifiably signed and cannot be modified by a third party.
No Downtime
Using the blockchain, zero downtime systems can finally be realized.
Advanced Features for the Blockchain
Mijin is not only a simple platform for creating points or custom currencies, but will have many advanced features.
Support for Multiple Assets
Unlike Bitcoin that has only a single digital asset, Mijin supports any arbitrary asset, allowing you to freely create and manage all your assets. We call these.
Support for Multi-signature Accounts
Mijin supports m-of-n multi-signature accounts at the platform level. You can designate multiple signatory accounts that need to sign off on transactions from an account. This can be useful for managing departmental budgets for companies or governments.
Smart Contract Support
Mijin will allow for powerful computational contracts and programs to be run in a decentralized and verifiable manner.
[http://mijin.io/en/about-mijin]
EVALUATION:
Over a year ago, Marc Andreessen, the doyen of Silicon Valley’s venture capitalists, listed the blockchain’s distributed consensus model as the most important invention since the Internet itself.
[http://recode.net/2015/07/05/forget-bitcoin-what-is-the-blockchain-and-why-should-you-care/]
EVALUATION:
This is why blockchain technology is so exciting – it is not just about an incremental improvement in utility e.g. escrow smart contracts, it is not just about dramatically lowering the cost of setting up a trusted business, see the Great Unbundle blog, it is also about the ability to quickly and cheaply experiment with new money creation models.
[https://www.linkedin.com/pulse/crypto-20-musings-bitcoin-money-creation-alex-batlin??]
EVALUATION:
Blockchain technology allows the elimination of any centralized point of failure, storing all the platform data on all system nodes in a distributed fashion.
[http://wavesplatform.com/]
name::
* McsEngl.bcnnet'Law (bcnlaw)@cptIt,
* McsEngl.bcnlaw@cptIt,
* McsEngl.bcnnet'law@cptIt,
* McsEngl.blockchain-law@cptIt,
_DESCRIPTION:
A-bcnnet#ql:idMcsBcnnet# to exist must-issue money-(cryptocurrency)#ql:idBcnmny#.
Since {1971} money is-backed by thin-air and controlled by governments and financial-institutions.
This destroyed the-link (the-invisible-hand) of money with real-economy and was one of the-reasons that drived the-world into https://en.wikipedia.org/wiki/Financial_crisis_of_2007%E2%80%932008.
Bcnnets decentralize the-control of money.
Obviously there-is a-conflict between the-usefulness-of-bcnnets#ql:idBcnsvc# and the-control of money by governments and financial-institutions.
That's why the-law on cryptocurrencies varies substantially from country to country and is still UNDEFINDED or CHANGING in many of them [https://en.wikipedia.org/wiki/Legality_of_bitcoin_by_country].
[hmnSngo.2017-03-26]
name::
* McsEngl.bcnnet'Relation-to-other-computer-systems@cptIt,
* McsEngl.blockchain-relation-to-other-computer-systems@cptIt,
_DESCRIPTION:
To grasp the potential that applications built on top of blockchains can deliver, it is essential to understand the three key differences between blockchains and most existing computer designs.
We present these below as non-localization, security, and auditability.
[https://www.provenance.org/whitepaper]
name::
* McsEngl.bcnnet'Conference@cptIt,
* McsEngl.bcncfc@cptIt,
* McsEngl.bcnnet'conference@cptIt,
* McsEngl.bcnnet'event@cptIt,
* McsEngl.blockchain-conference@cptIt,
CONSENSUS 2016
CoinDesk is proud to present its 2nd annual blockchain technology summit, Consensus 2016, in collaboration with Digital Currency Group (DCG), the blockchain industry’s most active investor, and Coin Center, the industry’s leading public policy research and advocacy center. The multi-day event will define what is “real” in blockchain technology and focus on how to mainstream real-world applications for consumers and enterprises alike. This May 2-4, professionals from leading industry startups, investment firms, financial services institutions, academic and policy groups will congregate at the New York Marriott Marquis for Consensus 2016.
[http://www.coindesk.com/events/consensus-2016/]
CONSENSUS 2015
Consensus 2015, CoinDesk's inaugural summit on digital currencies and blockchain tech brought together more than 600 professionals from the tech, finance, and investment sectors – organizations such as Citi, PayPal, Wells Fargo, IBM and more. Experts, innovators, and executives across multiple sectors convened to explore the digital currency economy in-depth.
[http://www.coindesk.com/events/consensus-2016/]
name::
* McsEngl.bcnnet'tool@cptIt,
name::
* McsEngl.Scatter@cptIt,
_DESCRIPTION:
Scatter is a blockchain signature provider as well as an identity and single-sign-on system. It currently supports both Ethereum and EOS, with more blockchain support already underway.
[https://medium.com/getscatter/the-blockchain-isnt-just-for-web-applications-silly-rabbit-926a4ea5ccd1]
name::
* McsEngl.bcnnet'Resource (bcnrsc)@cptIt,
* McsEngl.bcnnet'resource@cptIt,
* McsEngl.bcnrsc@cptIt,
* McsEngl.blockchain-resource@cptIt,
_ADDRESS.WPG:
* {2016-07-27} https://blog.ethereum.org/2016/07/27/inflation-transaction-fees-cryptocurrency-monetary-policy// Vitalik Buterin,
* {2016-06-22} http://cointelegraph.com/news/bitcoin-is-potential-national-threat-says-us-regulator,
* http://www.ibm.com/blockchain/what_is_blockchain.html,
* http://www.wsj.com/articles/bitcoins-blockchain-technology-proves-itself-in-wall-street-test-1460021421,
* {2016-03-04} Jeff John Roberts: The Crisis in Bitcoin and the Rise of Blockchain
http://fortune.com/2016/03/04/crisis-in-bitcoin-rise-of-blockchain//
* https://www.weforum.org/agenda/2016/03/could-blockchain-technology-make-big-banks-a-thing-of-the-past/?utm_content=buffer804cf&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer/
* https://www.weforum.org/agenda/2016/03/could-blockchain-technology-help-the-worlds-poor,
* http://recode.net/2015/07/05/forget-bitcoin-what-is-the-blockchain-and-why-should-you-care//
* http://edcab.eu/read/about,
* http://nakamotoinstitute.org/about//
name::
* McsEngl.bcnrsc.BOOK@cptIt,
Blockchain Revolution: How the Technology Behind Bitcoin Is Changing Money, Business and the World Paperback – 26 May 2016
[https://www.amazon.co.uk/Blockchain-Revolution-Technology-Changing-Business/dp/0241237858/]
"Mastering Bitcoin". Andreas M. Adonopoulos.
- https://www.bitcoinbook.info//
- https://github.com/bitcoinbook/bitcoinbook,
name::
* McsEngl.bcnnet'whole.DAO (bcndao)@cptIt,
* McsEngl.bcndao@cptIt,
* McsEngl.blockchain-Decentralized-Autonomous-Organization@cptIt,
* McsEngl.blockchain-DAO@cptIt,
_DESCRIPTION:
IF a-bcnnet incorporates (= buildin) a-decentralized-governing-system
THEN it is-becoming a-DAO.
[hmnSngo.2017-03-28]
_DESCRIPTION:
Organization is a-system-of-humans with an-administering-system.
IF it has-no administering-system, it is a-GROUP.
No humans, no group, no organization, no DAO.
A-blockchain-network only if it will add an-administering-system is becoming organization.
Bitcoin, Ethereum networks do-not have such a-system and have a-tendency to split.
BitShares clearly states in its whitepaper that it is a-DAO-company (as it runs for profit).
"BitShares is a decentralized autonomous company, and as such offers products to earn their shareholders a profit.
As we have seen in the previous section, it also offers a way to pay for expense, such as development and administration but earns a profit by burnning (i.e. reducing supply).
Of course, the company can only be profitable if the income exceeds the expenses.
Thus, we will now discuss both in detail". [idBtswpr4]
A-DAO RUNS autonomously.
It evolves with decentralized-decision-making.
[hmnSngo.2017-03-29]
===
The proof-of-work structure that secures and maintains the Bitcoin network is one manner of organizing individuals who do not necessarily trust one another to act in the best interest of all participants of the network.
[http://docs.bitshares.eu/bitshares/whatis.html#consensus-technology]
name::
* McsEngl.bcndao'Resource@cptIt,
_ADDRESS.WPG:
* {2013-09-19} Vitalik Buterin: Bootstrapping A Decentralized Autonomous Corporation: Part I: https://bitcoinmagazine.com/articles/bootstrapping-a-decentralized-autonomous-corporation-part-i-1379644274/
_SPECIFIC:
* Bitshares-DAO,
* BOScoin-DAO,
* DASH-DAO,
* Dfinity-DAO,
* Tezos-DAO,
name::
* McsEngl.bcnnet'DOING@cptIt,
* McsEngl.bcndng@cptIt,
* McsEngl.bcnnet'doing@cptIt,
* McsEngl.blockchain-doing@cptIt,
name::
* McsEngl.bcndng.CREATING@cptIt,
* McsEngl.bcnnet'creating@cptIt,
* McsEngl.bcndng.creating@cptIt,
* McsEngl.blockchain-creating@cptIt,
name::
* McsEngl.bcndng.UPGRATING@cptIt,
* McsEngl.bcndng.upgrating@cptIt,
* McsEngl.bcnnet'protocol-upgrate-mechanism@cptIt,
* McsEngl.bcnnet'upgrating@cptIt,
* McsEngl.blockchain-upgrating@cptIt,
_DESCRIPTION:
One of the important arguments in the blockchain space is that of whether hard forks or soft forks are the preferred protocol upgrade mechanism.
[http://vitalik.ca/general/2017/03/14/forks_and_markets.html]
===
To update means to bring someone or something up to date, whereas to upgrade means to raise or improve something to a higher standard.
_ADDRESS.WPG:
* http://vitalik.ca/general/2017/03/14/forks_and_markets.html,
name::
* McsEngl.bcndng.GOVERNING@cptIt,
* McsEngl.bcnnet'decision-making-process@cptIt,
* McsEngl.bcnnet'governing@cptIt,
* McsEngl.bcnnet'managing@cptIt,
_SPECIFIC:
Bitcoin: Non-systematic
Ethereum: Non-systematic
BOSnet: Democratic Congress (One node=One vote)
name::
* McsEngl.bcndng.FUNDING@cptIt,
* McsEngl.bcndng.funding@cptIt,
* McsEngl.blockchain-funding@cptIt,
name::
* McsEngl.bcndng.SERVICE (bcnsvc)@cptIt,
* McsEngl.bcnnet'adoption@cptIt,
* McsEngl.bcnnet'application@cptIt,
* McsEngl.bcnnet'service@cptIt,
* McsEngl.bcnnet'usage@cptIt,
* McsEngl.bcnsvc@cptIt,
* McsEngl.blockchain-service@cptIt,
_DESCRIPTION:
Although currency transactions are the most common applications of the blockchain technology, some groups are also attempting to transfer other digital assets, such as financial products and services, logistics information, property ownership, identity etc.
[https://www.boscoin.io/wordpress/wp-content/themes/boscoin/src/pdf/boscoinwhitepaperv20170202.pdf]
===
The-service of a-blockchain-network and the-service of its consensus-money is the-same.
[hmnSngo.2017-02-04]
name::
* McsEngl.bcnsvc'Resource@cptIt,
_ADDRESS.WPG:
* http://www.blockchaintechnologies.com/blockchain-applications,
* {2016-12-13} Beyond bitcoin: 4 surprising uses for blockchain: https://www.weforum.org/agenda/2016/12/fighting-human-trafficking-tracing-blood-diamonds-and-other-surprising-uses-for-blockchain??
* https://news.bitcoin.com/ecb-plans-blockchain-e-governance//
* {2016-11-28} 5 Blockchain Applications That Are Shaping Your Future: http://www.huffingtonpost.com/ameer-rosic-/5-blockchain-applications_b_13279010.html,
* {2016-04-27} ECB Reveals Plans for Blockchain E-Governance http://cointelegraph.com/news/from-microsoft-to-nasdaq-blockchain-is-gaining-unprecedented-traction,
* {2016-04-10} Match & Teach Me: Blockchain, Psychometrics To Help Teach Refugees: http://cointelegraph.com/news/match-teach-me-blockchain-psychometrics-to-help-teach-refugees,
* {2016-04-09} Blockchain: Overhyped or Underexplored, It Will Be Deployed At Scale: http://cointelegraph.com/news/blockchain-overhyped-or-underexplored-it-will-be-deployed-at-scale,
* {2016-04-08} Filipino Breach: How Blockchain Can Bring Privacy Revolution To Masses: http://cointelegraph.com/news/filipino-breach-how-blockchain-can-bring-privacy-revolution-to-masses,
* {2016-04-06} Blockchain Goes On A Brand Protection Mission, Fights Counterfeiting: http://cointelegraph.com/news/blockchain-goes-on-a-brand-protection-mission-fights-counterfeiting,
* {2016-03-16} Response to Marcella Atzori: can the blockchain provide governance? https://bitnation.co/blog/response-marcella-atzori-can-blockchain-provide-governance//
* {2016-01-08} The Top 10 Blockchain Startups to Watch in 2016: https://medium.com/the-intrepid-review/the-top-10-blockchain-startups-to-watch-in-2016-the-leaders-who-are-changing-the-game-6195606b0d70#.1wzcae4ki,
name::
* McsEngl.bcnsvc.specific@cptIt,
* McsEngl.bcnsvc.specific@cptIt,
_SPECIFIC:
* Academic-degree-service,
* Administering-decentralized,
* Asset-exchange,
* Banking-sector,
* Birth-certificate-service,
* Charity-service,
* Crownd-funding,
* Energy-sector,
* Exchange-value-service,
* Financial-sector,
* Healthcare-sector,
* Identification-service,
* Info-tech-sector,
* Land-registry#ql:idBcnsvcLdr#,
* Legal-sector,
* Manufacturing-sector,
* Marketplace,
* Money-transfer,
* Music-service,
* Program-service,
* Proof-of-existance,
* Smart-contract-service,
* Trade-sector,
* Transportation-sector,
* Voting,
* Wedding-certificate-service,
* Will-service,
name::
* McsEngl.bcnsvc.SPECIFIC-DIVISION.info-stored@cptIt,
_DESCRIPTION:
Blockchain stores timestamped and unchanged information with many applications.
_SPECIFIC:
* academic-degree-service,
* birth-certificate-service,
* charity-service,
* exchange-value-service,
* land-info-service,
* music-service,
* program-service,
* voting-service,
* wedding-certificate-service,
* will-service,
name::
* McsEngl.bcnsvc.SPECIFIC-DIVISION.sector@cptIt,
* McsEngl.bcnnet'industry@cptIt,
* McsEngl.bcnnet'sector@cptIt,
* McsEngl.bcnsvc.sector-division@cptIt,
_ADDRESS.WPG:
* {2017-02-07} Banking Is Only The Start: 27 Big Industries Where Blockchain Could Be Used, https://www.cbinsights.com/blog/industries-disrupted-blockchain//
_SPECIFIC:
* Banking-sector,
* Energy-sector,
* Financial-sector,
* Healthcare-sector,
* Info-tech-sector,
* Legal-sector,
* Manufacturing-sector,
* Music-sector,
* Trade-sector,
* Transportation-sector,
==
name::
* McsEngl.bcnsvc.sector.FINANCIAL@cptIt,
* McsEngl.bcnsvc.financial@cptIt,
_DESCRIPTION:
“Bitcoin—or more precisely, the underlying technology that allows it to function, called distributed ledgers, or blockchain—could allow what many see as a radical rewiring of the financial sector.”
[http://cointelegraph.com/news/imf-magazine-examines-present-and-future-of-bitcoin]
_ADDRESS.WPG:
* https://www.bloomberg.com/news/articles/2016-06-06/central-bankers-told-they-should-be-sprinting-toward-blockchain,
* https://www.weforum.org/agenda/2016/05/how-blockchain-could-shake-up-stock-markets//
name::
* McsEngl.bcnsvc.BANKING@cptIt,
_ADDRESS.WPG:
* Humaniq is a simple and secure 4th generation mobile bank. We are developing a completely new banking experience by dissolving all the barriers of archaic banks such as the need to come to a branch, doing endless paperwork, dealing with hard-to-use, buggy mobile apps, and protecting data with hard-to-remember, complex passwords.We have created a safe, strong financial tool, specifically designed to be used by people who are undereducated or who don’t possess identification. Most of them live in emerging economies on less than two dollars a day. We believe we can change that. Learn more about Humaniq…
https://humaniq.co//
name::
* McsEngl.exchange.Gold@cptIt,
* McsEngl.bcnsvc.gold-exchange@cptIt,
name::
* McsEngl.bcnsvc.money@cptIt,
_ADDRESS.WPG:
* http://dcebrief.com/tunisia-becomes-first-nation-to-put-nations-currency-on-a-blockchain// {2015-12-28}
* https://cointelegraph.com/news/ukraine-to-become-next-country-to-go-cashless-plans-national-digital-currency,
name::
* McsEngl.Neufund-ogn@cptIt,
_DESCRIPTION:
Neufund is building a blockchain-based and investor-directed platform which bridges the world of cryptocurrency and equity. The fund unlocks the resources of cryptocurrency and blockchain to fund startups and all forms of technological innovation and disruption.
[http://neufund.org/]
name::
* McsEngl.bcnsvc.sector.RECRUITMENT@cptIt,
* McsEngl.bcnsvc.recruitment@cptIt,
_ADDRESS.WPG:
* https://chronobank.io// ChronoBank.io is an ambitious and wide-ranging blockchain project, aimed at disrupting the HR/recruitment/finance industries in a similar way to how Uber disrupted the taxi business and how Upwork represented an evolution in freelancing.
name::
* McsEngl.bcnsvc.sector.TRADE@cptIt,
* McsEngl.bcnsvc.trade@cptIt,
_ADDRESS.WPG:
* https://cointelegraph.com/news/wells-fargo-and-australian-bank-begin-sending-physical-products-via-blockchain,
name::
* McsEngl.bcnsvc.FREIGHT@cptIt,
* McsEngl.bcnsvc.handover@cptIt,
_ADDRESS.WPG:
* https://cointelegraph.com/news/ibm-maersk-to-deliver-first-blockchain-project-by-end-of-2017,
name::
* McsEngl.bcnsvc.Invoice-managing@cptIt,
_DESCRIPTION:
The government in Singapore has turned to Blockchain developing a system to prevent invoice fraud cases.
[https://cointelegraph.com/news/power-to-the-people-blockchain-replaces-government-in-europe]
name::
* McsEngl.bcnsvc.Provenance-project@cptIt,
* McsEngl.provenance-ogn@cptIt,
_DESCRIPTION:
Project Provenance began with a frustration for how little we know about the things we buy
We are now a growing collective with backgrounds in software design, product manufacturing and data science. Our base is in London, but our mission is global. Our common goal is to deliver meaningful change to commerce through open and accessible information about products and supply chains.
[https://www.provenance.org/about]
_ADDRESS.WPG:
* The woman whose mum inspired her to track ethical food
By Matthew Wheeler
Business reporter
13 February 2017
- http://www.bbc.com/news/business-38773878,
name::
* McsEngl.bcnsvc.sector.ENERGY@cptIt,
* McsEngl.bcnsvc.energy@cptIt,
_ADDRESS.WPG:
* http://www.greentechmedia.com/articles/read/the-energy-blockchain-could-bitcoin-be-a-catalyst-for-the-distributed-grid?
name::
* McsEngl.bcnsvc.sector.LEGAL@cptIt,
* McsEngl.bcnsvc.legal@cptIt,
_ADDRESS.WPG:
* {2016-10-14} Argentina-Based Notarization Platform Launches Public Beta, Brings Bitcoin to Legal Industry: https://cointelegraph.com/news/argentina-based-notarization-platform-launches-public-beta-brings-bitcoin-to-legal-industry,
name::
* McsEngl.bcnsvc.sector.MANUFACTURING@cptIt,
* McsEngl.bcnsvc.manufacturing@cptIt,
_ADDRESS.WPG:
* {2016-06-08} http://cointelegraph.com/news/blockchain-watch-manufactures-start-using-blockchain-to-confirm-authenticity-of-luxury-goods,
- Upon the sale or transfer of assets, the original owner performs a simple operation on the blockchain to automatically transfer their right to ownership to the new owner.
name::
* McsEngl.bcnsvc.sector.MUSIC@cptIt,
* McsEngl.bcnsvc.music@cptIt,
_ADDRESS.WPG:
* http://www.ibtimes.co.uk/pink-floyd-blockchain-technology-music-could-be-truly-revolutionary-1569649,
name::
* McsEngl.bcnsvc.sector.TECH.INFO@cptIt,
_ADDRESS:
* https://sonm.io// SONM is a decentralized worldwide fog supercomputer for general purpose computing from site hosting to scientific calculations.
The purpose of SONM project is to replace traditional Proof-of-Work cryptocurrency mining prevalent in the blockchain community at the moment.
name::
* McsEngl.bcnsvc.cloud-computing@cptIt,
_ADDRESS.WPG:
* BLOCKCHAIN-BASED DISTRIBUTED CLOUD COMPUTING: http://iex.ec//
name::
* McsEngl.bcnsvc.cloud-storage@cptIt,
* McsEngl.sector.storage-bcnnet@cptIt,
_ADDRESS.WPG:
* https://cointelegraph.com/news/sia-v103-comes-out-aims-at-revolution-in-blockchain-cloud-storage,
* http://cointelegraph.com/news/cloud-storage-meets-bitcoin-blockchain-siacoin-takes-on-amazon-google-microsoft,
* https://sia.tech//
name::
* McsEngl.bcnsvc.content-providing@cptIt,
_ADDRESS.WPG:
* https://cointelegraph.com/news/how-to-monetize-content-using-blockchain-platforms,
name::
* McsEngl.bcnsvc.BLOCKCHAIN-SERVICE-PROVIDING@cptIt,
_ADDRESS.WPG:
* http://cointelegraph.com/news/emercoin-blockchain-engine-becomes-first-blockchain-solution-available-on-microsoft-azure-marketplace,
Emercoin joined the Microsoft Azure program in January 2016, becoming one of the first partners and blockchain implementing service providers. On this day, the Emercoin Blockchain Engine has become the first Microsoft Azure Market application to provide blockchain services to end users around the world.
name::
* McsEngl.bcnsvc.GOVERNANCE@cptIt,
_DESCRIPTION:
Blockchain technology and dApps have the ability to decentralize power from existing authorities in business, law, and technology to a broad set of stakeholders.
This shift will disrupt current business, economic and social paradigms.
Transaction costs and barriers to entry in various industries will be reduced in these industries.
The result will likely be an increase in economic exchange and prosperity.
[https://consensys.net/vision/]
name::
* McsEngl.bcnsvc.GOVERNANCE.SOCIETY@cptIt,
* McsEngl.bcnsvc.governance@cptIt,
* McsEngl.government-services-on-blockchain@cptIt,
* McsEngl.bcnsvc.Public-sector@cptIt,
* McsEngl.bcnsvc.sector.Public@cptIt,
* McsEngl.public-services-on-blockchain@cptIt,
_DESCRIPTION:
The need to look beyond the currency and investigate the potential use of the technology in industries outside payments is often emphasized. So should global governments be embracing Blockchain?
Backing e-government platforms with Blockchain can solve a number of issues that arise when dealing with public authorities nowadays. Citizens feel so disconnected from their governments and think the general level of state bureaucracy is unbelievable. Therefore, digitization of state services in general and especially the integration of Blockchain in this sphere is an interesting process to follow.
[https://cointelegraph.com/news/power-to-the-people-blockchain-replaces-government-in-europe]
_ADDRESS.WPG:
* http://www.borderless.tech//
name::
* McsEngl.bcnsvc.Land-registry@cptIt,
* McsEngl.bcnsvc.land-registry@cptIt,
* McsEngl.bcnsvc.real-estate-transaction@cptIt,
* McsEngl.blockchain.land-registry@cptIt,
_DESCRIPTION:
Ghana has been playing around with Blockchain to apply it in land registry with 28 communities involved in the project to enable tamper-resistant property ownership.
[https://cointelegraph.com/news/power-to-the-people-blockchain-replaces-government-in-europe]
===
For instance, Sweden is working to back real estate transactions with Blockchain technology, enabling all parties involved to easily track the progress of agreements.
[https://cointelegraph.com/news/power-to-the-people-blockchain-replaces-government-in-europe]
_ADDRESS.WPG:
* {time.2017-04-04} https://cointelegraph.com/news/blockchain-land-registry-trial-in-sweden-concludes-second-phase,
name::
* McsEngl.bcnsvc.Social-security@cptIt,
* McsEngl.bcnsvc.social-security@cptIt,
_ADDRESS.WPG:
* China recently announced that they would put their entire social security system on a Blockchain.
[https://cointelegraph.com/news/ukraine-to-become-next-country-to-go-cashless-plans-national-digital-currency 2016-11-13]
name::
* McsEngl.bcnsvc.Voting@cptIt,
* McsEngl.bcnsvc.voting@cptIt,
* McsEngl.blockchain-voting@cptIt,
* McsEngl.voting.blockchain@cptIt,
_ADDRESS.WPG:
* {2017.04-06} https://cointelegraph.com/news/blockchain-voting-may-lead-to-liquid-democracy-globally-in-20-years,
* {2016-06-30} https://cointelegraph.com/news/australia-to-make-blockchain-voting-app-a-global-democratic-movement,
While Russia is testing an e-proxy voting system based on a distributed ledger, Australia is launching a Blockchain voting app in hopes of starting a global political movement.
The Flux Party is a new Australian political party that aims to return power over important decisions made in Parliament to individual electors.
* http://cointelegraph.com/news/russia-tests-blockchain-voting-plans-to-launch-it-in-2017, National Settlement Depository, Russia’s central securities depository, has successfully tested an e-proxy voting system based on a distributed ledger (blockchain) technology.
* {2016} http://www.europarl.europa.eu/RegData/etudes/ATAG/2016/581918/EPRS_ATA(2016)581918_EN.pdf, European Parliament Research Service.
name::
* McsEngl.bcnsvc.Welfare-benefit@cptIt,
_DESCRIPTION:
The UK has been exploring the use of Blockchain to manage and monitor the distribution of welfare benefits.
[https://cointelegraph.com/news/power-to-the-people-blockchain-replaces-government-in-europe]
name::
* McsEngl.bcnsvc.ECONOMY@cptIt,
* McsEngl.bcnsvc.decentralized@cptIt,
* McsEngl.blockchain-decentralized-economy@cptIt,
_ADDRESS.WPG:
* {2017-03-30} How Amir Taaki Tried to Build Bitcoin Economy in Syria While Fighting ISIS: https://cointelegraph.com/news/how-amir-taaki-tried-to-build-bitcoin-economy-in-syria-while-fighting-isis,
name::
* McsEngl.bcnsvc.IDENTIFICATION@cptIt,
* McsEngl.bcnsvc.identification@cptIt,
* McsEngl.bcnsvc.ID@cptIt,
_ADDRESS.WPG:
* https://uport.me/#home, Your universal digital passport
Simple, secure, self-sovereign identity on Ethereum
Self-sovereign identity puts you 100% in control of your identity and data
* https://shocard.com/how-it-works//
name::
* McsEngl.bcnsvc.COORDINATION.GLOBAL@cptIt,
* McsEngl.bcnsvc.coordination.global@cptIt,
* McsEngl.bcnsvc.global-coordination@cptIt,
_ADDRESS.WPG:
* http://www.telegraph.co.uk/business/2016/06/20/skype-inventor-jaan-tallinn-wants-to-use-bitcoin-technology-to-s//
name::
* McsEngl.bcnsvc.FERMAT-FRAMEWORK@cptIt,
_DESCRIPTION:
Fermat is a Decentralized, Blockchain enabled, Modular App Platform that unleashes the P2P “Internet of People” Economy.
Fermat seeks to deliver the better world, initially promised by Bitcoin. Through a decentralized app framework that incentivizes collaborative development, shared ownership and hyper-customization of modular software, the Project aims to unshackle free markets, by removing intermediaries from their current levels of influence, and to earn widespread mainstream adoption.
Fermat’s central premise is that there is a path to software development that is smarter, better and more efficient than the status quo. The Fermat framework allows anyone from anywhere to collaborate and mutually profit from shared ownership of modular applications: it enables an open-ended stream of micropayments to authors of reusable software components that can be perpetually combined and recombined across an ever-expanding library of useful, highly-customizable, peer-to-peer commercial applications (apps).
The blockchain-enabled system is built to be user-controlled, censorship-resistant and flexible – a platform for person-to-person exchange of goods, service, assets and data, free from the whims, risks, costs and interference of unwanted, self-interested third parties who put their priorities ahead of those of the people directly involved in the exchange.
Our roadmap to a better world starts from the view of mass adoption. Our first step is to envision a future where cryptocurrency is mass-adopted; fiat currencies are already completely digitized; and people have the freedom to choose which electronic currency to use, where to store them and how and when to exchange that purchasing power.
In this future people manage multiple online identities, using the one that best fits their current needs in each situation. They transact with whatever privacy level they choose. They not only have money on their devices, but a whole suite of software that can use their digital money to enable and sustain all kinds of p2p business models. Fermat is making this possible.
I envision a future where humans are more important than legal fictions like companies and corporations and non-objective realities like nations and states.
–LUIS FERNANDO MOLINA
[http://www.fermat.org/fermat-about-us/our-vision/]
_ADDRESS.WPG:
* https://drive.google.com/file/d/0Bzq6JfsbkKrAUFAwWUNyNS12ekU/view?ts=56f6c013,
We welcome your feedback.
You can email us at: white.paper.feedback@fermat.org.
If you’d like to comment on the Google Doc,
please send us the email to which you’d like us to grant comment access.
name::
* McsEngl.bcnsvc.MARKETPLACE@cptIt,
_DESCRIPTION:
MARKETPLACE
The Nxt Marketplace feature allows you to list items for sale and make sales on the blockchain.
You do not need to rely on external market sites to conduct your business. Instead, transactions are done between seller and buyer directly.
[https://nxt.org/what-is-nxt/marketplace/]
name::
* McsEngl.bcnsvc.NOTARIZATION-service@cptIt,
* McsEngl.bcnsvc.notarization@cptIt,
====== lagoGreek:
* McsElln.συμβολαιογραφική-υπηρεσία@cptIt,
_ADDRESS.WPG:
* https://cointelegraph.com/news/argentina-based-notarization-platform-launches-public-beta-brings-bitcoin-to-legal-industry,
name::
* McsEngl.bcnsvc.RECORD-KEEPING@cptIt,
* McsEngl.bcnsvc.record-keeping@cptIt,
_DESCRIPTION:
The opening for a blockchain intern at Disney illustrates that banks and financial institutions are no longer the only companies looking at blockchain solutions.
The blockchain can find applications in any industry where records need to be securely maintained and processed – whether they be land records, medical records or shipping records.
We can expect companies in other industries to follow Disney's lead and start looking at blockchain solutions in the near future.
[http://cointelegraph.com/news/walt-disney-now-loves-blockchain-going-trustless-in-seattle]
_ADDRESS.WPG:
* student-credintials: http://www.cnbc.com/2016/05/09/schools-are-recording-students-results-on-the-blockchain.html,
_SPECIFIC:
* Academic-degrees,
* intellectual-property#ql:idBcnsvcIpt#,
* land-registry#ql:idBcnsvcLdr#,
* medical-records-registry,
* shipping-registry,
* strudents-credentials,
* wedding-agreement,
name::
* McsEngl.bcnsvc.INTELLECTUAL-PROPERTY@cptIt,
* McsEngl.bcnsvc.intellectual-property@cptIt,
_ADDRESS.WPG:
* https://cointelegraph.com/news/blockai-uses-bitcoin-blockchain-to-protect-intellectual-property, blockai.com,
name::
* McsEngl.bcnsvc.WEDDING-AGREEMENT@cptIt,
* McsEngl.bcnsvc.wedding-agreement@cptIt,
{time.2014}:
This isn't the first connection that Disney has with the blockchain.
Way back in 2014, the first blockchain wedding took place at Disneyland, Florida.
David Mondrus and Joyce Bayo registered their wedding agreement on the blockchain, eliminating the role of both religious and government officials.
[http://cointelegraph.com/news/walt-disney-now-loves-blockchain-going-trustless-in-seattle]
name::
* McsEngl.bcnsvc.Blockstack (bsksvc)@cptIt,
* McsEngl.bcnbsk@cptIt,
* McsEngl.blockstack-platform@cptIt,
* McsEngl.bsksvc@cptIt,
_DESCRIPTION:
Blockstack is a new internet for decentralized, server-less applications.
Building on Blockstack starts with single-page applications built in Javascript that are downloaded onto user devices.
Developers plug into blockstack.js, which provides API’s for authenticating the user, grabbing application data from the user, and storing new application data with the user (encrypted and backed up to cloud storage).
The blockchain is utilized to maintain a cross-application identity system, securely mapping user IDs to usernames, public keys, and data storage URIs.
Developers don’t have to worry about running servers, maintaining databases, or building out user management systems, and decentralized, server-less applications can be built more simply than their traditional counterparts.
[https://blockstack.org/about]
name::
* McsEngl.blockstack'ID@cptIt,
_ADDRESS.WPG:
* https://docs.blockstack.org/browser/ids-introduction.html,
name::
* McsEngl.blockstack'browser@cptIt,
_DESCRIPTION:
The Blockstack Browser is itself a DApp. Logging in confirms you have a valid ID with the required secret recovery key or magic recovery code. The secret recovery key is a 12 or 24 word phrase you recorded when you created the ID. The magic recovery code is a string of characters Blockstack emailed to you when you created your identity. You can confirm your identity with either.
[https://docs.blockstack.org/develop/zero_to_dapp_3.html#confirm-or-get-a-blockstack-id]
name::
* McsEngl.blockstack'Gaia@cptIt,
_DESCRIPTION:
The Gaia data storage hub (https://hub.blockstack.org/).
The storage hub is purely a service without user-facing functionality.
[https://docs.blockstack.org/develop/zero_to_dapp_3.html#overview-of-the-animal-kingdom-dapp]
name::
* McsEngl.blockstack'blockstack.js@cptIt,
_DESCRIPTION:
The Blockstack Javascript library is all a developer needs to create a DApp. It grants the application the ability to authenticate a Blockstack identity and to read and write to the user’s data stored in a Gaia hub.
[https://docs.blockstack.org/develop/zero_to_dapp_3.html#understand-the-application-code]
_ADDRESS.WPG:
* https://blockstack.github.io/blockstack.js/,
name::
* McsEngl.blockstack'Dapp@cptIt,
_DESCRIPTION:
To participate in application mining your application must integrate Blockstack authentication.
[https://docs.blockstack.org/develop/zero_to_dapp_3.html#authenticating-user-identity]
name::
* McsEngl.blockstack'resource@cptIt,
_ADDRESS.WPG:
* {2018-10-22} he Launch of the Stacks Genesis Block, https://blog.blockstack.org/the-launch-of-the-stacks-genesis-block/,
* {2017-03-14} https://cointelegraph.com/news/blockstack-launches-third-ever-blockchain-product-on-amazon-marketplace,
name::
* McsEngl.bcnnet.specific@cptIt,
* McsEngl.bcnnet.specific@cptIt,
* McsEngl.bcnnetSpc@cptIt,
_SPECIFIC:
* aeternity-network##
* akasha-network#ql:akasha_network_cpt#
* bitcoin-network#ql:netbtc_cpt#
* blockchain-curency-network#ql:netcbc#
* ethereum-network#ql:ethereum_network#
* gnosis-network##
* lisk-network##
* Ripple-network#ql:ripple_distributed_network@cptIt51.11#
* synereo#ql:synereo_network_cpt#
_SPECIFIC:
Thus, in general, there are two approaches toward building a consensus protocol: building an independent network, and building a protocol on top of Bitcoin
[https://github.com/ethereum/wiki/wiki/White-Paper#alternative-blockchain-applications]
name::
* McsEngl.bcnnet.SPECIFIC-DIVISION.builtin-governance@cptIt,
SPECIFIC:
* builtin-goverance#ql:idBcnnetBig#,
* builtinNo-goverance,
name::
* McsEngl.bcnnet.BUILTIN-GOVERNANCE@cptIt,
* McsEngl.bcnnetBig@cptIt,
* McsEngl.bcnnet.builtin-governance@cptIt,
* McsEngl.blockchain-network-with-builtin-decentralized-governance@cptIt,
_DESCRIPTION:
Blockchain-network with builtin project decentralized governance.
Not centralized governance.
Not governance only written in a-smart-contract-program.
Decentralized governance of the-people of the-project.
[hmnSngo.2017-04-04]
_SPECIDIC:
* Decred-network {2016}#ql:idDcrnet#,
* BitShares-network {2015}#ql:idBtsnet#,
* Dash-network {2014}#ql:idDashnet#,
* BOScoin-network#ql:idBosnet#,
* Dfinity-network#ql:idDfnnet#
name::
* McsEngl.bcnnet.SPECIFIC-DIVISION.consensus-algorithm@cptIt,
_SPECIFIC:
* proof-of-stake-bcnnet,
* proof-of-work-bcnnet,
* hybrid-stake-work-bcnnet,
name::
* McsEngl.bcnnet.SPECIFIC-DIVISION.blockchain@cptIt,
_SPECIFIC:
* dependent-bcnnet#ql:idBcnnetDpt#,
* dependentNo-bcnnet#ql:idBcnnetDptNo#
name::
* McsEngl.bcnnet.SPECIFIC-DIVISION.time-of-genesis@cptIt,
name::
* McsEngl.bcnnet.SPECIFIC-DIVISION.user@cptIt,
_SPECIFIC:
* public-bcnnet#ql:idBcnnetPbc#,
* publicNo-bcnnet#ql:idBcnnetPbcN#
name::
* McsEngl.bcnnet.SPECIFIC-DIVISION.service@cptIt,
_SPECIFIC:
* app-service#ql:idBcnnetPgm#,
* government-service,
* exval-token-service#ql:idEvtnet#,
* record-keeping-service,
name::
* McsEngl.bcnnet.SPECIFIC-DIVISION.evoluting@cptIt,
_SPECIFIC:
* announcement-stage|phase,
* ico-stage,
* planning-stage,
* development-stage,
* experimental-stage,
* testing-stage,
* working|production-stage,
* working.stableNo-stage,
* working.stable-stage,
* working.mature-stage,
===
* conceptual-stage,
* development-stage,
* production-stage,
name::
* McsEngl.bcnnet.blockchain.DEPENDENT (bcnnetDpt)@cptIt,
* McsEngl.bcnnet.dependent@cptIt,
* McsEngl.bcnnetDpt@cptIt,
_DESCRIPTION:
Dependent-bcnnet is a-bcnnet#ql:idMcsBcnnet# that does-NOT-operate autonomously.
It works as another layer on another bcnnet.
[hmnSngo.2017-03-27]
_SPECIFIC:
* Humaniq#ql:idHmqnet#, (Ethereum)
* Omni_layer#ql:idBcnomnl#, (Bitcoin)
name::
* McsEngl.bcnnetDpt.Omni-layer@cptIt,
* McsEngl.Omni-layer@cptIt,
_DESCRIPTION:
Omni is a platform for creating and trading custom digital assets and currencies.
It is a software layer built on top of the most popular, most audited, most secure blockchain -- Bitcoin.
Omni transactions are Bitcoin transactions that enable next-generation features on the Bitcoin Blockchain.
Our reference implementation, Omni Core is an enhanced Bitcoin Core that provides all the features of Bitcoin as well as advanced Omni Layer features.
[http://www.omnilayer.org/]
name::
* McsEngl.bcnnetDpt.Raiden-network (rdnnet)@cptIt,
* McsEngl.raiden-network@cptIt,
* McsEngl.rdnnet@cptIt,
_DESCRIPTION:
Raiden Network
High speed asset transfers for Ethereum
Payment-Channel Network for Ethereum
Raiden is a technology that leverages off-chain state networks to extend Ethereum with some nice properties for asset transfers:
Scalable: it scales linearly with the number of participants (1,000,000+ transfers per second possible)
Fast: Transfers are confirmed and final within the fraction of a second
Confidential: Single transfers don’t show up in the global shared ledger
Interoperable: Works with any token that follows Ethereum’s standardized token API
Low Fees: Transaction fees can be 7 orders of magnitude lower than on the blockchain
Micro-payments: Low transaction fees allow to efficiently transfer tiny values
Technology
The technology enabling this is similar to the proposed Bitcoin Lightning Network.
The basic idea is to switch from a model where all transactions hit the shared ledger on the blockchain (which is the bottleneck) to a model where users can privately exchange messages which sign the transfer of value.
Raiden uses a network of p2p payment channels and deposits in Ethereum to preserve the guarantees expected from a blockchain system.
Raiden is implemented as an extension to Ethereum. A Raiden node runs alongside an Ethereum node and communicates with other Raiden nodes to facilitate transfers and with the Ethereum blockchain to manage deposits. It offers a simple API which makes it easy to use Raiden in DApps.
Applications
Micropayments for content distribution: Alternative to Paywalls, Ads and Subscriptions. (Figure a decentralized youtube where the creators of a video are paid for every second watched)
Decentralized M2M markets: especially in IoT where tiny chunks of bandwidth, storage, cpu time, energy, sensor data, etc. can be traded.
Frictionless Token Systems: Game Tokens, Reward Tokens, Private Currencies
API Access: Accessing and monetizing APIs on a per use basis is at the core of the upcoming Machine-to-Machine economy
Fast Decentralized Exchanges
Complementary to Ethereum
Vitalik Buterin: “State channels are an important technology that has the potential to greatly improve the scalability and privacy of many categories of blockchain applications; in conjunction with sharding and other privacy-preserving cryptographic technologies, they are an important ingredient in helping decentralized systems to achieve the properties that mainstream individual and institutional users expect and deserve.”
Links
Coindesk feature on Raiden: “Will Ethereum Beat Bitcoin to Mainstream Microtransactions?”
Robert McCone’s blogpost about a lightning style network on Ethereum
Oktahedron Podcast with Augusto from the core team, explaining the Raiden Network
Raiden Network IoT Demo - Enabling High Speed Asset Transfers
Development
The Raiden Network is currently under development. Release of an MVP is planned for the end of March 2017. See our GitHub repository and read our latest blog post on development progress for the latest updates.
[http://raiden.network/]
name::
* McsEngl.bcnnetDpt.SIDECHAIN@cptIt,
* McsEngl.sidechain@cptIt,
name::
* McsEngl.scnet'Resource@cptIt,
_ADDRESS.WPG:
* {2014-10-26} https://gendal.me/2014/10/26/a-simple-explanation-of-bitcoin-sidechains//
* {2014-10-22} https://blockstream.com/sidechains.pdf,
name::
* McsEngl.bcnnet.blockchain.DEPENDENT.NO@cptIt,
* McsEngl.bcnnet.independent@cptIt,
_DESCRIPTION:
A-blockchain-network with an-independent blockchain.
name::
* McsEngl.bcnnet.service.PROGRAM@cptIt,
* McsEngl.bcnnetPgm@cptIt,
* McsEngl.bcnnet.application@cptIt,
* McsEngl.bcnnet.program@cptIt,
_SPECIFIC:
* BOScoin-network#ql:idBosnet#,
* Dfinity-network#ql:idDfnnet#,
* Ethereum-network#ql:idEthnet#,
* Qtem-network#ql:idQtmnet#,
* Tezos-network#ql:idTzsnet#
name::
* McsEngl.bcnnet.service.EXCHANGE-VALUE-TOKEN (evtnet)@cptIt,
* McsEngl.evtnet@cptIt, {2017-04-14}
* McsEngl.exchange-value-token-bcnnet@cptIt, {2017-04-14}
* McsEngl.bcnnetEvtkn@cptIt, {2017-03-31}
* McsEngl.bcnnet.currency-application@cptIt,
* McsEngl.bcnnet.money@cptIt,
* McsEngl.bcnnet.value-transfer@cptIt,
* McsEngl.bcnnetMny@cptIt,
* McsEngl.money-bcnnet@cptIt,
* McsEngl.net.blockchain.currency@cptIt,
* McsEngl.net.currency.blockcain@cptIt,
* McsEngl.satoshi-based-blockchain@cptIt,
* McsEngl.stmIthMny.currency.crypto@cptIt,
* McsEngl.stmIthMny.currency.cryptocurrency@cptIt,
* McsEngl.cryptocurrency-network@cptIt51.12,
* McsEngl.cryptocurrency-platform@cptIt51.12,
* McsEngl.netBcnMny@cptIt,
* McsEngl.netCbc@cptIt,
* McsEngl.netCcc@cptIt, {2016-04-03}
* McsEngl.sihCcc@cptIt,
* McsEngl.sihCrypto@cptIt51.12,
* McsEngl.stmIthCrypto@cptIt,
_DESCRIPTION:
Exchange-value-token-blockchain-networks were the first networks#ql:idMcsBcnnet# created, when Satoshi#ql:idBtchmnSnt# solved the-double-spending-problem without a central authority.
[hmnSngo.2017-03-31]
_GENERIC:
* blockchain-network#ql:idMcsBcnnet#,
* distributed-stmIthMny#cptItsoft98.13#
name::
* McsEngl.evtnet'Protocol@cptIt,
name::
* McsEngl.evtprl'Implementation-language@cptIt,
_DESCRIPTION:
Nxt was built from scratch in Java – one of the most popular programming languages for developers and users alike, and one ideally suited to the needs of the web. Most other cryptocurrencies are written in C++ (including Bitcoin and its immediate derivatives), which has a smaller base of developers. Java is cross-platform, meaning that it can be run on any operating system without modification. It’s also used on 3 billion phones and mobile devices worldwide.
The widespread use of Java and the open source nature of Nxt makes it a universal application that can be used on any mainstream device or operating system and can be maintained by potentially millions of software developers worldwide. The Nxt protocol reflects the values and strengths of the project itself: its development was entirely decentralised, spread across many different countries as its core members came together to create a platform that would not only improve upon the first generation of cryptocurrencies but add totally new features to position it for a whole new era in the history of the internet.
[http://nxt.org/about/what-is-nxt/]
name::
* McsEngl.evtnet'Blockchain@cptIt,
name::
* McsEngl.evtnet'Consensus-exchange-value-token@cptIt,
name::
* McsEngl.evtnet'Organization@cptIt,
name::
* McsEngl.HolyTransaction@cptIt,
_ADDRESS.WPG:
* https://holytransaction.com/
_DESCRIPTION:
Universal Wallet
Access Bitcoin, Litecoin, Dogecoin, Peercoin, Darkcoin, Blackcoin and Mastercoin with all of its assets from one unified interface. Easy and instantly, right from this website. No software downloads required.
[https://holytransaction.com/]
name::
* McsEngl.evtnet.specific@cptIt,
* McsEngl.evtnet.specific@cptIt,
_SPECIFIC:
* Bitcoin-network#ql:idBtcnet#,
* Decred-network#ql:idDcrnet#
name::
* McsEngl.bcnnet.time.Zcash (ZECnet {2016-10-28})@cptIt,
* McsEngl.zcash-network@cptIt,
* McsEngl.zecnet@cptIt,
_DESCRIPTION:
Internet money
Zcash is the first open, permissionless cryptocurrency that can fully protect the privacy of transactions using zero-knowledge cryptography.
[https://z.cash//]
name::
* McsEngl.zecnet'Blockchain (zecbcn)@cptIt,
name::
* McsEngl.zecnet'Block-explorer (zecber)@cptIt,
_ADDRESS.WPG:
* https://explorer.zcha.in//
* BlockH0 https://explorer.zcha.in/blocks/00040fe8ec8471911baa1db1266ea15dd06b4a8a5c453883c000b031973dce08,
name::
* McsEngl.zecnet'Consensus-evt (ZECcevt)@cptIt,
* McsEngl.mnyZcash@cptIt,
* McsEngl.mnyZEC@cptIt,
* McsEngl.Zcash@cptIt,
* McsEngl.zeccevt@cptIt,
_DESCRIPTION:
Zcash ZEC
Zcash is a totally private decentralized crypto using a new cryptographic algorithm for payments using a zero-knowledge proof of construction, providing safe encryption of a sender, a recipient and an amount sent. Zcash has a view key for users to see and control the content.
[https://changelly.com/supported-currencies]
===
Privacy technology for blockchains
Zcash is the first open, permissionless financial system employing zero-knowledge security.
The Zcash genesis block will launch in 7 days. Zcash is currently in testnet (testnet coins have no value and will never hold monetary value); our engineering roadmap is publicly available here. If anyone says that they will pay you Zcash before October 28, 2016, then there must be some mistake, because Zcash will not exist until then.
WHAT IS ZCASH?
Zcash offers total payment confidentiality, while still maintaining a decentralized network using a public blockchain. Unlike Bitcoin, Zcash transactions automatically hide the sender, recipient, and value of all transactions on the blockchain. Only those with the correct view key can see the contents. Users have complete control and can opt-in to provide others with their view key at their discretion.
Zcash transactions do not depend on the cooperation of other parties.
[https://z.cash/] {2016-10-20}
name::
* McsEngl.zecnet'Resource@cptIt,
_ADDRESS.WPG:
* https://z.cash//
* {2016-10-20} https://cointelegraph.com/news/with-launch-of-zcash-approaching-mining-companies-get-prepared,
name::
* McsEngl.bcnnet.time.Lisk (LSKnet {2016-05-24})@cptIt,
* McsEngl.lisk-network@cptIt,
* McsEngl.lsknet@cptIt,
* McsEngl.netLisk@cptIt,
* McsEngl.netLsk@cptIt,
_DESCRIPTION:
Lisk is a public blockchain platform that provides decentralized blockchain apps.
It was forked from Crypti by Max Kordek and Olivier Beddows in early 2016.
[https://en.wikipedia.org/wiki/Lisk]
name::
* McsEngl.lsknet'Protocol@cptIt,
_ADDRESS.WPG:
* https://github.com/LiskHQ/lisk-wiki/wiki/Technical-Protocol-Reference,
name::
* McsEngl.lsknet'Node@cptIt,
name::
* McsEngl.lsknode.MINER@cptIt,
name::
* McsEngl.lsknodeMnr'Mining@cptIt,
* McsEngl.lskmining@cptIt,
* McsEngl.lskmng@cptIt,
_DESCRIPTION:
Forging
Lisk utilizes an inflationary forging rewards system which creates new LSK for every successful block.
During year 1, the forging rewards are set at 5 LSK per block.
Every 3,000,000 blocks (~1 year) forging rewards are reduced by 1 LSK, ending at 1 LSK per block after 5 years.
The forging rewards will then stay at 1 LSK per block indefinitely.[12]
The Forging Rewards will be equally distributed through all active (top 101) delegates, same as any network fees.
[https://en.wikipedia.org/wiki/Lisk#Forging]
name::
* McsEngl.lsknet'Blockchain@cptIt,
name::
* McsEngl.lskbcn'Block-Explorer (lskbex)@cptIt,
_ADDRESS.WPG:
* https://explorer.lisk.io//
* BlockH1 https://explorer.lisk.io/block/13658550407518916215,
name::
* McsEngl.lsknet'Consensus-evt (LSKcevt {2016})@cptIt,
* McsEngl.lisk-Consensus-Exval-Token@cptIt,
* McsEngl.lskcevt@cptIt,
* McsEngl.lsknet'cevt@cptIt,
* McsEngl.mnyLsk@cptIt,
_DESCRIPTION:
Lisk LSK
Lisk is a new decentralized application platform with its own cryptocurrency.
The platform is based on JavaScript and allows to create and distribute decentralised applications (DApps) and so-called sidechains.
These are custom blockchains integrated into the Lisk’s one.
Lisk uses Delegated-Proof-of-Stake, a highly secured and flexible consensus model, which elects 101 delegates to create blocks.
[https://changelly.com/supported-currencies]
_GENERIC:
* Consensus-exchange-value-token#ql:idBcncevt#
name::
* McsEngl.lskcevt'Exchange-rate@cptIt,
name::
* McsEngl.lsknet'Bapp@cptIt,
_DESCRIPTION:
Bapp (Dapp, Blockchain App, App)
A decentralized application, which is running in a sidechain of Lisk. If you add a bapp to Lisk, an entry will be made on the blockchain. This will "register" it and makes it visible to everyone.
[https://github.com/LiskHQ/lisk-wiki/wiki/Glossary]
name::
* McsEngl.lsknet'Human@cptIt,
Who created Lisk?
Lisk is a more open alternative to Crypti created by former members of the Crypti Foundation, namely Max Kordek and Olivier Beddows.
[https://github.com/LiskHQ/lisk-wiki/wiki/FAQ#who-created-lisk]
name::
* McsEngl.lsknet'Relation-to-ethereum@cptIt,
_DESCRIPTION:
Differences from Ethereum
- Lisk and Ethereum both try to provide a platform for a similar idea: Decentralized Applications (Lisk calls them Blockchain Applications[13])
- Lisk is an all-around Blockchain (Decentralized) Application platform, that allows for endless possibilities on the developers and/or entities end to build and create, while Ethereum is a platform that only allows for Smart Contract based projects to be created, which in the end limits the overall potential of a set-goal that individuals project can reach or obtain.
- Lisk uses DPoS, while Ethereum currently uses PoW (they have stated they plan to switch to PoS eventually).[14]
- Applications language: Lisk uses Javascript, while Ethereum currently uses Solidity.[15]
- Applications location: Lisk uses sidechains, while Ethereum currently stores it on the main chain.[16]
- Error handling: In Lisk, if your application has an issue it will be contained to only your chain, but require a hard fork to fix. In Ethereum, applications are run in a virtual machine on the main chain so any error should just result in the waste of transaction fees, but be contained to the VM (as long as there is no bug in the VM).
- Applications VM: Ethereum applications are run in the Ethereum Virtual Machine (EVM). Lisks does not have a VM, but it is in development.
[https://en.wikipedia.org/wiki/Lisk#Differences_from_Ethereum]
name::
* McsEngl.lsknet'Resource@cptIt,
_ADDRESS.WPG:
* https://lisk.io//
* https://github.com/LiskHQ/lisk-wiki/wiki,
* https://explorer.lisk.io/delegateMonitor,
* https://blog.lisk.io/what-is-lisk-and-what-it-isnt-e7b6b6188211, (Max Kordek)
name::
* McsEngl.lsknet.EVOLUTING@cptIt,
{time.2016-05-24}:
=== mainnet live:
On May 24, 2016, the main network for Lisk went live and it became available for trading on major exchanges.
[https://github.com/LiskHQ/lisk-wiki/wiki]
name::
* McsEngl.bcnnet.time.Waves (WAVnet {2016-04-15})@cptIt,
* McsEngl.bcnnet.waves@cptIt,
* McsEngl.netWav@cptIt,
* McsEngl.waves-network@cptIt,
* McsEngl.wavnet@cptIt,
_DESCRIPTION:
WAVES is a decentralized blockchain platform focusing on custom blockchain tokens operations.
National currencies transfer is maintained on the WAVES blockchain through compliant gateway operators.
Decentralized token exchange facilitates fundraising, crowdfunding, and trading of financial instruments on the blockchain.
Lightweight clients provide an easy installation procedure and a flat learning curve for end users.
[https://wavesplatform.com/whitepaper_v0.pdf]
name::
* McsEngl.wavnet'Protocol (wavprl)@cptIt,
name::
* McsEngl.wavprl'White-paper@cptIt,
_ADDRESS.WPG:
* {2016-04-01} https://blog.wavesplatform.com/waves-whitepaper-164dd6ca6a23#.4b9dzixu9,
WAVES is a decentralized blockchain platform focusing on custom blockchain tokens operations.
National currencies transfer is maintained on the WAVES blockchain through compliant gateway operators.
Decentralized token exchange facilitates fundraising, crowdfunding, and trading of financial instruments on the blockchain.
Lightweight clients provide an easy installation procedure and a flat learning curve for end users.
‘Hypothesis: Every conceivable application of blockchain technology will be tried, but p2p digital cash will remain most used application’.
Ryan X Charles
‘The killer application of blockchain technology is the blockchain itself.’
Common wisdom
Since its inception, blockchain technology has been fraught with controversy over its most natural application -- value transfer using the network token.
Decentralized money is a ground-breaking development, but blockchain technology cannot be reduced to this alone.
Being essentially a distributed database, the blockchain allows for various types of distributed ledger entries, the nature of which depends on their interpretation by the blockchain’s users.
Introducing the blockchain as a foundation for digital cash attracted a great deal of attention to the technology, putting regulators and governments worldwide on high alert in the process.
There is no doubt that Bitcoin will establish itself as a valid monetary system.
But it is also obvious that there should not be too many blockchain tokens in use as money at the present time, since the low liquidity and high volatility this causes prevent the use of emerging blockchains as a secure store of value.
We propose to focus on other uses of blockchain tokens -- those which are often overlooked in favor of the low-level opportunities which blockchain technology might provide, such as smart contracts.
There is very strong untapped potential in a classical colored coins approach, and the WAVES platform is designed to realize this to its fullest extent.
Smart contracts, being a natural development of Bitcoin scripting, are inevitable and will be one of the cornerstones of blockchain technology.
On the other hand, certain features are much easier to implement using other approaches.
Custom tokens operations realized as an attachment to blockchain transactions are very flexible and can be used in a variety of applications, from national currencies transfer over the blockchain to decentralized trading.
A focus on such operations might well complement the approach introduced by Ethereum.[1]
In the following sections we will describe the technical motivation for WAVES platform’s features and illustrate them with use cases.
We intend to determine the most “production-ready” aspects of current blockchain technology and apply them to the real-world problems.
name::
* McsEngl.Custom blockchain tokens and their usage.@cptIt,
name::
* McsEngl.Technical motivation.@cptIt,
Blockchain assets and colored coins approaches emerged around 2013, when several protocols utilizing Bitcoin’s blockchain were implemented. [4] [5] [6]
Besides this, there were several attempts to build custom blockchain tokens platform from scratch, of which the most notable is Nxt. [7]
We develop the approach which Nxt implemented, realizing custom tokens creation and transfer through attachments added to blockchain transactions.
This approach has clear merits, such as the ability to implement new transaction types easily, but from practical point of view it is fraught with the problem of mandatory hard forks -- when adding a new transaction type, network client software has to be updated, since old clients cannot support new transaction types.
WAVES approaches this problem by offering an extensible solution, in which new transaction types are introduced through plug-ins that are not included in the core software module, but are instead installed as an extension on top of it.
Clients that do not have the relevant plug-in installed can still relay these custom transactions.
This approach allows third-party developers to introduce new transaction types, and creates an Appstore-like ecosystem.
Only the most basic transaction types are supported at the core level, including:
- Custom token creation, deletion and transfer
- Decentralized token exchange, realized as a distributed order-matching engine, where Bid and Ask network transactions are matched against each other
- Anonymity features -- anonymous order books are a must for an industry-grade trading platform
It should be noted that WAVES makes a crucial step ahead with decentralized blockchain trading by offering trading of one custom token against another (asset-to-asset trading).
This opens up a whole new range of opportunities, including trading against tokens tied to national currencies, thus replicating traditional trading infrastructures.
name::
* McsEngl.National currencies on the blockchain.@cptIt,
Although using the main network token for value transfer is quite natural, it nevertheless raises several issues. Use of low-liquidity and highly volatile tokens for value transfer has obvious drawbacks for merchants, and creates tension with regulatory bodies. Still, fully decentralized money is viable, which is demonstrated by the slow but steady adoption of Bitcoin as a currency.
However, in order to provide sufficient liquidity and mitigate the volatility that prevents decentralized money usage as a store of value, the overall number of tokens used as currency should be limited (at least in the initial stages of the development of the technology). We strongly advocate using only Bitcoin as a currency for this reason.
Our approach to handling external value transfer tokens and currencies stems from the ‘Multigateway’ approach.[2] In the case of Bitcoin there is a party (or multi-sig parties) that maintains an in-and-out exchange procedure for Bitcoin, swapping it for its corresponding network token. Thus we facilitate Bitcoin transfers using the WAVES blockchain.
This approach is obviously centralized, due to limitations inherent in Bitcoin itself. It is opposed to a “market peg” approach, which relies on providing a dynamic peg though certain market-making procedures. At first sight the market peg approach may seem to be an adequate way of mirroring financial assets on decentralised platform, but with further consideration hidden centralization invariably surfaces.
By explicitly introducing centralization into supporting blockchain national currencies and BTC we are able to open new horizons for existing financial institutions. Their role can be reduced to providing liquidity for their fiat assets and KYC/AML procedures. Maintaining payment infrastructure is fully outsourced to decentralized blockchains.
This approach to providing national currencies on the blockchain was pioneered with the CoinoUSD token on Nxt’s blockchain. It is also similar to Ripple’s gateways approach. We believe that such a strategy can compete with the emerging permissioned blockchains approach and attract financial institutions willing to work on open blockchains.
name::
* McsEngl.Crowdfunding; decentralized financial instruments and beyond.@cptIt,
We believe that blockchains are an effective means for managing most aspects of community-based projects, from financial to organizational elements. Blockchain technology, due to its innate latency, cannot support high-frequency trading. Most probably centralized solutions will always be preferable for high-volume transactions with milliseconds execution times. But for applications in which instant transactions are not required, blockchains provide a very natural environment -- for example, for issuing crowdfunding tokens and managing financial flows within a community. This is an area in which using decentralized solutions is beneficial and centralization brings little to the table.
If we consider a Kickstarter-like model of pledging certain amounts of money in exchange for a product to be released in the future, we can see its obvious limitations. A project backer cannot exit her “investment” in the project by selling it another user. On the other hand such a use case is very natural using a blockchain-based system, where custom tokens can be swapped and transferred by design.
Issuing securities is highly regulated in most jurisdictions. Tokens can be associated with securities, especially if some projections about future token price are made or a token issuer promises to pay certain dividend. However, the blockchain is a regulation-agnostic instrument. If a legal entity wishing to utilize the blockchain for a securities issue is compliant with local laws and regulations then issuing securities on a blockchain is as legitimate as conducting a stock exchange listing.
Start-up fundraising, private investment placements and venture-stage investments seem to be the most appropriate areas for blockchain-powered financial instruments. On the other hand it can be used by a larger businesses for specific financial operations too, such as clearing and settlement, so long as these do not entail overly taxing speed requirements.
In most jurisdictions (notably excluding the US), blockchain-based fundraising that does not exceed a given limit can be carried out perfectly legally. Equity crowdfunding laws in the US allow fundraising with a simplified SEC registration procedure.
Strict US securities laws are intended to prevent fraud, and for this a strong centralized watchdog, such as US Securities and Exchange Commission, is needed. But the advance of decentralized technology can introduce some form of community and decentralized issuer vetting, which might eventually replace centralized regulators.
Having crowdfunding as one of WAVES platform’s main use cases means that some form of decentralized KYC/AML must be integrated into the system core. To that end we are realizing a decentralized reputation system, which should eliminate unscrupulous actors on the WAVES blockchain.
name::
* McsEngl.Lightweight clients; two-tier architecture; Proof of Stake; and usability.@cptIt,
name::
* McsEngl.Two-tier architecture and lightweight clients.@cptIt,
The classic Bitcoin approach is essentially a way to synchronize a distributed system through common transaction logs.
It requires that each network node store the full copy of the transaction history.
Obviously this does not scale well, since eventually not every node will be able to store the full history.
There are different ways to mitigate this -- a simplified payment verification procedure that allows storage of only that data essential for a given node; off-chain transactions; bidirectional payment tunnels; reducing blockchain bloat; working directly with the system state [8].
With the simplest approach, where all nodes are equal at Genesis block, centralization may emerge as low-capacity nodes have to rely on full, high-capacity nodes that can afford to store the full blockchain.
Effectively, a two-tier architecture emerges.
Does this make the system inherently centralized?
No, since a new node can always enter the network and become a full node if it has sufficient resources.
Of course, emerging centralization brings trust issues, since lightweight nodes have to trust the full nodes and can become a victim of a rogue full node.
However, there are ways to mitigate this, such as polling several nodes, maintaining trusted nodes lists, and so on.
WAVES platform enforces an approach that might at first seem extreme to a classic cryptocurrency advocate.
Lightweight nodes do not download the blockchain at all, instead relying on full nodes for payment verification and network interaction.
The approach is based on the SuperNET lite client[3] that has successfully been run on the Nxt platform for over a year.
WAVES is built on the Scorex platform,[8] which develops an approach based on using current network state as an alternative to full transaction history.
A simplified payment verification procedure will be realized for the lightweight node, adding another security layer.
System state can be downloaded by a lightweight node, and simplified payment verification procedures based on this.
name::
* McsEngl.Proof-of-stake consensus; stake leasing.@cptIt,
We have chosen the Proof-of-Stake protocol as a consensus algorithm for WAVES. This choice is based on its successful use in Nxt, as well as on certain theoretical considerations. At the same time we propose an enhancement to the PoS protocol, which should provide for reduced transaction times and increased transaction throughput -- Leased PoS (LPoS).
In a PoS system each node that holds a balance in the main network token has a chance (proportional to its balance) to produce a block.
In the two-tier architecture it is logical to move payment processing onto the full nodes alone.
At the same time, all nodes with non-zero balances still have to be eligible for staking rewards.
The theoretical issue of reduced security caused by fewer nodes staking can be addressed through explicit balance leasing from lightweight nodes to full nodes.
By leasing their balance to a trusted full node a lightweight node actually increases its chance of collecting transaction fees, since it does not have to stay online, and the full node has an increased chance of producing a block due to its increased balance.
Account leasing is not equivalent to balance transfer; a lightweight node can still transfer its balance to another node and conduct other operations.
By leasing out their balance, lightweight nodes effectively select which full nodes will carry out most of the network’s payment processing.
Reducing the number of nodes that can potentially produce blocks allows for faster confirmation times, lower latency, and a higher system throughput.
name::
* McsEngl.Lightweight nodes realization and browser plugins.@cptIt,
The lightweight node is realized as a browser plugin written in JavaScript. It interacts with Scorex-based full nodes. The plugin is installed from browser app-stores. Since no blockchain download is needed a user obtains a fully-fledged blockchain-powered wallet immediately following a simple installation procedure.
The wallet interface resembles traditional online banking/brokerage interfaces. Integrated national currencies allow for native value transfer denominated in fiat. Exchange of national currencies into and out of the blockchain is carried out by a trusted provider. Once a user has completed the national currency token purchase she can transfer it to another user or trade with it on a decentralized exchange.
Asset-to-asset trading makes it possible to provide a stock market-like trading interface, by allowing trading against USD, EUR, CNY, and so on. All in all, the platform interface is closer to traditional financial interfaces than to a normal cryptocurrency client. We find it important to provide an interface to which most users are already well accustomed, at the same time as empowering it with blockchain technology. Users can do things they were unable to do with traditional financial platforms, but the learning curve remains flat, which is a key to mass-market adoption.
name::
* McsEngl.Additional key WAVES features.@cptIt,
WAVES targets in the first place community-based development and projects.
To that end decentralized voting and messaging are implemented.
It will allow for a DAO-like experience in managing community projects, whilst remaining straightforward from a technical point of view.
WAVES will allow payment of network transaction fees in custom tokens (assets).
Along with the transaction in question, an order to exchange the asset into the main network token is sent to the decentralized exchange, and the transaction can be included in the next block only after that order has been executed.
WAVES platform is being built with mass adoption in mind from the start.
In this general overview we have attempted to show the technical solutions that may be used to give the end-user previously unseen opportunities, and to pave the way for the rapid adoption of blockchain technology.
#idWavwprref1#[1] https://github.com/ethereum/wiki/wiki/White-Paper
#idWavwprref2#[2] http://multigateway.org/
#idWavwprref3#[3] https://github.com/Tosch110/SuperNet-Lite
#idWavwprref4#[4] https://github.com/CounterpartyXCP
#idWavwprref5#[5] https://github.com/OpenAssets/open-assets-protocol
#idWavwprref6#[6] https://github.com/OmniLayer/spec
#idWavwprref7#[7] http://wiki.nxtcrypto.org/wiki/Whitepaper:Nxt
name::
* McsEngl.wavnet'Blockchain (wavbcn)@cptIt,
name::
* McsEngl.wavbcn'Block-Explorer (wavbex)@cptIt,
_ADDRESS:
* http://wavesexplorer.com//
* http://wavesexplorer.com/blocks/1,
name::
* McsEngl.wavbcn'Consenus-algorithm@cptIt,
_DESCRIPTION:
Q: Why are you using PoS rather than PoW?
A: Proof of work might be more secure in theory, but I still consider it to be an inelegant solution to the problem of consensus due to the wasted computational resource. Something better will come in time. Meanwhile, PoS is the way to go.
Q: Is the PoS consensus system the same as in the Nxt system?
A: At launch we will use a ‘plain vanilla’ PoS. Classical PoS is good enough for all intents and purposes. (‘Nothing-at-stake’ arguments are of a purely theoretical nature.) There will be improvements later, possibly including an entirely new kind of PoS system.
[https://wavestalk.org/general-discussion/waves-faq/]
name::
* McsEngl.wavnet'Consensus-evt (WAVEScevt)@cptIt,
* McsEngl.wavnet'cevt@cptIt,
* McsEngl.WAVEScevt@cptIt,
_DESCRIPTION:
Waves (WAVES)
$0.443330 (3.29%)
0.00037363 BTC (2.02%)
Market Cap
$44,333,000
37,364 BTC
Volume (24h)
$169,417
142.78 BTC
Circulating Supply
100,000,000 WAVES
[https://coinmarketcap.com/currencies/waves/] {2017-04-15}
name::
* McsEngl.wavnet'Funding@cptIt,
_DESCRIPTION:
Q: How much funding did Waves receive?
A: 29,636 bitcoins were crowdfunded from 5,790 participants in April and May 2016, with a market value of around $16 million at the time the ICO ended.
[https://wavestalk.org/general-discussion/waves-faq/]
name::
* McsEngl.wavnet'Reletion-to-ethereum@cptIt,
_DESCRIPTION:
Q: What is the difference between Waves and Ethereum?
A: Ethereum is developing bitcoin scripting for smart contracts. It’s powerful but makes certain things very complicated.
We took another road where things are simpler: it’s very easy to add all the functionality you need using plug-ins, so you don’t have to code complicated contracts.
Also, our focus is on mass adoption.
We’re specifically targeting two markets: fiat transfers on the blockchain and crowdfunding on the blockchain.
They are ripe for disruption, and we’ll be offering a product for a very general audience.
[https://wavestalk.org/general-discussion/waves-faq/]
name::
* McsEngl.wavnet'Resource@cptIt,
_ADDRESS.WPG:
* http://wavesexplorer.com//
* https://waveswallet.io//
* http://assets.wavesplatform.com//
name::
* McsEngl.wavnet'Service (wavsvc)@cptIt,
_DESCRIPTION:
We’re specifically targeting two markets: fiat transfers on the blockchain and crowdfunding on the blockchain. They are ripe for disruption, and we’ll be offering a product for a very general audience.
[https://wavestalk.org/general-discussion/waves-faq/]
===
A universe of tokens
WAVES is a decentralized platform that allows any user to issue, transfer, swap and trade custom tokens directly on the blockchain.
Decentralized trading
WAVES uses blockchain technology to offer an integrated exchange which does not depend on a central authority, server, or static infrastructure.
Your gateway to the world
The gateways partnered with WAVES make it a breeze to swap digital assets for traditional money right in your bank account, and vice versa.
Blockchain voting
WAVES also includes an innovative means of decentralized voting, with no single authority or the risk of manipulation this carries.
Decentralized crowdfunding
WAVES integrates its own crowdfunding platform, Crowdstarter, which allows entrepreneurs to launch their projects easily and in a decentralized manner.
Innovative reputation system
Absence of governance carries its own risks. WAVES' decentralized reputation system will play a key role in bringing confidence to the assets ecosystem.
[https://wavesplatform.com//]
name::
* McsEngl.wavsvc.DEX@cptIt,
_DESCRIPTION:
The Blockchain platform Waves has announced the release of its own decentralized exchange, DEX, on its mainnet.
The exchange, which Waves hopes will improve on previous attempts at decentralized trading with new features, is available via a full node or through the API. Later, the resource will become available to all users.
[https://cointelegraph.com/news/waves-debuts-dex-decentralized-exchange-mining-power-leasing {2017-03-30}]
name::
* McsEngl.wavnet.EVOLUTING@cptIt,
{time.2016}:
=== Genesis:
[https://blog.wavesplatform.com/wavesplatform-mainnet-launched-22f65b46d6af#.sxfb1vnjr, {2016-06-10}]
===
Q: Do you have a rough timeline for development?
A: There is a strong emphasis on fast development. Full launch will be in late summer 2016. [https://wavestalk.org/general-discussion/waves-faq/]
name::
* McsEngl.bcnnet.time.Decred (DCRnet {2016-02-08})@cptIt,
* McsEngl.bcnnet.Decred@cptIt,
* McsEngl.netDcr@cptIt,
* McsEngl.netDecred@cptIt,
* McsEngl.Decred-network@cptIt,
* McsEngl.DEcentralized-CREDit@cptIt,
_DESCRIPTION:
An open, progressive, and self-funding cryptocurrency with a system of community-based governance integrated into its blockchain.
[https://github.com/decred]
===
Decred is a cryptocurrency, similar to Bitcoin, with a strong focus on community input, open governance and sustainable funding and development.
It utilizes a hybrid “proof-of-work” and “proof-of-stake” mining system to ensure that a small group cannot dominate the flow of transactions or make changes to Decred without the input of the community.
A unit of currency is called a ‘decred’ (DCR).
To ensure the integrity of the currency and prevent people from making fraudulent transactions or creating their own coins, Decred uses a method of recording transactions known as a blockchain.
[https://docs.decred.org//]
_GENERIC:
* Blockchain-network-with-builtin-decentralized-governance#ql:idBcnnetBig#,
* Exchange-value-token-blockchain-network#ql:idEvtnet#
name::
* McsEngl.dcrnet'Protocol@cptIt,
name::
* McsEngl.dcrprl'Constitution (dcrcttn)@cptIt,
Decred Constitution
Decred (/'di:'kred/, /d?'kred/, dee-cred) is an open, progressive, and self-funding cryptocurrency with a system of community-based governance integrated into its blockchain. The project mission is to develop technology for the public benefit, with a primary focus on cryptocurrency technology. Decred, as a currency and as a project, is bound by the following set of rules, which include guiding principles, a system of governance, and a funding mechanism. These rules have been established in an effort to create an equitable and sustainable framework within which to achieve Decred's goals.
Free and Open-Source Software - All software developed as part of Decred shall be free and open source-software.
Free Speech and Consideration - Everyone has the right to communicate opinions and ideas without fear of censorship. Consideration shall be given to all constructive speech that is based in fact and reason.
Multi-Stakeholder Inclusivity - Inclusivity represents a multi-stakeholder system and an active effort shall be maintained to include a diverse set of views and users. While it would be ideal to include everyone, Decred shall comply with all relevant bodies of law in the jurisdictions where applicable, such as embargoes and other trade sanctions.
Incremental Privacy and Security - Privacy and security are priorities and shall be balanced with the complexity of their implementations. Additional privacy and security technology shall be implemented on a continuing and incremental basis, both proactively and on-demand in response to attacks.
Fixed Finite Supply - Issuance is finite and the total maximum number of coins in Decred shall not change. The total maximum supply for Decred is 20,999,999.99800912 coins, with a per-block subsidy that adjusts every 6,144 blocks (approximately 21.33 days) by reducing by a factor of 100/101. The genesis block subsidy starts at 31.19582664 coins.
Universal Fungibility - Universal fungibility is fundamental to Decred being a store of value and attacks against it shall be actively monitored and countermeasures pursued as necessary.
Governance of the network occurs directly through the blockchain via hybridization of a block's proof-of-work ("PoW") with its proof-of-stake ("PoS"). PoS contributors, known as stakeholders, can effectively override PoW contributors, known as miners, if 60% or more of the stakeholders vote against a particular block created by a miner.
A lottery system is used to determine which stakeholders vote on each block and collect a subsidy.
To be a stakeholder, one must purchase one or more tickets, which entails locking a specified amount of coins for approximately 1 day (256 blocks).
After waiting for the ticket to mature, the ticket is entered into a lottery that runs once per block where the winning tickets gain the ability to vote on the previous block.
Stakeholders must wait an average of 28 days (8,192 blocks) to vote their tickets, and during this time the coins used to purchase the ticket remain locked. The wait may be much longer or shorter than the average of 28 days because the ticket selection process is pseudorandom. Tickets expire after approximately 142 days (40,960 blocks).
Stakeholder votes recorded in the blockchain are rewarded with 6% of each block subsidy, and each block can have up to 5 votes for a total of 30% of each block subsidy.
PoW receives 60% of each block subsidy, subject to the constraint that their subsidy scales linearly with the number of PoS votes included, e.g. including 3 of 5 votes reduces PoW subsidy by 60%.
The votes themselves decide by majority decision whether the general transaction tree of the previous block, including the PoW subsidy, is valid. Thus, if PoS voters vote against a particular PoW block, it destroys the PoW subsidy (and development subsidy) and invalidates any regular transactions within that block.
Additional vote bits may be set when stakeholders submit votes, allowing stakeholders to vote on matters besides the previous block.
Off-chain decision-making shall be used to resolve disputes related to development and voted on by the Decred Assembly as they arise, as an effective proof-of-assembly ("PoA"), until such time PoA is integrated into the blockchain.
The Decred Assembly shall be composed of diverse Assembly members who are selected for membership by the Admission Council from the project ecosystem for representation.
Councils that are composed of Assembly members shall be formed to address ongoing and episodic matters. The initial Councils shall serve the separate functions of admission (Admission Council), creation (Creation Council), and attrition (Attrition Council).
The Admission Council shall vote on the inclusion of new members into the Assembly. All additional Councils shall be created by the Creation Council. The Attrition Council shall be responsible for deactivating both Councils and Assembly members as necessary.
Membership of the Decred Assembly shall consist of Assembly members who have been confirmed by a 60% or greater affirmative vote by the Admission Council. There is no restriction on the age or nationality of Assembly members, the only requirement is that of merit as judged by the Admission Council. Merit is judged on the basis of two characteristics: (1) the amount of time over which one has been involved with the project, and (2) one's body of work and its impact in the context of the project.
Attrition is embraced by temporarily deactivating or actively expelling Assembly members by a 60% or greater affirmative vote by the Attrition Council on the basis of: (1) substantial non-fulfillment of duties for one or more Councils or the Assembly, and/or (2) counterproductive behaviour that goes against the framework set forth in the Constitution without constructive action toward solutions.
All matters formally presented to a Council shall be resolved by a vote in 365 days or less.
Sustainability and longevity require that a subsidy of 10% of all block rewards be given to a development organization on an ongoing basis. The initial development organization shall be Decred Holdings Group LLC ("DHG"), a Nevis LLC that is responsible for funding work related to the development of the project, such as software development, infrastructure, and awareness.
DHG shall only fund work that adheres to the guiding principles.
DHG shall issue public financial statements every six months, starting March 8th, 2016. The frequency of financial statements may increase with activity, but it shall not occur more often than quarterly.
DHG shall put forth a budget proposal each year on March 8th, after the corresponding public financial statement has been issued.
The Funding Council shall review, propose changes, make changes, and ultimately approve the proposal by April 8th, one month from the initial budget proposal.
Final approval of the budget via PoA vote shall occur after Funding Council approval by April 18th, two months from the initial proposal.
DHG shall make public requests for proposals ("RFPs") for projects that are to be completed by parties on a contractual basis. RFPs shall include a scope and an explanation of how the work shall benefit the project. Parties that submit proposals shall be required to include: (1) a detailed description of the work to be performed, (2) a series of milestones that can be verified as work is completed, and (3) a quote for the work, itemized by milestone, in U.S. Dollars ("USD").
All proposals, both submitted and accepted, shall be made public one week after a proposal has been selected. Once the selection occurs, the associated RFP shall be removed. Contracted parties shall be paid exclusively in decred ("DCR") at the current effective DCR/USD rate at the time of payment, unless specifically noted otherwise.
In the future, the development organization may need to change from DHG to another entity that serves an identical function. If and when this occurs, DHG shall transfer all assets to the new entity and the development subsidy shall be directed to the new entity.
name::
* McsEngl.dcrnet'Node (dcrnod)@cptIt,
* McsEngl.dcrnet'computer-in-the-Decred-network@cptIt,
* McsEngl.dcrnod@cptIt,
_GENERIC:
* Blockchain-network-node#ql:idBcnnod#
name::
* McsEngl.dcrnod'Peer@cptIt,
FAQ.5. Why am I connecting to only 8 outbound peers?
There is an intentional unconfigurable limit of 8 outbound peers. More outbound peers than that does not help you in any way and is actually worse for both you and the network. This has been tested extremely thoroughly in Bitcoin, including btcsuite (the upstream project for Decred). All you would do by upping your outbound connections is waste valuable slots of the relatively few public peers there are (there are always a much higher number of “leechers” than there are “seeders”).
On the other hand, increasing your maximum connections, which really just increases the number of allowed inbound connections, helps the network by ensuring there are more slots available for new nodes and SPV clients which Decred does not have yet, but it will.
[https://docs.decred.org/faq/configuration/#5-why-am-i-connecting-to-only-8-outbound-peers]
name::
* McsEngl.dcrnod.MINER@cptIt,
name::
* McsEngl.dcrnet'mining.POOL@cptIt,
_ADDRESS.WPG:
* https://docs.decred.org/mining/proof-of-work/solo-mining/cgminer/windows//
Sign up for a mining pool
These mining pools are known to support Decred:
http://yiimp.ccminer.org
http://coinmine.pl/dcr
https://dcr.maxminers.net
https://dcr.suprnova.cc
https://pool.mn/dcr
https://zpool.ca
Mining pools all work more or less the same but you may wish to sign up at multiple pools and see which one suits you the best.
[https://docs.decred.org/mining/proof-of-work/#sign-up-for-a-mining-pool]
name::
* McsEngl.dcrnet'mining.SOLO@cptIt,
_ADDRESS.WPG:
* https://docs.decred.org/mining/proof-of-work/solo-mining/cgminer/windows//
_DESCRIPTION:
Solo mining is not recommended and is not covered by this documentation! The Decred network regularly sees a network hash rate of up to 10,000Gh/s. Solo mining is generally only done by advanced individuals or organized groups with a large cluster of GPUs so it is not addressed here.
[https://docs.decred.org/mining/proof-of-work/]
_DESCRIPTION:
When you mine in a pool, your hashrate is combined with all the other pool miners’ hashrates to look for the correct solution for a block. You will receive a reward based on the amount of work your miner performs in the pool. Pool mining distributes shares based on blocks found so you can earn a steady amount of Decred rather than the “all or none” of solo mining.
[https://docs.decred.org/mining/proof-of-work/]
name::
* McsEngl.dcrnet'Blockchain (dcrbcn)@cptIt,
name::
* McsEngl.dcrbcn'Block (dcrblk)@cptIt,
* McsEngl.dcrblk@cptIt,
name::
* McsEngl.dcrblk'Hash@cptIt,
block 00000000000004ffcf24b4a7ba827766cdd7bd1f31a42b6c8b83584a068eb154
name::
* McsEngl.dcrblk'Header@cptIt,
Block header format
Decred block headers occupy 180 bytes when serialized. The serialization format for a block header is displayed below:
Field Description Size
* dcrblk'Version Block header version 4 bytes
* dcrblk'Previous_block Hash of the previous block 32 bytes
* dcrblk'Merkle_root Merkle tree hash calculated using all transactions in the block 32 bytes
* dcrblk'Stake_root Merkle tree hash calculated using all stake transactions in the block 32 bytes
* dcrblk'Vote_bits Bit flags. Currently only used to signify votes on the previous merkle root 2 bytes
* dcrblk'Final_state Commitment to the final state of the PRNG (for lottery purposes) 6 bytes
* dcrblk'Voters Number of participating voters in the block 2 bytes
* dcrblk'Fresh_stake Number of new tickets in the block 1 byte
* dcrblk'Revocations Number of revocations present in the block 1 byte
* dcrblk'Pool_size Size of the ticket pool 4 bytes
* dcrblk'Bits Difficulty target for the block 4 bytes
* dcrblk'SBits Stake difficulty target for the block 8 bytes
* dcrblk'Height The number of blocks that precede the block in the blockchain 4 bytes
* dcrblk'Size Number of bytes that the serialized block occupies 4 bytes
* dcrblk'Timestamp Time that the block was created 4 bytes
* dcrblk'Extra_data The nonce and any other data that may be used later for consensus purposes 40 bytes
Example encoded block header
0x01, 0x00, 0x00, 0x00, // Version 1
0x6f, 0xe2, 0x8c, 0x0a, 0xb6, 0xf1, 0xb3, 0x72, // PrevBlock
0xc1, 0xa6, 0xa2, 0x46, 0xae, 0x63, 0xf7, 0x4f,
0x93, 0x1e, 0x83, 0x65, 0xe1, 0x5a, 0x08, 0x9c,
0x68, 0xd6, 0x19, 0x00, 0x00, 0x00, 0x00, 0x00,
0x3b, 0xa3, 0xed, 0xfd, 0x7a, 0x7b, 0x12, 0xb2, // MerkleRoot
0x7a, 0xc7, 0x2c, 0x3e, 0x67, 0x76, 0x8f, 0x61,
0x7f, 0xc8, 0x1b, 0xc3, 0x88, 0x8a, 0x51, 0x32,
0x3a, 0x9f, 0xb8, 0xaa, 0x4b, 0x1e, 0x5e, 0x4a,
0x3b, 0xa3, 0xed, 0xfd, 0x7a, 0x7b, 0x12, 0xb2, // StakeRoot
0x7a, 0xc7, 0x2c, 0x3e, 0x67, 0x76, 0x8f, 0x61,
0x7f, 0xc8, 0x1b, 0xc3, 0x88, 0x8a, 0x51, 0x32,
0x3a, 0x9f, 0xb8, 0xaa, 0x4b, 0x1e, 0x5e, 0x4a,
0x00, 0x00, // VoteBits
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // FinalState
0x00, 0x00, // Voters
0x00, // FreshStake
0x00, // Revocations
0x00, 0x00, 0x00, 0x00, //Poolsize
0xff, 0xff, 0x00, 0x1d, // Bits
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // SBits
0x00, 0x00, 0x00, 0x00, // Height
0x00, 0x00, 0x00, 0x00, // Size
0x29, 0xab, 0x5f, 0x49, // Timestamp
0xf3, 0xe0, 0x01, 0x00, // Nonce
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // ExtraData
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
[https://docs.decred.org/advanced/block-header-specifications/]
name::
* McsEngl.dcrblk.Block1@cptIt,
Block#1
BlockHash 000000000000437482b6d47f82f374cde539440ddb108b0a76886f0d87d126b9
Summary
Number Of Transactions 1
Height 1 (Mainchain)
Block Reward 1680000.00000000 DCR
Timestamp Mon, 08 Feb 2016 18:02:15 GMT
Merkle Root
b4895fb9d0b54822550828f2ba07a68ddb1894796800917f8672e65067696347
Stake Root
0000000000000000000000000000000000000000000000000000000000000000
Previous Block 0
VoteBits 1
Final State 000000000000
Voters 0
FreshStake 0
Revocations 0
PoolSize 0
Difficulty 32767.74999809
SBits 2
Bits 1b01ffff
Size (bytes) 113521
Version 1
Stake Version 0
Nonce 3671491438
Next Block 2
[https://mainnet.decred.org/block-index/1]
name::
* McsEngl.dcrblk.Block0@cptIt,
_DESCRIPTION:
Block#0
BlockHash 298e5cc3d985bfe7f81dc135f360abe089edd4396b86d2de66b0cef42b21d980
Summary
Number Of Transactions 1
Height 0 (Mainchain)
Block Reward 0 DCR
Timestamp Mon, 08 Feb 2016 18:00:00 GMT
Merkle Root
66aa7491b9adce110585ccab7e3fb5fe280de174530cca10eba2c6c3df01c10d
Stake Root
0000000000000000000000000000000000000000000000000000000000000000
VoteBits 0
Final State 000000000000
Voters 0
FreshStake 0
Revocations 0
PoolSize 0
Difficulty 32767.74999809
SBits 2
Bits 1b01ffff
Size (bytes) 0
Version 1
Stake Version 0
Nonce 0
Next Block 1
[https://mainnet.decred.org/block-index/0]
name::
* McsEngl.dcrbcn'Block-Explorer (dcrbex)@cptIt,
_ADDRESS.WPG:
* https://mainnet.decred.org//
* blockH0: https://mainnet.decred.org/block/298e5cc3d985bfe7f81dc135f360abe089edd4396b86d2de66b0cef42b21d980,
name::
* McsEngl.dcrbcn'Consensus-algorithm@cptIt,
* McsEngl.dcrnet'consensus-algorithm@cptIt,
* McsEngl.dcrnet'block-verification@cptIt,
* McsEngl.dcrnet'transaction-verification@cptIt,
_DESCRIPTION:
Each block in the blockchain is a record of transactions that have occurred since the last block (about 5 minutes).
Every computer (node) in the Decred network shares this blockchain.
Nodes in the network run an algorithm many times over a block looking for a solution with a known difficulty.
This process is known as “proof-of-work” mining.
Once the solution is found it is broadcast to the network.
The network then verifies the solution (finding the solution is very hard, but verifying it is easy).
Decred uses an extra step of verification known as “proof-of-stake” mining.
Stakeholders who have purchased tickets now have the chance to vote on the block.
5 tickets are chosen randomly from the ticket pool and if at least 3 of them vote ‘yes’ the block is permanently added to the blockchain and the transactions are cleared.
Both PoS and PoW miners are compensated with DCR for the resources used to mine the block.
[https://docs.decred.org/]
Overview
Decred has two methods of transaction verification proof-of-work (PoW) and proof-of-stake (PoS).
1. Proof-of-work (PoW) Mining
Proof-of-work mining, more commonly referred to as PoW mining, is the activity of committing your computer’s hardware and resources to process network transactions and build the blocks that make up the blockchain in the Decred network. Each time a block is created (by a miner), about 30 new Decred coins are made. These coins are then split up as follows:
Subsidy Party
60% PoW Miners
30% PoS Voters
10% Decred development subsidy
You will, on average, receive a reward that is roughly proportional to the hashrate of your miner and the overall hashrate of the network when you commit your computer to PoW mining. To get started, you must have a computer with a video card. Most video cards can be used for mining (including the “mobile” types found in some laptops). In general, higher end video cards perform at higher hashrates and therefore receive higher rewards.
2. Proof-of-stake (PoS) Mining
Proof of Stake mining is the second method of block verification in Decred. It is computationally cheap but it requires you to already have some DCR in your wallet. In the Decred network, PoW miners solve blocks then turn those blocks over to PoS miners to vote on them. When a block is completed, 5 tickets are chosen at random from the ticket pool to vote on the block. If at least 3 votes are ‘Yes’ then the block is validated, included in the block chain and both PoW and PoS miners are paid.
If the vote fails, the block is discarded and the transactions return to be included in another block. The PoW miners are not paid, however the PoS miners are.
This is to incentivize PoW miners to mine according to the wishes of PoS miners.
For example, if the rules of the network change in the future any PoW miners who don’t follow them will not be paid.
It also helps stop large mining pools getting too much influence over the network.
In cryptocurrencies that don’t use PoS, the large groups of PoW miners who effectively control the network can collude to block transactions, stop network changes or even force faked transactions (although this would take a huge amount of resources).
Collusion between PoW and PoS miners is not possible as tickets are not chosen until the time of the vote.
Collusion between PoS miners is likewise remote as the ticket pool is kept at around 40,960 active tickets at any time.
The chance of three tickets belonging to the same individual or group being chosen for the same block is very small.
Even if this did happen every transaction is validated at least twice so the chance of anyone manipulating the blockchain is effectively zero.
[https://docs.decred.org/mining/overview/]
name::
* McsEngl.dcrbcn'Address@cptIt,
* McsEngl.decred-address@cptIt,
_DESCRIPTION:
9. What are the different types of addresses?
A Decred address is actually just a representation of a public key (which itself could be a script hash) along with a 2-byte prefix which identifies the network and type and a checksum suffix in order to detect improperly entered addresses.
Consequently, you can always tell what type of address it is based on the 2-byte prefix.
The first byte of the prefix identifies the network. This is why all mainnet addresses start with “D”, testnet addresses start with “T”, and simnet addresses start with “S”. The second byte of the prefix identifies the type of address it is.
The most common addresses used at the moment are secp256k1 pubkey hashes, which are identified by a lowercase “s”. It represents a single public key and therefore only has a single associated private key which can be used to redeem it.
The stake pool, however, uses a pay-to-script-hash address, which is identified by the second byte being a lowercase “c” (again that is shown in the linked params). The specific flavor of script it generates is a multi-signature 1-of-2, which is how it allows either the pool, or you, to vote. Both you and the stake pool have your own private keys and since the script only requires one signature of the possible two, that is how it allows delegation of voting rights to the pool without you giving up your voting rights completely.
[https://docs.decred.org/faq/wallets-and-seeds/#9-what-are-the-different-types-of-addresses]
name::
* McsEngl.dcrbcn'Hash-rate@cptIt,
* McsEngl.decreed-blockchain-hashing-power@cptIt,
* McsEngl.decreed-blockchain-hashing-rate@cptIt,
* McsEngl.dcrnet'hash-rate@cptIt,
* McsEngl.dcrnet'hashing-power@cptIt,
* McsEngl.blockchain-hash-rate@cptIt,
_DESCRIPTION:
network hash rate of up to 10,000Gh/s.
[https://docs.decred.org/mining/proof-of-work/]
name::
* McsEngl.dcrnet'Consensus-exchange-value-token (DCRcevt)@cptIt,
* McsEngl.dcrcevt@cptIt,
* McsEngl.decret-consensus-exval-token@cptIt,
_DESCRIPTION:
A unit of currency is called a ‘decred’ (DCR).
[https://docs.decred.org/]
name::
* McsEngl.dcrnet'Governance-system (dcrgov)@cptIt,
* McsEngl.dcrgov@cptIt,
* McsEngl.dcrnet'governance-system@cptIt,
* McsEngl.Decred-governance-system@cptIt,
_DESCRIPTION:
Governance
Layered form of transparent meritocratic governance that extends beyond proof-of-work and proof-of-stake mechanisms to bring forward and represent insider and outsider voices in the community [9]
Bottom-up decision-making through the Decred Assembly - an evolving and inclusive list of community members who make non-financial contributions to the project through their work and effort [10]
Project bound by the Decred Constitution#ql:idDcrcttn# on the core principles of finite issuance, privacy, security, fungibility, inclusivity, and progressive development of the technology that keeps these principles together [11]
[https://wiki.decred.org/Main_Page]
name::
* McsEngl.dcrgov'Decred-Assembly (dcrasl)@cptIt,
* McsEngl.dcrasl@cptIt,
* McsEngl.Decred-Assembly@cptIt,
_DESCRIPTION:
Off-chain decision-making shall be used to resolve disputes related to development and voted on by the Decred Assembly as they arise, as an effective proof-of-assembly ("PoA"), until such time PoA is integrated into the blockchain.
The Decred Assembly shall be composed of diverse Assembly members who are selected for membership by the Admission Council from the project ecosystem for representation.
Councils that are composed of Assembly members shall be formed to address ongoing and episodic matters. The initial Councils shall serve the separate functions of admission (Admission Council), creation (Creation Council), and attrition (Attrition Council).
The Admission Council shall vote on the inclusion of new members into the Assembly. All additional Councils shall be created by the Creation Council. The Attrition Council shall be responsible for deactivating both Councils and Assembly members as necessary.
Membership of the Decred Assembly shall consist of Assembly members who have been confirmed by a 60% or greater affirmative vote by the Admission Council. There is no restriction on the age or nationality of Assembly members, the only requirement is that of merit as judged by the Admission Council. Merit is judged on the basis of two characteristics: (1) the amount of time over which one has been involved with the project, and (2) one's body of work and its impact in the context of the project.
Attrition is embraced by temporarily deactivating or actively expelling Assembly members by a 60% or greater affirmative vote by the Attrition Council on the basis of: (1) substantial non-fulfillment of duties for one or more Councils or the Assembly, and/or (2) counterproductive behaviour that goes against the framework set forth in the Constitution without constructive action toward solutions.
All matters formally presented to a Council shall be resolved by a vote in 365 days or less.
[idDcrcttnpgov]
===
Decred Assembly
The first of the groups in the layered governance system is the Decred Assembly, a rolling list of the most meritorious members of the Decred community who will be expected to vote episodically on Assembly-wide issues (creating an effective proof-of-assembly) and participate in committees. The Assembly is a threshold meritocracy with rolling appointments for no fixed length of time, where members are admitted on the basis of what they have actually done for Decred not what they promise to do. Assemblypersons will contribute to the advancement of Decred through discussion and voting in various committees that may be long- or short-lived. Proof-of-assembly, in the form of Assembly-wide votes, will be included in the blockchain in the future, but is not included currently.
Additional layers of governance are planned, e.g., proof-of-developers, and will be formalized in conjunction with the community as Decred development progresses.
[https://wiki.decred.org/Introduction]
name::
* McsEngl.dcrnet'Program (dcrpgm)@cptIt,
name::
* McsEngl.dcrpgm'Dcrnet-development@cptIt,
* McsEngl.dcrnet'development@cptIt,
* McsEngl.dcrpgm'Dcrnet-development@cptIt,
_DESCRIPTION:
Self-Funded Development
Decred includes a mechanism for self-funding development to ensure the project is and remains sustainable. A major sticking point for many open-source projects is that they require funding to survive, meaning they typically need to ask for donations and are limited by the funding they receive. To ensure that Decred remains free from the problems related to lack of funding, Decred's consensus rules include a 10% development subsidy in each block that is paid to a development organization on an ongoing basis.
The current development organization is Decred Holdings Group, LLC (DHG), a Nevis-based organization. The development organization will be open to anyone who makes contributions to develop Decred, will remain transparent and issue regular financial statements biannually, and will publicly account for how funds are spent. This entity is built to be adaptable and open to community feedback and guidance, and may therefore change in the future if circumstances require adaptation for it to continue serving its goal to make and keep Decred development sustainable as the project and network scale upward.
[https://wiki.decred.org/Introduction]
name::
* McsEngl.dcrpgm'API@cptIt,
* McsEngl.dcrapi@cptIt,
* McsEngl.Decred-API@cptIt,
name::
* McsEngl.dcrpgm'File@cptIt,
_LOCATION:
The files and file content are the same on all platforms. The only difference is the file location. Each program (dcrd, dcrwallet, and dcrctl has a directory of its own to store the configuration files.
On Windows they are located in %LOCALAPPDATA% (\Users\synagonism\AppData\Local\ you can type that into the Windows explorer location bar to go straight to the folder).
On Linux and other properly behaving UNIX they are in ~/.dcrd/, ~/.dcrwallet/, and ~/.dcrctl/ respectively. These are hidden directories and will not show up with ls, but are accessible using cd .dcrd, cd .dcrwallet, and cd .dcrctl from the home directory.
OS X does not follow the proper UNIX way and puts them in ~/Libraries/Application Support/Dcrd, ~/Libraries/Application Support/Dcrwallet, and ~/Libraries/Application Support/Dcrctl.
Only the dcrd and dcrwallet folders are created by default. If you want to store the login information for dcrctl you will need to manually create the directory for it.
[https://docs.decred.org/advanced/storing-login-details/]
name::
* McsEngl.dcrpgm.specific@cptIt,
* McsEngl.dcrpgm.specific@cptIt,
name::
* McsEngl.dcrpgm.cgminer@cptIt,
* McsEngl.cgminer@cptIt,
* McsEngl.cgminer-program@cptIt,
_ADDRESS.WPG:
* https://github.com/ckolivas/cgminer,
* https://docs.decred.org/mining/proof-of-work/solo-mining/cgminer/windows//
name::
* McsEngl.dcrpgm.dcrd@cptIt,
* McsEngl.dcrd@cptIt,
_DESCRIPTION:
dcrd: The node daemon, this command-line application handles block management and consensus.
[https://docs.decred.org/getting-started/beginner-guide/]
name::
* McsEngl.dcrd'Option@cptIt,
Application options
Option Description
-A or --appdata= Path to dcrd home directory ($HOME/.dcrd)
-V or --version Display version information and exit
-C or --configfile= Path to configuration file
-b or --datadir= Directory to store data
--logdir= Directory to log output. ($HOME/.dcrd/logs)
-a or --addpeer= Add a peer to connect with at startup
--connect= Connect only to the specified peers at startup
--nolisten Disable listening for incoming connections – NOTE: Listening is automatically disabled if the --connect or --proxy options are used without also specifying listen interfaces via --listen
--listen= Add an interface/port to listen for connections (default all interfaces port: 9108, testnet: 19108)
--maxpeers= Max number of inbound and outbound peers (125)
--banduration= How long to ban misbehaving peers. Valid time units are {s, m, h}. Minimum 1 second (24h0m0s)
-u or --rpcuser= Username for RPC connections
-P or --rpcpass= Password for RPC connections
--rpclimituser= Username for limited RPC connections
--rpclimitpass= Password for limited RPC connections
--rpclisten= Add an interface/port to listen for RPC connections (default port: 8334, testnet: 18334)
--rpccert= File containing the certificate file
--rpckey= File containing the certificate key
--rpcmaxclients= Max number of RPC clients for standard connections (10)
--rpcmaxwebsockets= Max number of RPC clients for standard connections (25)
--norpc Disable built-in RPC server – NOTE: The RPC server is disabled by default if no rpcuser/rpcpass is specified
--notls Disable TLS for the RPC server – NOTE: This is only allowed if the RPC server is bound to localhost
--nodnsseed Disable DNS seeding for peers
--externalip: Add an ip to the list of local addresses we claim to listen on to peers
--proxy= Connect via SOCKS5 proxy (eg. 127.0.0.1:9050)
--proxyuser= Username for proxy server
--proxypass= Password for proxy server
--onion= Connect to tor hidden services via SOCKS5 proxy (eg. 127.0.0.1:9050)
--onionuser= Username for onion proxy server
--onionpass= Password for onion proxy server
--noonion= Disable connecting to tor hidden services
--torisolation Enable Tor stream isolation by randomizing user credentials for each connection
--testnet Use the test network
--simnet Use the simulation test network
--nocheckpoints= Disable built-in checkpoints. Don’t do this unless you know what you’re doing.
--dbtype= Database backend to use for the Block Chain (leveldb)
--profile= Enable HTTP profiling on given port – NOTE port must be between 1024 and 65536 (6060)
--cpuprofile= Write CPU profile to the specified file
--memprofile= Write mem profile to the specified file
--dumpblockchain= Write blockchain as a gob-encoded map to the specified file
--miningtimeoffset= Offset the mining timestamp of a block by this many seconds (positive values are in the past)
-d or --debuglevel: Logging level for all subsystems {trace, debug, info, warn, error, critical} – You may also specify <subsystem>=<level>,<subsystem2>=<level>,… to set the log level for individual subsystems – Use show to list available subsystems (info)
--upnp Use UPnP to map our listening port outside of NAT
--limitfreerelay= Limit relay of transactions with no transaction fee to the given amount in thousands of bytes per minute (15)
--norelaypriority Do not require free or low-fee transactions to have high priority for relaying
--maxorphantx= Max number of orphan transactions to keep in memory (1000)
--generate= Generate (mine) decreds using the CPU
--miningaddr= Add the specified payment address to the list of addresses to use for generated blocks – At least one address is required if the generate option is set
--blockminsize= Mininum block size in bytes to be used when creating a block
--blockmaxsize= Maximum block size in bytes to be used when creating a block (750000)
--blockprioritysize= Size in bytes for high-priority/low-fee transactions when creating a block (50000)
--getworkkey= DEPRECATED – Use the –miningaddr option instead
--addrindex= Build and maintain a full address index. Currently only supported by leveldb.
--dropaddrindex= Deletes the address-based transaction index from the database on start up, and the exits.
--nonaggressive Disable mining off of the parent block of the blockchain if there aren’t enough voters
--nominingstatesync Disable synchronizing the mining state with other nodes
[https://docs.decred.org/advanced/program-options/]
name::
* McsEngl.dcrpgm.dcrctl@cptIt,
* McsEngl.dcrctl@cptIt,
_DESCRIPTION:
dcrctl Usage
dcrctl provides a way to control both the daemon dcrd and the wallet dcrwallet using the json rpc interface without actually writing json.
To simplify the examples we will assume that you have all password stored in the config files.
Stopping the programs
To cleanly shut down the programs:
dcrctl --wallet stop
dcrctl stop
Finding the current block height
dcrctl getblockcount
See your balance
dcrctl --wallet getbalance
Get a new address
dcrctl --wallet getnewaddress
Send funds to an address
dcrctl --wallet sendtoaddress TseGH6Xfq9k8Co6txJbY3kiiM7vpaYzXD4T 13
[https://docs.decred.org/advanced/dcrctl-usage/]
name::
* McsEngl.dcrctl'Command (dcrctl [command])@cptIt,
You can always see all commands with dcrctl -l:
* dcrctl'getbestblock
Get the most recent block and hash in the chain.
{
"hash": "00000000000004c5c0bcd4f35c4d194bfe240f8003dfc97db29eeacc3aeeb4a0",
"height": 105057
}
* dcrctl'getbestblockhash
Get the hash of the most recent block in the chain.
* dcrctl'getblockcount
Get the current number of blocks in the chain.
* dcrctl'getdifficulty
Get the current PoW mining difficulty.
1.83210056947851e+06
* dcrctl'gethashespersec
Get the network hash rate.
* dcrctl'getinfo
Displays some basic info about the network including current block number and network difficulty.
{
"version": 70000,
"protocolversion": 2,
"blocks": 105063,
"timeoffset": 2,
"connections": 8,
"proxy": "",
"difficulty": 1.83210056947851e+06,
"testnet": false,
"relayfee": 0.01,
"errors": ""
}
* dcrctl'getmininginfo
Probably the most useful PoW command. Shows the current block, size and difficulty, as well as the total network hash rate per second.
{
"blocks": 105063,
"currentblocksize": 9482,
"currentblocktx": 6,
"difficulty": 1.83210056947851e+06,
"stakedifficulty": 11938483761,
"errors": "",
"generate": false,
"genproclimit": 1,
"hashespersec": 0,
"networkhashps": 22452086771892,
"pooledtx": 270,
"testnet": false
}
* dcrctl'getnettotals
Gets the amount of data sent and received by the daemon.
{
"totalbytesrecv": 670119,
"totalbytessent": 341359,
"timemillis": 1486387877568
}
* dcrctl'getpeerinfo
Similar to getnettoals, includes network data transfer, time connected, block height when daemon was started and current block height.
[
{
"id": 10,
"addr": "92.222.84.111:9108",
"services": "00000003",
"lastsend": 1486387854,
"lastrecv": 1486387854,
"bytessent": 25517,
"bytesrecv": 63555,
"conntime": 1486382573,
"timeoffset": 2,
"pingtime": 84412,
"version": 2,
"subver": "/dcrwire:0.2.0/dcrd:0.3.0/",
"inbound": false,
"startingheight": 105047,
"currentheight": 105054,
"banscore": 0,
"syncnode": false
},
...
{
"id": 12,
"addr": "[2001:41d0:2:b57f::9]:9108",
"services": "00000003",
"lastsend": 1486387929,
"lastrecv": 1486387929,
"bytessent": 19671,
"bytesrecv": 69002,
"conntime": 1486383848,
"timeoffset": 2,
"pingtime": 113461,
"version": 3,
"subver": "/dcrwire:0.2.0/dcrd:0.7.0/",
"inbound": false,
"startingheight": 105053,
"currentheight": 105063,
"banscore": 0,
"syncnode": true
}
]
* dcrctl'getstakedifficulty
Returns current PoS difficulty.
{
"current": 119.38483761,
"next": 119.38483761
}
* dcrctl'getticketpoolvalue Gets the DCR value of all tickets in the pool.
1.53768733078834e+06
* dcrctl'help ("command")
Show the help for a command.
* dcrctl'missedtickets
Show all of your tickets that missed voting.
{
"tickets": [
"1921eaed456da8352d6735d17881d4b817b01b0acdc2b8547b07c360d3072800",
"281fb62fca76881935c0eed73ead93bccd13b1690fed6f2cdb1299d013012e00",
* dcrctl'rebroadcastmissed
Rebroadcast missed tickets to the network. This is done automatically on starting the wallet.
* dcrctl'rebroadcastwinners
As above, but for voted tickets.
* dcrctl'stop
Stop the daemon.
[https://docs.decred.org/advanced/program-options/]
name::
* McsEngl.dcrctl'Command.wallet (dcrctl --wallet [command])@cptIt,
* McsEngl.dcrctlCmdWlt@cptIt,
Wallet server commands (--wallet)
* dcrctl'addmultisigaddress nrequired ["key",...] ("account")
Adds an address that requires multiple signatures to use.
* dcrctl'consolidate inputs ("account") Cleans up funds in multiple addresses in an account and puts it in a single address. Note there is a transaction fee to use this command.
* dcrctl'createmultisig nrequired ["key",...]
Used for multi signature wallets.
* dcrctl'createnewaccount "account"
Create a new account. Note, this makes a new account within the current wallet, NOT a new wallet.
* dcrctl'dumpprivkey "address"
Disabled on mainnet for security reasons.
* dcrctl'encryptwallet "passphrase"
Encrypt the wallet with the given phrase
* dcrctl'getaccount "address"
This command will tell you what account the given address belongs to.
* dcrctl'getaccountaddress "account"
Return the first address in the given account (default is ‘default’).
* dcrctl'getaddressesbyaccount "account"
Get all the addresses in the given account.
* dcrctl'getbalance ("account" minconf=1 "balancetype")
Get the spendable balance in the given account. To get the entire balance in the wallet, use ‘getbalance * 0 all’.
* dcrctl'getbalancetomaintain This is the minimum balance to maintain in the wallet when using auto stake buying.
* dcrctl'getmasterpubkey
Get the public key for your wallet. This will allow people to view, but not spend funds in your wallet. It is safe to provide to others.
* dcrctl'getnewaddress ("account" verbose=false)
Get a new address in the given account.
* dcrctl'getreceivedbyaccount "account" (minconf=1)
Gets the total amount of DCR ever received by this wallet. This includes stake returns so it could be quite large if you’re PoS mining.
* dcrctl'getreceivedbyaddress "address" (minconf=1)
Get funds received by the given address.
* dcrctl'getseed
Disabled on mainnet for security.
* dcrctl'getstakeinfo
Retreive useful information on the current status of the PoS pool. See PoS Commands.
{
"blockheight": 105683,
"poolsize": 44597,
"difficulty": 137.79580711,
"allmempooltix": 0,
"ownmempooltix": 0,
"immature": 0,
"live": 0,
"proportionlive": 0,
"voted": 0,
"totalsubsidy": 0,
"missed": 0,
"proportionmissed": 0,
"revoked": 0,
"expired": 0
}
* dcrctl'getticketfee
Get the average fee being paid for tickets.
* dcrctl'getticketmaxprice
Get the maximum price that your wallet will auto purchase tickets for.
* dcrctl'gettickets includeimmature
Get all your current tickets. Second argument should be true if you want to see immature tickets too.
* dcrctl'gettransaction "txid" (includewatchonly=false) Get the transaction associated with the given id.
* dcrctl'listaccounts (minconf=1)
See all accounts and their spendable balance in your wallet.
{
"default": 0,
"imported": 0
}
* dcrctl'listreceivedbyaccount (minconf=1 includeempty=false includewatchonly=false)
Get a list of all your accounts and the amount of DCR that has been received by them.
* dcrctl'listreceivedbyaddress (minconf=1 includeempty=false includewatchonly=false) Get a list of all your addresses and the amount of DCR that has been received by them.
* dcrctl'listsinceblock ("blockhash" targetconfirmations=1 includewatchonly=false)
List transactions that occurred since the given block hash.
* dcrctl'listtransactions ("account" count=10 from=0 includewatchonly=false)
List the number of transactions as specified by ‘count’ in the given account.
* dcrctl'move "fromaccount" "toaccount" amount (minconf=1 "comment")
Move funds between accounts in the same wallet.
* dcrctl'purchaseticket "fromaccount" spendlimit (minconf=1 "ticketaddress" "comment")
Manually purchase PoS tickets. ‘fromaccount’ will usually be “default”. ‘spendlimit’ is the amount you want to spend on tickets in total, not per ticket.
* dcrctl'renameaccount "oldaccount" "newaccount"
Rename an account in your wallet.
* dcrctl'sendfrom "fromaccount" "toaddress" amount (minconf=1 "comment" "commentto") Send DCR from the given account to the given address. You can add an optional comment.
* dcrctl'sendtoaddress "address" amount ("comment" "commentto") Similar to above but uses the default account to send from.
* dcrctl'setbalancetomaintain balance Used for auto staking. The wallet will auto buy tickets until it reaches this threshold.
* dcrctl'setticketfee fee Set the (non-refunable) fee for purchasing stake tickets. See FAQ#Ticket fee
* dcrctl'setticketmaxprice max Set the maximum price the wallet will pay when auto buying tickets.
* dcrctl'setticketvotebits "txhash" votebits ("votebitsext") Sets the given ticket to vote ‘yes’ or ‘no’ (default yes)
* dcrctl'settxfee amount
Sets the fee per kB of transaction data you are willing to pay. Note this is NOT the same as setticketfee above.
* dcrctl'walletlock
Lock the wallet (no funds can be sent).
* dcrctl'walletpassphrase "passphrase" timeout
Unlock the wallet using the given pass phrase for the given time period in seconds. 0 will unlock the wallet until it is restarted.
* dcrctlc'walletpassphrasechange "oldpassphrase" "newpassphrase"
Change your wallet passphrase.
[https://docs.decred.org/advanced/program-options/]
name::
* McsEngl.dcrnet'Wallet (dcrwlt)@cptIt,
* McsEngl.dcrwallet@cptIt,
_DESCRIPTION:
Decred uses a wallet to store, transfer and receive DCR#ql:idDcrcet#. This wallet signs every transaction in and out with a special public key that is unique to you. This is how the network knows that the address sending the transaction is the correct one. Think of your bank account and PIN. When you use your card (wallet) you also enter your PIN (public key) so the bank knows it was you that authorized the transaction. The main difference here is that the public key is known by everyone on the network whereas your PIN is not. When you start using Decred, you will generate a private key that you must not give to anyone.
[https://docs.decred.org/]
===
Now that you are connected to the network, the next thing you need to do is create a wallet that will hold your account addresses and DCR balance.
If you participate in mining or stake mining, this is where your payments will go.
[https://docs.decred.org/getting-started/user-guides/windows/#create-your-wallet]
name::
* McsEngl.dcrwlt'Account@cptIt,
* McsEngl.Decred-account@cptIt,
_DESCRIPTION:
Decred-account is a-collection of addresses#ql:idDcrads#.
dcrctl --wallet createnewaccount "account"
Create a new account. Note, this makes a new account within the current wallet, NOT a new wallet.
dcrctl --wallet listaccounts (minconf=1)
See all accounts and their spendable balance in your wallet.
{
"default": 0,
"imported": 0
}
dcrctl --wallet renameaccount "oldaccount" "newaccount"
Rename an account in your wallet.
dcrctl --wallet getaddressesbyaccount "account"
Get all the addresses in the given account.
name::
* McsEngl.dcrwlt.dcrwallet-cli-program (dcrwltCli)@cptIt,
* McsEngl.dcrwallet-cli-program@cptIt,
_DESCRIPTION:
dcrwallet is a-cli-program to manage addresses#ql:idDcrads#.
name::
* McsEngl.dcrwltCli'File@cptIt,
name::
* McsEngl.dcrwltCli'wallet.db@cptIt,
4. Can someone steal my coins if they access wallet.db?
Nobody can steal your coins if they get access to the wallet.db4 file unless they also have your private passphrase. If you chose to use public encryption, they also cannot get access to any of your extended public keys or addresses.
[https://docs.decred.org/faq/wallets-and-seeds/#4-can-someone-steal-my-coins-if-they-access-walletdb]
name::
* McsEngl.dcrwltCli'Key.PUBLIC@cptIt,
dcrctl --wallet getmasterpubkey
dpubZFWfp7u3a952Txva4yTCJGUZkNmvwF9uVuZxo1a52ya7QqMSWJwKuqmR8vAQ3dmuhFkKuG3Qam92CC8axLo98aeaYi8QmsqYFse8Tx2GHix
name::
* McsEngl.dcrwltCli'Key.PRIVATE (Seed)@cptIt,
* McsEngl.dcrwltCli'seed@cptIt,
_DESCRIPTION:
This is the list of words that make up your private key
[https://docs.decred.org/getting-started/user-guides/windows/]
dcrctl --wallet getseed
Disabled on mainnet for security.
5. Can someone use a brute-force attack on a random wallet to regenerate its seed words (the words are not salted)?
All the seed words are is a direct mapping of English words to hex digits. The seed is nothing more than a 256-bit (32-byte) cryptographically random number. Salt does not apply here at all. It has nothing to do with brute-forcing5 random cryptographic numbers.
In other words, since each word can be 256 possibilities and there are 32 words, that yields 256^32 (or 2^256 depending on how you want to look at it, but it is the same number) possibilities. That number is larger than the entire number of hydrogen atoms in the known universe. In fact, it is almost more than the number of atoms total in the known universe.
To put this in perspective, assuming there are 7 billion people on the planet and each person owned 10 computers and each one of those computers could test a billion possibilities a second and that you could find the solution on average after testing only 50% of the total possibilities, it would still take 26x10^48 (that’s 26 trillion trillion trillion trillion) years to brute-force a single seed.
[https://docs.decred.org/faq/wallets-and-seeds/#5-can-someone-use-a-brute-force-attack-on-a-random-wallet-to-regenerate-its-seed-words-the-words-are-not-salted]
_DESCRIPTION:
Simple utility to convert a Decred seed hex to seed words needed for importing into wallets.
[https://github.com/davecgh/dcrseedhextowords]
name::
* McsEngl.dcrwltCli'Money@cptIt,
name::
* McsEngl.dcrwltCli'Sending-to-address@cptIt,
dcrctl --wallet sendfrom "fromaccount" "toaddress" amount (minconf=1 "comment" "commentto")
Send DCR from the given account to the given address. You can add an optional comment.
dcrctl --wallet sendtoaddress "address" amount ("comment" "commentto")
Similar to above but uses the default account to send from.
dcrctl --wallet sendtoaddress TseGH6Xfq9k8Co6txJbY3kiiM7vpaYzXD4T 13
name::
* McsEngl.dcrwltCli'Passphrase@cptIt,
* dcrctl -wallet walletpassphrase "passphrase" timeout
Unlock the wallet using the given pass phrase for the given time period in seconds. 0 will unlock the wallet until it is restarted.
dcrctlc --wallet walletpassphrasechange "oldpassphrase" "newpassphrase"
Change your wallet passphrase.
name::
* McsEngl.dcrwltCli'Creating@cptIt,
_DESCRIPTION:
> dcrwallet --create
Enter the private passphrase for your new wallet:
[https://docs.decred.org/getting-started/user-guides/windows/#create-your-wallet]
name::
* McsEngl.dcrwltCli'Connecting-to-network@cptIt,
_DESCRIPTION:
Now that you have created your wallet and connected to the Decred network, you need to link your wallet to the network so it can send and receive coins and participate in mining.
[https://docs.decred.org/getting-started/user-guides/windows/#create-your-wallet]
name::
* McsEngl.dcrwltCli'Deleting@cptIt,
Deleting Your Wallet
There are a few reasons you might need to delete your wallet.
- You need to restore your wallet from seed.
- You do not have the seed any more and want to make a new wallet.
- You want to remove the wallet from a particular computer.
First you need to find the wallet directory which varies by platform. You can find information for each opperating system here.
In that directory, you need to delete the file mainnet/wallet.db. That will completely remove your wallet from that computer. To access it again you will need to restore from the original seed.
It is important to note that it is possible (but not certain) that a deleted file may be recovered using file recovery tools. If you are deleting this for security reasons you probably need to use a secure deletion tool such as GNU shred.
[https://docs.decred.org/advanced/deleting-your-wallet/]
name::
* McsEngl.dcrwlt.WEB@cptIt,
* McsEngl.dcrnet'browser-wallet@cptIt,
_FAQ:
1. How secure is the web client?
The web client is a fork of Copay, so it is as secure as that1. The seed (and hence private keys) are kept and computed locally in your browser’s local storage and everything is run client-side. The server never has access to any of the private data needed to spend coins.
2. Can you solo stake mine with the web client?
No, recall that the browser wallet runs locally on your machine. That would not lend itself well to running 24/7. As a result, the browser wallet will never be able to solo stake2. It would however be possible to support stake pooling with it. Stake pools provide you with the ability to not have a wallet running 24/7 since it will be the pool’s responsibility to be online and cast a vote on your behalf at that point.
3. Is it safe to delete the wallet and start over?
It is safe3. The only difference is you will need to go to Import Wallet this time instead of creating a new one.
[https://docs.decred.org/faq/web-client/]
name::
* McsEngl.dcrnet'Security@cptIt,
FAQ.4. What are the security implications of using the same RPC server authentication passwords with dcrd and dcrwallet?
There is a lot less you can do with access to dcrd than you can to dcrwallet. The key point is that RPC access to dcrwallet, when the wallet is unlocked, can be used to spend coins.
When they are both on the same machine, it probably does not matter all that much, but when you are running more secure setups where the wallet is on a separate machine than dcrd, you would pretty clearly not want to use the same credentials for both. Remember that dcrd has to be on an Internet-facing machine in order to stay synced to the network (download the block chain data, broadcast transactions, and so on).
On the other hand, the dcrwallet that contains your funds, for best security, should really not be on a system that has Internet access as it is significantly more difficult for someone to steal your coins if the wallet that contains them is not even on a machine that is accessible via the Internet. Obviously, if you are staking your coins, you will need at least one Internet-facing dcrwallet instance. Thus, the most secure setup involves having one “cold” dcrwallet instance that is on a machine that is not Internet-accessible, and a second “hot” dcrwallet instance (using a different seed of course) to which the cold dcrwallet instance delegates voting right via the --ticketaddress parameter, both of which use different credentials.
[https://docs.decred.org/faq/configuration/#4-what-are-the-security-implications-of-using-the-same-rpc-server-authentication-passwords-with-dcrd-and-dcrwallet]
name::
* McsEngl.dcrnet'Resource@cptIt,
_ADDRESS.WPG:
* https://decred.org//
* docs: https://docs.decred.org//
* https://wiki.decred.org/Main_Page,
* download: https://github.com/decred/decred-release/releases,
* source: https://github.com/decred,
* https://stats.decred.org//
name::
* McsEngl.dcrnet.MAIN@cptIt,
* McsEngl.dcrnet.mainnet@cptIt,
name::
* McsEngl.dcrnet.TEST@cptIt,
* McsEngl.dcrnet.testnet@cptIt,
_DESCRIPTION:
3. Can I run mainnet and testnet daemons and wallets at the same time and on the same machine?¶
Yes3, just add --testnet to the appropriate spots (dcrd, dcrwallet, dcrctl) and everything will work. This is why they use different ports and data/log directories!
[https://docs.decred.org/faq/configuration/#3-can-i-run-mainnet-and-testnet-daemons-and-wallets-at-the-same-time-and-on-the-same-machine]
name::
* McsEngl.bcnnet.time.PIVX (PIVXnet {2016-01-29})@cptIt,
_DESCRIPTION:
PIVX, Private Instant Verified Transaction, is a privacy-focused, decentralized, open source cryptocurrency run by a global community run by creators, innovators, and technology enthusiasts.
[https://pivx.org/]
name::
* McsEngl.pivxnet'Consensus-evt (PIVXcevt)@cptIt,
_DESCRIPTION:
PIVX (PIVX)
$2.10 (16.06%)
0.00178412 BTC (17.03%)
Rank 10
Currency
Market Cap
$111,236,380
94,560 BTC
Volume (24h)
$2,698,460
2,294 BTC
Circulating Supply
53,000,748 PIVX
[https://coinmarketcap.com/currencies/pivx/] {2017-04-16}
name::
* McsEngl.pivxnet'Governance@cptIt,
_DESCRIPTION:
Governance:
Our goal for the PIVX Governance system is to involve the community. We’ve got a long way to get there, but soon we expect to be making huge initial steps. This process will take a long time, and we call it Community Designed Governance.
This page explains the 3 areas of the Governance system and how voting is managed.
All areas of DAO Governance follow the same process in terms of submitting a proposal, and Master Node Owners voting to accept/reject the proposal. Such voting can only happen at each Super Block. (Roughly once per month.)
There are 3 types of Proposals:
Manifesto Governance:
This will very rarely – almost never – happen, and will require a high amount of participation (Metric not yet defined) by Master Node Owners (MNOs) during the voting process. Key is to make sure that even MNOs that typically don’t involve themselves with voting for proposals, are made aware a Manifesto Proposal has been submitted, and that they have been well informed of the issue(s) involved in a factual and unbiased way.
Treasury Governance:
These proposals are the most common and are for allocating funds in the monthly treasury budget. These funds can be used for anything related to support PIVX. It may be overhead costs for servers, or Google Apps etc., or it may be for advertising, or to help launch a business that could not be justified otherwise.
Protocol Governance:
These proposals are zero cost and are to make decisions to change the code base – the protocol – of the PIVX system. If such a decision requires funding, then that funding portion would be a separate Treasury Governance proposal submitted after the Protocol Governance proposal has been accepted.
[https://pivx.org/governance/]
name::
* McsEngl.pivxnet'Resource@cptIt,
_ADDRESS.WPG:
* https://pivx.org//
* BlockH0: http://www.presstab.pw/phpexplorer/PIVX/block.php?blockhash=0000041e482b9b9691d98eefb48473405c0b8ec31b76df3797c74a78680ef818,
name::
* McsEngl.bcnnet.time.BitShares2 (BTSnet {2015-10-13})@cptIt,
* McsEngl.BitShares-network@cptIt,
* McsEngl.btsnet@cptIt,
_DESCRIPTION:
BitShares - Your share in the Decentralized Exchange
Built using the latest in industry research, BitShares 2.0 offers a stack of financial services including exchange and banking on a blockchain.
[https://bitshares.org/]
_GENERIC:
* Blockchain-network-with-builtin-decentralized-governance#ql:idBcnnetBig#,
* Exchange-value-token-blockchain-network#ql:idBcnnetEvtkn#
name::
* McsEngl.btsnet'whole.DAO (btsdac)@cptIt,
* McsEngl.BitShares-Decentralized-autonomous-company@cptIt,
* McsEngl.btsdac@cptIt,
_DESCRIPTION:
BitShares is a decentralized autonomous company, and as such offers products to earn their shareholders a profit.
As we have seen in the previous section, it also offers a way to pay for expense, such as development and administration but earns a profit by burnning (i.e. reducing supply).
Of course, the company can only be profitable if the income exceeds the expenses.
Thus, we will now discuss both in detail.
[idBtswpr4]
name::
* McsEngl.btsnet'Protocol (btsprl)@cptIt,
name::
* McsEngl.btsprl'White-paper.2015-12-18 (btswpr)@cptIt,
_ADDRESS.WPG:
* http://docs.bitshares.eu/_downloads/bitshares-general.pdf,
BITSHARES 2.0: GENERAL OVERVIEW
Fabian Schuh, Daniel Larimer
Cryptonomex, Cryptonomex.com( * #ql:idBtswprnota#)
Blacksburg (VA), USA
{ fabian, dan}@cryptonomex.com
Release: financial-platform/1.0-rc2-2-gb5c3ca7 (2015-12-18)
BitShares 2.0 is an industrial-grade decentralized platform built for high-performance financial smart contracts.
The decentralized exchange that allows for trading of arbitrary pairs without counterparty risk facilitates only one out of many available features.
Market-pegged assets, such as the bitUSD, are crypto tokens that come with all the advantages of traditional cryptocurrencies like bitcoin but trade for at least the value of their underlying asset, e.g. $1.
Furthermore, BitShares represents the first decentralized autonomous company that lets its shareholders decide on its future direction and products.
This paper gives a brief overview over the whole BitShares platform, recapitulates known blockchain technologies and redefines state-of-the-art.
BitShares is a technology supported by next generation entrepreneurs, investors, and developers with a common interest in finding free market solutions by leveraging the power of globally decentralized consensus and decision making.
Consensus technology has the power to do for economics what the internet did for information.
It can harness the combined power of all humanity to coordinate the discovery and aggregation of realtime knowledge, previously unobtainable.
This knowledge can be used to more effectively coordinate the allocation of resources toward their most productive and valuable use.
Bitcoin is the first fully autonomous system to utilize distributed consensus technology to create a more efficient and reliable global payment network.
The core innovation of Bitcoin is the Blockchain, a cryptographically secured public ledger of all accounts on the Bitcoin network that facilitates the transfer of value from one individual directly to another.
For the first time in history, financial transactions over the internet no longer require a middle man to act as a trustworthy, confidential fiduciary.
BitShares looks to extend the innovation of the blockchain to more industries that rely upon the internet to provide their services.
Whether its banking, stock exchanges [-1-#ql:idBtswprref1#], lotteries [-2-#ql:idBtswprref2#], voting [-3-#ql:idBtswprref3#], music [-4-#ql:idBtswprref4#], auctions or many others, a digital public ledger allows for the creation of distributed autonomous companies (or DACs) that provide better quality services at a fraction of the cost incurred by their more traditional, centralized counterparts.
The advent of DACs ushers in a new paradigm in organizational structure in which companies can run without any human management and under the control of an incorruptible set of business rules.
These rules are encoded in publicly auditable open source software distributed across the computers of the companies’ shareholders, who effortlessly secure the company from arbitrary control.
BitShares does for business what bitcoin did for money by utilizing distributed consensus technology to create companies that are inherently global, transparent, trustworthy, efficient and most importantly profitable.
Why and how BitShares achieves a decentralized but profitable business is described in more detail in a distinct paper [?].
BitShares has went through many changes and has done its best to stay on top of blockchain technology.
Towards the end of 2014 some of the DACs were merged and the X was dropped from ”BitShares X” to become simply BitShares (BTS).
The next step in the evolution of BitShares was named Bitshares 2.0, and incorporates all of the feedback and lessons learned from the BitShares stakeholders, partners, developers, marketers, and other community leaders throughout a full year of research and development.
With the former BitShares 1.0, the core development team has closely controlled the development and direction of BitShares.
With BitShares reaching maturity at version 2.0, the team is ready to remove the training wheels, and let the direction of all future development be decided completely by stakeholder vote.
By utilizing a new worker voting system that will be included in BitShares 2.0, the development will continue in whatever direction is approved by its stakeholders.
With this new structure, BitShares will be more robust, and sustainable while being agile, flexible and adaptive to overcome unforeseen hurdles of the future.
This paper is intended as an introduction to BitShares 2.0 and presents the basic concepts of the peer-to-peer nature, the distributed public ledger in form of a blockchain, and give a brief overview of the decentral consensus mechanism applied to reach blockchain state consensus.
We further discuss the basic blockchain tokens (BTS), its distribution and usage in BitShares.
We also describe the wallet and operations with the network as well as outline the functionalities of BitShares accounts.
In the BitShares network the base token is called a BitShare and carries the abbreviation BTS.
It is dividable into 105 = 100,000 sub-units.
In general, all properties of Bitcoin also apply to BTS, namely, they have value, can be transfered on the blockchain and are secured by an Elliptic Curve Digital Signature Algorithm (ECDSA) on the curve secp256k1.
In contrast to most crypto-currencies, BitShares does not claim to be a currency but rather an equity in a decentral autonomous company (DAC).
As a result, the market valuation of BitShares is free floating and may be as volatile as any other equity (e.g. of traditional companies).
Nonetheless, BTS tokens can be used as collateral in financial smart contracts [-5-#ql:idBtswprref5#] such as market pegged assets and thus back every existing smartcoin such as the bitUSD.
The following subsection recapitulate the initial distribution and supply of BTS.
BitShares has set an example of a social agreement by establishing its own sharedropping standards.
The idea behind sharedropping is that any future chain will always benefit by choosing to align itself with the ones who worked hard at making the technology possible.
The base tokens of BitShares 2.0 will be distributed on a 1:1 basis fully honoring the BTS tokens in the BitShares 1.0 network.
For the sake of completeness, the following paragraphs will describe the initial distribution of BTS tokens in the aforementioned BitShares 1.0 network from PTS and AGS.
The original grandfather prototype, formerly called proto-shares (PTS), BitShares PTS was a simple minable cryptocurrency (similar to Bitcoin) that was created to allow people to advertise their interest in receiving free token samples in future DACs.
PTS functions as a high-tech mailing list for distributing free sample bitshares from many developers of decentral autonomous companies (DACs).
The only people who tended to own PTS tokens were those who understand DACs, so DAC developers prefer to target them with free samples rather than air dropping their samples onto a much less interested general population.
The industry recommendation was that when a DAC is launched, at least 10% of the DAC’s total tokens are given proportionally to holders of PTS.
This was not a contract or a guarantee; it was a social consensus of those in the DAC community about what percentage of a new DAC’s tokens should be distributed to those who have supported the BitShares industry by owning its PTS tokens.
The BitShares DAC honored this social consensus and even sharedropped 47% of its ever existing supply onto BitShares PTS holders.
The original grandmother prototype formerly called angel-shares (AGS) in reference to the patron angels who once funded the performing arts.
That’s why AGS are not liquid. (No one can trade the proof that you were the once willing to donate to this cause.)
The donations have been recorded in the public blockchain of bitcoin which now acts as a book of honorable donors.
The bitcoin address used as donation address was
1ANGELwQwWxMmbdaSWhWLqBEtPTkWb8uDc
Note, that the donation period for AGS lasting 200 days has ended already and that donations to this address never resulted nor will result in any obligations whatsoever.
Since the social consensus includes AGS, the industry recommendation again is to give at least 10% to holders of AGS.
Similar to BitShares PTS, the 47% of the total BTS supply have been sharedropped onto members of the AGS mailing-list proportionally.
We see that the seed allocation (initial distribution) of BitShares, which took place over a 1 year period, from November 2013 to November 2014, was achieved by sharedropping 47% to BitShares PTS and another 47% to BitShares AGS.
This way, the full, fairness was defined by equal opportunity and in the case of BTS we have distributed fairly by CPU mining of PTS while, alternatively, everyone had an additional equal opportunity by contribute to AGS.
Having attracted two different groups of investors with a mined crypto token via PTS and a donation based book of donors via AGS, everyone had a chance to participate and be rewarded with stake in the genesis block of BitShares 1.0.
This genesis block solely consisted of AGS and PTS holders on a 50%/50% ratio such that the BTS tokens initially issued by this genesis can be considered well distributed.
The other 6% are set aside to secure the future of BitShares and funds its development and operational costs.
In practice, they are put into the so called reserves pool that no one has control over except the BitShares protocol.
In contrast to many other cryptocurrencies, every shareholder has a say as to how these funds are spend (see section 4.2).
Let us discuss the organization structure of the BitShares network when interpreted as a company.
Some of these entities are associated with a cost for the business and need to be accounted for in profit calculations.
In BitShares, the witnesses’ job is to collect transactions, bundle them into a block, sign the block and broadcast it to the network.
They essentially are the block producers for the underlying consensus mechanism (see section 5.4).
For each successfully constructed block, a witness is payed in shares that are taken from the limited reserves pool at a rate that is defined by the shareholders by means of approval voting.
Since Bitcoin struggled to reach a consensus about the size of their blocks, the people in the cryptocurrency space realized that the governance of a DAC should not be ignored.
Hence, BitShares offers a tools to reach on-chain consensus about business management decisions.
The BitShares blockchain has a set of parameters available that are subject of shareholder approval.
Shareholders can define their preferred set of parameters and thereby create a so called committee member or alternatively vote for an existing committee member.
The BitShares committee consists of C active committee members.
For each business parameter the protocol will calculate the difference between up- and down-votes (vpro - vcon) for each active committee member and then take the median of the top C active members:
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgBtswprFigAlg.png!#
Since, C is a parameter as any other, the shareholders decide for the size of the committee.
The BitShares ecosystem has a set of parameters available that are subject of shareholder approval.
Initially, BitShares has the following blockchain parameters:
fee structure:
fees that have to be paid by customers for individual transactions
block interval:
i.e. block interval, max size of block/transaction
expiration parameters:
i.e. maximum expiration interval
witness parameters:
i.e. maximum amount of witnesses (block producers)
committee parameters:
i.e. maximum amount of committee members
witness pay:
payment for each witnesses per signed block
worker budget:
available budget available for budget items (e.g. development)
Please note that the given set of parameters serves as an example and that the network’s parameters are subject to change over time.
Additionally to defining the parameters any active witness can propose a protocol or business upgrade (i.e. hard fork) which can be voted on (or against) by shareholders.
When the total votes for the hard fork are greater than the median witness weight w then the hard fork takes effect.
Thanks to the funds stored in the reserve pool, BitShares can offer to not only pay for its own development and protocol improvement but also support and encourage growth of an ecosystem.
In order to be get paid by BitShares, a proposal containing
(a) the date of work begin,
(b) the date of work end,
(c) a daily pay (denoted in BTS),
(d) the worker’s name, and
(e) an internet address
has to be publish on the blockchain and approved by shareholders.
A worker can also choose on of the following properties:
• vesting: pay to the worker’s account
• refund: return the pay back to the reserve pool to be used for future projects
• burn: destroys the pay thus reducing share supply, equivalent to share buy-back of a company stock.
A blockchain parameter (defined by shareholders through the committee) defines the daily available budget.
No more than that can be paid at any time to all so called workers combined.
The daily budget is distributed as illustrated in fig. 1:
(1) The available budget is taken out of reserves pool.
(2) The budget items are sorted according to their approval rate (vpro - vcon) in a descending order.
(3) Starting at the worker with the highest approval rate, the requested daily pay is payed until the daily budget is depleted.
(4) The worker with the least approval rate that was paid may receive less than the requested pay
Hence, in order to be successfully funded by the BitShares ecosystem, the shareholder approval for your budget item needs to be highly ranked.
Since the payments for workers from the non-liquid reserve pool result in an increased supply of BTS, these payments are vesting over a period of time defined by shareholders.
'def.Proxy-Voting' denotes the process of handing out ones voting power to someone else.
This process can be reverted to reclaim ones voting power.
The motivation behind proxy voting is to reduce voting apathy and allow active shareholders to react more quickly to business and security concerns.
That way, misbehaving witnesses can be fired more rapidly.
That is centralizing in some respects, but it’s controlled centralization in the sense that nothing can happen too quickly and if shareholders don’t like which way it is going, still have the ability to switch courses.
Compared to classical crypto currencies (e.g. Bitcoin), this process is somewhat similar to pooled mining with the exception that every shareholder can participate and only voting power is handed over.
Furthermore, this allows for independent non-profit oriented decisions because there is no profit variance but purely political influence.
# idBtswprfig1#
#!imgBtswprFig1.png!#
Figure 1: Illustration of budget item payments.
BitShares is a decentralized autonomous company, and as such offers products to earn their shareholders a profit.
As we have seen in the previous section, it also offers a way to pay for expense, such as development and administration but earns a profit by burnning (i.e. reducing supply).
Of course, the company can only be profitable if the income exceeds the expenses.
Thus, we will now discuss both in detail.
The BitShares DAC offers their private customers several products and in this paper we would like to briefly highlight some of them.
Of course, all of these come with the properties of cryptocurrencies, namely
(a) global accessibility,
(b) customizable anonymity,
(c) industry-grade security,
(d) freedom from counterparty-risk,
(e) flexible account Control,
(f) low transaction delays, and
(g) world-wide decentralized network.
Keep in mind that, as BitShares has the technical possibilities to upgrade itself with shareholder approval, new products and properties can be added in a timely manner.
The core product of BitShares is a class of assets referred to as Market-Pegged Assets (MPA), BitAssets, or SmartCoins and represent a crypto-token that has at least the value of the underlying asset.
For instance, a bitUSD can always be sold for $1, either to a merchant at face-value, or to the network (by means of settlement of a contract) in return for BitShares’ core currency (BTS) worth $1.
In practice, a SmartCoin always has 100% or more of its value backed by means of a contract for difference (CFD) between two parties with BTS as collateral.
What makes these CFDs unique is that they are free from counterparty risk.
This is achievable by letting the network itself (implemented as a software protocol) be responsible for securing the collateral and performing (forced) settlements if required as is described in more detail in [-5-#ql:idBtswprref5#].
Applications for SmartCoins are obvious:
With the aforementioned properties, a bitUSD qualifies for regular and instant payments, for example with a smartphone or a modern browser application.
In contrast, a bitGOLD (with one ounce of gold as underlying asset) would fit those people’s needs that see gold as long-term store of value.
As long as an asset has a unique global price, a SmartCoin could track its value.
This allows for even more sophisticated applications, such as tracking a stock market index, or the price of a liter of gasoline.
In addition to market-pegged assets, the BitShares network also offers to register customizable assets on the public ledger.
For instance, a BitShares customer may create the asset FREE and distribute them to friends for free.
Another customer may want his company shares to be traded in the BitShares network.
Yet another use-case would be event tickets that can be sold at a fixed price and allow the holder to enter a concert.
Since the use-cases of these User-Issued Assets (UIA) are manifold and space is limited in this paper, we discuss them in depth in [-5-#ql:idBtswprref5#].
As we have seen in the previous section, the BitShares network offers to register different types of assets.
It also allows for trading between almost(-1-#ql:idBtswprnot1#) any two pairs in an instant, trust-less and secure manner by means of the BitShares Decentralized Exchange (DEX).
In traditional trading, a clearing house is necessary because trades are made much faster than the cycle time for completing the underlying transaction.
Since in BitShares trades between two parties are performed on a global scale in a decentralized network and no middlemen are required, there is no need for settlement or clearing delays.
If a trade in the DEX executes, the bought asset instantly (T+0 [-6-#ql:idBtswprref6#]) appears in the customers wallet.
In combinations with SmartCoins, a startup could easily perform a dollar-denominated crowd-funding without legal or tax implications due to the velocity of cryptocurrency tokens.
Furthermore, as all order-books are shared on a global scale, the markets will become more efficient because no different prices existing on different locations on earth.
Of course, the DEX is open 24/7 and does not apply any limits to customers.
A more detailed discussion about the DEX can be found in a distinct paper [-5-#ql:idBtswprref5#].
In BitShares, each account is separated into
• Active Permission which has control over its funds and
• Owner Permission which controls the account itself.
Furthermore, BitShares uses authorities consisting of one or many entities that authorize an action, such as transfers, trades or account modifications.
An authority consists of one or several pairs of an account name with a weight.
In order to obtain a valid transaction, the sum of the weights from signing the parties has to exceed the threshold as defined in the permissions.
Let’s discuss some examples to shed some light on the used terminology and the use-cases.
We assume that a new account is created with it’s active permissions set as described below.
Note that the same scheme also works for the owner permissions!
A flat multi-signature scheme is composed of M entities of which N entities must sign in order for the transaction to be valid.
Now, in BitShares, we have weights and a threshold instead of M and N.
Still we can achieve the very same thing with even more flexibility as we will see now.
Let’s assume, Alice, Bob, Charlie and Dennis have common funds.
We want to be able to construct a valid transaction if only two of those agree.
Hence a 2-of-4 (N-of-M) scheme can look as follows:
Account Weight
Alice 33%
Bob 33%
Charlie 33%
Dennis 33%
Threshold: 51%
All four participants have a weight of 33% but the threshold is set to 51%.
Hence only two out of the four need to agree to validate the transaction.
Alternatively, to construct a 3-of-4 scheme, we can either decrease the weights to 17 or increase the threshold to 99%.
With the threshold and weights, we now have more flexibility over our funds, or more precisely, we have more control.
For instance, we can have separate weights for different people.
Let’s assume Alice wants to secure here funds against theft by a multisignature scheme but she does not want to hand over too much control to her friends.
Hence, we create an authority similar to:
Account Weight
Alice 49%
Bob 25%
Charlie 25%
Dennis 10%
Threshold: 51%
Now the funds can either be accessed by Alice and a single friend or by all three friends together.
Let’s take a look at a simple multi-hierarchical corporate account setup.
We are looking at a company that has a Chief of Financial Officer (CFO) and a some departments working for him, such as the Treasurer, Controller, Tax Manager, Accounting, etc.
The company also has a CEO that wants to have spending privileges.
Hence we construct an authority for the funds according to:
Account Weight
CEO.COMPANY 51%
CFO.COMPANY 51%
Threshold: 51%
whereas CEO.COMPANY and CFO.COMPANY have their own authorities.
For instance, the CFO.COMPANY account could look like:
CFO.COMPANY Weight
Chief.COMPANY 51%
Treasurer.COMPANY 33%
Controller.COMPANY 33%
Tax Manager.COMPANY 10%
Accounting.COMPANY 10%
Threshold: 51%
This scheme allows:
• the CEO to spend funds
• the Chief of Finance Officer to spend funds
• Treasurer together with Controller to spend funds
• Controller or Treasurer together with wither the Tax Manager or Accounting to spend funds.
Hence, a try of arbitrary depth can be spanned in order to construct a flexible authority to reflect mostly any business usecase.
In the BitShares ecosystem every operation is assigned an individual fee that has to be payed in the core asset (BTS) the end user.
These fees are subject to change and are defined by the elected committee members.
Thus each and every shareholder of the BitShares core asset (BTS) has a say as to what the fees should be.
If shareholders can be convinced to reduce a certain fee and consensus is reached, the fee will be reduced automatically by the blockchain.
This allows the ecosystem, to stay flexible and adept the price for the usage of its products over time.
Since the network expects the fees to be payed on the the core asset (BTS) but many users may not want to hold any, the protocol allows to trade an arbitrary asset into BTS from the asset-specific *fee pool* at the *core exchange rate* which is defined by the issuer (or the witnesses in the case of a market pegged asset).
Revenue streams are essentially caused by fees that have to be payed when using the DACs products, such as market pegged assets, user-issued assets, or the decentralized exchange [-5-#ql:idBtswprref5#].
These fees are variable, can be changed by shareholder approval and include
(a) transfers,
(b) order operations,
(c) account operations,
(d) asset operations,
(e) witness creations
(f) proposal operations
(g) withdraw permission operations
(h) committee member operations,
(i) worker creation, and more.
In contrast to bitcoin, where newly created coins in each block are distributed solely among countless miners that immensely overpay for the network security [-7-#ql:idBtswprref7#], the BitShares ecosystem achieves a better security at lower costs by means of an adjustable number of approved and trusted witnesses in DPOS.
Additionally, the BitShares ecosystem has the capability to pay for its own development through budget items.
Both, the payment for witnesses, as well as the budget items are required to be approved by the shareholders.
#idBtswprfig2#
#!imgBtswprFig2.png!#
Figure 2: Cash flow of BitShares 2.0
As an example, an entrepreneur may approach the shareholders and offer to launch a business in the BitShares space that would greatly benefit the ecosystem.
If he succeeds and convinces the shareholders to vote for and not against his plan, he could get an initial funding by the DAC.
Another use-case would be the improvement of the blockchain’s protocol.
A developer could propose a change or extension of the existing software implementation and be payed by the DAC to do so (after shareholder approval).
Hence, as long as the average shareholders acts rational, the BitShares blockchain can be seen as a self-funded but profitable business
Accounts in BitShares are separated into three groups.
We decided to give users the option to upgrade their accounts into a VIP-like status if they desire and profit from reduced fees and additional features.
A regular account is a non-member.
Lifetime Members get a percentage cashback on every transaction fee they pay and qualify to earn referral income (see below) from users they register with or refer to the network.
A Lifetime membership is associated with a certain one-time fee that is defined by the committee and qualifies for reduced transaction fees.
If a lifetime membership is too much you can still get the same cashback for the next year by becoming an annual subscriber for a smaller one-time fee which lasts for only one year and qualifies for reduced transactions fee during that time.
Every time an account you referred pays a transaction fee, that fee is divided among several different accounts.
The network takes a cut, and the Lifetime Member who referred the account gets a cut.
The registrar is the account that paid the transaction fee to register the account with the network.
The registrar gets to decide how to divide the remaining fee between themselves and their own affiliate.
Fees paid are only divided among the network, referrers, and registrars once every maintenance interval.
The paid fees are divided among two or three parties, depending on the parameter d that can be set by the registrar:
total fee = network fee(20%)
+ registrar(80% · (100% - d%)) (1)
+ referrer(80% · (d%))
Most fees are made available immediately, but fees over the vesting threshold (such as those paid to upgrade your membership or register a premium account name) must vest for some days as defined by the committee.
Before describing how BitShares can be used to secure financial freedom, we first discuss the technical specifications briefly.
Among these is the public ledger (also referred to as the blockchain), the peer-to-peer network, the distributed consensus finding mechanism and the system parameters available to BitShares.
As in other crypto-currencies, the public ledger of BitShares is built and stored in a linked series of blocks, known as a blockchain.
The ledger provides a permanent record of transactions that have taken place, and also establishes an order in which transactions have occurred.
Hence, every content of the blockchain can be assigned an permanent and unique identifier in form of a scalar number.
Every full node in the BitShares network stores a full copy of this blockchain and can verify its validity and the evaluate new blocks.
Every block contains
• a reference to the previous block,
• a timestamp,
• a hash of a secret,
• the secret of the previous hash,
• a set of transactions, and
• a signature by the block producing authority
As will be discussed in section-5.4#ql:idBtswpr54#, the consensus mechanism allows for synchronous block production with constant block confirmation times, e.g., one block every 5 s.
Since the blocks mainly embrace customer transactions but has to perform time intensive tasks, or execute rare events from time to time, some actions such as reenumeration of blockchainbased votes and rare events such as newly registered block producers (witnesses) are carried out more rarely but still on a frequent so called 'defn.maintenance-interval'.
Historically we have stated that a blockchain becomes irreversible after one round of block production with greater than 51% participation.
It turns out that this metric is too fuzzy because of noise in how witnesses are ordered.
In an effort to provide stronger/absolute guarantees a new metric has been derived that determines the exact point at which a particular block becomes irreversible.
The algorithm to define the metric goes as follows:
Sort N witnesses by the last block number they signed, then take the highest block number that is lower than 66% of all other witnesses.
This will indicate that said block has been confirmed by 66% of all witnesses and is clearly irreversible.
This particular metric is dynamic and can respond to changes in the order of witnesses and is immune to situations where the network fragments into more than two pieces.
In the event of a major disruption users are guaranteed that no block older than that number can ever be undone.
If we had only 17 witnesses and 3 second block confirmation interval, then this will take an average of 34 seconds.
If we had 101 witnesses and 3 second blocks then this will take an average of 3.3 minutes for block to be irreversible,
Having this metric is important to give everyone in the network peace of mind in the unlikely event that a software bug or network issue causes all witnesses to fall out of sync and gives a clear measure of when they are considered back in sync.
Anyone accepting transactions as final prior to the most recent irreversible block is choosing to take some extra risk on their transaction.
The peer-to-peer network distributes the full blockchain database across the world.
It consists of public and private nodes as well as seed nodes that are used for initial connection to the peer-to-peer network.
Anybody may connect to any known node and download the current global and unique state (i.e. the blockchain).
Once a node is in sync with the peer-to-peer network it received and applies newly created blocks, and assists new network nodes by further distribution of the blockchain.
Additionally, new blocks are broadcast to all connected nodes.
Furthermore, network nodes receive transaction from participants and forward them to the rest of the network until they reach the witness that is in charge of constructing the next block.
Hence, new transaction broadcasts do not necessarily need to reach all nodes.
Building a low-latency network requires P2P nodes that have low-latency connections and a protocol designed to minimize latency.
For the purpose of this document we will assume that two nodes are located on opposite sides of the globe with a ping round-trip time of 250 ms.
In the Bitcoin network architecture, transactions and blocks were broadcast in a following manner: inventory messages notify peers of transactions and blocks, then peers fetch the transaction or block from one peer.
After validating the item a node will broadcast an inventory message to its peers.
Under this model it will take approximately 0.75 s for a peer to communicate a transaction or block to another peer even if their size was 0 and there was no processing overhead.
This level of performance is unacceptable for a network attempting to produce one block every second.
This prior protocol also sent every transaction twice: initial broadcast, and again as part of a block.
To minimize latency each node needs to immediately broadcast the data it receives to its peers after validating it.
Given the average transaction size is less than 100 bytes, it is almost as efficient to send the transaction as it is to send the notice (assuming a 20 byte transaction id).
Consensus is the mechanism by which a subset of people decide upon unitary rational action.
The process of consensus decisionmaking allows for all participants to consent upon a resolution of action even if not the favored course of action for each individual participant.
Bitcoin was the first system to integrate a fully decentralized consensus method with the modern technology of the internet and peer-to-peer networks in order to more efficiently facilitate the transfer of value through electronic communication.
The proof-of-work structure that secures and maintains the Bitcoin network is one manner of organizing individuals who do not necessarily trust one another to act in the best interest of all participants of the network.
It is of importance to distinguish a democratic voting process in which every citizen of a community has one and only one vote from a distributed consensus mechanism in crypto-currencies hand over voting power either in relation to hashing power (e.g. proof-of-work) or on a per stake basis (e.g. proof-of-stake).
In both cases, those that invest in the required infrastructure to increase their voting percentage (i.e. by buying mining hardware or stake) act as 'defn.shareholder' in a distributed community.
The BitShares community employs Delegated Proof-of-Stake (DPOS) in order to find efficient solutions to distributed consensus decision making.
DPOS attempts to solve the problems of both Bitcoin’s traditional proof-of-work system, and the proofof-stake system of Peercoin and NXT by implementing a layer of technological democracy to offset the negative effects of centralization.
For historical reasons, the technology is still called delegated proof-of-stake even though what have been delegates in BitShares 1.0 are now so called 'defn.witnesses'.
In DPOS set of N witnesses (formerly known as delegates) sign the blocks and are voted on by those using the network with every transaction that gets made.
By using a decentralized voting process, DPOS is by design more democratic than comparable systems.
Rather than eliminating the need for trust all together, DPOS has safeguards in place the ensure that those trusted with signing blocks on behalf of the network are doing so correctly and without bias.
A more detailed description about the distributed consensus mechanism as well as a discussion how blockchain forking is prevented during attacks is given in a separate paper [-8-#ql:idBtswprref8#].
Additionally, each block signed must have a verification that the block before it was signed by a trusted node.
DPOS eliminates the need to wait until a certain number of untrusted nodes have verified a transaction before it can be confirmed.
This reduced need for confirmation produces an increase in speed of transaction times.
By intentionally placing trust with the most trustworthy of potential block signers, as decided by the network, no artificial encumbrance need be imposed to slow down the block signing process.
DPOS allows for many more transactions to be included in a block than either proof of work or proof of stake systems.
In a delegated proof-of-stake system, centralization still occurs, but it is controlled.
Unlike other methods of securing cryptocurrency networks, every client in a DPOS system has the ability to decide who is trusted rather than trust concentrating in the hands of those with the most resources.
DPOS allows the network to reap some of the major advantages of centralization, while still maintaining some calculated measure of decentralization.
Furthermore, once a witness has reached approval by shareholders, surpasses the threshold of the most N active witnesses, and, hence, is elected to actively participate in the block production procedure, its power is equivalent to all other active witnesses.
This system is enforced by a fair election process where anyone could potentially become a delegated representative (witness) of the majority of users.
Please note that DPOS has a recommended 1 - 2 block confirmation versus bitcoin’s 6 block recommendation.
DPOS is much more resistant against forks for the following reasons:
• When a fork is produced it is very likely that all witnesses have seen and processed your transaction and thus no alternative transactions can be broadcast and the next witness is almost certain to include your transaction.
All witnesses are much more trusted than miners.
• The probability of a fork after a block has been produced is very low (΅ 0.01%) where as Bitcoin has 25 orphans in the last 22 days (about 1 per day in Dec 3, 2014) which translates into 0.7% of blocks are orphaned.
• On normal operations, DPOS achieves a 100% witness participation rate and when we are less than that it is more often because a witness went offline and didn’t produce a block than because they produced a fork.
• In BitShares 1.0 forks have almost always been resolved within 30 seconds.
Assuming a 10 second block interval, Bitshares is mathematically over 70x less likely to orphan after 1 block than Bitcoin after 1 block (10 minutes).
After 3 blocks (30 seconds) any random orphan will have been resolved and the probability of alternative chains is much lower than the 0.000001% of Bitcoin.
By the time Bitcoin gets to .7% orphan probability, BitShares has 60 blocks which would have a probability of being orphaned of less than 10-120.
Similar to most crypto-currencies, there is a set of predefined operations that can be performed on the blockchain.
In contrast to Bitcoin, which uses a technique called script to describe operations that shall be performed in a programmatic way using OP codes, the BitShares network has a predefined (but extensible) set of operations that a user may perform.
All operations end up on the blockchain eventually.
Once they are validated and confirmed by a witness by being included into a block, they are executed and update the state of the blockchain accordingly.
The release version of BitShares 2.0 comes with
(a) transfer ops,
(b) trading order ops,
(c) account ops,
(d) asset ops,
(e) witness ops,
(f) committee ops,
(g) worker ops, and
(h) vesting ops,
However, since BitShares allows for shareholder approved, live protocol upgrades, the set of operations can be extended and modified.
On the blockchain level, each operation is assigned an individual id with a custom set of parameters for performance and latency reasons.
Having defined operations, we can now put these into a list of operations and construct a transaction.
In addition to its operations, a transaction also consists of
(a) an expiration date,
(b) a reference block number,
(c) a reference block prefix,
(d) a set of extensions, and
(e) a set of signatures to authorize each operation.
Each node (including witnesses) verifies that all requires signatures to perform the given operations are present and valid prior to propagating the transactions to the rest of the network and hence to the witness node constructing the next block.
If the transaction is included into a block it is considered finally valid or executed.
Additionally, the Graphene technology allows users to propose a transaction which requires approval of multiple accounts in order to execute.
These transactions are only partially valid and do not execute until they are completely valid.
The user proposes a transaction, then signatory accounts add or remove their approvals from this operation.
When a sufficient number of approvals have been granted, the operations in the proposal are used to create a virtual transaction which is subsequently evaluated.
Even if the transaction fails, the proposal will be kept until the expiration time, at which point, if sufficient approval is granted, the transaction will be evaluated a final time.
This allows transactions which will not execute successfully until a given time to still be executed through the proposal mechanism.
The first time the proposed transaction succeeds, the proposal will be regarded as resolved, and all future updates will be invalid.
The common use-case would be similar to so called multisignature transactions which must be signed by two parties.
Classical crypto currencies had the issue that such proposed transaction had to be communicated on separated channels until all required signatures have been collected.
With BitShares, it is no possible to propose a transaction on the blockchain and have the required signatures be added by the respective parties.
The proposal system in combination with corporate accounts allows for arbitrarily complex or recursively nested authorities.
If a recursive authority (i.e. an authority which requires approval of nested authorities on other accounts) is required for a proposal, then a second proposal can be used to grant the nested authority’s approval.
That is, a second proposal can be created which, when sufficiently approved, adds the approval of a nested authority to the first proposal.
This multiple-proposal scheme can be used to acquire approval for an arbitrarily deep authority tree.
In general, BitShares has similarities and differences to most known crypto-currencies.
As many others, BitShares is based on a blockchain that stores and propagates transactions, i.e. user operations.
Since, with DPOS, computational resources are used solely for the purpose of transaction propagation and confirmation, rather than wasteful computational work, the block production interval has been reduced to a few seconds.
Eventually, this improves the over-all profitability of the DAC.
Additionally, we make use of named accounts that can be registered on the blockchain.
Users no longer need to send money to an alphanumeric string that can be copied incorrectly.
Rather, funds can be sent as easily as sending an email, and in the same fashion.
Name registration allows for the identification of who transactions are originating with no need to manually create a contact account for a given address.
Transactions may contain a memo field that allow users to describe the nature of the transaction or broadcast secure messages about the price of the current transaction fee.
Since BitShares 2.0 implements confidential transaction, there is no longer a need for mixing or master nodes.
Transactions can be more private in BitShares than in Bitcoin, for example, with no additional work needed from the user.
BitShares is a 100% proof-of-stake system.
This means it is a lot more efficient (cost per security) than proof-of-work and therefore does not have to dilute stakeholders/coinholders (there is a 10% yearly dilution of Bitcoin-holders as per 2015 with Bitcoin and lowering this dilution would mean to lower the security).
Hence, the cost of securing the BitShares network is merely a fraction of all transaction fees accumulated by the network.
The job of the block producers is simple: include as many valid transactions in your given block as possible and sign a single block.
These Block producers compete for the most approval in order to be allowed to produce blocks.
Shareholder votes are proportionate to the relative number of shares they own.
The BitShares DAC is completely shareholder run.
Now people can be hired by the blockchain.
Where coins like Bitcoin dilute to pay for network security, BitShares takes these fees and directs them towards continual improvement of the network and community.
This helps insure BitShares will stay competitive in its feature set.
More details about the consensus scheme of BitShares will be made available in a separated whitepaper.
Recalling the initial distribution of BTS, it seem convincing to assume that most alternative distributions are way more unfair and some disproportionately favor their respective core developers.
Since BitShares is a self-funded DAC, it can pay for its future development autonomously by dilution, if shareholders reach an on-blockchain consensus by approval voting.
Furthermore, it becomes clear from the descriptions that BitShares is governed by its shareholders and the committee whose members have shareholder approval.
This allows for flexible adjustment of blockchain parameters, such as transaction fees, block interval, and more, as well as protocol upgrades to include new features.
Since the BitShares is a self-funded blockchain, that can pay its workers by protocol, a healthy competition for new improvements, upgrades and additional features can be expected.
The properties and features mentioned in this paper make clear that the BitShares DAC is well-prepared for its own features.
It was shown that, due to on-blockchain voting, a decentralized development and funding can be achieved.
The consensus mechanism DPOS reaches a trade-off between efficiency and required trust while keeping a better decentralization that mostly every other blockchain consensus scheme.
# idBtswprref1#[1] Daniel Larimer, “Creating a Fiat/Bitcoin Exchange without Fiat Deposits.” https://bitcointalk.org/index.php?topic=223747.0.
# idBtswprref2#[2] “DACPlay,” http://dacPLAY.org.
# idBtswprref3#[3] Adam Ernest, “Follow My Vote,” http://followmyvote.com.
# idBtswprref4#[4] Cedric Cobban, “Follow My Vote,” http://peertracks.com.
# idBtswprref5#[5] “BitShares 2.0: Financial Smart Contract Platform,” BitShares Whitepapers, 2015.
# idBtswprref6#[6] “The trade is the settlement,” http://t0.com/.
# idBtswprref7#[7] Daniel Larimer, “Overpaying for Security,” http://letstalkbitcoin.com/is-bitcoin-overpaying-for-falsesecurity/#.Ui-p9WTFT7s.
# idBtswprref8#[8] “BitShares 2.0: Distributed Consensus,” BitShares Whitepapers, 2015.
# idBtswprnota#(*) This work was supported by Cryptonomex and honorable members of the bitsharestalk.org community.
# idBtswprnot1#(1) The issuer of an asset may white-/or black-list trading partners.
name::
* McsEngl.btsnet'Blockchain (btsbcn)@cptIt,
name::
* McsEngl.btsbcn'Block (btsblk)@cptIt,
name::
* McsEngl.btsblk.GENESIS@cptIt,
_DESCRIPTION:
Block 1
0 transactions in this block, produced at 2015-10-13 14:12 (UTC)
[https://cryptofresh.com/b/1]
name::
* McsEngl.btsnet'Consensus-exchange-value-token (BTScevt)@cptIt,
* McsEngl.bitshares-token@cptIt,
* McsEngl.btscevt@cptIt,
name::
* McsEngl.btsnet'Governance-system (btsgov)@cptIt,
* McsEngl.btsgov@cptIt,
* McsEngl.btsnet'builin-governance-system@cptIt,
* McsEngl.btsnet'Decentralized-Governance-By-Blockchain@cptIt,
name::
* McsEngl.btsnet'Commitee@cptIt,
_DESCRIPTION:
Decentralized Committee:
Decisions that can effect the BitShares ecosystem are made using a on-chain committee voted upon by shareholders.
Hence, no single entity can change the deal retroactively.
[http://docs.bitshares.eu/bitshares/user/you-should-know.html]
name::
* McsEngl.btsnet'Human (btshmn)@cptIt,
name::
* McsEngl.btshmn.SHAREHOLDER (btshsh)@cptIt,
_DESCRIPTION:
Become Shareholder: If you buy BTS either from a partner exchange or from the DEX, you become a shareholder of the BitShares decentralized business and as such can take a cut of its profits and participate in votes for future directions.
[http://docs.bitshares.eu/bitshares/user/you-should-know.html#the-investors]
name::
* McsEngl.btsnet'Organization (btsogn)@cptIt,
* McsEngl.bitshares'organization@cptIt,
* McsEngl.btsogn@cptIt,
name::
* McsEngl.btsogn.Cryptonomex-Inc@cptIt,
* McsEngl.Cryptonomex-Inc@cptIt,
_DESCRIPTION:
Cryptonomex Inc. is an independent blockchain development company founded by the core developers of the BitShares blockchain. Our mission is to faciliate the growth and adoption of industrial blockchain technology.
[https://cryptonomex.com/]
name::
* McsEngl.btsnet'Resource (btsrsc)@cptIt,
* McsEngl.bitshares'resource@cptIt,
* McsEngl.btsresource@cptIt,
* McsEngl.btsrsc@cptIt,
_ADDRESS.WPG:
* https://bitshares.org//
=== DOCS:
* http://docs.bitshares.eu//
* FIRST STEPS FOR END-USERS http://docs.bitshares.eu/bitshares/user/first-steps-users.html,
=== COMMUNITY:
* https://www.bitsharestalk.org//
name::
* McsEngl.btsnet.EVOLUTING@cptIt,
{time.2014}
Towards the end of 2014 some of the DACs were merged and the X was dropped from ”BitShares X” to become simply BitShares (BTS).
[White-paper#ql:idBtswpr#]
name::
* McsEngl.bcnnet.time.Ethereum (ETHnet {2015-07-30})@cptIt,
* McsEngl.bcnnet.ethereum@cptIt,
* McsEngl.ethereum@cptIt,
* McsEngl.ethereum-network@cptIt,
* McsEngl.ethnet@cptIt,
* McsEngl.ethereum-ecosystem@cptIt,
* McsEngl.ethereum-network@cptIt,
* McsEngl.ethereum-platform@cptIt,
* McsEngl.ethereum-project@cptIt,
* McsEngl.ethereum-space@cptIt,
* McsEngl.ethnet@cptIt,
* McsEngl.net.ethereum@cptIt,
* McsEngl.netEth@cptIt, {2017-01-28}
_DESCRIPTION:
Ethereum is a programmable blockchain.
Rather than give users a set of pre-defined operations (e.g. bitcoin transactions), Ethereum allows users to create their own operations of any complexity they wish. In this way, it serves as a platform for many different types of decentralized blockchain applications, including but not limited to cryptocurrencies.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#ethereum-virtual-machine]
_GENERIC:
* blockchain-network#ql:idMcsBcnnet#,
* stmIthCrypto#cptItsoft51.12#
_DESCRIPTION:
Ethereum is a peer to peer network where every peer stores the same copy of a blockchain database and runs an Ethereum virtual machine to maintain and alter it’s state. Proof of work is integrated into the blockchain technology by making the creation of a new block require all members of the network undertake the proof of work. Consensus is achieved via incentivization for peers to always accept the longest chain of blocks in the blockchain by distribution of a cryptographic token of value: ‘ether’.
This leaves us with a new piece of technology that does not fit within the client-server model nor does it qualify as a traditional peer-to-peer network as its existence is incentivised meaning it can be relied upon to provide a consistent deterministic service.
Because of its distributed nature and built in cryptographic security it can act as a third party, capable of arbitrating trustlessly, and without interference from outside parties. Through the use of cryptocurrencies decisions made by software can have financial consequences for people, organisations or even other software.
[https://dappsforbeginners.wordpress.com/tutorials/introduction-to-development-on-ethereum/]
===
Ether is a necessary element -- a fuel -- for operating the distributed application platform Ethereum. [https://ethereum.org/ether]
===
Ethereum is a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference.
Ethereum is how the Internet was supposed to work.
Ethereum was crowdfunded during August 2014 by fans all around the world. It is developed by ETHDEV with contributions from great minds across the globe.
[https://www.ethereum.org/]
Original author(s) Vitalik Buterin, Gavin Wood
Developer(s) Gavin Wood, Jeffrey Wilcke, Vitalik Buterin, et al
Written in C++, Go, JavaScript, Python, Java, node.js
Operating system Linux, POSIX, Windows, OS X
Type Decentralized computing
License GPL3, MIT, LGPL, et al
Website www.ethereum.org
Ethereum Software ETHEREUM-YOUTUBE-PROFILE-PIC.png
Original author(s) Vitalik Buterin, Gavin Wood
Developer(s) Gavin Wood, Jeffrey Wilcke, Vitalik Buterin, et al
Written in C++, Go, JavaScript, Python, Java, node.js
Operating system Linux, POSIX, Windows, OS X
Type Decentralized computing
License GPL3, MIT, LGPL, et al
Website www.ethereum.org
Ethereum is a blockchain-based cryptocurrency that includes a virtual machine featuring stateful user-created smart contracts and a Turing-complete contract language. Ethereum uses its currency unit, Ether, as payment to incentivise a network of peers to provide computational services defined by the smart contracts deployed on the blockchain.
Ethereum was initially described by Vitalik Buterin in late 2013,[1] formally described by Gavin Wood in early 2014 in the so-called Yellow Paper[2] and launched 30 July 2015.[3] It is among a group of "next generation" (or "Bitcoin 2.0") platforms.[4]
[https://en.wikipedia.org/wiki/Ethereum]
===
Ethereum was designed as a smart contract platform.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#5ae8]
===
Ethereum – a Decentralised Consensus Network
[https://dappsforbeginners.wordpress.com/tutorials/introduction-to-development-on-ethereum/]
===
Ethereum is the world's first publicly accessible computer. Situated on the Internet, anyone may pay a small fee to its open group of maintainers in order to use it. Secured and authenticated through cryptography, it provides a unprecedented opportunity for use as the cornerstone of IoT, Internet-law, smart contracts and the next digital economy.
[https://ethcore.io/]
===
The basis for decentralised consensus is the peer-to-peer network of participating nodes which maintain and secure the blockchain.
[https://ethereum-homestead.readthedocs.org/en/latest/ethereum-ecosystem/infrastructure.html#the-ethereum-network]
===
Ethereum is a programmable blockchain. Rather than give users a set of pre-defined operations (e.g. bitcoin transactions), Ethereum allows users to create their own operations of any complexity they wish. In this way, it serves as a platform for many different types of decentralized blockchain applications, including but not limited to cryptocurrencies.
Ethereum in the narrow sense refers to a suite of protocols that define a platform for decentralised applications. At the heart of it is the Ethereum Virtual Machine (“EVM”), which can execute code of arbitrary algorithmic complexity. In computer science terms, Ethereum is “Turing complete”. Developers can create applications that run on the EVM using friendly programming languages modelled on existing languages like javascript and python.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#what-is-ethereum]
===
Ethereum is a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference.
Ethereum is how the Internet was supposed to work.
Ethereum was crowdfunded during August 2014 by fans all around the world. It is developed by ETHDEV with contributions from great minds across the globe.
[https://www.ethereum.org/]
Original author(s) Vitalik Buterin, Gavin Wood
Developer(s) Gavin Wood, Jeffrey Wilcke, Vitalik Buterin, et al
Written in C++, Go, JavaScript, Python, Java, node.js
Operating system Linux, POSIX, Windows, OS X
Type Decentralized computing
License GPL3, MIT, LGPL, et al
Website www.ethereum.org
Ethereum Software ETHEREUM-YOUTUBE-PROFILE-PIC.png
Original author(s) Vitalik Buterin, Gavin Wood
Developer(s) Gavin Wood, Jeffrey Wilcke, Vitalik Buterin, et al
Written in C++, Go, JavaScript, Python, Java, node.js
Operating system Linux, POSIX, Windows, OS X
Type Decentralized computing
License GPL3, MIT, LGPL, et al
Website www.ethereum.org
Ethereum is a blockchain-based cryptocurrency that includes a virtual machine featuring stateful user-created smart contracts and a Turing-complete contract language. Ethereum uses its currency unit, Ether, as payment to incentivise a network of peers to provide computational services defined by the smart contracts deployed on the blockchain.
Ethereum was initially described by Vitalik Buterin in late 2013,[1] formally described by Gavin Wood in early 2014 in the so-called Yellow Paper[2] and launched 30 July 2015.[3] It is among a group of "next generation" (or "Bitcoin 2.0") platforms.[4]
[https://en.wikipedia.org/wiki/Ethereum]
name::
* McsEngl.ethnet'ATTRIBUTE@cptIt,
_ADDRESS.WPG:
* http://gavwood.com/Paper.pdf,
External Actor:
A person or other entity able to interface to an Ethereum node, but external to the world of Ethereum.
It can interact with Ethereum through depositing signed Transactions and inspecting the blockchain and associated state.
Has one (or more) intrinsic Accounts.
Address:
A 160-bit code used for identifying Accounts.
Account:
Accounts have an intrinsic balance and transaction count maintained as part of the Ethereum state.
They also have some (possibly empty) EVM Code and a (possibly empty) Storage State associated with them.
Though homogenous, it makes sense to distinguish between two practical types of account: those with empty associated EVM Code (thus the account balance is controlled, if at all, by some external entity) and those with non-empty associated EVM Code (thus the account represents an Autonomous Object). Each Account has a single Address that identifies it.
Transaction: A piece of data, signed by an External Actor. It represents either a Message or a new Autonomous Object. Transactions are recorded into each block of the blockchain.
Autonomous Object: A notional object existent only within the hypothetical state of Ethereum. Has an intrinsic address and thus an associated account; the account will have non-empty associated EVM Code. Incorporated only as the Storage State of that account.
Storage State: The information particular to a given Account that is maintained between the times that the
Account’s associated EVM Code runs.
Message: Data (as a set of bytes) and Value (specified as Ether) that is passed between two Accounts, either
through the deterministic operation of an Autonomous Object or the cryptographically secure signature of the Transaction.
Message Call: The act of passing a message from one Account to another. If the destination account is associated with non-empty EVM Code, then the VM will be started with the state of said Object and the Message acted upon. If the message sender is an Autonomous Object, then the Call passes any data returned from the VM operation.
Gas: The fundamental network cost unit. Paid for exclusively by Ether (as of PoC-4), which is converted freely to and from Gas as required. Gas does not exist outside of the internal Ethereum computation engine; its price is set by the Transaction and miners are free to ignore Transactions whose Gas price is too low.
Contract: Informal term used to mean both a piece of EVM Code that may be associated with an Account or an Autonomous Object.
Object: Synonym for Autonomous Object.
App: An end-user-visible application hosted in the Ethereum Browser.
Ethereum Browser: (aka Ethereum Reference Client) A cross-platform GUI of an interface similar to a simplified browser (a la Chrome) that is able to host sandboxed applications whose backend is purely on the Ethereum protocol.
Ethereum Virtual Machine: (aka EVM) The virtual machine that forms the key part of the execution model for an Account’s associated EVM Code.
Ethereum Runtime Environment: (aka ERE) The environment which is provided to an Autonomous Object executing in the EVM. Includes the EVM but also the structure of the world state on which the EVM relies for certain I/O instructions including CALL & CREATE.
EVM Code: The bytecode that the EVM can natively execute. Used to formally specify the meaning and ramifications of a message to an Account.
EVM Assembly: The human-readable form of EVM-code.
LLL: The Lisp-like Low-level Language, a human-writable language used for authoring simple contracts and general low-level language toolkit for trans-compiling to.
name::
* McsEngl.ethnet'trustless@cptIt,
This is why you might have heard people call Ethereum ‘trustless’ – there’s no need for users to trust into a central authority to ‘do the right thing’.
[https://dappsforbeginners.wordpress.com/tutorials/your-first-dapp/]
name::
* McsEngl.ethnet'STATE@cptIt,
* McsEngl.ethnet'state@cptIt,
* McsEngl.ethstate@cptIt,
_DESCRIPTION:
The state in Ethereum essentially consists of a key-value map, where the keys are addresses and the values are account declarations, listing the balance, nonce, code and storage for each account (where the storage is itself a tree).
For example, the Morden testnet genesis state looks as follows:
{
"0000000000000000000000000000000000000001": {
"balance": "1"
},
"0000000000000000000000000000000000000002": {
"balance": "1"
},
"0000000000000000000000000000000000000003": {
"balance": "1"
},
"0000000000000000000000000000000000000004": {
"balance": "1"
},
"102e61f5d8f9bc71d0ad4a084df4e65e05ce0e1c": {
"balance": "1606938044258990275541962092341162602522202993782792835301376"
}
}
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum// Buterin.Vitalik]
===
The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethstate'Updating@cptIt,
_DESCRIPTION:
Unlike transaction history, however, the state needs to be frequently updated: the balance and nonce of accounts is often changed, and what’s more, new accounts are frequently inserted, and keys in storage are frequently inserted and deleted. What is thus desired is a data structure where we can quickly calculate the new tree root after an insert, update edit or delete operation, without recomputing the entire tree. There are also two highly desirable secondary properties:
The depth of the tree is bounded, even given an attacker that is deliberately crafting transactions to make the tree as deep as possible. Otherwise, an attacker could perform a denial of service attack by manipulating the tree to be so deep that each individual update becomes extremely slow.
The root of the tree depends only on the data, not on the order in which updates are made. Making updates in a different order and even recomputing the tree from scratch should not change the root.
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum// Buterin.Vitalik]
name::
* McsEngl.ethnet'Protocol (ethprl)@cptIt,
ethprl'NAME.ENGLISH:
* McsEngl.ethnet'protocol@cptIt,
* McsEngl.ethprl@cptIt,
ethprl'GENERIC:
* blockchain-protocol#ql:idBcnprl#
name::
* McsEngl.ethprl'Implementation-language@cptIt,
* McsEngl.ethnet'coding-language@cptIt,
* McsEngl.ethnet'source-code-language@cptIt,
* McsEngl.ethprl'implementation-language@cptIt,
_DESCRIPTION:
Contrast this to the Ethereum ecosystem which today has no less than 6 implementations of consensus: C++, Go, Python, Java, JavaScript, and Haskell.
[https://blog.ethereum.org/2016/02/09/cut-and-try-building-a-dream/]
name::
* McsEngl.ethprl'White-paper (ethwpr)@cptIt,
* McsEngl.ethereum-white-paper@cptIt,
* McsEngl.ethnet'white-paper@cptIt,
* McsEngl.ethprl'white-paper@cptIt,
* McsEngl.ethwpr@cptIt,
ADDRESS.WPG:
* {2017-03-12} 36-revision: https://github.com/ethereum/wiki/wiki/White-Paper/307f463132be1878013196695ef82ca19eee4693,
A Next-Generation Smart Contract and Decentralized Application Platform
Satoshi Nakamoto's development of Bitcoin in 2009 has often been hailed as a radical development in money and currency, being the first example of a digital asset which simultaneously has no backing or "http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/" and no centralized issuer or controller.
However, another, arguably more important, part of the Bitcoin experiment is the underlying blockchain technology as a tool of distributed consensus, and attention is rapidly starting to shift to this other aspect of Bitcoin.
Commonly cited alternative applications of blockchain technology include using on-blockchain digital assets to represent custom currencies and financial instruments ("https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit"), the ownership of an underlying physical device ("https://en.bitcoin.it/wiki/Smart_Property"), non-fungible assets such as domain names ("http://namecoin.org"), as well as more complex applications involving having digital assets being directly controlled by a piece of code implementing arbitrary rules ("http://szabo.best.vwh.net/smart_contracts_idea.html") or even blockchain-based "http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/" (DAOs).
What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create "contracts" that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code.
The concept of decentralized digital currency, as well as alternative applications like property registries, has been around for decades.
The anonymous e-cash protocols of the 1980s and the 1990s were mostly reliant on a cryptographic primitive known as Chaumian Blinding.
Chaumian Blinding provided these new currencies with high degrees of privacy, but their underlying protocols largely failed to gain traction because of their reliance on a centralized intermediary.
In 1998, Wei Dai's http://www.weidai.com/bmoney.txt became the first proposal to introduce the idea of creating money through solving computational puzzles as well as decentralized consensus, but the proposal was scant on details as to how decentralized consensus could actually be implemented.
In 2005, Hal Finney introduced a concept of "http://www.finney.org/~hal/rpow/", a system which uses ideas from b-money together with Adam Back's computationally difficult Hashcash puzzles to create a concept for a cryptocurrency, but once again fell short of the ideal by relying on trusted computing as a backend.
In 2009, a decentralized currency was for the first time implemented in practice by Satoshi Nakamoto, combining established primitives for managing ownership through public key cryptography with a consensus algorithm for keeping track of who owns coins, known as "proof of work."
The mechanism behind proof of work was a breakthrough because it simultaneously solved two problems.
First, it provided a simple and moderately effective consensus algorithm, allowing nodes in the network to collectively agree on a set of updates to the state of the Bitcoin ledger.
Second, it provided a mechanism for allowing free entry into the consensus process, solving the political problem of deciding who gets to influence the consensus, while simultaneously preventing Sybil attacks.
It does this by substituting a formal barrier to participation, such as the requirement to be registered as a unique entity on a particular list, with an economic barrier - the weight of a single node in the consensus voting process is directly proportional to the computing power that the node brings.
Since then, an alternative approach has been proposed called 'defn.proof-of-stake', calculating the weight of a node as being proportional to its currency holdings and not its computational resources.
The discussion concerning the relative merits of the two approaches is beyond the scope of this paper but it should be noted that both approaches can be used to serve as the backbone of a cryptocurrency.
#!https://raw.githubusercontent.com/ethereumbuilders/GitBook/master/en/vitalik-diagrams/statetransition.png!#
From a technical standpoint, the ledger of a cryptocurrency such as Bitcoin can be thought of as a state transition system, where there is a "state" consisting of the ownership status of all existing bitcoins and a "state transition function" that takes a state and a transaction and outputs a new state which is the result.
In a standard banking system, for example, the state is a balance sheet, a transaction is a request to move $X from A to B, and the state transition function reduces the value of A's account by $X and increases the value of B's account by $X.
If A's account has less than $X in the first place, the state transition function returns an error.
Hence, one can formally define:
APPLY(S,TX) -> S' or ERROR
In the banking system defined above:
APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }
But:
APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR
The "state" in Bitcoin is the collection of all coins (technically, "unspent transaction outputs" or UTXO) that have been minted and not yet spent, with each UTXO having a denomination and an owner (defined by a 20-byte address which is essentially a cryptographic public key[-1-#ql:idEthwprnot1#]).
A transaction contains one or more inputs, with each input containing a reference to an existing UTXO and a cryptographic signature produced by the private key associated with the owner's address, and one or more outputs, with each output containing a new UTXO for addition to the state.
The state transition function `APPLY(S,TX) -> S'` can be defined roughly as follows:
1. For each input in `TX`:
* If the referenced UTXO is not in `S`, return an error.
* If the provided signature does not match the owner of the UTXO, return an error.
2. If the sum of the denominations of all input UTXO is less than the sum of the denominations of all output UTXO, return an error.
3. Return `S'` with all input UTXO removed and all output UTXO added.
The first half of the first step prevents transaction senders from spending coins that do not exist, the second half of the first step prevents transaction senders from spending other people's coins, and the second step enforces conservation of value.
In order to use this for payment, the protocol is as follows.
Suppose Alice wants to send 11.7 BTC to Bob.
First, Alice will look for a set of available UTXO that she owns that totals up to at least 11.7 BTC.
Realistically, Alice will not be able to get exactly 11.7 BTC; say that the smallest she can get is 6+4+2=12.
She then creates a transaction with those three inputs and two outputs.
The first output will be 11.7 BTC with Bob's address as its owner, and the second output will be the remaining 0.3 BTC "change".
If Alice does not claim this change by sending it to an address owned by herself, the miner will be able to claim it.
#!https://raw.githubusercontent.com/ethereumbuilders/GitBook/master/en/vitalik-diagrams/block.png!#
If we had access to a trustworthy centralized service, this system would be trivial to implement; it could be coded exactly as described, using a centralized server's hard drive to keep track of the state.
However, with Bitcoin we are trying to build a decentralized currency system, so we will need to combine the state transition system with a consensus system in order to ensure that everyone agrees on the order of transactions.
Bitcoin's decentralized consensus process requires nodes in the network to continuously attempt to produce packages of transactions called "blocks".
The network is intended to create one block approximately every ten minutes, with each block containing a timestamp, a nonce, a reference to (i.e., hash of) the previous block and a list of all of the transactions that have taken place since the previous block.
Over time, this creates a persistent, ever-growing, "blockchain" that continually updates to represent the latest state of the Bitcoin ledger.
The algorithm for checking if a block is valid, expressed in this paradigm, is as follows:
1. Check if the previous block referenced by the block exists and is valid.
2. Check that the timestamp of the block is greater than that of the previous block[-2-#ql:idEthwprnot2#] and less than 2 hours into the future
3. Check that the proof of work on the block is valid.
4. Let `S[0]` be the state at the end of the previous block.
5. Suppose `TX` is the block's transaction list with `n` transactions. For all `i` in `0...n-1`, set `S[i+1] = APPLY(S[i],TX[i])` If any application returns an error, exit and return false.
6. Return true, and register `S[n]` as the state at the end of this block.
Essentially, each transaction in the block must provide a valid state transition from what was the canonical state before the transaction was executed to some new state.
Note that the state is not encoded in the block in any way; it is purely an abstraction to be remembered by the validating node and can only be (securely) computed for any block by starting from the genesis state and sequentially applying every transaction in every block.
Additionally, note that the order in which the miner includes transactions into the block matters; if there are two transactions A and B in a block such that B spends a UTXO created by A, then the block will be valid if A comes before B but not otherwise.
The one validity condition present in the above list that is not found in other systems is the requirement for "proof of work".
The precise condition is that the double-SHA256 hash of every block, treated as a 256-bit number, must be less than a dynamically adjusted target, which as of the time of this writing is approximately 2<sup>187</sup>.
The purpose of this is to make block creation computationally "hard", thereby preventing Sybil attackers from remaking the entire blockchain in their favor.
Because SHA256 is designed to be a completely unpredictable pseudorandom function, the only way to create a valid block is simply trial and error, repeatedly incrementing the nonce and seeing if the new hash matches.
At the current target of ~2<sup>187</sup>, the network must make an average of ~2<sup>69</sup> tries before a valid block is found; in general, the target is recalibrated by the network every 2016 blocks so that on average a new block is produced by some node in the network every ten minutes.
In order to compensate miners for this computational work, the miner of every block is entitled to include a transaction giving themselves 25 BTC out of nowhere.
Additionally, if any transaction has a higher total denomination in its inputs than in its outputs, the difference also goes to the miner as a "transaction fee".
Incidentally, this is also the only mechanism by which BTC are issued; the genesis state contained no coins at all.
In order to better understand the purpose of mining, let us examine what happens in the event of a malicious attacker.
Since Bitcoin's underlying cryptography is known to be secure, the attacker will target the one part of the Bitcoin system that is not protected by cryptography directly: the order of transactions.
The attacker's strategy is simple:
1. Send 100 BTC to a merchant in exchange for some product (preferably a rapid-delivery digital good)
2. Wait for the delivery of the product
3. Produce another transaction sending the same 100 BTC to himself
4. Try to convince the network that his transaction to himself was the one that came first.
Once step (1) has taken place, after a few minutes some miner will include the transaction in a block, say block number 270000.
After about one hour, five more blocks will have been added to the chain after that block, with each of those blocks indirectly pointing to the transaction and thus "confirming" it.
At this point, the merchant will accept the payment as finalized and deliver the product; since we are assuming this is a digital good, delivery is instant.
Now, the attacker creates another transaction sending the 100 BTC to himself.
If the attacker simply releases it into the wild, the transaction will not be processed; miners will attempt to run `APPLY(S,TX)` and notice that `TX` consumes a UTXO which is no longer in the state.
So instead, the attacker creates a "fork" of the blockchain, starting by mining another version of block 270000 pointing to the same block 269999 as a parent but with the new transaction in place of the old one.
Because the block data is different, this requires redoing the proof of work. Furthermore, the attacker's new version of block 270000 has a different hash, so the original blocks 270001 to 270005 do not "point" to it; thus, the original chain and the attacker's new chain are completely separate.
The rule is that in a fork the longest blockchain is taken to be the truth, and so legitimate miners will work on the 270005 chain while the attacker alone is working on the 270000 chain.
In order for the attacker to make his blockchain the longest, he would need to have more computational power than the rest of the network combined in order to catch up (hence, "51% attack").
#!https://raw.githubusercontent.com/ethereumbuilders/GitBook/master/en/vitalik-diagrams/spv1.png!#
01: it suffices to present only a small number of nodes in a Merkle tree to give a proof of the validity of a branch.
#!https://raw.githubusercontent.com/ethereumbuilders/GitBook/master/en/vitalik-diagrams/spv2.png!#
02: any attempt to change any part of the Merkle tree will eventually lead to an inconsistency somewhere up the chain.
An important scalability feature of Bitcoin is that the block is stored in a multi-level data structure.
The "hash" of a block is actually only the hash of the block header, a roughly 200-byte piece of data that contains the timestamp, nonce, previous block hash and the root hash of a data structure called the Merkle tree storing all transactions in the block.
A Merkle tree is a type of binary tree, composed of a set of nodes with a large number of leaf nodes at the bottom of the tree containing the underlying data, a set of intermediate nodes where each node is the hash of its two children, and finally a single root node, also formed from the hash of its two children, representing the "top" of the tree.
The purpose of the Merkle tree is to allow the data in a block to be delivered piecemeal: a node can download only the header of a block from one source, the small part of the tree relevant to them from another source, and still be assured that all of the data is correct.
The reason why this works is that hashes propagate upward: if a malicious user attempts to swap in a fake transaction into the bottom of a Merkle tree, this change will cause a change in the node above, and then a change in the node above that, finally changing the root of the tree and therefore the hash of the block, causing the protocol to register it as a completely different block (almost certainly with an invalid proof of work).
The Merkle tree protocol is arguably essential to long-term sustainability.
A "full node" in the Bitcoin network, one that stores and processes the entirety of every block, takes up about 15 GB of disk space in the Bitcoin network as of April 2014, and is growing by over a gigabyte per month.
Currently, this is viable for some desktop computers and not phones, and later on in the future only businesses and hobbyists will be able to participate.
A protocol known as "simplified payment verification" (SPV) allows for another class of nodes to exist, called "light nodes", which download the block headers, verify the proof of work on the block headers, and then download only the "branches" associated with transactions that are relevant to them.
This allows light nodes to determine with a strong guarantee of security what the status of any Bitcoin transaction, and their current balance, is while downloading only a very small portion of the entire blockchain.
The idea of taking the underlying blockchain idea and applying it to other concepts also has a long history.
In 2005, Nick Szabo came out with the concept of "http://nakamotoinstitute.org/secure-property-titles", a document describing how "new advances in replicated database technology" will allow for a blockchain-based system for storing a registry of who owns what land, creating an elaborate framework including concepts such as homesteading, adverse possession and Georgian land tax.
However, there was unfortunately no effective replicated database system available at the time, and so the protocol was never implemented in practice.
After 2009, however, once Bitcoin's decentralized consensus was developed a number of alternative applications rapidly began to emerge.
* Namecoin - created in 2010, https://namecoin.org/ is best described as a decentralized name registration database.
In decentralized protocols like Tor, Bitcoin and BitMessage, there needs to be some way of identifying accounts so that other people can interact with them, but in all existing solutions the only kind of identifier available is a pseudorandom hash like `1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy`.
Ideally, one would like to be able to have an account with a name like "george".
However, the problem is that if one person can create an account named "george" then someone else can use the same process to register "george" for themselves as well and impersonate them.
The only solution is a first-to-file paradigm, where the first registerer succeeds and the second fails - a problem perfectly suited for the Bitcoin consensus protocol.
Namecoin is the oldest, and most successful, implementation of a name registration system using such an idea.
* Colored coins - the purpose of https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit is to serve as a protocol to allow people to create their own digital currencies - or, in the important trivial case of a currency with one unit, digital tokens, on the Bitcoin blockchain.
In the colored coins protocol, one "issues" a new currency by publicly assigning a color to a specific Bitcoin UTXO, and the protocol recursively defines the color of other UTXO to be the same as the color of the inputs that the transaction creating them spent (some special rules apply in the case of mixed-color inputs).
This allows users to maintain wallets containing only UTXO of a specific color and send them around much like regular bitcoins, backtracking through the blockchain to determine the color of any UTXO that they receive.
* Metacoins - the idea behind a metacoin is to have a protocol that lives on top of Bitcoin, using Bitcoin transactions to store metacoin transactions but having a different state transition function, `APPLY'`.
Because the metacoin protocol cannot prevent invalid metacoin transactions from appearing in the Bitcoin blockchain, a rule is added that if `APPLY'(S,TX)` returns an error, the protocol defaults to `APPLY'(S,TX) = S`.
This provides an easy mechanism for creating an arbitrary cryptocurrency protocol, potentially with advanced features that cannot be implemented inside of Bitcoin itself, but with a very low development cost since the complexities of mining and networking are already handled by the Bitcoin protocol.
Metacoins have been used to implement some classes of financial contracts, name registration and decentralized exchange.
Thus, in general, there are two approaches toward building a consensus protocol: building an independent network, and building a protocol on top of Bitcoin.
The former approach, while reasonably successful in the case of applications like Namecoin, is difficult to implement; each individual implementation needs to bootstrap an independent blockchain, as well as building and testing all of the necessary state transition and networking code.
Additionally, we predict that the set of applications for decentralized consensus technology will follow a power law distribution where the vast majority of applications would be too small to warrant their own blockchain, and we note that there exist large classes of decentralized applications, particularly decentralized autonomous organizations, that need to interact with each other.
The Bitcoin-based approach, on the other hand, has the flaw that it does not inherit the simplified payment verification features of Bitcoin.
SPV works for Bitcoin because it can use blockchain depth as a proxy for validity; at some point, once the ancestors of a transaction go far enough back, it is safe to say that they were legitimately part of the state.
Blockchain-based meta-protocols, on the other hand, cannot force the blockchain not to include transactions that are not valid within the context of their own protocols.
Hence, a fully secure SPV meta-protocol implementation would need to backward scan all the way to the beginning of the Bitcoin blockchain to determine whether or not certain transactions are valid.
Currently, all "light" implementations of Bitcoin-based meta-protocols rely on a trusted server to provide the data, arguably a highly suboptimal result especially when one of the primary purposes of a cryptocurrency is to eliminate the need for trust.
Even without any extensions, the Bitcoin protocol actually does facilitate a weak version of a concept of "smart contracts".
UTXO in Bitcoin can be owned not just by a public key, but also by a more complicated script expressed in a simple stack-based programming language.
In this paradigm, a transaction spending that UTXO must provide data that satisfies the script.
Indeed, even the basic public key ownership mechanism is implemented via a script: the script takes an elliptic curve signature as input, verifies it against the transaction and the address that owns the UTXO, and returns 1 if the verification is successful and 0 otherwise.
Other, more complicated, scripts exist for various additional use cases.
For example, one can construct a script that requires signatures from two out of a given three private keys to validate ("multisig"), a setup useful for corporate accounts, secure savings accounts and some merchant escrow situations.
Scripts can also be used to pay bounties for solutions to computational problems, and one can even construct a script that says something like "this Bitcoin UTXO is yours if you can provide an SPV proof that you sent a Dogecoin transaction of this denomination to me", essentially allowing decentralized cross-cryptocurrency exchange.
However, the scripting language as implemented in Bitcoin has several important limitations:
* Lack of Turing-completeness - that is to say, while there is a large subset of computation that the Bitcoin scripting language supports, it does not nearly support everything.
The main category that is missing is loops.
This is done to avoid infinite loops during transaction verification; theoretically it is a surmountable obstacle for script programmers, since any loop can be simulated by simply repeating the underlying code many times with an if statement, but it does lead to scripts that are very space-inefficient.
For example, implementing an alternative elliptic curve signature algorithm would likely require 256 repeated multiplication rounds all individually included in the code.
* Value-blindness - there is no way for a UTXO script to provide fine-grained control over the amount that can be withdrawn.
For example, one powerful use case of an oracle contract would be a hedging contract, where A and B put in $1000 worth of BTC and after 30 days the script sends $1000 worth of BTC to A and the rest to B.
This would require an oracle to determine the value of 1 BTC in USD, but even then it is a massive improvement in terms of trust and infrastructure requirement over the fully centralized solutions that are available now.
However, because UTXO are all-or-nothing, the only way to achieve this is through the very inefficient hack of having many UTXO of varying denominations (eg. one UTXO of 2<sup>k</sup> for every k up to 30) and having O pick which UTXO to send to A and which to B.
* Lack of state - UTXO can either be spent or unspent; there is no opportunity for multi-stage contracts or scripts which keep any other internal state beyond that.
This makes it hard to make multi-stage options contracts, decentralized exchange offers or two-stage cryptographic commitment protocols (necessary for secure computational bounties).
It also means that UTXO can only be used to build simple, one-off contracts and not more complex "stateful" contracts such as decentralized organizations, and makes meta-protocols difficult to implement.
Binary state combined with value-blindness also mean that another important application, withdrawal limits, is impossible.
* Blockchain-blindness - UTXO are blind to certain blockchain data such as the nonce and previous block hash.
This severely limits applications in gambling, and several other categories, by depriving the scripting language of a potentially valuable source of randomness.
Thus, we see three approaches to building advanced applications on top of cryptocurrency: building a new blockchain, using scripting on top of Bitcoin, and building a meta-protocol on top of Bitcoin.
Building a new blockchain allows for unlimited freedom in building a feature set, but at the cost of development time, bootstrapping effort and security.
Using scripting is easy to implement and standardize, but is very limited in its capabilities, and meta-protocols, while easy, suffer from faults in scalability.
With Ethereum, we intend to build an alternative framework that provides even larger gains in ease of development as well as even stronger light client properties, while at the same time allowing applications to share an economic environment and blockchain security.
The intent of Ethereum is to create an alternative protocol for building decentralized applications, providing a different set of tradeoffs that we believe will be very useful for a large class of decentralized applications, with particular emphasis on situations where rapid development time, security for small and rarely used applications, and the ability of different applications to very efficiently interact, are important.
Ethereum does this by building what is essentially the ultimate abstract foundational layer: a blockchain with a built-in Turing-complete programming language, allowing anyone to write smart contracts and decentralized applications where they can create their own arbitrary rules for ownership, transaction formats and state transition functions.
A bare-bones version of Namecoin can be written in two lines of code, and other protocols like currencies and reputation systems can be built in under twenty.
Smart contracts, cryptographic "boxes" that contain value and only unlock it if certain conditions are met, can also be built on top of the platform, with vastly more power than that offered by Bitcoin scripting because of the added powers of Turing-completeness, value-awareness, blockchain-awareness and state.
In Ethereum, the state is made up of objects called "accounts", with each account having a 20-byte address and state transitions being direct transfers of value and information between accounts.
An Ethereum account contains four fields:
* The **nonce**, a counter used to make sure each transaction can only be processed once
* The account's current **ether balance**
* The account's **contract code**, if present
* The account's **storage** (empty by default)
"Ether" is the main internal crypto-fuel of Ethereum, and is used to pay transaction fees.
In general, there are two types of accounts: **externally owned accounts**, controlled by private keys, and **contract accounts**, controlled by their contract code.
An externally owned account has no code, and one can send messages from an externally owned account by creating and signing a transaction; in a contract account, every time the contract account receives a message its code activates, allowing it to read and write to internal storage and send other messages or create contracts in turn.
Note that "contracts" in Ethereum should not be seen as something that should be "fulfilled" or "complied with"; rather, they are more like "autonomous agents" that live inside of the Ethereum execution environment, always executing a specific piece of code when "poked" by a message or transaction, and having direct control over their own ether balance and their own key/value store to keep track of persistent variables.
The term "transaction" is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account.
Transactions contain:
* The recipient of the message
* A signature identifying the sender
* The amount of ether to transfer from the sender to the recipient
* An optional data field
* A `STARTGAS` value, representing the maximum number of computational steps the transaction execution is allowed to take
* A `GASPRICE` value, representing the fee the sender pays per computational step
The first three are standard fields expected in any cryptocurrency.
The data field has no function by default, but the virtual machine has an opcode with which a contract can access the data; as an example use case, if a contract is functioning as an on-blockchain domain registration service, then it may wish to interpret the data being passed to it as containing two "fields", the first field being a domain to register and the second field being the IP address to register it to.
The contract would read these values from the message data and appropriately place them in storage.
The `STARTGAS` and `GASPRICE` fields are crucial for Ethereum's anti-denial of service model.
In order to prevent accidental or hostile infinite loops or other computational wastage in code, each transaction is required to set a limit to how many computational steps of code execution it can use.
The fundamental unit of computation is "gas"; usually, a computational step costs 1 gas, but some operations cost higher amounts of gas because they are more computationally expensive, or increase the amount of data that must be stored as part of the state.
There is also a fee of 5 gas for every byte in the transaction data.
The intent of the fee system is to require an attacker to pay proportionately for every resource that they consume, including computation, bandwidth and storage; hence, any transaction that leads to the network consuming a greater amount of any of these resources must have a gas fee roughly proportional to the increment.
Contracts have the ability to send "messages" to other contracts.
Messages are virtual objects that are never serialized and exist only in the Ethereum execution environment.
A message contains:
* The sender of the message (implicit)
* The recipient of the message
* The amount of ether to transfer alongside the message
* An optional data field
* A `STARTGAS` value
Essentially, a message is like a transaction, except it is produced by a contract and not an external actor.
A message is produced when a contract currently executing code executes the `CALL` opcode, which produces and executes a message.
Like a transaction, a message leads to the recipient account running its code.
Thus, contracts can have relationships with other contracts in exactly the same way that external actors can.
Note that the gas allowance assigned by a transaction or contract applies to the total gas consumed by that transaction and all sub-executions.
For example, if an external actor A sends a transaction to B with 1000 gas, and B consumes 600 gas before sending a message to C, and the internal execution of C consumes 300 gas before returning, then B can spend another 100 gas before running out of gas.
#!https://raw.githubusercontent.com/ethereumbuilders/GitBook/master/en/vitalik-diagrams/ethertransition.png!#
The Ethereum state transition function, `APPLY(S,TX) -> S'` can be defined as follows:
1. Check if the transaction is well-formed (ie. has the right number of values), the signature is valid, and the nonce matches the nonce in the sender's account. If not, return an error.
2. Calculate the transaction fee as `STARTGAS * GASPRICE`, and determine the sending address from the signature. Subtract the fee from the sender's account balance and increment the sender's nonce. If there is not enough balance to spend, return an error.
3. Initialize `GAS = STARTGAS`, and take off a certain quantity of gas per byte to pay for the bytes in the transaction.
4. Transfer the transaction value from the sender's account to the receiving account. If the receiving account does not yet exist, create it. If the receiving account is a contract, run the contract's code either to completion or until the execution runs out of gas.
5. If the value transfer failed because the sender did not have enough money, or the code execution ran out of gas, revert all state changes except the payment of the fees, and add the fees to the miner's account.
6. Otherwise, refund the fees for all remaining gas to the sender, and send the fees paid for gas consumed to the miner.
For example, suppose that the contract's code is:
if !self.storage[calldataload(0)]:
self.storage[calldataload(0)] = calldataload(32)
Note that in reality the contract code is written in the low-level EVM code; this example is written in Serpent, one of our high-level languages, for clarity, and can be compiled down to EVM code.
Suppose that the contract's storage starts off empty, and a transaction is sent with 10 ether value, 2000 gas, 0.001 ether gasprice, and 64 bytes of data, with bytes 0-31 representing the number `2` and bytes 32-63 representing the string `CHARLIE`.
The process for the state transition function in this case is as follows:
1. Check that the transaction is valid and well formed.
2. Check that the transaction sender has at least 2000 * 0.001 = 2 ether. If it is, then subtract 2 ether from the sender's account.
3. Initialize gas = 2000; assuming the transaction is 170 bytes long and the byte-fee is 5, subtract 850 so that there is 1150 gas left.
3. Subtract 10 more ether from the sender's account, and add it to the contract's account.
4. Run the code. In this case, this is simple: it checks if the contract's storage at index `2` is used, notices that it is not, and so it sets the storage at index `2` to the value `CHARLIE`. Suppose this takes 187 gas, so the remaining amount of gas is 1150 - 187 = 963
5. Add 963 * 0.001 = 0.963 ether back to the sender's account, and return the resulting state.
If there was no contract at the receiving end of the transaction, then the total transaction fee would simply be equal to the provided `GASPRICE` multiplied by the length of the transaction in bytes, and the data sent alongside the transaction would be irrelevant.
Note that messages work equivalently to transactions in terms of reverts: if a message execution runs out of gas, then that message's execution, and all other executions triggered by that execution, revert, but parent executions do not need to revert.
This means that it is "safe" for a contract to call another contract, as if A calls B with G gas then A's execution is guaranteed to lose at most G gas.
Finally, note that there is an opcode, `CREATE`, that creates a contract; its execution mechanics are generally similar to `CALL`, with the exception that the output of the execution determines the code of a newly created contract.
The code in Ethereum contracts is written in a low-level, stack-based bytecode language, referred to as "Ethereum virtual machine code" or "EVM code".
The code consists of a series of bytes, where each byte represents an operation.
In general, code execution is an infinite loop that consists of repeatedly carrying out the operation at the current program counter (which begins at zero) and then incrementing the program counter by one, until the end of the code is reached or an error or `STOP` or `RETURN` instruction is detected.
The operations have access to three types of space in which to store data:
* The **stack**, a last-in-first-out container to which values can be pushed and popped
* **Memory**, an infinitely expandable byte array
* The contract's long-term **storage**, a key/value store. Unlike stack and memory, which reset after computation ends, storage persists for the long term.
The code can also access the value, sender and data of the incoming message, as well as block header data, and the code can also return a byte array of data as an output.
The formal execution model of EVM code is surprisingly simple.
While the Ethereum virtual machine is running, its full computational state can be defined by the tuple `(block_state, transaction, message, code, memory, stack, pc, gas)`, where `block_state` is the global state containing all accounts and includes balances and storage.
At the start of every round of execution, the current instruction is found by taking the `pc`th (Program Counter) byte of `code` (or 0 if `pc >= len(code)`), and each instruction has its own definition in terms of how it affects the tuple.
For example, `ADD` pops two items off the stack and pushes their sum, reduces `gas` by 1 and increments `pc` by 1, and `SSTORE` pops the top two items off the stack and inserts the second item into the contract's storage at the index specified by the first item.
Although there are many ways to optimize Ethereum virtual machine execution via just-in-time compilation, a basic implementation of Ethereum can be done in a few hundred lines of code.
#!https://raw.githubusercontent.com/ethereumbuilders/GitBook/master/en/vitalik-diagrams/apply_block_diagram.png!#
The Ethereum blockchain is in many ways similar to the Bitcoin blockchain, although it does have some differences.
The main difference between Ethereum and Bitcoin with regard to the blockchain architecture is that, unlike Bitcoin, Ethereum blocks contain a copy of both the transaction list and the most recent state.
Aside from that, two other values, the block number and the difficulty, are also stored in the block.
The basic block validation algorithm in Ethereum is as follows:
1. Check if the previous block referenced exists and is valid.
2. Check that the timestamp of the block is greater than that of the referenced previous block and less than 15 minutes into the future
3. Check that the block number, difficulty, transaction root, uncle root and gas limit (various low-level Ethereum-specific concepts) are valid.
4. Check that the proof of work on the block is valid.
5. Let `S[0]` be the state at the end of the previous block.
6. Let `TX` be the block's transaction list, with `n` transactions. For all `i` in `0...n-1`, set `S[i+1] = APPLY(S[i],TX[i])`. If any application returns an error, or if the total gas consumed in the block up until this point exceeds the `GASLIMIT`, return an error.
7. Let `S_FINAL` be `S[n]`, but adding the block reward paid to the miner.
8. Check if the Merkle tree root of the state `S_FINAL` is equal to the final state root provided in the block header. If it is, the block is valid; otherwise, it is not valid.
The approach may seem highly inefficient at first glance, because it needs to store the entire state with each block, but in reality efficiency should be comparable to that of Bitcoin.
The reason is that the state is stored in the tree structure, and after every block only a small part of the tree needs to be changed.
Thus, in general, between two adjacent blocks the vast majority of the tree should be the same, and therefore the data can be stored once and referenced twice using pointers (ie. hashes of subtrees).
A special kind of tree known as a "Patricia tree" is used to accomplish this, including a modification to the Merkle tree concept that allows for nodes to be inserted and deleted, and not just changed, efficiently.
Additionally, because all of the state information is part of the last block, there is no need to store the entire blockchain history - a strategy which, if it could be applied to Bitcoin, can be calculated to provide 5-20x savings in space.
A commonly asked question is "where" contract code is executed, in terms of physical hardware.
This has a simple answer: the process of executing contract code is part of the definition of the state transition function, which is part of the block validation algorithm, so if a transaction is added into block `B` the code execution spawned by that transaction will be executed by all nodes, now and in the future, that download and validate block `B`.
In general, there are three types of applications on top of Ethereum.
The first category is financial applications, providing users with more powerful ways of managing and entering into contracts using their money.
This includes sub-currencies, financial derivatives, hedging contracts, savings wallets, wills, and ultimately even some classes of full-scale employment contracts.
The second category is semi-financial applications, where money is involved but there is also a heavy non-monetary side to what is being done; a perfect example is self-enforcing bounties for solutions to computational problems.
Finally, there are applications such as online voting and decentralized governance that are not financial at all.
On-blockchain token systems have many applications ranging from sub-currencies representing assets such as USD or gold to company stocks, individual tokens representing smart property, secure unforgeable coupons, and even token systems with no ties to conventional value at all, used as point systems for incentivization.
Token systems are surprisingly easy to implement in Ethereum.
The key point to understand is that all a currency, or token system, fundamentally is a database with one operation: subtract X units from A and give X units to B, with the proviso that (i) A had at least X units before the transaction and (ii) the transaction is approved by A.
All that it takes to implement a token system is to implement this logic into a contract.
The basic code for implementing a token system in Serpent looks as follows:
def send(to, value):
if self.storage[msg.sender] >= value:
self.storage[msg.sender] = self.storage[msg.sender] - value
self.storage[to] = self.storage[to] + value
This is essentially a literal implementation of the "banking system" state transition function described further above in this document.
A few extra lines of code need to be added to provide for the initial step of distributing the currency units in the first place and a few other edge cases, and ideally a function would be added to let other contracts query for the balance of an address.
But that's all there is to it.
Theoretically, Ethereum-based token systems acting as sub-currencies can potentially include another important feature that on-chain Bitcoin-based meta-currencies lack: the ability to pay transaction fees directly in that currency.
The way this would be implemented is that the contract would maintain an ether balance with which it would refund ether used to pay fees to the sender, and it would refill this balance by collecting the internal currency units that it takes in fees and reselling them in a constant running auction.
Users would thus need to "activate" their accounts with ether, but once the ether is there it would be reusable because the contract would refund it each time.
Financial derivatives are the most common application of a "smart contract", and one of the simplest to implement in code.
The main challenge in implementing financial contracts is that the majority of them require reference to an external price ticker; for example, a very desirable application is a smart contract that hedges against the volatility of ether (or another cryptocurrency) with respect to the US dollar, but doing this requires the contract to know what the value of ETH/USD is.
The simplest way to do this is through a "data feed" contract maintained by a specific party (eg. NASDAQ) designed so that that party has the ability to update the contract as needed, and providing an interface that allows other contracts to send a message to that contract and get back a response that provides the price.
Given that critical ingredient, the hedging contract would look as follows:
1. Wait for party A to input 1000 ether.
2. Wait for party B to input 1000 ether.
3. Record the USD value of 1000 ether, calculated by querying the data feed contract, in storage, say this is $x.
4. After 30 days, allow A or B to "reactivate" the contract in order to send $x worth of ether (calculated by querying the data feed contract again to get the new price) to A and the rest to B.
Such a contract would have significant potential in crypto-commerce.
One of the main problems cited about cryptocurrency is the fact that it's volatile; although many users and merchants may want the security and convenience of dealing with cryptographic assets, they may not wish to face that prospect of losing 23% of the value of their funds in a single day.
Up until now, the most commonly proposed solution has been issuer-backed assets; the idea is that an issuer creates a sub-currency in which they have the right to issue and revoke units, and provide one unit of the currency to anyone who provides them (offline) with one unit of a specified underlying asset (eg. gold, USD).
The issuer then promises to provide one unit of the underlying asset to anyone who sends back one unit of the crypto-asset.
This mechanism allows any non-cryptographic asset to be "uplifted" into a cryptographic asset, provided that the issuer can be trusted.
In practice, however, issuers are not always trustworthy, and in some cases the banking infrastructure is too weak, or too hostile, for such services to exist.
Financial derivatives provide an alternative.
Here, instead of a single issuer providing the funds to back up an asset, a decentralized market of speculators, betting that the price of a cryptographic reference asset (eg. ETH) will go up, plays that role.
Unlike issuers, speculators have no option to default on their side of the bargain because the hedging contract holds their funds in escrow.
Note that this approach is not fully decentralized, because a trusted source is still needed to provide the price ticker, although arguably even still this is a massive improvement in terms of reducing infrastructure requirements (unlike being an issuer, issuing a price feed requires no licenses and can likely be categorized as free speech) and reducing the potential for fraud.
The earliest alternative cryptocurrency of all, http://namecoin.org/, attempted to use a Bitcoin-like blockchain to provide a name registration system, where users can register their names in a public database alongside other data.
The major cited use case is for a http://en.wikipedia.org/wiki/Domain_Name_System system, mapping domain names like "bitcoin.org" (or, in Namecoin's case, "bitcoin.bit") to an IP address.
Other use cases include email authentication and potentially more advanced reputation systems.
Here is the basic contract to provide a Namecoin-like name registration system on Ethereum:
def register(name, value):
if !self.storage[name]:
self.storage[name] = value
The contract is very simple; all it is is a database inside the Ethereum network that can be added to, but not modified or removed from.
Anyone can register a name with some value, and that registration then sticks forever.
A more sophisticated name registration contract will also have a "function clause" allowing other contracts to query it, as well as a mechanism for the "owner" (ie. the first registerer) of a name to change the data or transfer ownership.
One can even add reputation and web-of-trust functionality on top.
Over the past few years, there have emerged a number of popular online file storage startups, the most prominent being Dropbox, seeking to allow users to upload a backup of their hard drive and have the service store the backup and allow the user to access it in exchange for a monthly fee.
However, at this point the file storage market is at times relatively inefficient; a cursory look at various http://online-storage-service-review.toptenreviews.com/ shows that, particularly at the "uncanny valley" 20-200 GB level at which neither free quotas nor enterprise-level discounts kick in, monthly prices for mainstream file storage costs are such that you are paying for more than the cost of the entire hard drive in a single month.
Ethereum contracts can allow for the development of a decentralized file storage ecosystem, where individual users can earn small quantities of money by renting out their own hard drives and unused space can be used to further drive down the costs of file storage.
The key underpinning piece of such a device would be what we have termed the "decentralized Dropbox contract".
This contract works as follows.
First, one splits the desired data up into blocks, encrypting each block for privacy, and builds a Merkle tree out of it.
One then makes a contract with the rule that, every N blocks, the contract would pick a random index in the Merkle tree (using the previous block hash, accessible from contract code, as a source of randomness), and give X ether to the first entity to supply a transaction with a simplified payment verification-like proof of ownership of the block at that particular index in the tree.
When a user wants to re-download their file, they can use a micropayment channel protocol (eg. pay 1 szabo per 32 kilobytes) to recover the file; the most fee-efficient approach is for the payer not to publish the transaction until the end, instead replacing the transaction with a slightly more lucrative one with the same nonce after every 32 kilobytes.
An important feature of the protocol is that, although it may seem like one is trusting many random nodes not to decide to forget the file, one can reduce that risk down to near-zero by splitting the file into many pieces via secret sharing, and watching the contracts to see each piece is still in some node's possession.
If a contract is still paying out money, that provides a cryptographic proof that someone out there is still storing the file.
The general concept of a "decentralized autonomous organization" is that of a virtual entity that has a certain set of members or shareholders which, perhaps with a 67% majority, have the right to spend the entity's funds and modify its code.
The members would collectively decide on how the organization should allocate its funds.
Methods for allocating a DAO's funds could range from bounties, salaries to even more exotic mechanisms such as an internal currency to reward work.
This essentially replicates the legal trappings of a traditional company or nonprofit but using only cryptographic blockchain technology for enforcement.
So far much of the talk around DAOs has been around the "capitalist" model of a "decentralized autonomous corporation" (DAC) with dividend-receiving shareholders and tradable shares; an alternative, perhaps described as a "decentralized autonomous community", would have all members have an equal share in the decision making and require 67% of existing members to agree to add or remove a member.
The requirement that one person can only have one membership would then need to be enforced collectively by the group.
A general outline for how to code a DAO is as follows.
The simplest design is simply a piece of self-modifying code that changes if two thirds of members agree on a change.
Although code is theoretically immutable, one can easily get around this and have de-facto mutability by having chunks of the code in separate contracts, and having the address of which contracts to call stored in the modifiable storage.
In a simple implementation of such a DAO contract, there would be three transaction types, distinquished by the data provided in the transaction:
* `[0,i,K,V]` to register a proposal with index `i` to change the address at storage index `K` to value `V`
* `[0,i]` to register a vote in favor of proposal `i`
* `[2,i]` to finalize proposal `i` if enough votes have been made
The contract would then have clauses for each of these.
It would maintain a record of all open storage changes, along with a list of who voted for them.
It would also have a list of all members.
When any storage change gets to two thirds of members voting for it, a finalizing transaction could execute the change.
A more sophisticated skeleton would also have built-in voting ability for features like sending a transaction, adding members and removing members, and may even provide for http://en.wikipedia.org/wiki/Delegative_democracy-style vote delegation (ie. anyone can assign someone to vote for them, and assignment is transitive so if A assigns B and B assigns C then C determines A's vote).
This design would allow the DAO to grow organically as a decentralized community, allowing people to eventually delegate the task of filtering out who is a member to specialists, although unlike in the "current system" specialists can easily pop in and out of existence over time as individual community members change their alignments.
An alternative model is for a decentralized corporation, where any account can have zero or more shares, and two thirds of the shares are required to make a decision.
A complete skeleton would involve asset management functionality, the ability to make an offer to buy or sell shares, and the ability to accept offers (preferably with an order-matching mechanism inside the contract).
Delegation would also exist Liquid Democracy-style, generalizing the concept of a "board of directors".
1. Savings wallets.
Suppose that Alice wants to keep her funds safe, but is worried that she will lose or someone will hack her private key.
She puts ether into a contract with Bob, a bank, as follows:
* Alice alone can withdraw a maximum of 1% of the funds per day.
* Bob alone can withdraw a maximum of 1% of the funds per day, but Alice has the ability to make a transaction with her key shutting off this ability.
* Alice and Bob together can withdraw anything.
Normally, 1% per day is enough for Alice, and if Alice wants to withdraw more she can contact Bob for help.
If Alice's key gets hacked, she runs to Bob to move the funds to a new contract.
If she loses her key, Bob will get the funds out eventually.
If Bob turns out to be malicious, then she can turn off his ability to withdraw.
2. Crop insurance.
One can easily make a financial derivatives contract but using a data feed of the weather instead of any price index.
If a farmer in Iowa purchases a derivative that pays out inversely based on the precipitation in Iowa, then if there is a drought, the farmer will automatically receive money and if there is enough rain the farmer will be happy because their crops would do well.
This can be expanded to natural disaster insurance generally.
3. A decentralized data feed.
For financial contracts for difference, it may actually be possible to decentralize the data feed via a protocol called "http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/".
SchellingCoin basically works as follows: N parties all put into the system the value of a given datum (eg. the ETH/USD price), the values are sorted, and everyone between the 25th and 75th percentile gets one token as a reward.
Everyone has the incentive to provide the answer that everyone else will provide, and the only value that a large number of players can realistically agree on is the obvious default: the truth.
This creates a decentralized protocol that can theoretically provide any number of values, including the ETH/USD price, the temperature in Berlin or even the result of a particular hard computation.
4. Smart multisignature escrow.
Bitcoin allows multisignature transaction contracts where, for example, three out of a given five keys can spend the funds.
Ethereum allows for more granularity; for example, four out of five can spend everything, three out of five can spend up to 10% per day, and two out of five can spend up to 0.5% per day.
Additionally, Ethereum multisig is asynchronous - two parties can register their signatures on the blockchain at different times and the last signature will automatically send the transaction.
5. Cloud computing.
The EVM technology can also be used to create a verifiable computing environment, allowing users to ask others to carry out computations and then optionally ask for proofs that computations at certain randomly selected checkpoints were done correctly.
This allows for the creation of a cloud computing market where any user can participate with their desktop, laptop or specialized server, and spot-checking together with security deposits can be used to ensure that the system is trustworthy (ie. nodes cannot profitably cheat).
Although such a system may not be suitable for all tasks; tasks that require a high level of inter-process communication, for example, cannot easily be done on a large cloud of nodes.
Other tasks, however, are much easier to parallelize; projects like SETI@home, folding@home and genetic algorithms can easily be implemented on top of such a platform.
6. Peer-to-peer gambling.
Any number of peer-to-peer gambling protocols, such as Frank Stajano and Richard Clayton's http://www.cl.cam.ac.uk/~fms27/papers/2008-StajanoCla-cyberdice.pdf, can be implemented on the Ethereum blockchain.
The simplest gambling protocol is actually simply a contract for difference on the next block hash, and more advanced protocols can be built up from there, creating gambling services with near-zero fees that have no ability to cheat.
7. Prediction markets.
Provided an oracle or SchellingCoin, prediction markets are also easy to implement, and prediction markets together with SchellingCoin may prove to be the first mainstream application of http://hanson.gmu.edu/futarchy.html as a governance protocol for decentralized organizations.
8. On-chain decentralized marketplaces,
using the identity and reputation system as a base.
The "Greedy Heaviest Observed Subtree" (GHOST) protocol is an innovation first introduced by Yonatan Sompolinsky and Aviv Zohar in http://www.cs.huji.ac.il/~avivz/pubs/13/btc_scalability_full.pdf.
The motivation behind GHOST is that blockchains with fast confirmation times currently suffer from reduced security due to a high stale rate - because blocks take a certain time to propagate through the network, if miner A mines a block and then miner B happens to mine another block before miner A's block propagates to B, miner B's block will end up wasted and will not contribute to network security.
Furthermore, there is a centralization issue: if miner A is a mining pool with 30% hashpower and B has 10% hashpower, A will have a risk of producing a stale block 70% of the time (since the other 30% of the time A produced the last block and so will get mining data immediately) whereas B will have a risk of producing a stale block 90% of the time.
Thus, if the block interval is short enough for the stale rate to be high, A will be substantially more efficient simply by virtue of its size.
With these two effects combined, blockchains which produce blocks quickly are very likely to lead to one mining pool having a large enough percentage of the network hashpower to have de facto control over the mining process.
As described by Sompolinsky and Zohar, GHOST solves the first issue of network security loss by including stale blocks in the calculation of which chain is the "longest"; that is to say, not just the parent and further ancestors of a block, but also the stale descendants of the block's ancestor (in Ethereum jargon, "uncles") are added to the calculation of which block has the largest total proof of work backing it.
To solve the second issue of centralization bias, we go beyond the protocol described by Sompolinsky and Zohar, and also provide block rewards to stales: a stale block receives 87.5% of its base reward, and the nephew that includes the stale block receives the remaining 12.5%.
Transaction fees, however, are not awarded to uncles.
Ethereum implements a simplified version of GHOST which only goes down seven levels.
Specifically, it is defined as follows:
* A block must specify a parent, and it must specify 0 or more uncles
* An uncle included in block B must have the following properties:
* It must be a direct child of the kth generation ancestor of B, where 2 <= k <= 7.
* It cannot be an ancestor of B
* An uncle must be a valid block header, but does not need to be a previously verified or even valid block
* An uncle must be different from all uncles included in previous blocks and all other uncles included in the same block (non-double-inclusion)
* For every uncle U in block B, the miner of B gets an additional 3.125% added to its coinbase reward and the miner of U gets 93.75% of a standard coinbase reward.
This limited version of GHOST, with uncles includable only up to 7 generations, was used for two reasons.
First, unlimited GHOST would include too many complications into the calculation of which uncles for a given block are valid.
Second, unlimited GHOST with compensation as used in Ethereum removes the incentive for a miner to mine on the main chain and not the chain of a public attacker.
Because every transaction published into the blockchain imposes on the network the cost of needing to download and verify it, there is a need for some regulatory mechanism, typically involving transaction fees, to prevent abuse.
The default approach, used in Bitcoin, is to have purely voluntary fees, relying on miners to act as the gatekeepers and set dynamic minimums.
This approach has been received very favorably in the Bitcoin community particularly because it is "market-based", allowing supply and demand between miners and transaction senders determine the price.
The problem with this line of reasoning is, however, that transaction processing is not a market; although it is intuitively attractive to construe transaction processing as a service that the miner is offering to the sender, in reality every transaction that a miner includes will need to be processed by every node in the network, so the vast majority of the cost of transaction processing is borne by third parties and not the miner that is making the decision of whether or not to include it.
Hence, tragedy-of-the-commons problems are very likely to occur.
However, as it turns out this flaw in the market-based mechanism, when given a particular inaccurate simplifying assumption, magically cancels itself out.
The argument is as follows.
Suppose that:
1. A transaction leads to `k` operations, offering the reward `kR` to any miner that includes it where `R` is set by the sender and `k` and `R` are (roughly) visible to the miner beforehand.
2. An operation has a processing cost of `C` to any node (ie. all nodes have equal efficiency)
3. There are `N` mining nodes, each with exactly equal processing power (ie. `1/N` of total)
4. No non-mining full nodes exist.
A miner would be willing to process a transaction if the expected reward is greater than the cost.
Thus, the expected reward is `kR/N` since the miner has a `1/N` chance of processing the next block, and the processing cost for the miner is simply `kC`.
Hence, miners will include transactions where `kR/N > kC`, or `R > NC`.
Note that `R` is the per-operation fee provided by the sender, and is thus a lower bound on the benefit that the sender derives from the transaction, and `NC` is the cost to the entire network together of processing an operation.
Hence, miners have the incentive to include only those transactions for which the total utilitarian benefit exceeds the cost.
However, there are several important deviations from those assumptions in reality:
1. The miner does pay a higher cost to process the transaction than the other verifying nodes, since the extra verification time delays block propagation and thus increases the chance the block will become a stale.
2. There do exist nonmining full nodes.
3. The mining power distribution may end up radically inegalitarian in practice.
4. Speculators, political enemies and crazies whose utility function includes causing harm to the network do exist, and they can cleverly set up contracts where their cost is much lower than the cost paid by other verifying nodes.
(1) provides a tendency for the miner to include fewer transactions, and (2) increases `NC`; hence, these two effects at least partially cancel each other out.
(3) and (4) are the major issue; to solve them we simply institute a floating cap: no block can have more operations than `BLK_LIMIT_FACTOR` times the long-term exponential moving average.
Specifically:
blk.oplimit = floor((blk.parent.oplimit * (EMA_FACTOR - 1) + floor(parent.opcount * BLK_LIMIT_FACTOR)) / EMA_FACTOR)
`BLK_LIMIT_FACTOR` and `EMA_FACTOR` are constants that will be set to 65536 and 1.5 for the time being, but will likely be changed after further analysis.
There is another factor disincentivizing large block sizes in Bitcoin: blocks that are large will take longer to propagate, and thus have a higher probability of becoming stales.
In Ethereum, highly gas-consuming blocks can also take longer to propagate both because they are physically larger and because they take longer to process the transaction state transitions to validate.
This delay disincentive is a significant consideration in Bitcoin, but less so in Ethereum because of the GHOST protocol; hence, relying on regulated block limits provides a more stable baseline.
An important note is that the Ethereum virtual machine is Turing-complete; this means that EVM code can encode any computation that can be conceivably carried out, including infinite loops.
EVM code allows looping in two ways.
First, there is a `JUMP` instruction that allows the program to jump back to a previous spot in the code, and a `JUMPI` instruction to do conditional jumping, allowing for statements like `while x < 27: x = x * 2`.
Second, contracts can call other contracts, potentially allowing for looping through recursion.
This naturally leads to a problem: can malicious users essentially shut miners and full nodes down by forcing them to enter into an infinite loop?
The issue arises because of a problem in computer science known as the halting problem: there is no way to tell, in the general case, whether or not a given program will ever halt.
As described in the state transition section, our solution works by requiring a transaction to set a maximum number of computational steps that it is allowed to take, and if execution takes longer computation is reverted but fees are still paid.
Messages work in the same way.
To show the motivation behind our solution, consider the following examples:
* An attacker creates a contract which runs an infinite loop, and then sends a transaction activating that loop to the miner.
The miner will process the transaction, running the infinite loop, and wait for it to run out of gas.
Even though the execution runs out of gas and stops halfway through, the transaction is still valid and the miner still claims the fee from the attacker for each computational step.
* An attacker creates a very long infinite loop with the intent of forcing the miner to keep computing for such a long time that by the time computation finishes a few more blocks will have come out and it will not be possible for the miner to include the transaction to claim the fee.
However, the attacker will be required to submit a value for `STARTGAS` limiting the number of computational steps that execution can take, so the miner will know ahead of time that the computation will take an excessively large number of steps.
* An attacker sees a contract with code of some form like `send(A,contract.storage[A]); contract.storage[A] = 0`, and sends a transaction with just enough gas to run the first step but not the second (ie. making a withdrawal but not letting the balance go down).
The contract author does not need to worry about protecting against such attacks, because if execution stops halfway through the changes get reverted.
* A financial contract works by taking the median of nine proprietary data feeds in order to minimize risk.
An attacker takes over one of the data feeds, which is designed to be modifiable via the variable-address-call mechanism described in the section on DAOs, and converts it to run an infinite loop, thereby attempting to force any attempts to claim funds from the financial contract to run out of gas.
However, the financial contract can set a gas limit on the message to prevent this problem.
The alternative to Turing-completeness is Turing-incompleteness, where `JUMP` and `JUMPI` do not exist and only one copy of each contract is allowed to exist in the call stack at any given time.
With this system, the fee system described and the uncertainties around the effectiveness of our solution might not be necessary, as the cost of executing a contract would be bounded above by its size.
Additionally, Turing-incompleteness is not even that big a limitation; out of all the contract examples we have conceived internally, so far only one required a loop, and even that loop could be removed by making 26 repetitions of a one-line piece of code.
Given the serious implications of Turing-completeness, and the limited benefit, why not simply have a Turing-incomplete language?
In reality, however, Turing-incompleteness is far from a neat solution to the problem.
To see why, consider the following contracts:
C0: call(C1); call(C1);
C1: call(C2); call(C2);
C2: call(C3); call(C3);
...
C49: call(C50); call(C50);
C50: (run one step of a program and record the change in storage)
Now, send a transaction to A.
Thus, in 51 transactions, we have a contract that takes up 2<sup>50</sup> computational steps.
Miners could try to detect such logic bombs ahead of time by maintaining a value alongside each contract specifying the maximum number of computational steps that it can take, and calculating this for contracts calling other contracts recursively, but that would require miners to forbid contracts that create other contracts (since the creation and execution of all 26 contracts above could easily be rolled into a single contract).
Another problematic point is that the address field of a message is a variable, so in general it may not even be possible to tell which other contracts a given contract will call ahead of time.
Hence, all in all, we have a surprising conclusion: Turing-completeness is surprisingly easy to manage, and the lack of Turing-completeness is equally surprisingly difficult to manage unless the exact same controls are in place - but in that case why not just let the protocol be Turing-complete?
The Ethereum network includes its own built-in currency, ether, which serves the dual purpose of providing a primary liquidity layer to allow for efficient exchange between various types of digital assets and, more importantly, of providing a mechanism for paying transaction fees. For convenience and to avoid future argument (see the current mBTC/uBTC/satoshi debate in Bitcoin), the denominations will be pre-labeled:
* 1: wei
* 10<sup>12</sup>: szabo
* 10<sup>15</sup>: finney
* 10<sup>18</sup>: ether
This should be taken as an expanded version of the concept of "dollars" and "cents" or "BTC" and "satoshi". In the near future, we expect "ether" to be used for ordinary transactions, "finney" for microtransactions and "szabo" and "wei" for technical discussions around fees and protocol implementation; the remaining denominations may become useful later and should not be included in clients at this point.
The issuance model will be as follows:
* Ether will be released in a currency sale at the price of 1000-2000 ether per BTC, a mechanism intended to fund the Ethereum organization and pay for development that has been used with success by other platforms such as Mastercoin and NXT. Earlier buyers will benefit from larger discounts. The BTC received from the sale will be used entirely to pay salaries and bounties to developers and invested into various for-profit and non-profit projects in the Ethereum and cryptocurrency ecosystem.
* 0.099x the total amount sold (60102216 ETH) will be allocated to the organization to compensate early contributors and pay ETH-denominated expenses before the genesis block.
* 0.099x the total amount sold will be maintained as a long-term reserve.
* 0.26x the total amount sold will be allocated to miners per year forever after that point.
| Group | At launch | After 1 year | After 5 years |
| Currency units | 1.198X | 1.458X | 2.498X |
| Purchasers | 83.5% | 68.6% | 40.0% |
| Reserve spent pre-sale | 8.26% | 6.79% | 3.96% |
| Reserve used post-sale | 8.26% | 6.79% | 3.96% |
| Miners | 0% | 17.8% | 52.0% |
Long-Term Supply Growth Rate (percent):
#!https://raw.githubusercontent.com/ethereumbuilders/GitBook/master/en/vitalik-diagrams/inflation.png!#
Despite the linear currency issuance, just like with Bitcoin over time the supply growth rate nevertheless tends to zero
The two main choices in the above model are (1) the existence and size of an endowment pool, and (2) the existence of a permanently growing linear supply, as opposed to a capped supply as in Bitcoin.
The justification of the endowment pool is as follows.
If the endowment pool did not exist, and the linear issuance reduced to 0.217x to provide the same inflation rate, then the total quantity of ether would be 16.5% less and so each unit would be 19.8% more valuable.
Hence, in the equilibrium 19.8% more ether would be purchased in the sale, so each unit would once again be exactly as valuable as before.
The organization would also then have 1.198x as much BTC, which can be considered to be split into two slices: the original BTC, and the additional 0.198x.
Hence, this situation is exactly equivalent to the endowment, but with one important difference: the organization holds purely BTC, and so is not incentivized to support the value of the ether unit.
The permanent linear supply growth model reduces the risk of what some see as excessive wealth concentration in Bitcoin, and gives individuals living in present and future eras a fair chance to acquire currency units, while at the same time retaining a strong incentive to obtain and hold ether because the "supply growth rate" as a percentage still tends to zero over time.
We also theorize that because coins are always lost over time due to carelessness, death, etc, and coin loss can be modeled as a percentage of the total supply per year, that the total currency supply in circulation will in fact eventually stabilize at a value equal to the annual issuance divided by the loss rate (eg. at a loss rate of 1%, once the supply reaches 26X then 0.26X will be mined and 0.26X lost every year, creating an equilibrium).
Note that in the future, it is likely that Ethereum will switch to a proof-of-stake model for security, reducing the issuance requirement to somewhere between zero and 0.05X per year.
In the event that the Ethereum organization loses funding or for any other reason disappears, we leave open a "social contract": anyone has the right to create a future candidate version of Ethereum, with the only condition being that the quantity of ether must be at most equal to `60102216 * (1.198 + 0.26 * n)` where `n` is the number of years after the genesis block.
Creators are free to crowd-sell or otherwise assign some or all of the difference between the PoS-driven supply expansion and the maximum allowable supply expansion to pay for development.
Candidate upgrades that do not comply with the social contract may justifiably be forked into compliant versions.
The Bitcoin mining algorithm works by having miners compute SHA256 on slightly modified versions of the block header millions of times over and over again, until eventually one node comes up with a version whose hash is less than the target (currently around 2<sup>192</sup>).
However, this mining algorithm is vulnerable to two forms of centralization.
First, the mining ecosystem has come to be dominated by ASICs (application-specific integrated circuits), computer chips designed for, and therefore thousands of times more efficient at, the specific task of Bitcoin mining.
This means that Bitcoin mining is no longer a highly decentralized and egalitarian pursuit, requiring millions of dollars of capital to effectively participate in.
Second, most Bitcoin miners do not actually perform block validation locally; instead, they rely on a centralized mining pool to provide the block headers.
This problem is arguably worse: as of the time of this writing, the top three mining pools indirectly control roughly 50% of processing power in the Bitcoin network, although this is mitigated by the fact that miners can switch to other mining pools if a pool or coalition attempts a 51% attack.
The current intent at Ethereum is to use a mining algorithm where miners are required to fetch random data from the state, compute some randomly selected transactions from the last N blocks in the blockchain, and return the hash of the result.
This has two important benefits.
First, Ethereum contracts can include any kind of computation, so an Ethereum ASIC would essentially be an ASIC for general computation - ie. a better CPU.
Second, mining requires access to the entire blockchain, forcing miners to store the entire blockchain and at least be capable of verifying every transaction.
This removes the need for centralized mining pools; although mining pools can still serve the legitimate role of evening out the randomness of reward distribution, this function can be served equally well by peer-to-peer pools with no central control.
This model is untested, and there may be difficulties along the way in avoiding certain clever optimizations when using contract execution as a mining algorithm.
However, one notably interesting feature of this algorithm is that it allows anyone to "poison the well", by introducing a large number of contracts into the blockchain specifically designed to stymie certain ASICs.
The economic incentives exist for ASIC manufacturers to use such a trick to attack each other.
Thus, the solution that we are developing is ultimately an adaptive economic human solution rather than purely a technical one.
One common concern about Ethereum is the issue of scalability.
Like Bitcoin, Ethereum suffers from the flaw that every transaction needs to be processed by every node in the network.
With Bitcoin, the size of the current blockchain rests at about 15 GB, growing by about 1 MB per hour.
If the Bitcoin network were to process Visa's 2000 transactions per second, it would grow by 1 MB per three seconds (1 GB per hour, 8 TB per year).
Ethereum is likely to suffer a similar growth pattern, worsened by the fact that there will be many applications on top of the Ethereum blockchain instead of just a currency as is the case with Bitcoin, but ameliorated by the fact that Ethereum full nodes need to store just the state instead of the entire blockchain history.
The problem with such a large blockchain size is centralization risk.
If the blockchain size increases to, say, 100 TB, then the likely scenario would be that only a very small number of large businesses would run full nodes, with all regular users using light SPV nodes.
In such a situation, there arises the potential concern that the full nodes could band together and all agree to cheat in some profitable fashion (eg. change the block reward, give themselves BTC).
Light nodes would have no way of detecting this immediately.
Of course, at least one honest full node would likely exist, and after a few hours information about the fraud would trickle out through channels like Reddit, but at that point it would be too late: it would be up to the ordinary users to organize an effort to blacklist the given blocks, a massive and likely infeasible coordination problem on a similar scale as that of pulling off a successful 51% attack.
In the case of Bitcoin, this is currently a problem, but there exists a blockchain modification https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/ which will alleviate this issue.
In the near term, Ethereum will use two additional strategies to cope with this problem.
First, because of the blockchain-based mining algorithms, at least every miner will be forced to be a full node, creating a lower bound on the number of full nodes.
Second and more importantly, however, we will include an intermediate state tree root in the blockchain after processing each transaction.
Even if block validation is centralized, as long as one honest verifying node exists, the centralization problem can be circumvented via a verification protocol.
If a miner publishes an invalid block, that block must either be badly formatted, or the state `S[n]` is incorrect.
Since `S[0]` is known to be correct, there must be some first state `S[i]` that is incorrect where `S[i-1]` is correct.
The verifying node would provide the index `i`, along with a "proof of invalidity" consisting of the subset of Patricia tree nodes needing to process `APPLY(S[i-1],TX[i]) -> S[i]`.
Nodes would be able to use those nodes to run that part of the computation, and see that the `S[i]` generated does not match the `S[i]` provided.
Another, more sophisticated, attack would involve the malicious miners publishing incomplete blocks, so the full information does not even exist to determine whether or not blocks are valid.
The solution to this is a challenge-response protocol: verification nodes issue "challenges" in the form of target transaction indices, and upon receiving a node a light node treats the block as untrusted until another node, whether the miner or another verifier, provides a subset of Patricia nodes as a proof of validity.
The Ethereum protocol was originally conceived as an upgraded version of a cryptocurrency, providing advanced features such as on-blockchain escrow, withdrawal limits, financial contracts, gambling markets and the like via a highly generalized programming language.
The Ethereum protocol would not "support" any of the applications directly, but the existence of a Turing-complete programming language means that arbitrary contracts can theoretically be created for any transaction type or application.
What is more interesting about Ethereum, however, is that the Ethereum protocol moves far beyond just currency.
Protocols around decentralized file storage, decentralized computation and decentralized prediction markets, among dozens of other such concepts, have the potential to substantially increase the efficiency of the computational industry, and provide a massive boost to other peer-to-peer protocols by adding for the first time an economic layer.
Finally, there is also a substantial array of applications that have nothing to do with money at all.
The concept of an arbitrary state transition function as implemented by the Ethereum protocol provides for a platform with unique potential; rather than being a closed-ended, single-purpose protocol intended for a specific array of applications in data storage, gambling or finance, Ethereum is open-ended by design, and we believe that it is extremely well-suited to serving as a foundational layer for a very large number of both financial and non-financial protocols in the years to come.
# idEthwprnot1#1. A sophisticated reader may notice that in fact a Bitcoin address is the hash of the elliptic curve public key, and not the public key itself.
However, it is in fact perfectly legitimate cryptographic terminology to refer to the pubkey hash as a public key itself.
This is because Bitcoin's cryptography can be considered to be a custom digital signature algorithm, where the public key consists of the hash of the ECC pubkey, the signature consists of the ECC pubkey concatenated with the ECC signature, and the verification algorithm involves checking the ECC pubkey in the signature against the ECC pubkey hash provided as a public key and then verifying the ECC signature against the ECC pubkey.
# idEthwprnot2#2. Technically, the median of the 11 previous blocks.
# idEthwprnot3#3. Internally, 2 and "CHARLIE" are both numbers, with the latter being in big-endian base 256 representation. Numbers can be at least 0 and at most 2<sup>256</sup>-1.
#idEthwprfrP1#1. Intrinsic value: http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/
#idEthwprfrP2#2. Smart property: https://en.bitcoin.it/wiki/Smart_Property
#idEthwprfrP3#3. Smart contracts: https://en.bitcoin.it/wiki/Contracts
#idEthwprfrP4#4. B-money: http://www.weidai.com/bmoney.txt
#idEthwprfrP5#5. Reusable proofs of work: http://www.finney.org/~hal/rpow/
#idEthwprfrP6#6. Secure property titles with owner authority: http://szabo.best.vwh.net/securetitle.html
#idEthwprfrP7#7. Bitcoin whitepaper: http://bitcoin.org/bitcoin.pdf
#idEthwprfrP8#8. Namecoin: https://namecoin.org/
#idEthwprfrP9#9. Zooko's triangle: http://en.wikipedia.org/wiki/Zooko's_triangle
#idEthwprfrP10#10. Colored coins whitepaper: https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit
#idEthwprfrP11#11. Mastercoin whitepaper: https://github.com/mastercoin-MSC/spec
#idEthwprfrP12#12. Decentralized autonomous corporations, Bitcoin Magazine: http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/
#idEthwprfrP13#13. Simplified payment verification: https://en.bitcoin.it/wiki/Scalability#Simplifiedpaymentverification
#idEthwprfrP14#14. Merkle trees: http://en.wikipedia.org/wiki/Merkle_tree
#idEthwprfrP15#15. Patricia trees: http://en.wikipedia.org/wiki/Patricia_tree
#idEthwprfrP16#16. GHOST: http://www.cs.huji.ac.il/~avivz/pubs/13/btc_scalability_full.pdf
#idEthwprfrP17#17. StorJ and Autonomous Agents, Jeff Garzik: http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoin-autonomous-agents.html
#idEthwprfrP18#18. Mike Hearn on Smart Property at Turing Festival: http://www.youtube.com/watch?v=Pu4PAMFPo5Y
#idEthwprfrP19#19. Ethereum RLP: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLP
#idEthwprfrP20#20. Ethereum Merkle Patricia trees: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-Tree
#idEthwprfrP21#21. Peter Todd on Merkle sum trees: http://sourceforge.net/p/bitcoin/mailman/message/31709140/
name::
* McsEngl.ethprl'Whisper@cptIt,
* McsEngl.Whisper@cptIt,
_DESCRIPTION:
In a nutshell whisper is a communication protocol for DApps to communicate with each other.
[https://github.com/ethereum/wiki/wiki/Whisper]
===
Whisper is a part of the Ethereum P2P protocol suite that allows for messaging between users via the same network that the blockchain runs on.
There are many uses, some of which are listed on the wiki
The protocol is seperate from the blockchain, so smart contracts do not have access.
Whisper has existed in a sort of alpha, working-prototype state for some time now. It can be enabled by using the -shh flag in geth, but nodes do not relay the messages by default, so chances are that messages won't get through unless you are directly connected to the recipient. API documentation can be found on github.
[http://ethereum.stackexchange.com/a/134]
name::
* McsEngl.ethnet'Node (ethnod)@cptIt,
* McsEngl.ethereum-node@cptIt,
* McsEngl.ethnet'node@cptIt,
* McsEngl.ethnod@cptIt,
_DESCRIPTION:
Nodes are COMPUTERS that run the-client-programs#ql:idEthclnt#
- stores a full or light copy of the-blockchain
- interacts with the-blockchain.
[hmnSngo.2017-03-16]
_GENERIC:
* blockchain-network-node#ql:idBcnnod#
_ADDRESS.WPG:
* https://www.ethernodes.org/network/1,
_DESCRIPTION:
Nodes that maintain and verify the network are incentivized by mathematically enforced economic incentives coded into the protocol.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#a-next-generation-blockchain]
===
Node overview
Id 000c157e3fdc04c299fcf1c433c51e7d079d33c4c9175275299c834f1fef355f
791741ae23ca387018320038caa90fc5e243bec3992d9a6d789b771dfea42f0f
Host 94.242.61.32
Port 46897
Client id Parity/v1.5.4-beta-74b850e-20170223/x86_64-linux-gnu/rustc1.15.1
Client Parity
Client version v1.5.4-beta-74b850e-20170223
OS x86_64-linux-gnu
Capabilities [par/1 par/2 eth/62 eth/63]
Protocol version 63
Network id 1
Total difficulty 204795435708956
Best hash c8268e06bf48ff52c6ce9be4f2b3560b5a881133b55f4a1e5d44a401a67477ad
Genesis hash 41941023680923e0fe4d74a34bdac8141f2540e3ae90623718e47d66d1ca4a2d
Last seen Thu Mar 16 2017 13:54:29 GMT+0100 (CET)
Country Russian Federation
City
[https://www.ethernodes.org/node/000c157e3fdc04c299fcf1c433c51e7d079d33c4c9175275299c834f1fef355f791741ae23ca387018320038caa90fc5e243bec3992d9a6d789b771dfea42f0f]
name::
* McsEngl.ethnod'Computer@cptIt,
_DESCRIPTION:
Thanks to Merkle trees, it is possible to build Ethereum nodes that run on all computers and laptops large and small, smart phones, and even internet of things devices such as those that will be produced by Slock.it.
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum// Buterin.Vitalik]
name::
* McsEngl.ethnod.AGGREGATE@cptIt,
{time.2017-03-16}
Total 10789 (100%)
United States 3175 (29.43%)
Germany 942 (8.73%)
United Kingdom 595 (5.51%)
Canada 496 (4.60%)
Russian Federation 484 (4.49%)
China 479 (4.44%)
Netherlands 459 (4.25%)
France 344 (3.19%)
Australia 275 (2.55%)
Switzerland 200 (1.85%)
[https://www.ethernodes.org/network/1]
{time.2017-02-03}
Total 6176 (100%)
United States 1826 (29.57%)
Germany 481 (7.79%)
Russian Federation 368 (5.96%)
United Kingdom 299 (4.84%)
China 286 (4.63%)
Canada 258 (4.18%)
Netherlands 256 (4.15%)
France 228 (3.69%)
Australia 125 (2.02%)
Switzerland 125 (2.02%)
[https://www.ethernodes.org/network/1]
name::
* McsEngl.ethnod.FULL@cptIt,
* McsEngl.ethnet'full-node@cptIt,
* McsEngl.ethnod.full@cptIt,
_DESCRIPTION:
Full nodes on the Bitcoin blockchain store every transaction made going back to the zero block; full nodes on the Ethereum blockchain additionally store the static code (if any) associated with a given account and that code’s current state in storage.
[https://medium.com/@ConsenSys/ethereum-bitcoin-plus-everything-a506dc780106#.izxhgdxdt]
name::
* McsEngl.ethnod.MINER (ethnodMnr)@cptIt,
* McsEngl.ethnodMnr@cptIt,
* McsEngl.ethminer@cptIt,
* McsEngl.ethminer-node@cptIt,
_DESCRIPTION:
Miner. A node on the network that mines, i.e., works to process blocks on the blockchain. You can see a partial list of live Ethereum miners here: stats.ethdev.com.
[https://medium.com/@ConsenSys/a-101-noob-intro-to-programming-smart-contracts-on-ethereum-695d15c1dab4#.5x9da12dp]
===
These transaction fees are collected by the nodes that validate the network. These “miners” are nodes in the Ethereum network that receive, propogate, verify, and execute transactions. The miners then group the transactions – which include many updates to the “state” of accounts in the Ethereum blockchain – into what are called “blocks”, and miners then compete with one another for their block to be the next one to be added to the blockchain. Miners are rewarded with ether for each successful block they mine. This provides the economic incentive for people to dedicate hardware and electricity to the Ethereum network.
...
Just as in the Bitcoin network, miners are tasked with solving a complex mathematical problem in order to successfully “mine” a block. This is known as a “Proof of Work”. Any computational problem that requires orders of magnitude more resources to solve algorithmically than it takes to verify the solution is a good candidate for proof of work. In order to discourage centralisation due to the use of specialised hardware (e.g. ASICs), as has occurred in the Bitcoin network, Ethereum chose a memory-hard computational problem. If the problem requires memory as well as CPU, the ideal hardware is in fact the general computer. This makes Ethereum’s Proof of Work ASIC-resistant, allowing a more decentralized distribution of security than blockchains whose mining is dominated by specialized hardware, like Bitcoin.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]
name::
* McsEngl.ethnodMnr'Hardware@cptIt,
_DESCRIPTION:
To mine Ethereum you need a GPU, 4+GB RAM, Etherum account and GPU miner.
The GPU must have at least 2GB memory.
Recomended AMD GPU driver 15.12.
[https://eth.nanopool.org/help]
name::
* McsEngl.ethnodMnr'Mining (ethmining)@cptIt,
* McsEngl.ethereum-mining@cptIt,
* McsEngl.ethnet'mining@cptIt,
* McsEngl.ethmining@cptIt,
* McsEngl.ethmng@cptIt,
_DESCRIPTION:
Mining is the process of dedicating effort (working) to bolster one series of transactions (a block) over any other potential competitor block.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
_DESCRIPTION:
The Ethereum network is kept running by computers all over the world.
In order to reward the computational costs of both processing the contracts and securing the network, there is a reward that is given to the computer that was able to create the latest block on the chain.
Every 12 seconds, on average, a new block is added to the blockchain with the latest transactions processed by the network and the computer that generated this block will be awarded 5 ether.
Due to the nature of the algorithm for block generation, this process (generating a proof of work) is guaranteed to be random and rewards are given in proportion to the computational power of each machine.
This process is usually called mining in the crypto-currency lingo.
[https://ethereum.org/ether]
===
Mining ether = Securing the Network = Verifying Computation
[https://ethereum-homestead.readthedocs.io/en/latest/mining.html#introduction]
name::
* McsEngl.ethmining'Resource@cptIt,
_ADDRESS.WPG:
* {2016.07} Amazon AWS Ethereum Cloud Mining Tutorial-12 Step Guide to Generating ETC! https://steemit.com/ethereum/@coininstant/amazon-aws-ethereum-cloud-mining-tutorial-12-step-guide-to-generating-etc,
name::
* McsEngl.ethnet'Blockchain (ethbcn)@cptIt,
* McsEngl.blockchain.ethereum@cptIt,
* McsEngl.blockchain-of-ethereum@cptIt,
* McsEngl.ethbcn@cptIt,
* McsEngl.ethblockchain@cptIt,
* McsEngl.ethdistributed-database@cptIt,
* McsEngl.ethereum-blockchain@cptIt,
* McsEngl.ethledger@cptIt,
* McsEngl.ethnet'blockchain@cptIt,
_DESCRIPTION:
The Ethereum blockchain (or "ledger") is the decentralized, massively replicated database in which the current state of all accounts is stored.
The blockchain uses a database called a Patricia tree (or "trie") to store all accounts; this is essentially a specialized kind of Merkle tree that acts as a generic key/value store.
[https://github.com/ethereum/wiki/wiki/Ethereum-Development-Tutorial#basics-of-the-ethereum-blockchain]
===
the blockchain, where all the EVM state is represented.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#262d]
===
Blockchain technology is the technological basis of Bitcoin, first described by its mysterious author Satoshi Nakamoto#ql:idBtchmnSnt# in his white paper “Bitcoin: A Peer-to-Peer Electronic Cash System”, published in 2008. While the use of blockchains for more general uses was already discussed in the original paper, it was not until a few years later that blockchain technology emerged as a generic term. A blockchain is a distributed computing architecture where every network node executes and records the same transactions, which are grouped into blocks. Only one block can be added at a time, and every block contains a mathematical proof that verifies that it follows in sequence from the previous block. In this way, the blockchain’s “distributed database” is kept in consensus across the whole network. Individual user interactions with the ledger (transactions) are secured by strong cryptography. Nodes that maintain and verify the network are incentivized by mathematically enforced economic incentives coded into the protocol.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#a-next-generation-blockchain]
name::
* McsEngl.ethbcn'Block (ethblk)@cptIt,
* McsEngl.ethblk@cptIt,
* McsEngl.ethblock@cptIt,
* McsEngl.ethereum-block@cptIt,
* McsEngl.ethnet'block@cptIt,
_DESCRIPTION:
4.4. The Block. The block in Ethereum is the collection of relevant pieces of information (known as the block header ), H, together with information corresponding to the comprised transactions, T, and a set of other block headers U that are known to have a parent equal to the present block’s parent’s parent (such blocks are known as ommers2).
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
The blocks on the blockchain represent units of time, the blockchain itself is a temporal dimension and represents the entire of history of states at the discrete time points designated by the blocks on the chain.
[https://ethereum-homestead.readthedocs.org/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#eoa-vs-contract-accounts]
name::
* McsEngl.ethblk'part.Header (ethblkH)@cptIt,
* McsEngl.ethblk'header@cptIt,
* McsEngl.ethblkH@cptIt,
_DESCRIPTION:
4.4. The Block.
The block in Ethereum is the collection of relevant pieces of information (known as the block header ), H, together with information corresponding to the comprised transactions, T, and a set of other block headers U that are known to have a parent equal to the present block’s parent’s parent (such blocks are known as ommers2).
The block header contains several pieces of information:
parentHash: The Keccak 256-bit hash of the parent block’s header, in its entirety; formally Hp.
ommersHash: The Keccak 256-bit hash of the ommers list portion of this block; formally Ho.
beneficiary: The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally Hc.
stateRoot: The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally Hr.
transactionsRoot: The Keccak 256-bit hash of the root node of the trie structure populated with
each transaction in the transactions list portion of the block; formally Ht.
receiptsRoot: The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally He.
logsBloom: The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally Hb.
difficulty: A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block’s difficulty level and the timestamp; formally Hd.
number: A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally Hi.
gasLimit: A scalar value equal to the current limit of gas expenditure per block; formally Hl.
gasUsed: A scalar value equal to the total gas used in transactions in this block; formally Hg.
timestamp: A scalar value equal to the reasonable output of Unix’s time() at this block’s inception; formally Hs.
extraData: An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally Hx.
mixHash: A 256-bit hash which proves combined with the nonce that a sufficient amount of computation has been carried out on this block; formally Hm.
nonce: A 64-bit hash which proves combined with the mix-hash that a sufficient amount of computation has been carried out on this block; formally Hn.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethblk'parentHash (ethblkHp)@cptIt,
* McsEngl.ethblk'parentHash@cptIt,
* McsEngl.ethblk'parent-hash@cptIt,
* McsEngl.ehtblkHp@cptIt,
_DESCRIPTION:
parentHash: The Keccak 256-bit hash of the parent block’s header, in its entirety; formally Hp.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethblk'ommersHash (ethblkHo)@cptIt,
* McsEngl.ethblk'ommersHash@cptIt,
* McsEngl.ethblk'ommers-hash@cptIt,
* McsEngl.ehtblkHo@cptIt,
_DESCRIPTION:
ommersHash: The Keccak 256-bit hash of the ommers list portion of this block; formally Ho.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethblk'beneficiary (ethblkHc)@cptIt,
* McsEngl.ethblk'beneficiary@cptIt,
* McsEngl.ethblk'miner@cptIt,
* McsEngl.ehtblkHc@cptIt,
_DESCRIPTION:
beneficiary: The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally Hc.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
20-bytes, 40-hexs,
===
Miner bb7b8287f3f0a933474a79eae42cbca977791171
[https://live.ether.camp/block/59]
name::
* McsEngl.ethblk'stateRoot (ethblkHr)@cptIt,
* McsEngl.ethblk'stateRoot@cptIt,
* McsEngl.ehtblkHr@cptIt,
_DESCRIPTION:
stateRoot: The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally Hr.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethblk'transactionsRoot (ethblkHt)@cptIt,
* McsEngl.ethblk'transactionsRoot@cptIt,
* McsEngl.ehtblkHt@cptIt,
_DESCRIPTION:
transactionsRoot: The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally Ht.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethblk'receiptsRoot (ethblkHe)@cptIt,
* McsEngl.ethblk'receiptsRoot@cptIt,
* McsEngl.ehtblkHe@cptIt,
_DESCRIPTION:
receiptsRoot: The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally He.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethblk'logsBloom (ethblkHb)@cptIt,
* McsEngl.ethblk'logsBloom@cptIt,
* McsEngl.ehtblkHb@cptIt,
_DESCRIPTION:
logsBloom: The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally Hb.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethblk'difficulty (ethblkHd)@cptIt,
* McsEngl.ethblk'difficulty@cptIt,
* McsEngl.ehtblkHd@cptIt,
_DESCRIPTION:
difficulty: A scalar value corresponding to the difficulty level of this block.
This can be calculated from the previous block’s difficulty level and the timestamp; formally Hd.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
Difficulty 17561410778
[https://live.ether.camp/block/59]
name::
* McsEngl.ethblk'number (ethblkHi)@cptIt,
* McsEngl.ethblk'height@cptIt,
* McsEngl.ethblk'number@cptIt,
* McsEngl.ehtblkHi@cptIt,
_DESCRIPTION:
number: A scalar value equal to the number of ancestor blocks.
The genesis block has a number of zero; formally Hi.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
Block#3000059
Hash 55bf7cf28ef891df9683fe80de1f7a985d803f8f21755a7977e76916b6dd78a3
Prev Hash d232b55f0b77a22fbc40ceea7ab9b9ba592034b5c9a71e2dca57c2912054bd72
Next Hash
Transactions 0
Uncle Hash 55bf7cf28ef891df9683fe80de1f7a985d803f8f21755a7977e76916b6dd78a3
Nonce c09eea000f9a5886
State Root 0920e25b921c1b518ce5ccbbada31fcec225f118a364d9c271d0bb3c591fa229
Tx Trie Root 56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421
Timestamp a month ago [1484475724]
Gas Limit 4000881
Gas Used 0
Miner c0ea08a2d404d3172d2add29a45be56da40e2949
Difficulty 104754858920035
Extra Data www.bw.com [7777772e62772e636f6d]
Bloom Filter
00 00 00 00 00 00 00 00
...
00 00 00 00 00 00 00 00
[https://live.ether.camp/block/3000059]
name::
* McsEngl.ethblkHi.Homestead@cptIt,
_DESCRIPTION:
4.2. Homestead. A significant block number for compatibility with the public network is the block marking the transition between the Frontier and Homestead phases of the platform, which we denote with the symbol NH, defined thus
(13) NH = 1,150,000
The protocol was upgraded at this block, so this symbol appears in some equations to account for the changes.
name::
* McsEngl.ethblk'gasLimit (ethblkHl)@cptIt,
* McsEngl.ethblk'gasLimit@cptIt,
* McsEngl.ehtblkHl@cptIt,
_DESCRIPTION:
gasLimit: A scalar value equal to the current limit of gas expenditure per block; formally Hl.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethblk'gasUsed (ethblkHg)@cptIt,
* McsEngl.ethblk'gasUsed@cptIt,
* McsEngl.ehtblkHg@cptIt,
_DESCRIPTION:
gasUsed: A scalar value equal to the total gas used in transactions in this block; formally Hg.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethblk'timestamp (ethblkHs)@cptIt,
* McsEngl.ethblk'timestamp@cptIt,
* McsEngl.ehtblkHs@cptIt,
_DESCRIPTION:
timestamp: A scalar value equal to the reasonable output of Unix’s time() at this block’s inception; formally Hs.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
Timestamp 2 years ago [1438270327]
[https://live.ether.camp/block/59]
name::
* McsEngl.ethblk'extraData (ethblkHx)@cptIt,
* McsEngl.ethblk'extraData@cptIt,
* McsEngl.ehtblkHx@cptIt,
_DESCRIPTION:
extraData: An arbitrary byte array containing data relevant to this block.
This must be 32 bytes or fewer; formally Hx.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
Extra Data Geth/LVIV/v1.0.0/linux/go1.4.2 [476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32]
[https://live.ether.camp/block/59]
name::
* McsEngl.ethblk'mixHash (ethblkHm)@cptIt,
* McsEngl.ethblk'mixHash@cptIt,
* McsEngl.ethblk'mix-hash@cptIt,
* McsEngl.ehtblkHm@cptIt,
_DESCRIPTION:
mixHash: A 256-bit hash which proves combined with the nonce that a sufficient amount of computation has been carried out on this block; formally Hm.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethblk'nonce (ethblkHn)@cptIt,
* McsEngl.ethblk'nance@cptIt,
* McsEngl.ehtblkHn@cptIt,
_DESCRIPTION:
nonce: A 64-bit hash which proves combined with the mix-hash that a sufficient amount of computation has been carried out on this block; formally Hn.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
Nonce: a meaningless value in a block which can be adjusted in order to try to satisfy the proof of work condition
[https://github.com/ethereum/wiki/wiki/Glossary]
===
Nonce 4ce04218c05e8275
[https://live.ether.camp/block/59]
name::
* McsEngl.ethblk'part.Transaction-list@cptIt,
* McsEngl.ethblk'transaction-list@cptIt,
* McsEngl.ethblkT@cptIt,
_DESCRIPTION:
4.4. The Block. The block in Ethereum is the collection of relevant pieces of information (known as the block header ), H, together with information corresponding to the comprised transactions, T, and a set of other block headers U that are known to have a parent equal to the present block’s parent’s parent (such blocks are known as ommers2).
...The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethblk'part.Ommer-list@cptIt,
* McsEngl.ethblk'ommer-list@cptIt,
* McsEngl.ethblkU@cptIt,
_DESCRIPTION:
4.4. The Block. The block in Ethereum is the collection of relevant pieces of information (known as the block header ), H, together with information corresponding to the comprised transactions, T, and a set of other block headers U that are known to have a parent equal to the present block’s parent’s parent (such blocks are known as ommers2).
...The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethblk'Hash@cptIt,
* McsEngl.ethblk'hash@cptIt,
_DESCRIPTION:
Hash 4d9423080290a650eaf6db19c87c76dff83d1b4ab64aefe6e5c5aa2d1f4b6623
Prev Hash cd5b5c4cecd7f18a13fe974255badffd58e737dc67596d56bc01f063dd282e9e
Next Hash 3cd0324c7ba14ba7cf6e4b664dea0360681458d76bd25dfc0d2207ce4e9abed4
Transactions 0
Uncle Hash 4d9423080290a650eaf6db19c87c76dff83d1b4ab64aefe6e5c5aa2d1f4b6623
[https://live.ether.camp/block/59]
name::
* McsEngl.ethblk'Gas@cptIt,
* McsEngl.ethblk'gas@cptIt,
_DESCRIPTION:
Gas Limit 5000
Gas Used 0
[https://live.ether.camp/block/59]
name::
* McsEngl.ethblk'Merkle-tree@cptIt,
* McsEngl.ethblk'Merkle-tree@cptIt,
* McsEngl.ethblk'Merkle-tree-hashing-algorithm@cptIt,
* McsEngl.ethblk'Merkle-trie@cptIt,
* McsEngl.ethnet'Merkle-tree@cptIt,
* McsEngl.Merkle-tree@cptIt,
_DESCRIPTION:
First, the basics. A Merkle tree, in the most general sense, is a way of hashing a large number of “chunks” of data together which relies on splitting the chunks into buckets, where each bucket contains only a few chunks, then taking the hash of each bucket and repeating the same process, continuing to do so until the total number of hashes remaining becomes only one: the root hash.
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum// Buterin.Vitalik]
_DESCRIPTION:
A Merkle proof consists of a chunk, the root hash of the tree, and the “branch” consisting of all of the hashes going up along the path from the chunk to the root. Someone reading the proof can verify that the hashing, at least for that branch, is consistent going all the way up the tree, and therefore that the given chunk actually is at that position in the tree. The application is simple: suppose that there is a large database, and that the entire contents of the database are stored in a Merkle tree where the root of the Merkle tree is publicly known and trusted (eg. it was digitally signed by enough trusted parties, or there is a lot of proof of work on it). Then, a user who wants to do a key-value lookup on the database (eg. “tell me the object in position 85273”) can ask for a Merkle proof, and upon receiving the proof verify that it is correct, and therefore that the value received actually is at position 85273 in the database with that particular root. It allows a mechanism for authenticating a small amount of data, like a hash, to be extended to also authenticate large databases of potentially unbounded size.
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum// Buterin.Vitalik]
_DESCRIPTION:
The original application of Merkle proofs was in Bitcoin, as described and created by Satoshi Nakamoto#ql:idBtchmnSnt# in 2009. The Bitcoin blockchain uses Merkle proofs in order to store the transactions in every block:
The benefit that this provides is the concept that Satoshi described as “simplified payment verification”: instead of downloading every transaction and every block, a “light client” can only download the chain of block headers, 80-byte chunks of data for each block that contain only five things:
A hash of the previous header
A timestamp
A mining difficulty value
A proof of work nonce
A root hash for the Merkle tree containing the transactions for that block.
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum// Buterin.Vitalik]
_DESCRIPTION:
Every block header in Ethereum contains not just one Merkle tree, but three trees for three kinds of objects:
- Transactions
- Receipts (essentially, pieces of data showing the effect of each transaction)
- State
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum// Buterin.Vitalik]
name::
* McsEngl.ethblk'Time@cptIt,
* McsEngl.ethblk'time@cptIt,
name::
* McsEngl.ethblk'Generation (Time-between-blocks)@cptIt,
* McsEngl.ethnet'blocktime@cptIt,
_DESCRIPTION:
The-time between block creation.
===
As dictated by the protocol, the difficulty dynamically adjusts in such a way that on average one block is produced by the entire network every 15 seconds. We say that the network produces a blockchain with a 15 second block time
[https://ethereum-homestead.readthedocs.io/en/latest/mining.html#what-is-mining]
name::
* McsEngl.ethblk'Relation-to-bitcoin-block@cptIt,
* McsEngl.ethblk'relation-to-bitcoin-block@cptIt,
_DESCRIPTION:
The main difference between Ethereum and Bitcoin with regard to the blockchain architecture is that, unlike Bitcoin, Ethereum blocks contain a copy of both the transaction list and the most recent state.
Aside from that, two other values, the block number and the difficulty, are also stored in the block.
[https://github.com/ethereum/wiki/wiki/White-Paper#blockchain-and-mining]
name::
* McsEngl.ethblk'Resource@cptIt,
_ADDRESS.WPG:
* https://etherchain.org/blocks,
* https://etherchain.org/block/3270980,
name::
* McsEngl.ethblk.GENESIS@cptIt,
* McsEngl.ethblk.first@cptIt,
* McsEngl.ethblk.genesis@cptIt,
* McsEngl.ethnet'genesis-block@cptIt,
_DESCRIPTION:
First, to initialize a new private blockchain, we will need what is called a Genesis block, which is going to be the first block in our blockchain.
This first block sets a few fundamental parameters for our blockchain, captured in a genesis.json file:
{
"nonce": "0x0000000000000042",
"mixhash": "0x0000000000000000000000000000000000000000000000000000000000000000",
"difficulty": "0x4000",
"alloc": {},
"coinbase": "0x0000000000000000000000000000000000000000",
"timestamp": "0x00",
"parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
"extraData": "Custom Ethereum Genesis Block",
"gasLimit": "0xffffffff"
}
[http://hypernephelist.com/2016/05/30/deploying-a-private-Ethereum-blockchain.html]
===
The genesis block has a number of zero; formally Hi.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
_ADDRESS.WPG:
* BlockH0 https://etherscan.io/block/0,
* http://ethdocs.org/en/latest/network/test-networks.html#the-genesis-file,
name::
* McsEngl.ethblk.LAST@cptIt,
* McsEngl.ethnet'best-block@cptIt,
* McsEngl.ethnet'last-block@cptIt,
* McsEngl.ethblk.last@cptIt,
name::
* McsEngl.ethblk.UNCLE@cptIt,
* McsEngl.ethblk.uncle@cptIt,
* McsEngl.ethnet'uncle@cptIt,
_DESCRIPTION:
Uncles are stale blocks i.e. with parents that are ancestors (max 6 blocks back) of the including block.
Valid uncles are rewarded in order to neutralise the effect of network lag on the dispersion of mining rewards, thereby increasing security (this is called the GHOST protocol).
Uncles included in a block formed by the successful PoW miner receive 7/8 of the static block reward (=4.375 ether).
A maximum of 2 uncles are allowed per block.
[https://ethereum-homestead.readthedocs.io/en/latest/mining.html#what-is-mining]
name::
* McsEngl.ethblk.PARENT@cptIt,
* McsEngl.ethblk.parent@cptIt,
name::
* McsEngl.ethblk.ANCESTOR@cptIt,
* McsEngl.ethblk.ancestor@cptIt,
name::
* McsEngl.ethbcn'Block-Explorer (ethbex)@cptIt,
* McsEngl.ethereum-block-explorer@cptIt,
* McsEngl.ethblk'explorer@cptIt,
* McsEngl.ethnet'explorer@cptIt,
_SPECIFIC:
* https://etherscan.io//
* https://etherchain.org//
* https://live.ether.camp//
name::
* McsEngl.ethbcn'Consensus-algorithm (ethcsa)@cptIt,
* McsEngl.block-validation-algorithm-of-ethereum@cptIt,
* McsEngl.ethereum-block-validation-algorithm@cptIt,
* McsEngl.ethconsensus-algorithm@cptIt,
* McsEngl.ethcsa@cptIt,
* McsEngl.ethnet'consensus-algorithm@cptIt,
_DESCRIPTION:
Consensus is based on choosing the block with the highest total difficulty.
... Note that in the Ethereum Serenity milestone, this is likely going to be replaced by a (see proof of stake model ).
[https://ethereum-homestead.readthedocs.io/en/latest/mining.html#what-is-mining]
===
a system such that we can reasonably expect that an agreement will be thus enforced autonomously,
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
The basic block validation algorithm in Ethereum is as follows:
1. Check if the previous block referenced exists and is valid.
2. Check that the timestamp of the block is greater than that of the referenced previous block and less than 15 minutes into the future
3. Check that the block number, difficulty, transaction root, uncle root and gas limit (various low-level Ethereum-specific concepts) are valid.
4. Check that the proof of work on the block is valid.
5. Let S[0] be the state at the end of the previous block.
6. Let TX be the block's transaction list, with n transactions. For all i in 0...n-1, set S[i+1] = APPLY(S[i],TX[i]). If any application returns an error, or if the total gas consumed in the block up until this point exceeds the GASLIMIT, return an error.
7. Let S_FINAL be S[n], but adding the block reward paid to the miner.
8. Check if the Merkle tree root of the state S_FINAL is equal to the final state root provided in the block header. If it is, the block is valid; otherwise, it is not valid.
[https://github.com/ethereum/wiki/wiki/White-Paper#blockchain-and-mining]
_GENERIC:
* bcnnet-consensus-algorithm#ql:idBcncsa#
name::
* McsEngl.ethcsa.Proof-of-Authority (ethpoa)@cptIt,
* McsEngl.ethpoa@cptIt,
* McsEngl.proof-of-authority@cptIt,
_DESCRIPTION:
Fortunately, the next version of the Ethereum testnet, Kovan, has been announced by the Parity community. Although this new testnet is incompatible with geth nodes, it uses the PoA (Proof of Authority) consensus, which should improve its resilience to spam attacks. ChronoBank has also made an application to become a trusted validator for the new testnet.
PoA is a replacement for PoW and can be used for both public and private chain setups. There is no mining involved to secure the network with PoA. Instead, it relies on trusted ‘Validators’ to ensure that legitimate transactions are added to blocks, and are processed and executed by the EVM faithfully.
Because mining does not occur on our proposed public testnet, malicious actors are prevented from acquiring testnet Ether -- solving the spam attack that Ropsten currently faces. There is no difference in the way that contracts are executed on PoA and PoW chains, so developers can test their contracts and user interfaces before deploying to the mainnet in a more reliable and convenient environment.
[https://blog.chronobank.io/chronobank-dev-update-7-49b387396b2c#.odbp6hdr9]
name::
* McsEngl.ethbcn'Size@cptIt,
{time.2016-03-16}:
Top News - Bitcoin Retweeted
Tuur Demeester ?@TuurDemeester 5h5 hours ago
8 months in,#Ethereum blockchain size is 10GB — some estimate growth rate of up to 1TB/yr. Thoughts on network scalability vs. security?
[https://twitter.com/TuurDemeester/status/710101175610286081]
How will Ethereum deal with ever increasing blockchain size?
There are many discussions around blockchain scalability. This questioned has been partially answered on this Ethereum StackExchange post and this blog post from Vitalik Buterin.
[https://ethereum-homestead.readthedocs.org/en/latest/frequently-asked-questions/frequently-asked-questions.html#how-will-ethereum-deal-with-ever-increasing-blockchain-size]
name::
* McsEngl.ethbcn'Transaction (ethtx)@cptIt,
* McsEngl.ethereum-message@cptIt,
* McsEngl.ethereum-transaction@cptIt,
* McsEngl.ethnet'Transaction@cptIt,
* McsEngl.ethtransaction@cptIt,
* McsEngl.ethtsn@cptIt,
* McsEngl.ethtx@cptIt,
_DESCRIPTION:
Transactions fundamentally change the state of the network.
A transaction can be
- as simple as sending Ether to another account, or
- as complicated as executing a contract function or
- adding a new contract to the network.
The defining characteristic of a transaction is that it writes (or changes) data.
Transactions cost Ether to run, known as "gas", and transactions take time to process.
When you execute a contract's function via a transaction, you cannot receive that function's return value because the transaction isn't processed immediately.
In general, functions meant to be executed via a transaction will not return a value; they will return a transaction id instead.
So in summary, transactions:
- Cost gas (Ether)
- Change the state of the network
- Aren't processed immediately
- Won't expose a return value (only a transaction id).
[http://truffleframework.com/docs/getting_started/contracts#transactions]
_GENERIC:
* blockchain-transaction#ql:idBcntx#
_DESCRIPTION:
The term “transaction” is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account.
images/chapter1/1-4.png
Transactions contain:
- recipient: The account the transaction is intended for.
- sender: A signature representing the originator of the transaction.
- amount: The amount of ETH to transfer from the sender to the recipient.
- data: An optional field to pass data to the smart contract.
- startgas: A value representing the maximum number of computational steps the transaction execution is allowed to take.
- gasprice: A value representing the fee the sender pays per computational step.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
===
A transaction is a message that is sent from one account to another account (which might be the same or the special zero-account, see below). It can include binary data (its payload) and Ether.
If the target account contains code, that code is executed and the payload is provided as input data.
If the target account is the zero-account (the account with the address 0), the transaction creates a new contract. As already mentioned, the address of that contract is not the zero address but an address derived from the sender and its number of transactions sent (the “nonce”). The payload of such a contract creation transaction is taken to be EVM bytecode and executed. The output of this execution is permanently stored as the code of the contract. This means that in order to create a contract, you do not send the actual code of the contract, but in fact code that returns that code.
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-8]
===
A blockchain is a globally shared, transactional database.
This means that everyone can read entries in the database just by participating in the network.
If you want to change something in the database, you have to create a so-called transaction which has to be accepted by all others.
The word transaction implies that the change you want to make (assume you want to change two values at the same time) is either not done at all or completely applied.
Furthermore, while your transaction is applied to the database, no other transaction can alter it.
As an example, imagine a table that lists the balances of all accounts in an electronic currency. If a transfer from one account to another is requested, the transactional nature of the database ensures that if the amount is subtracted from one account, it is always added to the other account. If due to whatever reason, adding the amount to the target account is not possible, the source account is also not modified.
Furthermore, a transaction is always cryptographically signed by the sender (creator). This makes it straightforward to guard access to specific modifications of the database. In the example of the electronic currency, a simple check ensures that only the person holding the keys to the account can transfer money from it.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#transactions]
===
The term “transaction” is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account to another account on the blockchain.
Transactions contain:
the recipient of the message,
a signature identifying the sender and proving their intention to send the message to the blockchain to the reciptient,
VALUE field - The amount of wei to transfer from the sender to the recipient,
an optional data field, which can contain the message sent to a contract,
a STARTGAS value, representing the maximum number of computational steps the transaction execution is allowed to take,
a GASPRICE value, representing the fee the sender is willing to pay for gas. One unit of gas corresponds to the execution of one atomic instrucion, i.e., a computational step.
[https://ethereum-homestead.readthedocs.org/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#what-is-a-transaction]
===
The Ethereum blockchain tracks the state of every account, and all state transitions on the Ethereum blockchain are transfers of value and information between accounts.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]
name::
* McsEngl.ethtx'part.nonce (ethtxTn)@cptIt,
* McsEngl.ethtx'nonce@cptIt,
* McsEngl.ethtxTn@cptIt,
_DESCRIPTION:
nonce: A scalar value equal to the number of transactions sent by the sender; formally Tn.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethtx'part.gasPrice (ethtxTp)@cptIt,
* McsEngl.ethtx'gasPrice@cptIt,
* McsEngl.ethtxTp@cptIt,
_DESCRIPTION:
gasPrice: A scalar value equal to the number of Wei to be paid per unit of gas for all computation costs incurred as a result of the execution of this transaction; formally Tp.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethtx'part.gasLimit (ethtxTg)@cptIt,
* McsEngl.ethtx'gasLimit@cptIt,
* McsEngl.ethtxTg@cptIt,
_DESCRIPTION:
gasLimit:
A scalar value equal to the maximum amount of gas that should be used in executing this transaction.
This is paid up-front, before any computation is done and may not be increased later; formally Tg.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethtx'part.to (ethtxTt)@cptIt,
* McsEngl.ethtx'destination@cptIt,
* McsEngl.ethtx'recipient@cptIt,
* McsEngl.ethtx'recipient-account@cptIt,
* McsEngl.ethtx'target-account@cptIt,
* McsEngl.ethtx'to@cptIt,
* McsEngl.ethtxTt@cptIt,
_DESCRIPTION:
to: The 160-bit address of the message call’s recipient or, for a contract creation transaction, Ψ, used here to denote the only member of B0 ; formally Tt.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
If the destination of the transaction is another EOA#ql:etheoa#, then the transaction may transfer some ether but otherwise does nothing.
However, if the destination is a-contract#ql:ethcta#, then the contract in turn activates, and automatically runs its code.
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#account-interactions-example-betting-contract]
===
If the target account contains code, that code is executed and the payload is provided as input data.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-8]
name::
* McsEngl.ethtx'part.value (ethtxTv)@cptIt,
* McsEngl.ethtx'ether@cptIt,
* McsEngl.ethtx'value@cptIt,
* McsEngl.ethtxTv@cptIt,
_DESCRIPTION:
value: A scalar value equal to the number of Wei to be transferred to the message call’s recipient or, in the case of contract creation, as an endowment to the newly created account; formally Tv.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
A transaction is a message that is sent from one account to another account (which might be the same or the-special-zero-account#ql:ethact.zero#, see below).
It can include binary data (its payload) and Ether.
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-8]
name::
* McsEngl.ethtx'part.v (ethtxTw)@cptIt,
* McsEngl.ethtx'v@cptIt,
* McsEngl.ethtxTw@cptIt,
_DESCRIPTION:
v, r, s: Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally Tw, Tr and Ts. This is expanded in Appendix F.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethtx'part.r (ethtxTr)@cptIt,
* McsEngl.ethtx'r@cptIt,
* McsEngl.ethtxTr@cptIt,
_DESCRIPTION:
v, r, s: Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally Tw, Tr and Ts. This is expanded in Appendix F.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethtx'part.s (ethtxTs)@cptIt,
* McsEngl.ethtx's@cptIt,
* McsEngl.ethtxTs@cptIt,
_DESCRIPTION:
v, r, s: Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally Tw, Tr and Ts. This is expanded in Appendix F.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethtx'Hash@cptIt,
TxHash: 0xbe5070a938fa049d360e881fbbb1f3e4e0f71344f07921a9e167b5f49fe5f28b (64 hexsymbols)
name::
* McsEngl.ethtx'Block@cptIt,
* McsEngl.ethtx'block-height@cptIt,
name::
* McsEngl.ethtx'Age@cptIt,
* McsEngl.ethtx'timestamp@cptIt,
name::
* McsEngl.ethtx'Sender-account@cptIt,
* McsEngl.ethtx'creator@cptIt,
* McsEngl.ethtx'from@cptIt,
_DESCRIPTION:
Furthermore, a transaction is always cryptographically signed by the sender (creator).
This makes it straightforward to guard access to specific modifications of the database.
In the example of the electronic currency, a simple check ensures that only the person holding the keys to the account can transfer money from it.
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html]
===
An Ethereum transaction contract code can trigger data reads and writes, do expensive computations like using cryptographic primitives, make calls (send messages) to other contracts, etc. Each of these operations have a cost measured in gas, and each gas unit consumed by a transaction must be paid for in Ether, based on a gas/Ether price which changes dynamically.
This price is deducted from the Ethereum account sending the transaction.
Transactions also have a gas limit parameter that is an upper bound on how much gas the transaction can consume, and is used as a safe-guard against programming errors that could deplete an account’s funds.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#262d]
name::
* McsEngl.ethtx'Fee@cptIt,
* McsEngl.ethtx'cost@cptIt,
* McsEngl.ethtx'fee@cptIt,
_DESCRIPTION:
The total ether cost of a transaction is based on 2 factors:
gasUsed is the total gas that is consumed by the transaction
gasPrice price (in ether) of one unit of gas specified in the transaction
Total cost = gasUsed * gasPrice
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#estimating-transaction-costs]
===
Fees applied to transaction go to support the networks that run the coin/token - so, for instance, every standard (non-contract) ETH transaction currently applies a fee of .000441 ETH.
This fee does not go to us; it goes to reward miners (thereby ensuring that the transaction is logged into the blockchain in a timely fashion) and support the Ethereum network itself.
Note that transactions that interact with a contract address will be more costly.
[https://decentral.zendesk.com/hc/en-us/articles/225024248-What-are-transaction-fees-and-what-fees-does-Jaxx-apply-]
===
Like in Bitcoin, users must pay small transaction fees to the network. This protects the Ethereum blockchain from frivolous or malicious computational tasks, like DDoS attacks or infinite loops. The sender of a transaction must pay for each step of the “program” they activated, including computation and memory storage. These fees are paid in amounts of Ethereum’s native value-token, ether.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]
name::
* McsEngl.ethtx'Gas-limit@cptIt,
* McsEngl.ethtx'gas-limit@cptIt,
_DESCRIPTION:
Transactions also have a gas limit parameter that is an upper bound on how much gas the transaction can consume, and is used as a safe-guard against programming errors that could deplete an account’s funds.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#5ae8]
name::
* McsEngl.ethtx'Log@cptIt,
* McsEngl.ethtx'log@cptIt,
_DESCRIPTION:
Next we specify an event, which is how in Solidity we use the logging facility of the Ethereum Virtual Machine.
When called, events cause the arguments to be stored in the transaction’s log.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
_EXAMPLE:
* https://etherscan.io/tx/0x3238a040c9ff9c06067401b366b804ad4f3824186336eae4f1a8f43c8c981b78#eventlog,
name::
* McsEngl.ethtx'Security@cptIt,
* McsEngl.ethtx'security@cptIt,
_ADDRESS.WPG:
* http://tap.dappbench.com//
* https://github.com/dob/tap,
name::
* McsEngl.ethtx'Resource@cptIt,
_ADDRESS.WPG:
* https://etherscan.io/txs,
* https://etherchain.org/txs,
* https://etherchain.org/tx/0xfaee6da035c0a943002d2f4f65b7714d92f11a6465ca69595719f2707f134557,
* https://github.com/EverexIO/Ethplorer/wiki/ethplorer-api#get-transaction-info,
name::
* McsEngl.ethtx'DOING@cptIt,
_DESCRIPTION:
ether transfer or trigger contract code
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#externally-owned-accounts-eoas]
name::
* McsEngl.ethtx'Creating@cptIt,
* McsEngl.ethtx'signing@cptIt,
name::
* McsEngl.ethtx'Submitting@cptIt,
* McsEngl.ethtx'processing@cptIt,
name::
* McsEngl.ethtx.specific@cptIt,
* McsEngl.ethtx.specific@cptIt,
_SPECIFIC:
Broadly speaking there are three types transactions supported on Ethereum:
- Transfer of Ether from one party to another
- Creation of a smart contract
- Transacting with a smart contract
[https://docs.web3j.io/transactions.html]
===
There are two types of transactions: a sending transaction and a contract creating transaction.
[https://ethereum.gitbooks.io/frontier-guide/content/opcodes,_costs,_and_gas.html]
===
There are two types of transactions:
those which result in message calls and
those which result in the creation of new accounts with associated code (known informally as ‘contract creation’).
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethtx.MESSAGE-CALL (ethtxmc)@cptIt,
* McsEngl.ethnet'message-call@cptIt,
* McsEngl.ethtx.message-call@cptIt,
* McsEngl.ethtxmc@cptIt,
_DESCRIPTION:
There are two types of transactions:
those which result in message calls and
those which result in the creation of new accounts with associated code (known informally as ‘contract creation’).
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethtxmc'part.data (ethtxTd)@cptIt,
* McsEngl.ethnet'payload-of-tx@cptIt,
* McsEngl.ethtx'data@cptIt,
* McsEngl.ethtx'binary-data@cptIt,
* McsEngl.ethtx'payload@cptIt,
* McsEngl.ethtxTd@cptIt,
_DESCRIPTION:
In contrast, a message call transaction contains:
data: An unlimited size byte array specifying the input data of the message call, formally Td.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
A transaction is a message that is sent from one account to another account (which might be the same or the special zero-account, see below).
It can include binary data (its payload) and Ether.
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-8]
name::
* McsEngl.ethtxmc.ETHER-TRANSFER@cptIt,
* McsEngl.ethtx.sending@cptIt,
* McsEngl.ethtx.standard@cptIt,
_DESCRIPTION:
The simplest transactions are ether transfer transactions.
[https://ethereum.gitbooks.io/frontier-guide/content/account_types.html]
===
A sending transaction is a standard transaction, containing a receiving address, an ether amount, a data bytearray and some other parameters, and a signature from the private key associated with the sender account.
[https://ethereum.gitbooks.io/frontier-guide/content/opcodes,_costs,_and_gas.html]
===
All code execution in the Ethreum Virtual Machine, or EVM must be triggered by a private key based account. This is done by sending a transaction, which may do something simple like transfering ether, or it may do something more complex like calling a function on a contract account.
[http://docs.ethereum-alarm-clock.com/en/latest/introduction.html]
name::
* McsEngl.ethtxmc.CONTRACT-PROGRAM-CALLING@cptIt,
* McsEngl.ethtx.interacting-with-contract@cptIt,
* McsEngl.ethtx.transacting-with-contract@cptIt,
* McsEngl.ethtx.contract-calling@cptIt,
* McsEngl.ethtx.contract-invocating@cptIt,
_DESCRIPTION:
your transactions are also of two types:
- those sent to normal accounts are ether transfers,
- while the rest are communication with smart contracts.
[https://www.ethereum.org/ether]
name::
* McsEngl.ethtx.CONTRACT-ACOUNT-CREATION (ethtxcac)@cptIt,
* McsEngl.ethtx.contract-acount-creation@cptIt,
* McsEngl.ethtx.contract-creating-transaction@cptIt,
* McsEngl.ethtxcac@cptIt,
_DESCRIPTION:
If the target account is the zero-account (the account with the address 0), the transaction creates a new contract.
As already mentioned, the address of that contract is not the zero address but an address derived from the sender and its number of transactions sent (the “nonce”).
The payload of such a contract creation transaction is taken to be EVM bytecode and executed.
The output of this execution is permanently stored as the code of the contract.
This means that in order to create a contract, you do not send the actual code of the contract, but in fact code that returns that code.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-8]
===
A contract creating transaction looks like a standard transaction, except the receiving address is blank. When a contract creating transaction makes its way into the blockchain, the data bytearray in the transaction is interpreted as EVM code, and the value returned by that EVM execution is taken to be the code of the new contract; hence, you can have a transaction do certain things during initialization. The address of the new contract is deterministically calculated based on the sending address and the number of times that the sending account has made a transaction before (this value, called the account nonce, is also kept for unrelated security reasons). Thus, the full code that you need to put onto the blockchain to produce the above name registry is as follows:
PUSH1 16 DUP PUSH1 12 PUSH1 0 CODECOPY PUSH1 0 RETURN STOP PUSH1 0 CALLDATALOAD SLOAD NOT PUSH1 9 JUMPI STOP PUSH1 32 CALLDATALOAD PUSH1 0 CALLDATALOAD SSTORE
The key opcodes are CODECOPY, copying the 16 bytes of code starting from byte 12 into memory starting at index 0, and RETURN, returning memory bytes 0-16, ie. code byes 12-28 (feel free to "run" the execution manually on paper to verify that those parts of the code and memory actually get copied and returned). Code bytes 12-28 are, of course, the actual code as we saw above.
[https://ethereum.gitbooks.io/frontier-guide/content/opcodes,_costs,_and_gas.html]
name::
* McsEngl.ethtxcac'part.init (ethtxTi)@cptIt,
* McsEngl.ethtx'init@cptIt,
* McsEngl.ethtxTi@cptIt,
_DESCRIPTION:
Additionally, a contract creation transaction contains:
init: An unlimited size byte array specifying the EVM-code for the account initialisation procedure, formally Ti.
init is an EVM-code fragment; it returns the body, a second fragment of code that executes each time the account receives a message call (either through a transaction or due to the internal execution of code). init is executed only once at account creation and gets discarded immediately thereafter.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethtx.GENESIS@cptIt,
* McsEngl.ethtx.genesis@cptIt,
_DESCRIPTION:
GENESIS_2b241f037337eb4acc61849bd272ac133f7cdf4b block:0 age:580 days 32 mins ago (2015-07-30-03.26.13pm) from:GENESIS IN to:0x2b241f037337eb4acc61849bd272ac133f7cdf4b 378,000 Ether 0 Ether
[https://etherscan.io/address/0x2b241f037337eb4acc61849bd272ac133f7cdf4b]
name::
* McsEngl.ethbcn.specific@cptIt,
* McsEngl.ethbcn.specific@cptIt,
* McsEngl.ethnet'blockchain.specific@cptIt,
_SPECIFIC:
Public blockchains: a public blockchain is a blockchain that anyone in the world can read, anyone in the world can send transactions to and expect to see them included if they are valid, and anyone in the world can participate in the consensus process – the process for determining what blocks get added to the chain and what the current state is. As a substitute for centralized or quasi-centralized trust, public blockchains are secured by cryptoeconomics – the combination of economic incentives and cryptographic verification using mechanisms such as proof of work or proof of stake, following a general principle that the degree to which someone can have an influence in the consensus process is proportional to the quantity of economic resources that they can bring to bear. These blockchains are generally considered to be “fully decentralized”.
Consortium blockchains: a consortium blockchain is a blockchain where the consensus process is controlled by a pre-selected set of nodes; for example, one might imagine a consortium of 15 financial institutions, each of which operates a node and of which 10 must sign every block in order for the block to be valid. The right to read the blockchain may be public, or restricted to the participants, and there are also hybrid routes such as the root hashes of the blocks being public together with an API that allows members of the public to make a limited number of queries and get back cryptographic proofs of some parts of the blockchain state. These blockchains may be considered “partially decentralized”.
Private blockchains: a fully private blockchain is a blockchain where write permissions are kept centralized to one organization. Read permissions may be public or restricted to an arbitrary extent. Likely applications include database management, auditing, etc internal to a single company, and so public readability may not be necessary in many cases at all, though in other cases public auditability is desired.
[https://ethereum-homestead.readthedocs.org/en/latest/network/connecting-to-the-network.html#public-private-and-consortium-blockchains]
name::
* McsEngl.ethnet'Account (ethact)@cptIt,
* McsEngl.ethact@cptIt,
* McsEngl.ethaccount@cptIt,
* McsEngl.ethnet'account@cptIt,
_DESCRIPTION:
Whereas the Bitcoin blockchain was purely a list of transactions, Ethereum’s basic unit is the account. The Ethereum blockchain tracks the state of every account, and all state transitions on the Ethereum blockchain are transfers of value and information between accounts.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]
===
There are two types of accounts on the Ethereum blockchain.
- Accounts that have a private key.
- Contracts (which do not have a private key)
Private key accounts are the accounts that humans operate, where as contract accounts are deployed pieces of code capable of executing some computer program.
[http://docs.ethereum-alarm-clock.com/en/latest/introduction.html]
===
There are two kinds of accounts in Ethereum which share the same address space: External accounts that are controlled by public-private key pairs (i.e. humans) and contract accounts which are controlled by the code stored together with the account.
The address of an external account is determined from the public key while the address of a contract is determined at the time the contract is created (it is derived from the creator address and the number of transactions sent from that address, the so-called “nonce”).
Apart from the fact whether an account stores code or not, the EVM treats the two types equally, though.
Every account has a persistent key-value store mapping 256 bit words to 256 bit words called storage.
Furthermore, every account has a balance in Ether (in “Wei” to be exact) which can be modified by sending transactions that include Ether.
[https://solidity.readthedocs.org/en/latest/introduction-to-smart-contracts.html#accounts]
===
Accounts are a central part of the Ethereum network and are an essential part of any transaction or contract. In Ethereum, there are two types of accounts: Externally Owned accounts (EOA) and Contract accounts.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/glossary.html]
name::
* McsEngl.ethact'Keypair@cptIt,
* McsEngl.ethact'key@cptIt,
* McsEngl.ethact'keypair@cptIt,
* McsEngl.ethkeypair@cptIt,
_DESCRIPTION:
Every account is defined by a pair of keys, a private key and public key.
[https://ethereum-homestead.readthedocs.io/en/latest/account-management.html]
name::
* McsEngl.ethact'Keyfile@cptIt,
_DESCRIPTION:
Every account is defined by a pair of keys, a private key and public key.
Accounts are indexed by their address which is derived from the public key by taking the last 20 bytes.
Every private key/address pair is encoded in a keyfile.
Keyfiles are JSON text files which you can open and view in any text editor.
The critical component of the keyfile, your account’s private key, is always encrypted, and it is encrypted with the password you enter when you create the account.
Keyfiles are found in the keystore subdirectory of your Ethereum node’s data directory.
Make sure you backup your keyfiles regularly!
[https://ethereum-homestead.readthedocs.io/en/latest/account-management.html]
name::
* McsEngl.ethact'keystore@cptIt,
The default data directory locations are platform specific:
Windows: \Users\username\%appdata%\Roaming\Ethereum\keystore
Linux: ~/.ethereum/keystore
Mac: ~/Library/Ethereum/keystore
[https://ethereum-homestead.readthedocs.io/en/latest/account-management.html]
name::
* McsEngl.ethact'Address (ethads 20-byte|40-hex|160-bit)@cptIt,
* McsEngl.ethact'address@cptIt,
* McsEngl.ethaddress@cptIt,
* McsEngl.ethads@cptIt,
* McsEngl.ethereum-address@cptIt,
* McsEngl.ethnet'address@cptIt,
_DESCRIPTION:
0x0998c9a0c7224Ec4ED782A4Ecfef53A0e25fA9FC
0x573383aFc6cd5eEc4114C8edA98D1915FE15425C
===
Every account is defined by a pair of keys, a private key and public key.
Accounts are indexed by their address which is derived from the public key by taking the last 20 bytes.
[https://ethereum-homestead.readthedocs.io/en/latest/account-management.html]
===
There are two kinds of accounts in Ethereum which share the same address space: External accounts that are controlled by public-private key pairs (i.e. humans) and contract accounts which are controlled by the code stored together with the account.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#accounts]
===
address
An Ethereum address represents an account. For EOA, the address is derived as the last 20 bytes of the public key controlling the account, e.g., cd2a3d9f938e13cd947ec05abc7fe734df8dd826.
This is a hexadecimal format (base 16 notation), which is often indicated explicitly by appending 0x to the address.
Web3.js and console functions accept addresses with or without this prefix but for transparency we encourage their use.
Since each byte of the address is represented by 2 hex characters, a prefixed address is 42 characters long.
Several apps and APIs are also meant to implement the new checksum-enabled address scheme introduced in the Mist Ethereum wallet as of version 0.5.0.
hexadecimal
Common representation format for byte sequencing. Its advantage is that values are represented in a compact format using two characters per byte (the characters [0-9][a-f]).
[https://ethereum-homestead.readthedocs.io/en/latest/glossary.html]
name::
* McsEngl.ethads'Builtin-check@cptIt,
_DESCRIPTION:
ATTENTION: Ethereum addresses don't have built-in checks on them yet. That means that if you mistype an address, your ether will be lost forever, without a secondary confirmation window. If you are moving a significant amount, start with smaller quantities that you can afford to lose, until you feel comfortable enough.
[https://www.ethereum.org/ether]
name::
* McsEngl.ethads'Resource@cptIt,
_ADDRESS.WPG:
* https://etherscan.io/address/0x53d284357ec70ce289d6d64134dfac8e511c8a3d,
* https://etherchain.org/account/0x007abbe8057433641acb791d966d33a12cf82d01,
* https://github.com/EverexIO/Ethplorer/wiki/ethplorer-api#get-address-info,
name::
* McsEngl.ethads.zero@cptIt,
_DESCRIPTION:
If the target account is the zero-account (the account with the address 0), the transaction creates a new contract.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-8]
name::
* McsEngl.ethact'Balance@cptIt,
* McsEngl.ethact'balance@cptIt,
* McsEngl.ethact'ether@cptIt,
_DESCRIPTION:
Furthermore, every account has a balance in Ether (in “Wei” to be exact) which can be modified by sending transactions that include Ether.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#accounts]
name::
* McsEngl.ethact'Balance.Subtoken@cptIt,
* McsEngl.ethact'token@cptIt,
name::
* McsEngl.ethact'Nonce@cptIt,
* McsEngl.ethact'nonce@cptIt,
_DESCRIPTION:
Account nonce: a transaction counter in each account.
This prevents replay attacks where a transaction sending eg. 20 coins from A to B can be replayed by B over and over to continually drain A's balance.
[https://github.com/ethereum/wiki/wiki/Glossary]
name::
* McsEngl.ethact'Code (linkL#ql:ethctp.binary#)@cptIt,
name::
* McsEngl.ethact'Location@cptIt,
* McsEngl.ethact'location@cptIt,
_DESCRIPTION:
All accounts in ethereum are stored in a merkle radix tree.
[https://github.com/ebuchman/evm-tools/blob/master/analysis/guide.md#contracts]
name::
* McsEngl.ethact'Store-of-data@cptIt,
* McsEngl.ethact'store-of-data@cptIt,
name::
* McsEngl.ethact'Structure@cptIt,
_STRUCTURE:
Ethereum accounts contain the following four fields:
- nonce: A counter which ensures a transaction may only be processed exactly once.
- balance: The current ETH balance of the account.
- code: The account’s contract code (if there is any).
- storage: The account’s storage (if there is any).
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
name::
* McsEngl.ethact'Transaction@cptIt,
name::
* McsEngl.ethact'transaction.IN@cptIt,
Transaction Information
TxHash: 0x01406301bd25b21c16d6a2a47dbbc64f1cb9231f5b26c3a084ad2161c34a2a69
Block Height: 2757949 (526943 block confirmations)
TimeStamp : 87 days 2 hrs ago (Dec-06-2016 11:52:02 AM +UTC)
From: 0x53b148c3650d248ea740439e268d07dcd27ddac4
To: 0xfbddda2a82ccab13b60b4488e87362959578ca15
Value: 4 Ether ($77.80)
Gas: 300000
Gas Price: 0.00000004 Ether
Gas Used By Transaction: 21000
Actual Tx Cost/Fee: 0.00084 Ether ($0.02)
Cumulative Gas Used: 21000
Nonce: 1
Input Data:
name::
* McsEngl.ethact'transaction.OUT@cptIt,
Transaction Information
TxHash: 0x7fdc591cd1a4e97e0623cded49cda5222714b7e321ecdae137a79fd38f618a28
Block Height: 2813266 (471621 block confirmations)
TimeStamp : 78 days 7 mins ago (Dec-15-2016 02:28:28 PM +UTC)
From: 0xfbddda2a82ccab13b60b4488e87362959578ca15
To: 0xb60508e4617c98131a36bbd46fb189e0efc8932c
Value: 3.5 Ether ($68.08)
Gas: 21000
Gas Price: 0.00000002 Ether
Gas Used By Transaction: 21000
Actual Tx Cost/Fee: 0.00042 Ether ($0.0082)
Cumulative Gas Used: 42000
Nonce: 0
Input Data:
name::
* McsEngl.ethact'Resource@cptIt,
_ADDRESS.WPG:
* https://etherscan.io/accounts, A total of 1095602 accounts found (89,342,484.874 Ether) {2017-03-01}
name::
* McsEngl.ethact'State@cptIt,
* McsEngl.ethact'state@cptIt,
_DESCRIPTION:
Whereas the Bitcoin blockchain was purely a list of transactions, Ethereum’s basic unit is the account.
The Ethereum blockchain tracks the state of every account, and all state transitions on the Ethereum blockchain are transfers of value and information between accounts.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]
name::
* McsEngl.ethact'DOING@cptIt,
name::
* McsEngl.ethact'Controling@cptIt,
_DESCRIPTION:
In general, there are two types of accounts:
- externally owned accounts, controlled by private keys, and
- contract accounts, controlled by their contract code.
[https://github.com/ethereum/wiki/wiki/White-Paper#ethereum-accounts]
name::
* McsEngl.ethact.specific@cptIt,
_SPECIFIC:
This distinction might be eliminated in Serenity.
[https://ethereum-homestead.readthedocs.org/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#eoa-vs-contract-accounts]
name::
* McsEngl.ethact.CONTRACT-ACCOUNT (ethcta)@cptIt,
* McsEngl.ethactc@cptIt,
* McsEngl.ethcta@cptIt,
* McsEngl.ethereum-contract-account@cptIt,
* McsEngl.ethactc@cptIt,
* McsEngl.ethcrt'account@cptIt,
_DESCRIPTION:
We need to use permissions like this because each contract is a separate account that can be called by any account in the system.
Even when we include a contract in the source file of another contract as with HelloFactory, each new contract will still be created as a separate, new contract account that is unrelated to its factory except for any references we might add ourselves.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features//]
===
Common info
Contract name ProofOfIdleness
Address 019d7e5ae8d2ba9a292244311dc7355058ab1b08
Involved in 76 Transactions
Balance ETHER 15.84
Nonce 1
[https://live.ether.camp/account/019d7e5ae8d2ba9a292244311dc7355058ab1b08]
name::
* McsEngl.ethcta'Address@cptIt,
* McsEngl.ethcta'address@cptIt,
_DESCRIPTION:
40 hexsymbols,
0xbf35faa9c265baf50c9cff8c389c363b05753275
===
The address of an external account is determined from the public key
while the address of a contract is determined at the time the contract is created (it is derived from the creator address and the number of transactions sent from that address, the so-called “nonce”).
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#accounts]
name::
* McsEngl.ethcta'Transaction-sent@cptIt,
Tx: 0x581f761cb4c70cb329475f0a770df3fbe9a9d7fa760a5875d2b4d0c92b058aec
Block: 3175356
Time: 2017-02-13 11:47:42 (16 days ago)
From: 0xbF35fAA9C265bAf50C9CFF8c389C363B05753275
To: 0x7bE7Fad439128cca6738F8A6813519aF4248365C
Amount: 90 Ether
Account Nonce: 16
Gas Price: 2e-8 Ether
Gas Limit: 77,953
Total Gas Used: 0
Tx Price: 0 Ether
Invoked by: 0xdc81eff532b6423928f598f650658ce284443b72436dbe3870a239b89c1ce4af
Payload:
0x (ASCII: )
name::
* McsEngl.ethcta'Relation-to-EOA@cptIt,
* McsEngl.ethcta'relation-to-eoa@cptIt,
* McsEngl.etheoa'relation-to-cta@cptIt,
_DESCRIPTION:
For most users, the basic difference between these is that human users control EOAs - because they can control the private keys which give control over an EOA.
Contract accounts, on the other hand, are governed by their internal code.
If they are “controlled” by a human user, it is because they are programmed to be controlled by an EOA with a certain address, which is in turn controlled by whoever holds the private keys that control that EOA.
[https://ethereum-homestead.readthedocs.io/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]
===
Regardless of whether or not the account stores code, the two types are treated equally by the EVM.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#accounts]
name::
* McsEngl.ethcta'Resource@cptIt,
_ADDRESS.WPG:
* https://etherscan.io/accounts/c, A total of 251,357 contracts found (10,742,904.733 Ether) {2017-03-01}
* https://etherchain.org/contracts,
* https://etherchain.org/account/0xbf35faa9c265baf50c9cff8c389c363b05753275,
name::
* McsEngl.ethcta'Creating@cptIt,
name::
* McsEngl.ethact.NORMAL (ethnla Externally-Owned-Account)@cptIt,
* McsEngl.ethactn@cptIt,
* McsEngl.etheoa@cptIt,
* McsEngl.ethereum-EOA@cptIt,
* McsEngl.ethereum-exteranlly-owned-account@cptIt,
* McsEngl.ethereum-normal-account@cptIt,
* McsEngl.ethnla@cptIt,
* McsEngl.etheoa@cptIt,
* McsEngl.ethereum-non-contract-account@cptIt,
* McsEngl.ethereum-normal-account@cptIt,
* McsEngl.ethereum-private-key-account@cptIt,
_DESCRIPTION:
An externally controlled account
- has an ether balance,
- can send transactions (ether transfer or trigger contract code),
- is controlled by private keys,
- has no associated code.
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#externally-owned-accounts-eoas]
===
Private key accounts are the accounts that humans operate, where as contract accounts are deployed pieces of code capable of executing some computer program.
[http://docs.ethereum-alarm-clock.com/en/latest/introduction.html]
===
Address 532219eff8c413621a7c68974dfec33d86350631
Involved in 38 Transactions
Balance ETHER 14,856.80 ...
Nonce 17
[https://live.ether.camp/account/532219eff8c413621a7c68974dfec33d86350631]
name::
* McsEngl.ethnla'Address@cptIt,
_DESCRIPTION:
40 hexsymbos
0xb794F5eA0ba39494cE839613fffBA74279579268
===
The address of an external account is determined from the public key
while the address of a contract is determined at the time the contract is created (it is derived from the creator address and the number of transactions sent from that address, the so-called “nonce”).
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#accounts]
name::
* McsEngl.ethnla'Relation-to-wallet@cptIt,
_DESCRIPTION:
Accounts are the most basic way to store Ether. They are simple public/private keypairs, which you use to sign transactions. You don't need to do anything to "register" an account with the network, just generate one and send some ether to it.
Wallets are smart-contracts that allow for advanced features such as transaction logging, multisig, withdrawal limits, and more. In order to create a wallet, you need to deploy the contract to the blockchain, which requires ether. You need to make sure you keep track not only of the keys required to access the wallet, but also the wallet address. Unlike with accounts, wallet addresses are not very easily derivable from the private key (although it's not the end of the world if you lose the wallet address, you can use a block explorer to find what contracts you've created recently). Technically you can recover the address from just the account that created it and the nonce of the transaction, but that's a hassle.
tl;dr: Start with an account, get some Ether, then create a wallet and store your ETH there
[http://ethereum.stackexchange.com/a/213]
name::
* McsEngl.ethnla'Resource@cptIt,
_ADDRESS.WPG:
* https://etherscan.io/accounts/a, A total of 844266 addresses found (77,579,354.315 Ether) {2017-03-01}
* https://etherchain.org/accounts,
* https://etherchain.org/account/0xb794f5ea0ba39494ce839613fffba74279579268,
name::
* McsEngl.ethnla'Creating@cptIt,
creating an account
$ geth account new
Your new account is locked with a password. Please give a password. Do not forget this password.
Passphrase:
Repeat Passphrase:
Address: {168bc315a2ee09042d83d7c5811b533620531f67}
[https://github.com/ethereum/go-ethereum/wiki/Managing-Your-Accounts#creating-an-account]
name::
* McsEngl.ethnla.COINBASE@cptIt,
* McsEngl.ethnet'coinbase@cptIt,
* McsEngl.ethnet'etherbase@cptIt,
_DESCRIPTION:
In order to mine you need a fully synced Ethereum client that is enabled for mining and at least one ethereum account.
This account is used to send the mining rewards to and is often referred to as coinbase or etherbase.
[https://ethereum-homestead.readthedocs.io/en/latest/mining.html#the-algorithm]
name::
* McsEngl.ethact.ZERO@cptIt,
* McsEngl.ethact.zero@cptIt,
_DESCRIPTION:
If the target account is the zero-account (the account with the address 0), the transaction creates a new contract.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-8]
name::
* McsEngl.ethact.EMPTY@cptIt,
* McsEngl.ethact.empty@cptIt,
_DESCRIPTION:
An empty account is an account that has zero balance, nonce and code.
Empty accounts are functionally equivalent to nonexistent accounts with the exception of a few gas calculations, and empty accounts can easily be turned into nonempty accounts by simply sending any amount of ether to them. Theoretically, if miners accept transactions with zero fees, even sending a transaction from an empty or nonexistent account is possible. The only practical difference is that empty accounts need to be stored in the Ethereum state tree, whereas nonexistent accounts do not.
[https://www.ethnews.com/vitalik-buterin-on-empty-accounts-and-the-ethereum-state]
name::
* McsEngl.ethnet'Exchange-value-token (ETHevt)@cptIt,
* McsEngl.ethereum-exchange-value-token@cptIt,
* McsEngl.ethevtkn@cptIt,
_SPECIFIC:
* ether#ql:idEthcevt#,
* consensousNo-evt#ql:idEthcevtN#
name::
* McsEngl.ethevt.ETHER (ETHcevt@cptIt, Ξ; {2015}),
* McsEngl.ETH@cptIt,
* McsEngl.ethcevt@cptIt, {2017-04-15}
* McsEngl.ether@cptIt,
* McsEngl.ethereum-consensus-token@cptIt,
* McsEngl.ethereum-ether-token@cptIt,
* McsEngl.mnyEth@cptIt,
* McsEngl.mnyEther@cptIt,
* McsEngl.mnyEthereum@cptIt,
* McsEngl.ethmny@cptIt,
_DESCRIPTION:
Ether is the name of the currency used within Ethereum.
It is used to pay for computation within the EVM.
This is done indirectly by purchasing gas for ether as explained in gas.
[http://ethdocs.org/en/latest/ether.html?highlight=wei#what-is-ether]
_GENERIC:
* consensous-exchange-value-token#ql:idBcncevt#
_DESCRIPTION:
THE CRYPTO-FUEL FOR THE ETHEREUM NETWORK
[https://www.ethereum.org/ether]
==
Ethereum ETH
Ethereum or Ether is a cryptocurrency designed to pay for the computational purposes of the Ethereum network. The name of the coin comes from the name of the platform intended to allow a network of peers to administer their own stateful user-created smart contracts in the absence of central authority.
[https://changelly.com/supported-currencies]
===
Ether is a necessary element -- a fuel -- for operating the distributed application platform Ethereum. It is a form of payment made by the clients of the platform to the machines executing the requested operations. To put it another way, ether is the incentive ensuring that developers write quality applications (wasteful code costs more), and that the network remains healthy (people are compensated for their contributed resources).
[https://ethereum.org/ether]
===
The currency unit of Ethereum is the Ether, used to pay for computational services on the network.
In order to finance development, Ethereum distributed the initial allocation of Ethers via a 42-day public sale, netting 31,591 bitcoins,[12] worth $18,439,086 at that time, in exchange for about 60,102,216 Ethers.
Ether is divided into smaller units of currency called finney, szabo, shannon, babbage, lovelace, and wei. Each larger unit is equal to 1000 of the next lower unit.[13] In practice, however, the developers encourage the use of ether and wei. Wei is the base unit of implementation and can not be further divided.
[https://en.wikipedia.org/wiki/Ethereum#Ether]
name::
* McsEngl.ethcevt'Decimal@cptIt,
* McsEngl.ether-decimal@cptIt,
_DESCRIPTION:
Ethers have a natural unit with 18 decimal places.
1.23 ether is represented as 1,230,000,000,000,000,000 or 1.23e18 or 123e16 natural units.
[https://github.com/bokkypoobah/TokenTrader/wiki/Frequently-Asked-Questions#what-are-natural-units]
name::
* McsEngl.ethcevt'Exchange-rate@cptIt,
* McsEngl.ether-exchange-rate@cptIt,
* McsEngl.ethexchange-rate@cptIt,
* McsEngl.ethcevt'exchange-rate@cptIt,
* McsEngl.ethcevt'forex-rate@cptIt,
* McsEngl.ethmny'exchange-rate@cptIt,
_ADDRESS.WPG:
* https://www.cryptonator.com/rates,
* http://ethereumprice.org//
* https://coinmarketcap.com/currencies/ethereum//
{time.2017-01-28}:
Ethereum (ETH)
From To Exchange Rate 24h Volume Change
ETH BTC 0.01146077 437895
ETH LTC 2.74647 139
ETH GBP 8.30021 57
ETH EUR 9.87598722 21747
ETH USD 10.502807 38919
ETH CAD 14.01432 41
ETH CNY 72.8 85
ETH RUR 613.11349041 586
ETH JPY 1267.761 37
ETH DOGE 50000.00000001 2
[https://www.cryptonator.com/rates#ETH]
{time.2016-03-28}:
Thus, the key resistance lines, which right now determine further development, are $10.9 and $11.4.
[http://cointelegraph.com/news/ethereum-eth-price-trends-3282016]
{time.2016-02-12}:
Launched in July 2015, the Ethereum coin includes a programmable smart contract platform and now ranks the second most expensive cryptocurrency after Bitcoin.
[http://cointelegraph.com/news/eight-months-since-release-ethereum-is-second-only-to-bitcoin]
name::
* McsEngl.ethcevt'Issuing@cptIt,
_DESCRIPTION:
Ether (ETH), the cryptofuel that powers distributed applications on the Ethereum platform, will be issued at a constant annual linear rate via the block mining process. This rate is 0.3 times the total amount of ETH that will be purchased in the pre-sale.
[https://blog.ethereum.org/2014/04/10/the-issuance-model-in-ethereum/]
Denominations
Ethereum has a metric system of denominations used as units of ether. Each denomination has its own unique name (some bear the family name of seminal figures playing a role in evolution of computer science and cryptoeconomics). The smallest denomination aka base unit of ether is called Wei. Below is a list of the named denominations and their value in Wei. Following a common (although somewhat ambiguous) pattern, ether also designates a unit (of 1e18 or one quintillion Wei) of the currency. Note that the currency is not called Ethereum as many mistakenly think, nor is Ethereum a unit.
Unit Wei Value Wei
wei 1 wei 1 mnyWei
Kwei (babbage) 1e3 wei 1,000 mnyBabbage
Mwei (lovelace) 1e6 wei 1,000,000 mnyLovelace
Gwei (shannon) 1e9 wei 1,000,000,000 mnyShannon
microether (szabo) 1e12 wei 1,000,000,000,000 mnySzabo, mnyMicroether
milliether (finney) 1e15 wei 1,000,000,000,000,000 mnyFinney, mnyMilliether
ether 1e18 wei 1,000,000,000,000,000,000
[http://ethdocs.org/en/latest/ether.html?highlight=wei#denominations]
name::
* McsEngl.ethcevt.AGGREGATE@cptIt,
_ADDRESS.WPG:
* https://etherscan.io/stat/supply,
* https://coinmarketcap.com/currencies/ethereum//
_DESCRIPTION:
How are ethers created?
The total supply of ether and its rate of issuance was decided by the donations gathered on the 2014 presale. The results were roughly:
60 million ether created to contributors of the presale
12 Million (20% of the above) were created to the development fund, most of it going to early contributors and developers and the remaining to the Ethereum Foundation
5 ethers are created every block (roughly 15-17 seconds) to the miner of the block
2-3 ethers are sometimes sent to another miner if they were also able to find a solution but his block wasn't included (called uncle/aunt reward)
Is the ether supply infinite?
No. According to the terms agreed by all parties on the 2014 presale, issuance of ether is capped at 18 million ether per year (this number equals 25% of the initial supply). This means that while the absolute issuance is fixed, the relative inflation is decreased every year. In theory if this issuance was kept indefinitely then at some point the rate of new tokens created every year would reach the average amount lost yearly (by misuse, accidental key lost, death of holders etc) and there would reach an equilibrium.
But the rate is not expected to be kept: sometime in 2017 Ethereum will be switched from Proof of Work to a new consensus algorithm under development, called Casper that is expected to be more efficient and require less mining subsidy. The exact method of issuance and which function it will serve is an area of active research, but what can be guaranteed now is that (1) the current maximum is considered a ceiling and the new issuance under casper will not exceed it (and is expected to be much less) and (2) whatever method is ultimately picked to issue, it will be a decentralized smart contract that will not give preferential treatment to any particular group of people and whose purpose is to benefit the overall health and security of the network.
[https://www.ethereum.org/ether]
_SPECIFIC:
* Circulating-supply,
* Total-supply,
{2017-02-23}
Genesis (60M Crowdsale+12M Other): 72,009,990.50 Ether
+ Mining Block Rewards: 16,223,980.63 Ether
+ Mining Uncle Rewards: 918,936.25 Ether
= Current Total Supply 89,152,907.37 Ether
{2017-02-12}
Genesis (60M Crowdsale+12M Other): 72,009,990.50 Ether
+ Mining Block Rewards: 15,892,811.25 Ether
+ Mining Uncle Rewards: 905,851.25 Ether
= Current Total Supply 88,808,653.00 Ether
[https://etherscan.io/stat/supply]
name::
* McsEngl.ethevt.CONSENSUS.NO (ethcevtN)@cptIt,
* McsEngl.ethcevtN@cptIt, {2017-04-15}
* McsEngl.ethcNet@cptIt, {2017-04-01}
* McsEngl.ethereum-consesusNo-exval-token@cptIt, {2017-04-01}
* McsEngl.ethereum-subcurrency@cptIt,
* McsEngl.ethereum-subtoken@cptIt,
* McsEngl.ethnet'subcurrency@cptIt,
* McsEngl.ethnet'token@cptIt,
* McsEngl.ethstn@cptIt, {2017-03-16}
* McsEngl.ethsubcurrency@cptIt,
* McsEngl.ethsubtoken@cptIt,
* McsEngl.ethtkn@cptIt,
* McsEngl.subcurrency.ethereum@cptIt,
* McsEngl.subtoken.ethereum@cptIt,
_DESCRIPTION:
On-blockchain token systems have many applications ranging from sub-currencies representing assets such as USD or gold to company stocks, individual tokens representing smart property, secure unforgeable coupons, and even token systems with no ties to conventional value at all, used as point systems for incentivization.
Token systems are surprisingly easy to implement in Ethereum.
The key point to understand is that all a currency, or token system, fundamentally is a database with one operation: subtract X units from A and give X units to B, with the proviso that (i) A had at least X units before the transaction and (2) the transaction is approved by A.
All that it takes to implement a token system is to implement this logic into a contract.
[https://github.com/ethereum/wiki/wiki/White-Paper#token-systems]
===
Plutons follows the ERC20 Token standard, which means Pluton can be used by any Ethereum software that supports this standard.
[https://plutusit.zendesk.com/hc/en-us]
name::
* McsEngl.ethcevtN'Address-of-contract-account@cptIt,
name::
* McsEngl.ethcevtN'Transaction@cptIt,
TxHash: 0xa26540fc32e3b136af585177618282dd4626986d90cfb75b433e6350925b7d6d
Block Height: 3273751 (67 block confirmations)
TimeStamp : 16 mins ago (Mar-01-2017 06:29:15 PM +UTC)
From: 0x354a7141ad6e6d3c6bd636635039eda3b86c39f9
To: Contract 0x48c80f1f4d53d5951e5d5438b54cba84f29f32a5 (REP-Augur)
330 REP TOKEN TRANSFER From 0x354a7141ad6e6d3c6bd636635039eda3b86c39f9 to 0x6830f081f460a59650deab16596f94eeca553c2c
Value: 0 Ether ($0.00)
Gas: 150000
Gas Price: 0.000000021 Ether
Gas Used By Transaction: 37210
Actual Tx Cost/Fee: 0.00078141 Ether ($0.01)
Cumulative Gas Used: 80466
Nonce: 2
Input Data:
[https://etherscan.io/tx/0xa26540fc32e3b136af585177618282dd4626986d90cfb75b433e6350925b7d6d]
name::
* McsEngl.ethcevtN'Resource@cptIt,
_ADDRESS.WPG:
* https://etherscan.io/token-search,
* https://github.com/EverexIO/Ethplorer/wiki/ethplorer-api#get-token-info,
* https://github.com/ethereum/EIPs/issues/20,
* https://ethereum.org/token,
_SPECIFIC:
* Arcade Token (0xAc709FcB44a43c35F0DA4e3163b117A17F3770f5)
* BCDN (0x1e797Ce986C3CFF4472F7D38d5C4aba55DfEFE40)
* Dentacoin (0x08d32b0da63e2C3bcF8019c9c5d849d7a9d791e6)
* Devcon2 (0xdd94De9cFE063577051A5eb7465D08317d8808B6)
* DVIP (0xadc46ff5434910bd17b24ffb429e585223287d7f)
* DXF - Decentralized Experience (0x72a68fb6d91ed8dc47b564e088e518c6d4a6ff44)
* EthereumMovieVenture (0xb802b24e0637c2b87d2e8b7784c055bbe921011a)
* HumaniQ - HMQ (https://etherscan.io/address/0x9734c136f5c63531b60d02548bca73a3d72e024d)
* ICONOMI (0x888666CA69E0f178DED6D75b5726Cee99A87D698)
* Mainstreet (0xe23cd160761f63fc3a1cf78aa034b6cdf97d3e0c)
* Melon (0xBEB9eF514a379B997e0798FDcC901Ee474B6D9A1)
* MetaGold (0x1dea4cA1Ca2A2c946B233a227883ef6846CF17d5)
* ROUND (0x4993CB95c7443bdC06155c5f5688Be9D8f6999a5)
* SIM (0x8FFf600F5c5F0Bb03F345fd60F09A3537845de0a)
* SwarmCity (0xb9e7f8568e08d5659f5d29c4997173d84cdf2607)
* TIME (https://etherscan.io/address/0x6531f133e6deebe7f2dce5a0441aa7ef330b4e53)
* VIP (0xb939ef33629bba211688724e401d4f6400c0ee6a)
* vSlice (0x5c543e7AE0A1104f78406C340E9C64FD9fCE5170)
* W-GNT (0x01afc37f4f85babc47c0e2d0eababc7fb49793c8)
* Willie Watts (0xd41f3b51e0c2d825a1178582d27c84dbfe48d1af)
name::
* McsEngl.ethcevtN.AGGREGATE@cptIt,
name::
* McsEngl.ethcevtN.TokenERC20@cptIt,
_DESCRIPTION:
ERC: 20
Title: Token standard
Status: Draft
Type: Informational
Created: 19-11.2015
Resolution: https://github.com/ethereum/wiki/wiki/Standardized_Contract_APIs
[https://github.com/ethereum/EIPs/issues/20]
name::
* McsEngl.ethcevtN.INTERESTING@cptIt,
_SPECIFIC:
INTERESTING TOKENS
0xe23cd160761f63fc3a1cf78aa034b6cdf97d3e0c (Mainstreet)
0x6531f133e6deebe7f2dce5a0441aa7ef330b4e53 (TIME)
0xb939ef33629bba211688724e401d4f6400c0ee6a (VIP)
0x08d32b0da63e2C3bcF8019c9c5d849d7a9d791e6 (Dentacoin)
0x1dea4cA1Ca2A2c946B233a227883ef6846CF17d5 (MetaGold)
0xBEB9eF514a379B997e0798FDcC901Ee474B6D9A1 (Melon)
0xb9e7f8568e08d5659f5d29c4997173d84cdf2607 (SwarmCity)
0xd41f3b51e0c2d825a1178582d27c84dbfe48d1af (Willie Watts)
0x9734c136F5c63531b60D02548Bca73a3d72E024D (HumaniQ)
0x8FFf600F5c5F0Bb03F345fd60F09A3537845de0a (SIM)
0x72a68fb6d91ed8dc47b564e088e518c6d4a6ff44 (DXF - Decentralized Experience)
0x01afc37f4f85babc47c0e2d0eababc7fb49793c8 (W-GNT)
0xb802b24e0637c2b87d2e8b7784c055bbe921011a (EthereumMovieVenture)
0x4993CB95c7443bdC06155c5f5688Be9D8f6999a5 (ROUND)
0xdd94De9cFE063577051A5eb7465D08317d8808B6 (Devcon2)
0x5c543e7AE0A1104f78406C340E9C64FD9fCE5170 (vSlice)
0x1e797Ce986C3CFF4472F7D38d5C4aba55DfEFE40 (BCDN)
0xAc709FcB44a43c35F0DA4e3163b117A17F3770f5 (Arcade Token)
0x888666CA69E0f178DED6D75b5726Cee99A87D698 (ICONOMI)
0xadc46ff5434910bd17b24ffb429e585223287d7f (DVIP)
[https://etherscan.io/token-search]
name::
* McsEngl.ethcevtN.DGX@cptIt,
* McsEngl.mnyDGX@cptIt,
* McsEngl.DGX-money@cptIt,
* McsEngl.Digix-Gold-token@cptIt,
* McsEngl.Digix-token@cptIt,
_DESCRIPTION:
Digix Tokens (DGX)
Dgx Tokens are minted via a Minter Smart Contract.
Each DGX token represents 1g of Gold and divisible to 0.001g.
For every PoA Card that is sent to the Minter Smart Contract, DGX tokens will be issued in return.
For instance, a 100g PoA Card sent to the Minter Smart Contract returns 100 DGX tokens to the user.
Digix Tokens are held in an Ethereum Wallet.
[https://dgx.io/whitepaper.pdf]
_ADDRESS.WPG:
* https://etherscan.io/address/0x55b9a11c2e8351b4ffc7b11561148bfac9977855,
name::
* McsEngl.ethcevtN.Pluton@cptIt,
_DESCRIPTION:
Plutons are digital tokens you earn as a reward for shopping with Plutus. Just like cash back or air miles on a credit card, the more you spend the more you earn. (We’re merchant agnostic, so every purchase counts).
Plutons you earn (or purchase early) will be available to convert on the Plutus exchange network, allowing you to make in-store purchases with zero fees on conversion.
[https://plutus.it/]
_ADDRESS.WPG:
* https://etherscan.io/token/Pluton,
* https://medium.com/@PlutusIT/how-to-get-your-pluton-balance-token-distribution-guide-4a671192a703#.rks7t98v7,
name::
* McsEngl.ethcevtN.Augur (REPevt)@cptIt,
* McsEngl.mnyAugur@cptIt,
* McsEngl.mnyREP@cptIt,
_DESCRIPTION:
Augur REP
Augur is a decentralized platform with rewards for accurate predictions of certain events. The predictions may concern almost any event with any possible outcomes and can be made by buying virtual shares. Augur provides creation of any prediction market and is fueled by its own cryptocurrency of the same name.
[https://changelly.com/supported-currencies]
name::
* McsEngl.ethcevtN.TIME-token (ethtmt)@cptIt,
* McsEngl.ethTIME-token@cptIt,
* McsEngl.ethtmt@cptIt,
* McsEngl.mnyTIME@cptIt,
* McsEngl.TIME-token@cptIt,
* McsEngl.chbTIME@cptIt,
* McsEngl.chbtmt@cptIt,
_DESCRIPTION:
TIME, the Ethereum token representing a stake in the ChronoBank initiative to disrupt the inefficient labour-hire market, has already been added to several exchanges — with more on the way.
[https://blog.chronobank.io/chronobanks-time-launches-on-four-exchanges-71c2bb5c989a#.wnktm5kng]
_GENERIC:
* ethereum-contract-account#ql:ethcta#
_DESCRIPTION:
TIME token is on the Ethereum blockchain. LH tokens will be initially created on the Ethereum blockchain, and then the software will be ported to other blockchains: WAVES, NEM, ETC.
Q: Will TIME tokens be tradeable on exchanges after the ICO?
A: Shortly after ICO. TIME is a standard ERC20 Ethereum token, it will be easy to connect it to Poloniex or other exchanges. No any additional integration will be needed, because they trade many ERC20 tokens already.
[https://blog.chronobank.io/chronobank-io-faq-4b920f003640#.sraeqe3iv]
{
"address":"0x6531f133e6deebe7f2dce5a0441aa7ef330b4e53",
"name":"Chronobank TIME",
"decimals":"8",
"symbol":"TIME",
"totalSupply":"71011281080000",
"owner":"0x",
"totalIn":70248058593454,
"totalOut":70757486151933,
"holdersCount":2307,
"issuancesCount":0,
"countOps":2714
}
[https://api.ethplorer.io/getTokenInfo/0x6531f133e6deebe7f2dce5a0441aa7ef330b4e53?apiKey=freekey]
name::
* McsEngl.ethtmt'Exchange-rate@cptIt,
{2017-04-22}
TIME/BTC
Bid:0.00770002
Ask:0.0078999
[https://www.livecoin.net/en/trade/orderbook]
{2017-03-08}
TIME/BTC 0.00561952 BTC 5.57% 12485.84 0.00639996 BTC 0.00451 BTC 0.00550049 BTC 0.00578 BTC
[https://www.livecoin.net/en/trade/orderbook]
===
TIME / BTC 0.006700004.1230.07
[https://mercatox.com/exchange]
name::
* McsEngl.ethtmt'Creator@cptIt,
Contract Creator:
address: https://etherscan.io/address/0x28a44f49b940b3875f882d08487d16295fb8bc09,
at txn: https://etherscan.io/tx/0x5dd58b1b6e4ce36604c65ad7bdd98c78a55e4af547ed2934042b7c2bf1dad3e4,
name::
* McsEngl.ethtmt'Address@cptIt,
_ADDRESS:
TIME contract address: 0x6531f133e6deebe7f2dce5a0441aa7ef330b4e53
name::
* McsEngl.ethtmt'CodeBinary@cptIt,
_CODE.BINARY:
0x6060604052361561014e5763ffffffff60e060020a60003504166306fdde0381146101ed578063095ea7b31461027a5780630ba12c83146102aa5780630e6d1de9146102cb57806318160ddd146102f4578063233850891461031357806323b872dd1461033757806323de66511461036d578063313ce5671461039157806349752baf146103b45780634bfaf2e8146103dd5780634dfe950d146103fc5780635b48684e1461041d5780636461fe391461043e5780636a630ee7146104ba57806370a08231146105395780637b7054c81461056457806395d89b411461059b578063a883fb9014610628578063a9059cbb14610651578063ac35caee14610681578063b2b45df5146106f5578063c915fc93146107a3578063cfb51928146107d0578063d4eec5a614610835578063dd62ed3e14610856578063ec698a2814610887578063fe8beb711461090e575b6101eb5b61015a610943565b604080517ff2d6e0ab00000000000000000000000000000000000000000000000000000000815233600160a060020a03818116602484015260048301938452366044840181905294169363f2d6e0ab9334936000939190819060640185858082843782019150509450505050506000604051808303818588803b156100005761235a5a03f11561000057505050505b565b005b34610000576101fa610954565b604080516020808252835181830152835191928392908301918501908083838215610240575b80518252602083111561024057601f199092019160209182019101610220565b505050905090810190601f16801561026c5780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b3461000057610296600160a060020a03600435166024356109df565b604080519115158252519081900360200190f35b34610000576102966109f4565b604080519115158252519081900360200190f35b34610000576102d8610a59565b60408051600160a060020a039092168252519081900360200190f35b3461000057610301610a69565b60408051918252519081900360200190f35b34610000576101eb600160a060020a0360043581169060243516604435610aea565b005b3461000057610296600160a060020a0360043581169060243516604435610b54565b604080519115158252519081900360200190f35b34610000576101eb600160a060020a0360043581169060243516604435610b7c565b005b346100005761039e610be6565b6040805160ff9092168252519081900360200190f35b34610000576102d8610c67565b60408051600160a060020a039092168252519081900360200190f35b3461000057610301610c76565b60408051918252519081900360200190f35b3461000057610296610c7d565b604080519115158252519081900360200190f35b3461000057610296610d27565b604080519115158252519081900360200190f35b3461000057604080516020600460643581810135601f8101849004840285018401909552848452610296948235600160a060020a03908116956024803590921695604435959460849492930191908190840183828082843750949650610d5395505050505050565b604080519115158252519081900360200190f35b3461000057604080516020600460443581810135601f8101849004840285018401909552848452610296948235600160a060020a031694602480359560649492939190920191819084018382808284375094965050509235600160a060020a03169250610d6c915050565b604080519115158252519081900360200190f35b3461000057610301600160a060020a0360043516610eb4565b60408051918252519081900360200190f35b3461000057610296600160a060020a036004358116906024359060443516610f3e565b604080519115158252519081900360200190f35b34610000576101fa611007565b604080516020808252835181830152835191928392908301918501908083838215610240575b80518252602083111561024057601f199092019160209182019101610220565b505050905090810190601f16801561026c5780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b34610000576102d8611095565b60408051600160a060020a039092168252519081900360200190f35b3461000057610296600160a060020a03600435166024356110a5565b604080519115158252519081900360200190f35b3461000057604080516020600460443581810135601f8101849004840285018401909552848452610296948235600160a060020a03169460248035956064949293919092019181908401838280828437509496506110cb95505050505050565b604080519115158252519081900360200190f35b346100005760408051602060046024803582810135601f8101859004850286018501909652858552610296958335600160a060020a0316959394604494939290920191819084018382808284375050604080516020601f89358b018035918201839004830284018301909452808352979998810197919650918201945092508291508401838280828437509496506110e295505050505050565b604080519115158252519081900360200190f35b3461000057610296600160a060020a036004351661128d565b604080519115158252519081900360200190f35b3461000057610301600480803590602001908201803590602001908080601f016020809104026020016040519081016040528093929190818152602001838380828437509496506113c595505050505050565b60408051918252519081900360200190f35b34610000576102966113d0565b604080519115158252519081900360200190f35b3461000057610301600160a060020a0360043581169060243516611431565b60408051918252519081900360200190f35b3461000057604080516020600460643581810135601f8101849004840285018401909552848452610296948235600160a060020a0390811695602480359092169560443595946084949293019190819084018382808284375094965050509235600160a060020a031692506114c4915050565b604080519115158252519081900360200190f35b34610000576102d8600160a060020a0360043516611619565b60408051600160a060020a039092168252519081900360200190f35b600061094e33611619565b90505b90565b6002805460408051602060018416156101000260001901909316849004601f810184900484028201840190925281815292918301828280156109d75780601f106109ac576101008083540402835291602001916109d7565b820191906000526020600020905b8154815290600101906020018083116109ba57829003601f168201915b505050505081565b60006109eb8383611670565b90505b92915050565b600554600090600160a060020a03161515610a1157506000610951565b426203f480600654011115610a2857506000610951565b506005805460048054600160a060020a0319908116600160a060020a03841617909155169055600060065560015b90565b600454600160a060020a03165b90565b6000805460015460408051602090810185905281517fb524abcf00000000000000000000000000000000000000000000000000000000815260048101939093529051600160a060020a039093169263b524abcf92602480820193929182900301818787803b156100005760325a03f115610000575050604051519150505b90565b60005433600160a060020a0390811691161415610b4d5781600160a060020a031683600160a060020a03167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925836040518082815260200191505060405180910390a35b5b5b505050565b6000610b728484846020604051908101604052806000815250611712565b90505b9392505050565b60005433600160a060020a0390811691161415610b4d5781600160a060020a031683600160a060020a03167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef836040518082815260200191505060405180910390a35b5b5b505050565b6000805460015460408051602090810185905281517fdc86e6f000000000000000000000000000000000000000000000000000000000815260048101939093529051600160a060020a039093169263dc86e6f092602480820193929182900301818787803b156100005760325a03f115610000575050604051519150505b90565b600054600160a060020a031681565b6006545b90565b60008054600154604080516020908101859052815160e160020a6374b5a315028152600160a060020a03338116600483015260248201949094529151929093169263e96b462a9260448084019382900301818787803b156100005760325a03f1156100005750506040515115905061095157600554600160a060020a03161515610d0957506000610951565b5060058054600160a060020a0319169055600060065560015b5b5b90565b600160a060020a03331660009081526007602052604090208054600160a060020a031916905560015b90565b6000610d6185858585611712565b90505b949350505050565b60008133600160a060020a0316610d8282611619565b600160a060020a03161415610ea9576000805460015460408051602090810194909452517f57a96dd0000000000000000000000000000000000000000000000000000000008152600160a060020a038a811660048301908152602483018b905260448301849052888216608484015260a0606484019081528a5160a48501528a5192909516956357a96dd0958d958d9590948d948d9490939260c40191908601908083838215610e4d575b805182526020831115610e4d57601f199092019160209182019101610e2d565b505050905090810190601f168015610e795780820380516001836020036101000a031916815260200191505b509650505050505050602060405180830381600087803b156100005760325a03f115610000575050604051519250505b5b5b50949350505050565b6000805460015460408051602090810185905281517f4d30b6be000000000000000000000000000000000000000000000000000000008152600160a060020a038781166004830152602482019490945291519290931692634d30b6be9260448084019382900301818787803b156100005760325a03f115610000575050604051519150505b919050565b60008133600160a060020a0316610f5482611619565b600160a060020a03161415610ffd576000805460015460408051602090810185905281517f14712e2f000000000000000000000000000000000000000000000000000000008152600160a060020a038b81166004830152602482018b905260448201949094528884166064820152915192909316936314712e2f9360848084019491939192918390030190829087803b156100005760325a03f115610000575050604051519250505b5b5b509392505050565b6003805460408051602060026001851615610100026000190190941693909304601f810184900484028201840190925281815292918301828280156109d75780601f106109ac576101008083540402835291602001916109d7565b820191906000526020600020905b8154815290600101906020018083116109ba57829003601f168201915b505050505081565b600554600160a060020a03165b90565b60006109eb83836020604051908101604052806000815250611847565b90505b92915050565b6000610b72848484611847565b90505b9392505050565b60008054600160a060020a0316156110fc57506000610b75565b60008054600160a060020a031916600160a060020a03861617815583516003805492819052917fc2575a0e9e593c00f959f8c92f12db2869c3395a3b0502d05e2516446f71f85b602060026101006001851615026000190190931692909204601f9081018390048201939288019083901061118257805160ff19168380011785556111af565b828001600101855582156111af579182015b828111156111af578251825591602001919060010190611194565b5b506111d09291505b808211156111cc57600081556001016111b8565b5090565b50506111db836113c5565b600181600019169055508160029080519060200190828054600181600116156101000203166002900490600052602060002090601f016020900481019282601f1061123157805160ff191683800117855561125e565b8280016001018555821561125e579182015b8281111561125e578251825591602001919060010190611243565b5b5061127f9291505b808211156111cc57600081556001016111b8565b5090565b5050600190505b9392505050565b60008054600154604080516020908101859052815160e160020a6374b5a315028152600160a060020a03338116600483015260248201949094529151929093169263e96b462a9260448084019382900301818787803b156100005760325a03f11561000057505060405151159050610f3957600554600160a060020a03161561131857506000610f39565b600160a060020a038216151561133057506000610f39565b600454600160a060020a03161515611365575060048054600160a060020a031916600160a060020a0383161790556001610f39565b60058054600160a060020a038416600160a060020a031990911681179091554260065560408051918252517faf574319215a31df9b528258f1bdeef2b12b169dc85ff443a49373248c77493a9181900360200190a15060015b5b5b919050565b60208101515b919050565b600160a060020a03338116600090815260076020526040812054909116156113fa57506000610951565b5060045433600160a060020a0390811660009081526007602052604090208054600160a060020a0319169190921617905560015b90565b6000805460015460408051602090810185905281517f1c8d5d38000000000000000000000000000000000000000000000000000000008152600160a060020a0388811660048301528781166024830152604482019490945291519290931692631c8d5d389260648084019382900301818787803b156100005760325a03f115610000575050604051519150505b92915050565b60008133600160a060020a03166114da82611619565b600160a060020a0316141561160d576000805460015460408051602090810194909452517f161ff662000000000000000000000000000000000000000000000000000000008152600160a060020a038b8116600483019081528b82166024840152604483018b90526064830184905288821660a484015260c0608484019081528a5160c48501528a51929095169563161ff662958e958e958e9591948e948e949193919260e401919086019080838382156115b0575b8051825260208311156115b057601f199092019160209182019101611590565b505050905090810190601f1680156115dc5780820380516001836020036101000a031916815260200191505b50975050505050505050602060405180830381600087803b156100005760325a03f115610000575050604051519250505b5b5b5095945050505050565b600160a060020a038082166000908152600760205260408120549091161561165b57600160a060020a0380831660009081526007602052604090205416611668565b600454600160a060020a03165b90505b919050565b600061167a610943565b600160a060020a0316637b7054c88484336000604051602001526040518463ffffffff1660e060020a0281526004018084600160a060020a0316600160a060020a0316815260200183815260200182600160a060020a0316600160a060020a031681526020019350505050602060405180830381600087803b156100005760325a03f115610000575050604051519150505b92915050565b600061171c610943565b600160a060020a031663ec698a2886868686336000604051602001526040518663ffffffff1660e060020a0281526004018086600160a060020a0316600160a060020a0316815260200185600160a060020a0316600160a060020a031681526020018481526020018060200183600160a060020a0316600160a060020a031681526020018281038252848181518152602001915080519060200190808383600083146117e3575b8051825260208311156117e357601f1990920191602091820191016117c3565b505050905090810190601f16801561180f5780820380516001836020036101000a031916815260200191505b509650505050505050602060405180830381600087803b156100005760325a03f115610000575050604051519150505b949350505050565b6000611851610943565b600160a060020a0316636a630ee7858585336000604051602001526040518563ffffffff1660e060020a0281526004018085600160a060020a0316600160a060020a031681526020018481526020018060200183600160a060020a0316600160a060020a031681526020018281038252848181518152602001915080519060200190808383600083146118ff575b8051825260208311156118ff57601f1990920191602091820191016118df565b505050905090810190601f16801561192b5780820380516001836020036101000a031916815260200191505b5095505050505050602060405180830381600087803b156100005760325a03f115610000575050604051519150505b93925050505600a165627a7a7230582014a2415442d222c840a9f97e881c3a1a8b3b9e45ca90ea33df3ca27a39dd6a500029
[https://etherscan.io/address/0x6531f133e6deebe7f2dce5a0441aa7ef330b4e53#code]
name::
* McsEngl.ethtmt'CodeAssembly@cptIt,
_CODE.ASSEMBLY:
PUSH1 0x60
PUSH1 0x40
MSTORE
CALLDATASIZE
ISZERO
PUSH2 0x014e
JUMPI
PUSH4 0xffffffff
PUSH1 0xe0
PUSH1 0x02
EXP
PUSH1 0x00
CALLDATALOAD
DIV
AND
PUSH4 0x06fdde03
DUP2
EQ
PUSH2 0x01ed
JUMPI
DUP1
PUSH4 0x095ea7b3
EQ
PUSH2 0x027a
JUMPI
DUP1
PUSH4 0x0ba12c83
EQ
PUSH2 0x02aa
JUMPI
DUP1
PUSH4 0x0e6d1de9
EQ
PUSH2 0x02cb
JUMPI
DUP1
PUSH4 0x18160ddd
EQ
PUSH2 0x02f4
JUMPI
DUP1
PUSH4 0x23385089
EQ
PUSH2 0x0313
JUMPI
DUP1
PUSH4 0x23b872dd
EQ
PUSH2 0x0337
JUMPI
DUP1
PUSH4 0x23de6651
EQ
PUSH2 0x036d
JUMPI
DUP1
PUSH4 0x313ce567
EQ
PUSH2 0x0391
JUMPI
DUP1
PUSH4 0x49752baf
EQ
PUSH2 0x03b4
JUMPI
DUP1
PUSH4 0x4bfaf2e8
EQ
PUSH2 0x03dd
JUMPI
DUP1
PUSH4 0x4dfe950d
EQ
PUSH2 0x03fc
JUMPI
DUP1
PUSH4 0x5b48684e
EQ
PUSH2 0x041d
JUMPI
DUP1
PUSH4 0x6461fe39
EQ
PUSH2 0x043e
JUMPI
DUP1
PUSH4 0x6a630ee7
EQ
PUSH2 0x04ba
JUMPI
DUP1
PUSH4 0x70a08231
EQ
PUSH2 0x0539
JUMPI
DUP1
PUSH4 0x7b7054c8
EQ
PUSH2 0x0564
JUMPI
DUP1
PUSH4 0x95d89b41
EQ
PUSH2 0x059b
JUMPI
DUP1
PUSH4 0xa883fb90
EQ
PUSH2 0x0628
JUMPI
DUP1
PUSH4 0xa9059cbb
EQ
PUSH2 0x0651
JUMPI
DUP1
PUSH4 0xac35caee
EQ
PUSH2 0x0681
JUMPI
DUP1
PUSH4 0xb2b45df5
EQ
PUSH2 0x06f5
JUMPI
DUP1
PUSH4 0xc915fc93
EQ
PUSH2 0x07a3
JUMPI
DUP1
PUSH4 0xcfb51928
EQ
PUSH2 0x07d0
JUMPI
DUP1
PUSH4 0xd4eec5a6
EQ
PUSH2 0x0835
JUMPI
DUP1
PUSH4 0xdd62ed3e
EQ
PUSH2 0x0856
JUMPI
DUP1
PUSH4 0xec698a28
EQ
PUSH2 0x0887
JUMPI
DUP1
PUSH4 0xfe8beb71
EQ
PUSH2 0x090e
JUMPI
JUMPDEST
PUSH2 0x01eb
JUMPDEST
PUSH2 0x015a
PUSH2 0x0943
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
PUSH32 0xf2d6e0ab00000000000000000000000000000000000000000000000000000000
DUP2
MSTORE
CALLER
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
DUP2
DUP2
AND
PUSH1 0x24
DUP5
ADD
MSTORE
PUSH1 0x04
DUP4
ADD
SWAP4
DUP5
MSTORE
CALLDATASIZE
PUSH1 0x44
DUP5
ADD
DUP2
SWAP1
MSTORE
SWAP5
AND
SWAP4
PUSH4 0xf2d6e0ab
SWAP4
CALLVALUE
SWAP4
PUSH1 0x00
SWAP4
SWAP2
SWAP1
DUP2
SWAP1
PUSH1 0x64
ADD
DUP6
DUP6
DUP1
DUP3
DUP5
CALLDATACOPY
DUP3
ADD
SWAP2
POP
POP
SWAP5
POP
POP
POP
POP
POP
PUSH1 0x00
PUSH1 0x40
MLOAD
DUP1
DUP4
SUB
DUP2
DUP6
DUP9
DUP1
EXTCODESIZE
ISZERO
PUSH2 0x0000
JUMPI
PUSH2 0x235a
GAS
SUB
CALL
ISZERO
PUSH2 0x0000
JUMPI
POP
POP
POP
POP
JUMPDEST
JUMP
JUMPDEST
STOP
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x01fa
PUSH2 0x0954
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x20
DUP1
DUP3
MSTORE
DUP4
MLOAD
DUP2
DUP4
ADD
MSTORE
DUP4
MLOAD
SWAP2
SWAP3
DUP4
SWAP3
SWAP1
DUP4
ADD
SWAP2
DUP6
ADD
SWAP1
DUP1
DUP4
DUP4
DUP3
ISZERO
PUSH2 0x0240
JUMPI
JUMPDEST
DUP1
MLOAD
DUP3
MSTORE
PUSH1 0x20
DUP4
GT
ISZERO
PUSH2 0x0240
JUMPI
PUSH1 0x1f
NOT
SWAP1
SWAP3
ADD
SWAP2
PUSH1 0x20
SWAP2
DUP3
ADD
SWAP2
ADD
PUSH2 0x0220
JUMP
JUMPDEST
POP
POP
POP
SWAP1
POP
SWAP1
DUP2
ADD
SWAP1
PUSH1 0x1f
AND
DUP1
ISZERO
PUSH2 0x026c
JUMPI
DUP1
DUP3
SUB
DUP1
MLOAD
PUSH1 0x01
DUP4
PUSH1 0x20
SUB
PUSH2 0x0100
EXP
SUB
NOT
AND
DUP2
MSTORE
PUSH1 0x20
ADD
SWAP2
POP
JUMPDEST
POP
SWAP3
POP
POP
POP
PUSH1 0x40
MLOAD
DUP1
SWAP2
SUB
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x0296
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
PUSH1 0x04
CALLDATALOAD
AND
PUSH1 0x24
CALLDATALOAD
PUSH2 0x09df
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
SWAP2
ISZERO
ISZERO
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x0296
PUSH2 0x09f4
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
SWAP2
ISZERO
ISZERO
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x02d8
PUSH2 0x0a59
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
SWAP1
SWAP3
AND
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x0301
PUSH2 0x0a69
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
SWAP2
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x01eb
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
PUSH1 0x04
CALLDATALOAD
DUP2
AND
SWAP1
PUSH1 0x24
CALLDATALOAD
AND
PUSH1 0x44
CALLDATALOAD
PUSH2 0x0aea
JUMP
JUMPDEST
STOP
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x0296
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
PUSH1 0x04
CALLDATALOAD
DUP2
AND
SWAP1
PUSH1 0x24
CALLDATALOAD
AND
PUSH1 0x44
CALLDATALOAD
PUSH2 0x0b54
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
SWAP2
ISZERO
ISZERO
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x01eb
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
PUSH1 0x04
CALLDATALOAD
DUP2
AND
SWAP1
PUSH1 0x24
CALLDATALOAD
AND
PUSH1 0x44
CALLDATALOAD
PUSH2 0x0b7c
JUMP
JUMPDEST
STOP
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x039e
PUSH2 0x0be6
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
PUSH1 0xff
SWAP1
SWAP3
AND
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x02d8
PUSH2 0x0c67
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
SWAP1
SWAP3
AND
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x0301
PUSH2 0x0c76
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
SWAP2
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x0296
PUSH2 0x0c7d
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
SWAP2
ISZERO
ISZERO
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x0296
PUSH2 0x0d27
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
SWAP2
ISZERO
ISZERO
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x20
PUSH1 0x04
PUSH1 0x64
CALLDATALOAD
DUP2
DUP2
ADD
CALLDATALOAD
PUSH1 0x1f
DUP2
ADD
DUP5
SWAP1
DIV
DUP5
MUL
DUP6
ADD
DUP5
ADD
SWAP1
SWAP6
MSTORE
DUP5
DUP5
MSTORE
PUSH2 0x0296
SWAP5
DUP3
CALLDATALOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
SWAP1
DUP2
AND
SWAP6
PUSH1 0x24
DUP1
CALLDATALOAD
SWAP1
SWAP3
AND
SWAP6
PUSH1 0x44
CALLDATALOAD
SWAP6
SWAP5
PUSH1 0x84
SWAP5
SWAP3
SWAP4
ADD
SWAP2
SWAP1
DUP2
SWAP1
DUP5
ADD
DUP4
DUP3
DUP1
DUP3
DUP5
CALLDATACOPY
POP
SWAP5
SWAP7
POP
PUSH2 0x0d53
SWAP6
POP
POP
POP
POP
POP
POP
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
SWAP2
ISZERO
ISZERO
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x20
PUSH1 0x04
PUSH1 0x44
CALLDATALOAD
DUP2
DUP2
ADD
CALLDATALOAD
PUSH1 0x1f
DUP2
ADD
DUP5
SWAP1
DIV
DUP5
MUL
DUP6
ADD
DUP5
ADD
SWAP1
SWAP6
MSTORE
DUP5
DUP5
MSTORE
PUSH2 0x0296
SWAP5
DUP3
CALLDATALOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
SWAP5
PUSH1 0x24
DUP1
CALLDATALOAD
SWAP6
PUSH1 0x64
SWAP5
SWAP3
SWAP4
SWAP2
SWAP1
SWAP3
ADD
SWAP2
DUP2
SWAP1
DUP5
ADD
DUP4
DUP3
DUP1
DUP3
DUP5
CALLDATACOPY
POP
SWAP5
SWAP7
POP
POP
POP
SWAP3
CALLDATALOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
SWAP3
POP
PUSH2 0x0d6c
SWAP2
POP
POP
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
SWAP2
ISZERO
ISZERO
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x0301
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
PUSH1 0x04
CALLDATALOAD
AND
PUSH2 0x0eb4
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
SWAP2
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x0296
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
PUSH1 0x04
CALLDATALOAD
DUP2
AND
SWAP1
PUSH1 0x24
CALLDATALOAD
SWAP1
PUSH1 0x44
CALLDATALOAD
AND
PUSH2 0x0f3e
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
SWAP2
ISZERO
ISZERO
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x01fa
PUSH2 0x1007
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x20
DUP1
DUP3
MSTORE
DUP4
MLOAD
DUP2
DUP4
ADD
MSTORE
DUP4
MLOAD
SWAP2
SWAP3
DUP4
SWAP3
SWAP1
DUP4
ADD
SWAP2
DUP6
ADD
SWAP1
DUP1
DUP4
DUP4
DUP3
ISZERO
PUSH2 0x0240
JUMPI
JUMPDEST
DUP1
MLOAD
DUP3
MSTORE
PUSH1 0x20
DUP4
GT
ISZERO
PUSH2 0x0240
JUMPI
PUSH1 0x1f
NOT
SWAP1
SWAP3
ADD
SWAP2
PUSH1 0x20
SWAP2
DUP3
ADD
SWAP2
ADD
PUSH2 0x0220
JUMP
JUMPDEST
POP
POP
POP
SWAP1
POP
SWAP1
DUP2
ADD
SWAP1
PUSH1 0x1f
AND
DUP1
ISZERO
PUSH2 0x026c
JUMPI
DUP1
DUP3
SUB
DUP1
MLOAD
PUSH1 0x01
DUP4
PUSH1 0x20
SUB
PUSH2 0x0100
EXP
SUB
NOT
AND
DUP2
MSTORE
PUSH1 0x20
ADD
SWAP2
POP
JUMPDEST
POP
SWAP3
POP
POP
POP
PUSH1 0x40
MLOAD
DUP1
SWAP2
SUB
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x02d8
PUSH2 0x1095
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
SWAP1
SWAP3
AND
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x0296
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
PUSH1 0x04
CALLDATALOAD
AND
PUSH1 0x24
CALLDATALOAD
PUSH2 0x10a5
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
SWAP2
ISZERO
ISZERO
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x20
PUSH1 0x04
PUSH1 0x44
CALLDATALOAD
DUP2
DUP2
ADD
CALLDATALOAD
PUSH1 0x1f
DUP2
ADD
DUP5
SWAP1
DIV
DUP5
MUL
DUP6
ADD
DUP5
ADD
SWAP1
SWAP6
MSTORE
DUP5
DUP5
MSTORE
PUSH2 0x0296
SWAP5
DUP3
CALLDATALOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
SWAP5
PUSH1 0x24
DUP1
CALLDATALOAD
SWAP6
PUSH1 0x64
SWAP5
SWAP3
SWAP4
SWAP2
SWAP1
SWAP3
ADD
SWAP2
DUP2
SWAP1
DUP5
ADD
DUP4
DUP3
DUP1
DUP3
DUP5
CALLDATACOPY
POP
SWAP5
SWAP7
POP
PUSH2 0x10cb
SWAP6
POP
POP
POP
POP
POP
POP
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
SWAP2
ISZERO
ISZERO
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x20
PUSH1 0x04
PUSH1 0x24
DUP1
CALLDATALOAD
DUP3
DUP2
ADD
CALLDATALOAD
PUSH1 0x1f
DUP2
ADD
DUP6
SWAP1
DIV
DUP6
MUL
DUP7
ADD
DUP6
ADD
SWAP1
SWAP7
MSTORE
DUP6
DUP6
MSTORE
PUSH2 0x0296
SWAP6
DUP4
CALLDATALOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
SWAP6
SWAP4
SWAP5
PUSH1 0x44
SWAP5
SWAP4
SWAP3
SWAP1
SWAP3
ADD
SWAP2
DUP2
SWAP1
DUP5
ADD
DUP4
DUP3
DUP1
DUP3
DUP5
CALLDATACOPY
POP
POP
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x20
PUSH1 0x1f
DUP10
CALLDATALOAD
DUP12
ADD
DUP1
CALLDATALOAD
SWAP2
DUP3
ADD
DUP4
SWAP1
DIV
DUP4
MUL
DUP5
ADD
DUP4
ADD
SWAP1
SWAP5
MSTORE
DUP1
DUP4
MSTORE
SWAP8
SWAP10
SWAP9
DUP2
ADD
SWAP8
SWAP2
SWAP7
POP
SWAP2
DUP3
ADD
SWAP5
POP
SWAP3
POP
DUP3
SWAP2
POP
DUP5
ADD
DUP4
DUP3
DUP1
DUP3
DUP5
CALLDATACOPY
POP
SWAP5
SWAP7
POP
PUSH2 0x10e2
SWAP6
POP
POP
POP
POP
POP
POP
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
SWAP2
ISZERO
ISZERO
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x0296
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
PUSH1 0x04
CALLDATALOAD
AND
PUSH2 0x128d
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
SWAP2
ISZERO
ISZERO
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x0301
PUSH1 0x04
DUP1
DUP1
CALLDATALOAD
SWAP1
PUSH1 0x20
ADD
SWAP1
DUP3
ADD
DUP1
CALLDATALOAD
SWAP1
PUSH1 0x20
ADD
SWAP1
DUP1
DUP1
PUSH1 0x1f
ADD
PUSH1 0x20
DUP1
SWAP2
DIV
MUL
PUSH1 0x20
ADD
PUSH1 0x40
MLOAD
SWAP1
DUP2
ADD
PUSH1 0x40
MSTORE
DUP1
SWAP4
SWAP3
SWAP2
SWAP1
DUP2
DUP2
MSTORE
PUSH1 0x20
ADD
DUP4
DUP4
DUP1
DUP3
DUP5
CALLDATACOPY
POP
SWAP5
SWAP7
POP
PUSH2 0x13c5
SWAP6
POP
POP
POP
POP
POP
POP
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
SWAP2
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x0296
PUSH2 0x13d0
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
SWAP2
ISZERO
ISZERO
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x0301
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
PUSH1 0x04
CALLDATALOAD
DUP2
AND
SWAP1
PUSH1 0x24
CALLDATALOAD
AND
PUSH2 0x1431
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
SWAP2
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x20
PUSH1 0x04
PUSH1 0x64
CALLDATALOAD
DUP2
DUP2
ADD
CALLDATALOAD
PUSH1 0x1f
DUP2
ADD
DUP5
SWAP1
DIV
DUP5
MUL
DUP6
ADD
DUP5
ADD
SWAP1
SWAP6
MSTORE
DUP5
DUP5
MSTORE
PUSH2 0x0296
SWAP5
DUP3
CALLDATALOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
SWAP1
DUP2
AND
SWAP6
PUSH1 0x24
DUP1
CALLDATALOAD
SWAP1
SWAP3
AND
SWAP6
PUSH1 0x44
CALLDATALOAD
SWAP6
SWAP5
PUSH1 0x84
SWAP5
SWAP3
SWAP4
ADD
SWAP2
SWAP1
DUP2
SWAP1
DUP5
ADD
DUP4
DUP3
DUP1
DUP3
DUP5
CALLDATACOPY
POP
SWAP5
SWAP7
POP
POP
POP
SWAP3
CALLDATALOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
SWAP3
POP
PUSH2 0x14c4
SWAP2
POP
POP
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
SWAP2
ISZERO
ISZERO
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
CALLVALUE
PUSH2 0x0000
JUMPI
PUSH2 0x02d8
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
PUSH1 0x04
CALLDATALOAD
AND
PUSH2 0x1619
JUMP
JUMPDEST
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
SWAP1
SWAP3
AND
DUP3
MSTORE
MLOAD
SWAP1
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
RETURN
JUMPDEST
PUSH1 0x00
PUSH2 0x094e
CALLER
PUSH2 0x1619
JUMP
JUMPDEST
SWAP1
POP
JUMPDEST
SWAP1
JUMP
JUMPDEST
PUSH1 0x02
DUP1
SLOAD
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x20
PUSH1 0x01
DUP5
AND
ISZERO
PUSH2 0x0100
MUL
PUSH1 0x00
NOT
ADD
SWAP1
SWAP4
AND
DUP5
SWAP1
DIV
PUSH1 0x1f
DUP2
ADD
DUP5
SWAP1
DIV
DUP5
MUL
DUP3
ADD
DUP5
ADD
SWAP1
SWAP3
MSTORE
DUP2
DUP2
MSTORE
SWAP3
SWAP2
DUP4
ADD
DUP3
DUP3
DUP1
ISZERO
PUSH2 0x09d7
JUMPI
DUP1
PUSH1 0x1f
LT
PUSH2 0x09ac
JUMPI
PUSH2 0x0100
DUP1
DUP4
SLOAD
DIV
MUL
DUP4
MSTORE
SWAP2
PUSH1 0x20
ADD
SWAP2
PUSH2 0x09d7
JUMP
JUMPDEST
DUP3
ADD
SWAP2
SWAP1
PUSH1 0x00
MSTORE
PUSH1 0x20
PUSH1 0x00
SHA3
SWAP1
JUMPDEST
DUP2
SLOAD
DUP2
MSTORE
SWAP1
PUSH1 0x01
ADD
SWAP1
PUSH1 0x20
ADD
DUP1
DUP4
GT
PUSH2 0x09ba
JUMPI
DUP3
SWAP1
SUB
PUSH1 0x1f
AND
DUP3
ADD
SWAP2
JUMPDEST
POP
POP
POP
POP
POP
DUP2
JUMP
JUMPDEST
PUSH1 0x00
PUSH2 0x09eb
DUP4
DUP4
PUSH2 0x1670
JUMP
JUMPDEST
SWAP1
POP
JUMPDEST
SWAP3
SWAP2
POP
POP
JUMP
JUMPDEST
PUSH1 0x05
SLOAD
PUSH1 0x00
SWAP1
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
ISZERO
ISZERO
PUSH2 0x0a11
JUMPI
POP
PUSH1 0x00
PUSH2 0x0951
JUMP
JUMPDEST
TIMESTAMP
PUSH3 0x03f480
PUSH1 0x06
SLOAD
ADD
GT
ISZERO
PUSH2 0x0a28
JUMPI
POP
PUSH1 0x00
PUSH2 0x0951
JUMP
JUMPDEST
POP
PUSH1 0x05
DUP1
SLOAD
PUSH1 0x04
DUP1
SLOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
NOT
SWAP1
DUP2
AND
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
DUP5
AND
OR
SWAP1
SWAP2
SSTORE
AND
SWAP1
SSTORE
PUSH1 0x00
PUSH1 0x06
SSTORE
PUSH1 0x01
JUMPDEST
SWAP1
JUMP
JUMPDEST
PUSH1 0x04
SLOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
JUMPDEST
SWAP1
JUMP
JUMPDEST
PUSH1 0x00
DUP1
SLOAD
PUSH1 0x01
SLOAD
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x20
SWAP1
DUP2
ADD
DUP6
SWAP1
MSTORE
DUP2
MLOAD
PUSH32 0xb524abcf00000000000000000000000000000000000000000000000000000000
DUP2
MSTORE
PUSH1 0x04
DUP2
ADD
SWAP4
SWAP1
SWAP4
MSTORE
SWAP1
MLOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
SWAP1
SWAP4
AND
SWAP3
PUSH4 0xb524abcf
SWAP3
PUSH1 0x24
DUP1
DUP3
ADD
SWAP4
SWAP3
SWAP2
DUP3
SWAP1
SUB
ADD
DUP2
DUP8
DUP8
DUP1
EXTCODESIZE
ISZERO
PUSH2 0x0000
JUMPI
PUSH1 0x32
GAS
SUB
CALL
ISZERO
PUSH2 0x0000
JUMPI
POP
POP
PUSH1 0x40
MLOAD
MLOAD
SWAP2
POP
POP
JUMPDEST
SWAP1
JUMP
JUMPDEST
PUSH1 0x00
SLOAD
CALLER
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
SWAP1
DUP2
AND
SWAP2
AND
EQ
ISZERO
PUSH2 0x0b4d
JUMPI
DUP2
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
DUP4
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
PUSH32 0x8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925
DUP4
PUSH1 0x40
MLOAD
DUP1
DUP3
DUP2
MSTORE
PUSH1 0x20
ADD
SWAP2
POP
POP
PUSH1 0x40
MLOAD
DUP1
SWAP2
SUB
SWAP1
LOG3
JUMPDEST
JUMPDEST
JUMPDEST
POP
POP
POP
JUMP
JUMPDEST
PUSH1 0x00
PUSH2 0x0b72
DUP5
DUP5
DUP5
PUSH1 0x20
PUSH1 0x40
MLOAD
SWAP1
DUP2
ADD
PUSH1 0x40
MSTORE
DUP1
PUSH1 0x00
DUP2
MSTORE
POP
PUSH2 0x1712
JUMP
JUMPDEST
SWAP1
POP
JUMPDEST
SWAP4
SWAP3
POP
POP
POP
JUMP
JUMPDEST
PUSH1 0x00
SLOAD
CALLER
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
SWAP1
DUP2
AND
SWAP2
AND
EQ
ISZERO
PUSH2 0x0b4d
JUMPI
DUP2
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
DUP4
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
PUSH32 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef
DUP4
PUSH1 0x40
MLOAD
DUP1
DUP3
DUP2
MSTORE
PUSH1 0x20
ADD
SWAP2
POP
POP
PUSH1 0x40
MLOAD
DUP1
SWAP2
SUB
SWAP1
LOG3
JUMPDEST
JUMPDEST
JUMPDEST
POP
POP
POP
JUMP
JUMPDEST
PUSH1 0x00
DUP1
SLOAD
PUSH1 0x01
SLOAD
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x20
SWAP1
DUP2
ADD
DUP6
SWAP1
MSTORE
DUP2
MLOAD
PUSH32 0xdc86e6f000000000000000000000000000000000000000000000000000000000
DUP2
MSTORE
PUSH1 0x04
DUP2
ADD
SWAP4
SWAP1
SWAP4
MSTORE
SWAP1
MLOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
SWAP1
SWAP4
AND
SWAP3
PUSH4 0xdc86e6f0
SWAP3
PUSH1 0x24
DUP1
DUP3
ADD
SWAP4
SWAP3
SWAP2
DUP3
SWAP1
SUB
ADD
DUP2
DUP8
DUP8
DUP1
EXTCODESIZE
ISZERO
PUSH2 0x0000
JUMPI
PUSH1 0x32
GAS
SUB
CALL
ISZERO
PUSH2 0x0000
JUMPI
POP
POP
PUSH1 0x40
MLOAD
MLOAD
SWAP2
POP
POP
JUMPDEST
SWAP1
JUMP
JUMPDEST
PUSH1 0x00
SLOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
DUP2
JUMP
JUMPDEST
PUSH1 0x06
SLOAD
JUMPDEST
SWAP1
JUMP
JUMPDEST
PUSH1 0x00
DUP1
SLOAD
PUSH1 0x01
SLOAD
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x20
SWAP1
DUP2
ADD
DUP6
SWAP1
MSTORE
DUP2
MLOAD
PUSH1 0xe1
PUSH1 0x02
EXP
PUSH4 0x74b5a315
MUL
DUP2
MSTORE
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
CALLER
DUP2
AND
PUSH1 0x04
DUP4
ADD
MSTORE
PUSH1 0x24
DUP3
ADD
SWAP5
SWAP1
SWAP5
MSTORE
SWAP2
MLOAD
SWAP3
SWAP1
SWAP4
AND
SWAP3
PUSH4 0xe96b462a
SWAP3
PUSH1 0x44
DUP1
DUP5
ADD
SWAP4
DUP3
SWAP1
SUB
ADD
DUP2
DUP8
DUP8
DUP1
EXTCODESIZE
ISZERO
PUSH2 0x0000
JUMPI
PUSH1 0x32
GAS
SUB
CALL
ISZERO
PUSH2 0x0000
JUMPI
POP
POP
PUSH1 0x40
MLOAD
MLOAD
ISZERO
SWAP1
POP
PUSH2 0x0951
JUMPI
PUSH1 0x05
SLOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
ISZERO
ISZERO
PUSH2 0x0d09
JUMPI
POP
PUSH1 0x00
PUSH2 0x0951
JUMP
JUMPDEST
POP
PUSH1 0x05
DUP1
SLOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
NOT
AND
SWAP1
SSTORE
PUSH1 0x00
PUSH1 0x06
SSTORE
PUSH1 0x01
JUMPDEST
JUMPDEST
JUMPDEST
SWAP1
JUMP
JUMPDEST
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
CALLER
AND
PUSH1 0x00
SWAP1
DUP2
MSTORE
PUSH1 0x07
PUSH1 0x20
MSTORE
PUSH1 0x40
SWAP1
SHA3
DUP1
SLOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
NOT
AND
SWAP1
SSTORE
PUSH1 0x01
JUMPDEST
SWAP1
JUMP
JUMPDEST
PUSH1 0x00
PUSH2 0x0d61
DUP6
DUP6
DUP6
DUP6
PUSH2 0x1712
JUMP
JUMPDEST
SWAP1
POP
JUMPDEST
SWAP5
SWAP4
POP
POP
POP
POP
JUMP
JUMPDEST
PUSH1 0x00
DUP2
CALLER
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
PUSH2 0x0d82
DUP3
PUSH2 0x1619
JUMP
JUMPDEST
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
EQ
ISZERO
PUSH2 0x0ea9
JUMPI
PUSH1 0x00
DUP1
SLOAD
PUSH1 0x01
SLOAD
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x20
SWAP1
DUP2
ADD
SWAP5
SWAP1
SWAP5
MSTORE
MLOAD
PUSH32 0x57a96dd000000000000000000000000000000000000000000000000000000000
DUP2
MSTORE
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
DUP11
DUP2
AND
PUSH1 0x04
DUP4
ADD
SWAP1
DUP2
MSTORE
PUSH1 0x24
DUP4
ADD
DUP12
SWAP1
MSTORE
PUSH1 0x44
DUP4
ADD
DUP5
SWAP1
MSTORE
DUP9
DUP3
AND
PUSH1 0x84
DUP5
ADD
MSTORE
PUSH1 0xa0
PUSH1 0x64
DUP5
ADD
SWAP1
DUP2
MSTORE
DUP11
MLOAD
PUSH1 0xa4
DUP6
ADD
MSTORE
DUP11
MLOAD
SWAP3
SWAP1
SWAP6
AND
SWAP6
PUSH4 0x57a96dd0
SWAP6
DUP14
SWAP6
DUP14
SWAP6
SWAP1
SWAP5
DUP14
SWAP5
DUP14
SWAP5
SWAP1
SWAP4
SWAP3
PUSH1 0xc4
ADD
SWAP2
SWAP1
DUP7
ADD
SWAP1
DUP1
DUP4
DUP4
DUP3
ISZERO
PUSH2 0x0e4d
JUMPI
JUMPDEST
DUP1
MLOAD
DUP3
MSTORE
PUSH1 0x20
DUP4
GT
ISZERO
PUSH2 0x0e4d
JUMPI
PUSH1 0x1f
NOT
SWAP1
SWAP3
ADD
SWAP2
PUSH1 0x20
SWAP2
DUP3
ADD
SWAP2
ADD
PUSH2 0x0e2d
JUMP
JUMPDEST
POP
POP
POP
SWAP1
POP
SWAP1
DUP2
ADD
SWAP1
PUSH1 0x1f
AND
DUP1
ISZERO
PUSH2 0x0e79
JUMPI
DUP1
DUP3
SUB
DUP1
MLOAD
PUSH1 0x01
DUP4
PUSH1 0x20
SUB
PUSH2 0x0100
EXP
SUB
NOT
AND
DUP2
MSTORE
PUSH1 0x20
ADD
SWAP2
POP
JUMPDEST
POP
SWAP7
POP
POP
POP
POP
POP
POP
POP
PUSH1 0x20
PUSH1 0x40
MLOAD
DUP1
DUP4
SUB
DUP2
PUSH1 0x00
DUP8
DUP1
EXTCODESIZE
ISZERO
PUSH2 0x0000
JUMPI
PUSH1 0x32
GAS
SUB
CALL
ISZERO
PUSH2 0x0000
JUMPI
POP
POP
PUSH1 0x40
MLOAD
MLOAD
SWAP3
POP
POP
JUMPDEST
JUMPDEST
JUMPDEST
POP
SWAP5
SWAP4
POP
POP
POP
POP
JUMP
JUMPDEST
PUSH1 0x00
DUP1
SLOAD
PUSH1 0x01
SLOAD
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x20
SWAP1
DUP2
ADD
DUP6
SWAP1
MSTORE
DUP2
MLOAD
PUSH32 0x4d30b6be00000000000000000000000000000000000000000000000000000000
DUP2
MSTORE
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
DUP8
DUP2
AND
PUSH1 0x04
DUP4
ADD
MSTORE
PUSH1 0x24
DUP3
ADD
SWAP5
SWAP1
SWAP5
MSTORE
SWAP2
MLOAD
SWAP3
SWAP1
SWAP4
AND
SWAP3
PUSH4 0x4d30b6be
SWAP3
PUSH1 0x44
DUP1
DUP5
ADD
SWAP4
DUP3
SWAP1
SUB
ADD
DUP2
DUP8
DUP8
DUP1
EXTCODESIZE
ISZERO
PUSH2 0x0000
JUMPI
PUSH1 0x32
GAS
SUB
CALL
ISZERO
PUSH2 0x0000
JUMPI
POP
POP
PUSH1 0x40
MLOAD
MLOAD
SWAP2
POP
POP
JUMPDEST
SWAP2
SWAP1
POP
JUMP
JUMPDEST
PUSH1 0x00
DUP2
CALLER
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
PUSH2 0x0f54
DUP3
PUSH2 0x1619
JUMP
JUMPDEST
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
EQ
ISZERO
PUSH2 0x0ffd
JUMPI
PUSH1 0x00
DUP1
SLOAD
PUSH1 0x01
SLOAD
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x20
SWAP1
DUP2
ADD
DUP6
SWAP1
MSTORE
DUP2
MLOAD
PUSH32 0x14712e2f00000000000000000000000000000000000000000000000000000000
DUP2
MSTORE
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
DUP12
DUP2
AND
PUSH1 0x04
DUP4
ADD
MSTORE
PUSH1 0x24
DUP3
ADD
DUP12
SWAP1
MSTORE
PUSH1 0x44
DUP3
ADD
SWAP5
SWAP1
SWAP5
MSTORE
DUP9
DUP5
AND
PUSH1 0x64
DUP3
ADD
MSTORE
SWAP2
MLOAD
SWAP3
SWAP1
SWAP4
AND
SWAP4
PUSH4 0x14712e2f
SWAP4
PUSH1 0x84
DUP1
DUP5
ADD
SWAP5
SWAP2
SWAP4
SWAP2
SWAP3
SWAP2
DUP4
SWAP1
SUB
ADD
SWAP1
DUP3
SWAP1
DUP8
DUP1
EXTCODESIZE
ISZERO
PUSH2 0x0000
JUMPI
PUSH1 0x32
GAS
SUB
CALL
ISZERO
PUSH2 0x0000
JUMPI
POP
POP
PUSH1 0x40
MLOAD
MLOAD
SWAP3
POP
POP
JUMPDEST
JUMPDEST
JUMPDEST
POP
SWAP4
SWAP3
POP
POP
POP
JUMP
JUMPDEST
PUSH1 0x03
DUP1
SLOAD
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x20
PUSH1 0x02
PUSH1 0x01
DUP6
AND
ISZERO
PUSH2 0x0100
MUL
PUSH1 0x00
NOT
ADD
SWAP1
SWAP5
AND
SWAP4
SWAP1
SWAP4
DIV
PUSH1 0x1f
DUP2
ADD
DUP5
SWAP1
DIV
DUP5
MUL
DUP3
ADD
DUP5
ADD
SWAP1
SWAP3
MSTORE
DUP2
DUP2
MSTORE
SWAP3
SWAP2
DUP4
ADD
DUP3
DUP3
DUP1
ISZERO
PUSH2 0x09d7
JUMPI
DUP1
PUSH1 0x1f
LT
PUSH2 0x09ac
JUMPI
PUSH2 0x0100
DUP1
DUP4
SLOAD
DIV
MUL
DUP4
MSTORE
SWAP2
PUSH1 0x20
ADD
SWAP2
PUSH2 0x09d7
JUMP
JUMPDEST
DUP3
ADD
SWAP2
SWAP1
PUSH1 0x00
MSTORE
PUSH1 0x20
PUSH1 0x00
SHA3
SWAP1
JUMPDEST
DUP2
SLOAD
DUP2
MSTORE
SWAP1
PUSH1 0x01
ADD
SWAP1
PUSH1 0x20
ADD
DUP1
DUP4
GT
PUSH2 0x09ba
JUMPI
DUP3
SWAP1
SUB
PUSH1 0x1f
AND
DUP3
ADD
SWAP2
JUMPDEST
POP
POP
POP
POP
POP
DUP2
JUMP
JUMPDEST
PUSH1 0x05
SLOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
JUMPDEST
SWAP1
JUMP
JUMPDEST
PUSH1 0x00
PUSH2 0x09eb
DUP4
DUP4
PUSH1 0x20
PUSH1 0x40
MLOAD
SWAP1
DUP2
ADD
PUSH1 0x40
MSTORE
DUP1
PUSH1 0x00
DUP2
MSTORE
POP
PUSH2 0x1847
JUMP
JUMPDEST
SWAP1
POP
JUMPDEST
SWAP3
SWAP2
POP
POP
JUMP
JUMPDEST
PUSH1 0x00
PUSH2 0x0b72
DUP5
DUP5
DUP5
PUSH2 0x1847
JUMP
JUMPDEST
SWAP1
POP
JUMPDEST
SWAP4
SWAP3
POP
POP
POP
JUMP
JUMPDEST
PUSH1 0x00
DUP1
SLOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
ISZERO
PUSH2 0x10fc
JUMPI
POP
PUSH1 0x00
PUSH2 0x0b75
JUMP
JUMPDEST
PUSH1 0x00
DUP1
SLOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
NOT
AND
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
DUP7
AND
OR
DUP2
SSTORE
DUP4
MLOAD
PUSH1 0x03
DUP1
SLOAD
SWAP3
DUP2
SWAP1
MSTORE
SWAP2
PUSH32 0xc2575a0e9e593c00f959f8c92f12db2869c3395a3b0502d05e2516446f71f85b
PUSH1 0x20
PUSH1 0x02
PUSH2 0x0100
PUSH1 0x01
DUP6
AND
ISZERO
MUL
PUSH1 0x00
NOT
ADD
SWAP1
SWAP4
AND
SWAP3
SWAP1
SWAP3
DIV
PUSH1 0x1f
SWAP1
DUP2
ADD
DUP4
SWAP1
DIV
DUP3
ADD
SWAP4
SWAP3
DUP9
ADD
SWAP1
DUP4
SWAP1
LT
PUSH2 0x1182
JUMPI
DUP1
MLOAD
PUSH1 0xff
NOT
AND
DUP4
DUP1
ADD
OR
DUP6
SSTORE
PUSH2 0x11af
JUMP
JUMPDEST
DUP3
DUP1
ADD
PUSH1 0x01
ADD
DUP6
SSTORE
DUP3
ISZERO
PUSH2 0x11af
JUMPI
SWAP2
DUP3
ADD
JUMPDEST
DUP3
DUP2
GT
ISZERO
PUSH2 0x11af
JUMPI
DUP3
MLOAD
DUP3
SSTORE
SWAP2
PUSH1 0x20
ADD
SWAP2
SWAP1
PUSH1 0x01
ADD
SWAP1
PUSH2 0x1194
JUMP
JUMPDEST
JUMPDEST
POP
PUSH2 0x11d0
SWAP3
SWAP2
POP
JUMPDEST
DUP1
DUP3
GT
ISZERO
PUSH2 0x11cc
JUMPI
PUSH1 0x00
DUP2
SSTORE
PUSH1 0x01
ADD
PUSH2 0x11b8
JUMP
JUMPDEST
POP
SWAP1
JUMP
JUMPDEST
POP
POP
PUSH2 0x11db
DUP4
PUSH2 0x13c5
JUMP
JUMPDEST
PUSH1 0x01
DUP2
PUSH1 0x00
NOT
AND
SWAP1
SSTORE
POP
DUP2
PUSH1 0x02
SWAP1
DUP1
MLOAD
SWAP1
PUSH1 0x20
ADD
SWAP1
DUP3
DUP1
SLOAD
PUSH1 0x01
DUP2
PUSH1 0x01
AND
ISZERO
PUSH2 0x0100
MUL
SUB
AND
PUSH1 0x02
SWAP1
DIV
SWAP1
PUSH1 0x00
MSTORE
PUSH1 0x20
PUSH1 0x00
SHA3
SWAP1
PUSH1 0x1f
ADD
PUSH1 0x20
SWAP1
DIV
DUP2
ADD
SWAP3
DUP3
PUSH1 0x1f
LT
PUSH2 0x1231
JUMPI
DUP1
MLOAD
PUSH1 0xff
NOT
AND
DUP4
DUP1
ADD
OR
DUP6
SSTORE
PUSH2 0x125e
JUMP
JUMPDEST
DUP3
DUP1
ADD
PUSH1 0x01
ADD
DUP6
SSTORE
DUP3
ISZERO
PUSH2 0x125e
JUMPI
SWAP2
DUP3
ADD
JUMPDEST
DUP3
DUP2
GT
ISZERO
PUSH2 0x125e
JUMPI
DUP3
MLOAD
DUP3
SSTORE
SWAP2
PUSH1 0x20
ADD
SWAP2
SWAP1
PUSH1 0x01
ADD
SWAP1
PUSH2 0x1243
JUMP
JUMPDEST
JUMPDEST
POP
PUSH2 0x127f
SWAP3
SWAP2
POP
JUMPDEST
DUP1
DUP3
GT
ISZERO
PUSH2 0x11cc
JUMPI
PUSH1 0x00
DUP2
SSTORE
PUSH1 0x01
ADD
PUSH2 0x11b8
JUMP
JUMPDEST
POP
SWAP1
JUMP
JUMPDEST
POP
POP
PUSH1 0x01
SWAP1
POP
JUMPDEST
SWAP4
SWAP3
POP
POP
POP
JUMP
JUMPDEST
PUSH1 0x00
DUP1
SLOAD
PUSH1 0x01
SLOAD
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x20
SWAP1
DUP2
ADD
DUP6
SWAP1
MSTORE
DUP2
MLOAD
PUSH1 0xe1
PUSH1 0x02
EXP
PUSH4 0x74b5a315
MUL
DUP2
MSTORE
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
CALLER
DUP2
AND
PUSH1 0x04
DUP4
ADD
MSTORE
PUSH1 0x24
DUP3
ADD
SWAP5
SWAP1
SWAP5
MSTORE
SWAP2
MLOAD
SWAP3
SWAP1
SWAP4
AND
SWAP3
PUSH4 0xe96b462a
SWAP3
PUSH1 0x44
DUP1
DUP5
ADD
SWAP4
DUP3
SWAP1
SUB
ADD
DUP2
DUP8
DUP8
DUP1
EXTCODESIZE
ISZERO
PUSH2 0x0000
JUMPI
PUSH1 0x32
GAS
SUB
CALL
ISZERO
PUSH2 0x0000
JUMPI
POP
POP
PUSH1 0x40
MLOAD
MLOAD
ISZERO
SWAP1
POP
PUSH2 0x0f39
JUMPI
PUSH1 0x05
SLOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
ISZERO
PUSH2 0x1318
JUMPI
POP
PUSH1 0x00
PUSH2 0x0f39
JUMP
JUMPDEST
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
DUP3
AND
ISZERO
ISZERO
PUSH2 0x1330
JUMPI
POP
PUSH1 0x00
PUSH2 0x0f39
JUMP
JUMPDEST
PUSH1 0x04
SLOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
ISZERO
ISZERO
PUSH2 0x1365
JUMPI
POP
PUSH1 0x04
DUP1
SLOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
NOT
AND
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
DUP4
AND
OR
SWAP1
SSTORE
PUSH1 0x01
PUSH2 0x0f39
JUMP
JUMPDEST
PUSH1 0x05
DUP1
SLOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
DUP5
AND
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
NOT
SWAP1
SWAP2
AND
DUP2
OR
SWAP1
SWAP2
SSTORE
TIMESTAMP
PUSH1 0x06
SSTORE
PUSH1 0x40
DUP1
MLOAD
SWAP2
DUP3
MSTORE
MLOAD
PUSH32 0xaf574319215a31df9b528258f1bdeef2b12b169dc85ff443a49373248c77493a
SWAP2
DUP2
SWAP1
SUB
PUSH1 0x20
ADD
SWAP1
LOG1
POP
PUSH1 0x01
JUMPDEST
JUMPDEST
JUMPDEST
SWAP2
SWAP1
POP
JUMP
JUMPDEST
PUSH1 0x20
DUP2
ADD
MLOAD
JUMPDEST
SWAP2
SWAP1
POP
JUMP
JUMPDEST
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
CALLER
DUP2
AND
PUSH1 0x00
SWAP1
DUP2
MSTORE
PUSH1 0x07
PUSH1 0x20
MSTORE
PUSH1 0x40
DUP2
SHA3
SLOAD
SWAP1
SWAP2
AND
ISZERO
PUSH2 0x13fa
JUMPI
POP
PUSH1 0x00
PUSH2 0x0951
JUMP
JUMPDEST
POP
PUSH1 0x04
SLOAD
CALLER
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
SWAP1
DUP2
AND
PUSH1 0x00
SWAP1
DUP2
MSTORE
PUSH1 0x07
PUSH1 0x20
MSTORE
PUSH1 0x40
SWAP1
SHA3
DUP1
SLOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
NOT
AND
SWAP2
SWAP1
SWAP3
AND
OR
SWAP1
SSTORE
PUSH1 0x01
JUMPDEST
SWAP1
JUMP
JUMPDEST
PUSH1 0x00
DUP1
SLOAD
PUSH1 0x01
SLOAD
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x20
SWAP1
DUP2
ADD
DUP6
SWAP1
MSTORE
DUP2
MLOAD
PUSH32 0x1c8d5d3800000000000000000000000000000000000000000000000000000000
DUP2
MSTORE
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
DUP9
DUP2
AND
PUSH1 0x04
DUP4
ADD
MSTORE
DUP8
DUP2
AND
PUSH1 0x24
DUP4
ADD
MSTORE
PUSH1 0x44
DUP3
ADD
SWAP5
SWAP1
SWAP5
MSTORE
SWAP2
MLOAD
SWAP3
SWAP1
SWAP4
AND
SWAP3
PUSH4 0x1c8d5d38
SWAP3
PUSH1 0x64
DUP1
DUP5
ADD
SWAP4
DUP3
SWAP1
SUB
ADD
DUP2
DUP8
DUP8
DUP1
EXTCODESIZE
ISZERO
PUSH2 0x0000
JUMPI
PUSH1 0x32
GAS
SUB
CALL
ISZERO
PUSH2 0x0000
JUMPI
POP
POP
PUSH1 0x40
MLOAD
MLOAD
SWAP2
POP
POP
JUMPDEST
SWAP3
SWAP2
POP
POP
JUMP
JUMPDEST
PUSH1 0x00
DUP2
CALLER
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
PUSH2 0x14da
DUP3
PUSH2 0x1619
JUMP
JUMPDEST
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
EQ
ISZERO
PUSH2 0x160d
JUMPI
PUSH1 0x00
DUP1
SLOAD
PUSH1 0x01
SLOAD
PUSH1 0x40
DUP1
MLOAD
PUSH1 0x20
SWAP1
DUP2
ADD
SWAP5
SWAP1
SWAP5
MSTORE
MLOAD
PUSH32 0x161ff66200000000000000000000000000000000000000000000000000000000
DUP2
MSTORE
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
DUP12
DUP2
AND
PUSH1 0x04
DUP4
ADD
SWAP1
DUP2
MSTORE
DUP12
DUP3
AND
PUSH1 0x24
DUP5
ADD
MSTORE
PUSH1 0x44
DUP4
ADD
DUP12
SWAP1
MSTORE
PUSH1 0x64
DUP4
ADD
DUP5
SWAP1
MSTORE
DUP9
DUP3
AND
PUSH1 0xa4
DUP5
ADD
MSTORE
PUSH1 0xc0
PUSH1 0x84
DUP5
ADD
SWAP1
DUP2
MSTORE
DUP11
MLOAD
PUSH1 0xc4
DUP6
ADD
MSTORE
DUP11
MLOAD
SWAP3
SWAP1
SWAP6
AND
SWAP6
PUSH4 0x161ff662
SWAP6
DUP15
SWAP6
DUP15
SWAP6
DUP15
SWAP6
SWAP2
SWAP5
DUP15
SWAP5
DUP15
SWAP5
SWAP2
SWAP4
SWAP2
SWAP3
PUSH1 0xe4
ADD
SWAP2
SWAP1
DUP7
ADD
SWAP1
DUP1
DUP4
DUP4
DUP3
ISZERO
PUSH2 0x15b0
JUMPI
JUMPDEST
DUP1
MLOAD
DUP3
MSTORE
PUSH1 0x20
DUP4
GT
ISZERO
PUSH2 0x15b0
JUMPI
PUSH1 0x1f
NOT
SWAP1
SWAP3
ADD
SWAP2
PUSH1 0x20
SWAP2
DUP3
ADD
SWAP2
ADD
PUSH2 0x1590
JUMP
JUMPDEST
POP
POP
POP
SWAP1
POP
SWAP1
DUP2
ADD
SWAP1
PUSH1 0x1f
AND
DUP1
ISZERO
PUSH2 0x15dc
JUMPI
DUP1
DUP3
SUB
DUP1
MLOAD
PUSH1 0x01
DUP4
PUSH1 0x20
SUB
PUSH2 0x0100
EXP
SUB
NOT
AND
DUP2
MSTORE
PUSH1 0x20
ADD
SWAP2
POP
JUMPDEST
POP
SWAP8
POP
POP
POP
POP
POP
POP
POP
POP
PUSH1 0x20
PUSH1 0x40
MLOAD
DUP1
DUP4
SUB
DUP2
PUSH1 0x00
DUP8
DUP1
EXTCODESIZE
ISZERO
PUSH2 0x0000
JUMPI
PUSH1 0x32
GAS
SUB
CALL
ISZERO
PUSH2 0x0000
JUMPI
POP
POP
PUSH1 0x40
MLOAD
MLOAD
SWAP3
POP
POP
JUMPDEST
JUMPDEST
JUMPDEST
POP
SWAP6
SWAP5
POP
POP
POP
POP
POP
JUMP
JUMPDEST
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
DUP1
DUP3
AND
PUSH1 0x00
SWAP1
DUP2
MSTORE
PUSH1 0x07
PUSH1 0x20
MSTORE
PUSH1 0x40
DUP2
SHA3
SLOAD
SWAP1
SWAP2
AND
ISZERO
PUSH2 0x165b
JUMPI
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
DUP1
DUP4
AND
PUSH1 0x00
SWAP1
DUP2
MSTORE
PUSH1 0x07
PUSH1 0x20
MSTORE
PUSH1 0x40
SWAP1
SHA3
SLOAD
AND
PUSH2 0x1668
JUMP
JUMPDEST
PUSH1 0x04
SLOAD
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
JUMPDEST
SWAP1
POP
JUMPDEST
SWAP2
SWAP1
POP
JUMP
JUMPDEST
PUSH1 0x00
PUSH2 0x167a
PUSH2 0x0943
JUMP
JUMPDEST
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
PUSH4 0x7b7054c8
DUP5
DUP5
CALLER
PUSH1 0x00
PUSH1 0x40
MLOAD
PUSH1 0x20
ADD
MSTORE
PUSH1 0x40
MLOAD
DUP5
PUSH4 0xffffffff
AND
PUSH1 0xe0
PUSH1 0x02
EXP
MUL
DUP2
MSTORE
PUSH1 0x04
ADD
DUP1
DUP5
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
DUP2
MSTORE
PUSH1 0x20
ADD
DUP4
DUP2
MSTORE
PUSH1 0x20
ADD
DUP3
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
DUP2
MSTORE
PUSH1 0x20
ADD
SWAP4
POP
POP
POP
POP
PUSH1 0x20
PUSH1 0x40
MLOAD
DUP1
DUP4
SUB
DUP2
PUSH1 0x00
DUP8
DUP1
EXTCODESIZE
ISZERO
PUSH2 0x0000
JUMPI
PUSH1 0x32
GAS
SUB
CALL
ISZERO
PUSH2 0x0000
JUMPI
POP
POP
PUSH1 0x40
MLOAD
MLOAD
SWAP2
POP
POP
JUMPDEST
SWAP3
SWAP2
POP
POP
JUMP
JUMPDEST
PUSH1 0x00
PUSH2 0x171c
PUSH2 0x0943
JUMP
JUMPDEST
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
PUSH4 0xec698a28
DUP7
DUP7
DUP7
DUP7
CALLER
PUSH1 0x00
PUSH1 0x40
MLOAD
PUSH1 0x20
ADD
MSTORE
PUSH1 0x40
MLOAD
DUP7
PUSH4 0xffffffff
AND
PUSH1 0xe0
PUSH1 0x02
EXP
MUL
DUP2
MSTORE
PUSH1 0x04
ADD
DUP1
DUP7
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
DUP2
MSTORE
PUSH1 0x20
ADD
DUP6
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
DUP2
MSTORE
PUSH1 0x20
ADD
DUP5
DUP2
MSTORE
PUSH1 0x20
ADD
DUP1
PUSH1 0x20
ADD
DUP4
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
DUP2
MSTORE
PUSH1 0x20
ADD
DUP3
DUP2
SUB
DUP3
MSTORE
DUP5
DUP2
DUP2
MLOAD
DUP2
MSTORE
PUSH1 0x20
ADD
SWAP2
POP
DUP1
MLOAD
SWAP1
PUSH1 0x20
ADD
SWAP1
DUP1
DUP4
DUP4
PUSH1 0x00
DUP4
EQ
PUSH2 0x17e3
JUMPI
JUMPDEST
DUP1
MLOAD
DUP3
MSTORE
PUSH1 0x20
DUP4
GT
ISZERO
PUSH2 0x17e3
JUMPI
PUSH1 0x1f
NOT
SWAP1
SWAP3
ADD
SWAP2
PUSH1 0x20
SWAP2
DUP3
ADD
SWAP2
ADD
PUSH2 0x17c3
JUMP
JUMPDEST
POP
POP
POP
SWAP1
POP
SWAP1
DUP2
ADD
SWAP1
PUSH1 0x1f
AND
DUP1
ISZERO
PUSH2 0x180f
JUMPI
DUP1
DUP3
SUB
DUP1
MLOAD
PUSH1 0x01
DUP4
PUSH1 0x20
SUB
PUSH2 0x0100
EXP
SUB
NOT
AND
DUP2
MSTORE
PUSH1 0x20
ADD
SWAP2
POP
JUMPDEST
POP
SWAP7
POP
POP
POP
POP
POP
POP
POP
PUSH1 0x20
PUSH1 0x40
MLOAD
DUP1
DUP4
SUB
DUP2
PUSH1 0x00
DUP8
DUP1
EXTCODESIZE
ISZERO
PUSH2 0x0000
JUMPI
PUSH1 0x32
GAS
SUB
CALL
ISZERO
PUSH2 0x0000
JUMPI
POP
POP
PUSH1 0x40
MLOAD
MLOAD
SWAP2
POP
POP
JUMPDEST
SWAP5
SWAP4
POP
POP
POP
POP
JUMP
JUMPDEST
PUSH1 0x00
PUSH2 0x1851
PUSH2 0x0943
JUMP
JUMPDEST
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
PUSH4 0x6a630ee7
DUP6
DUP6
DUP6
CALLER
PUSH1 0x00
PUSH1 0x40
MLOAD
PUSH1 0x20
ADD
MSTORE
PUSH1 0x40
MLOAD
DUP6
PUSH4 0xffffffff
AND
PUSH1 0xe0
PUSH1 0x02
EXP
MUL
DUP2
MSTORE
PUSH1 0x04
ADD
DUP1
DUP6
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
DUP2
MSTORE
PUSH1 0x20
ADD
DUP5
DUP2
MSTORE
PUSH1 0x20
ADD
DUP1
PUSH1 0x20
ADD
DUP4
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
PUSH1 0x01
PUSH1 0xa0
PUSH1 0x02
EXP
SUB
AND
DUP2
MSTORE
PUSH1 0x20
ADD
DUP3
DUP2
SUB
DUP3
MSTORE
DUP5
DUP2
DUP2
MLOAD
DUP2
MSTORE
PUSH1 0x20
ADD
SWAP2
POP
DUP1
MLOAD
SWAP1
PUSH1 0x20
ADD
SWAP1
DUP1
DUP4
DUP4
PUSH1 0x00
DUP4
EQ
PUSH2 0x18ff
JUMPI
JUMPDEST
DUP1
MLOAD
DUP3
MSTORE
PUSH1 0x20
DUP4
GT
ISZERO
PUSH2 0x18ff
JUMPI
PUSH1 0x1f
NOT
SWAP1
SWAP3
ADD
SWAP2
PUSH1 0x20
SWAP2
DUP3
ADD
SWAP2
ADD
PUSH2 0x18df
JUMP
JUMPDEST
POP
POP
POP
SWAP1
POP
SWAP1
DUP2
ADD
SWAP1
PUSH1 0x1f
AND
DUP1
ISZERO
PUSH2 0x192b
JUMPI
DUP1
DUP3
SUB
DUP1
MLOAD
PUSH1 0x01
DUP4
PUSH1 0x20
SUB
PUSH2 0x0100
EXP
SUB
NOT
AND
DUP2
MSTORE
PUSH1 0x20
ADD
SWAP2
POP
JUMPDEST
POP
SWAP6
POP
POP
POP
POP
POP
POP
PUSH1 0x20
PUSH1 0x40
MLOAD
DUP1
DUP4
SUB
DUP2
PUSH1 0x00
DUP8
DUP1
EXTCODESIZE
ISZERO
PUSH2 0x0000
JUMPI
PUSH1 0x32
GAS
SUB
CALL
ISZERO
PUSH2 0x0000
JUMPI
POP
POP
PUSH1 0x40
MLOAD
MLOAD
SWAP2
POP
POP
JUMPDEST
SWAP4
SWAP3
POP
POP
POP
JUMP
STOP
LOG1
PUSH6 0x627a7a723058
SHA3
EQ
LOG2
COINBASE
SLOAD
TIMESTAMP
'd2'(Unknown Opcode)
'22'(Unknown Opcode)
'c8'(Unknown Opcode)
BLOCKHASH
'a9'(Unknown Opcode)
'f9'(Unknown Opcode)
[https://etherscan.io/address/0x6531f133e6deebe7f2dce5a0441aa7ef330b4e53#code]
name::
* McsEngl.ethtmt'OgnExchange@cptIt,
_DESCRIPTION:
Livecoin is a well-established exchange that opened in 2015, at the bottom of the bitcoin bear market. Registered in London, the exchange has undertaken a series of measures to make it an attractive destination for traders, including lowering fees and offering VISA cards for rapid and easy withdrawal of funds. Currently, the majority of TIME’s volume occurs on Livecoin, as recorded by CoinMarketCap.
Liqui is a fairly new and relatively small exchange, but one that has a thriving community and a dedicated core of traders. Liqui is often fast to add new coins, proving agile where the larger exchanges take their time. At the present time, Liqui leads on price.
Mercatox is a professional trading platform for digital currencies. Although they focus on bitcoin, they have taken the decision to add TIME as well, judging it to have potential and appeal to their traders.
EtherDelta is a decentralised exchange built on Ethereum. More tech-savvy users will be able to trade peer-to-peer, without any risk of hacking or the failures that come with centralised exchanges.
[https://blog.chronobank.io/chronobanks-time-launches-on-four-exchanges-71c2bb5c989a#.wnktm5kng]
_SPECIFIC:
* https://bittrex.com/Market/Index?MarketName=BTC-TIME,
* DABTC.com, (Chinese)
* Livecoin, https://www.livecoin.net/
* Lykke,
name::
* McsEngl.ethtmt'Similar@cptIt,
_ADDRESS:
* https://etherscan.io/address/0x1818c9f1e2b22e37c3652c1a8df060f946dc6231,
* https://etherscan.io/address/0x1c440ded36ce7d8526ffac48b3bf293c320369a6,
* https://etherscan.io/address/0xf39c5f30a8c1e2e00b0b9ab3dc061b1c36a998ae,
name::
* McsEngl.ethtmt'Resource@cptIt,
_ADDRESS.WPG:
* https://etherscan.io/token/TIME,
* https://etherscan.io/address/0x6531f133e6deebe7f2dce5a0441aa7ef330b4e53,
* https://blog.chronobank.io/how-to-add-time-to-myetherwallet-e9057388c76a#.onuflhr05,
name::
* McsEngl.ethtmt.AGGREGATE@cptIt,
_DESCRIPTION:
After ChronoBank’s ICO ended in February, a total of 710,113 TIME tokens were created on the Ethereum blockchain and distributed to supporters.
[https://blog.chronobank.io/chronobanks-time-launches-on-four-exchanges-71c2bb5c989a#.wnktm5kng]
name::
* McsEngl.ethnet'Gas (ethgas)@cptIt,
* McsEngl.ethgas@cptIt,
* McsEngl.ethgas-cost@cptIt,
* McsEngl.ethnet'gas@cptIt,
_DESCRIPTION:
Gas is the-unit of computation-cost of EVM.
[hmnSngo.2017-03-16]
===
The fundamental unit of computation is “gas”; usually, a computational step costs 1 gas, but some operations cost higher amounts of gas because they are more computationally expensive, or increase the amount of data that must be stored as part of the state. There is also a fee of 5 gas for every byte in the transaction data. The intent of the fee system is to require an attacker to pay proportionately for every resource that they consume, including computation, bandwidth and storage; hence, any transaction that leads to the network consuming a greater amount of any of these resources must have a gas fee roughly proportional to the increment.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
===
Gas Cost is a static value for how much a computation costs in terms of Gas, and the intent is that the real value of the Gas never changes, so this cost should always stay stable over time.
[https://ethereum-homestead.readthedocs.io/en/latest/ether.html#gas-and-ether]
===
Executing transactions on Ethereum either runs computations or stores data.
This Costs the network CPU cycles or storage space.
That cost is paid for by the account that initiates the transaction.
The payment is called "gas".
Gas is currently paid using ETH.
At the time of writing this, 1 GAS = 0.00001 ETH.
[https://karl.tech/learning-solidity-part-1-deploy-a-contract/]
===
Just like a car needs so many gallons to travel such a distance, Ethereum transactions require so much Ether to spin so many CPU cycles or store such a quantity of data.
By simple virtue of Ether being a scarce and valuable resource, DoS attacks are prevented.
A blockchain billionaire looking to burn their fortune on a prank could slow the network for a time, but the winning miner of the nefarious transaction’s block would see quite a payday!
[https://medium.com/@ConsenSys/ethereum-bitcoin-plus-everything-a506dc780106#.s007sm8lm]
===
Gas: The fundamental network cost unit.
Paid for exclusively by Ether (as of PoC-4), which is converted freely to and from Gas as required.
Gas does not exist outside of the internal Ethereum computation engine; its price is set by the Transaction and miners are free to ignore Transactions whose Gas price is too low.
[https://ethereum.github.io/yellowpaper/paper.pdf]
===
Gas: a measurement roughly equivalent to computational steps. Every transaction is required to include a gas limit and a fee that it is willing to pay per gas; miners have the choice of including the transaction and collecting the fee or not. If the total number of gas used by the computation spawned by the transaction, including the original message and any sub-messages that may be triggered, is less than or equal to the gas limit, then the transaction processes. If the total gas exceeds the gas limit, then all changes are reverted, except that the transaction is still valid and the fee can still be collected by the miner. Every operation has a gas expenditure; for most operations it is 1, although some expensive operations fave expenditures up to 100 and a transaction itself has an expenditure of 500.
[https://github.com/ethereum/wiki/wiki/Glossary]
===
The principle behind Gas is to have a stable value for how much a transaction or computation costs on the Ethereum network.
[https://ethereum-homestead.readthedocs.io/en/latest/ether.html#gas-and-ether]
===
Gas is the relative cost between operations.
So:
- a single step calculation like if(2 > 1) will cost 1 gas
- an operation to store a value in storage will cost 100 gas
If you want to run a contract, this means a certain amount of operations will be executed. The total gas cost of those operations will be the cost of your transaction. It's like the amount of cpu cycles per operation. Everytime you send a transaction to a contract, you need to specify 3 numbers:
- value: the amount of ether you want to send into the account balance
- gas: the maximum amount of gas that may be used for processing a transaction
- gas-price the price per unit of gas you are willing to pay
The processing cost (fee) you offer for the transaction will be calculated as:
gas * gas-price (in eth/g) = ether
Gas is just a way to express relative cost and you can't send gas from 1 person to another. It is not a sub-currency like some people tend to think.
[https://www.reddit.com/r/ethereum/comments/271qdz/can_someone_explain_the_concept_of_gas_in_ethereum/chwp9r7]
name::
* McsEngl.ethgas'Price@cptIt,
* McsEngl.ethgas'price@cptIt,
* McsEngl.ethnet'gasPrice@cptIt,
_DESCRIPTION:
gasPrice
A user constructs and signs a transaction, and each user may specify whatever gasPrice they desire, which can be zero.
However, the Ethereum clients launched at Frontier had a default gasPrice of 0.05e12 wei.
As miners optimize for their revenue, if most transactions are being submitted with a gasPrice of 0.05e12 wei, it would be difficult to convince a miner to accept a transaction that specified a lower, or zero, gasPrice.
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#gasprice]
===
Gas Price is how much Gas costs in terms of another currency or token like Ether.
To stabilise the value of gas, the Gas Price is a floating value such that if the cost of tokens or currency fluctuates, the Gas Price changes to keep the same real value.
The Gas Price is set by the equilibrium price of how much users are willing to spend, and how much processing nodes are willing to accept.
[https://ethereum-homestead.readthedocs.io/en/latest/ether.html#gas-and-ether]
name::
* McsEngl.ethgas'Fee@cptIt,
* McsEngl.ethgas'fee@cptIt,
_DESCRIPTION:
Gas Fee is effectively the amount of Gas needed to be paid to run a particular transaction or program (called a contract). The Gas Fees of a block can be used to imply the computational load, transaction volume, or size of a block. The gas fees are paid to the miners (or bonded contractors in PoS).
[https://ethereum-homestead.readthedocs.io/en/latest/ether.html#gas-and-ether]
name::
* McsEngl.ethgas'Limit@cptIt,
* McsEngl.ethgas'limit@cptIt,
_DESCRIPTION:
Gas Limit is the maximum amount of Gas that can be used per block, it is considered the maximum computational load, transaction volume, or block size of a block, and miners can slowly change this value over time.
[https://ethereum-homestead.readthedocs.io/en/latest/ether.html#gas-and-ether]
name::
* McsEngl.ethgas'Refund@cptIt,
* McsEngl.ethgas'refund@cptIt,
_DESCRIPTION:
If some gas is left after the execution, it is refunded in the same way.
[http://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html#gas, 0-4-11.6d4cb248]
name::
* McsEngl.ethnet'Statistics@cptIt,
_ADDRESS.WPG:
* https://ethstats.net//
* https://etherscan.io//
* http://www.etherlisten.com//
* https://www.etherchain.org//
* http://ethernodes.org/network/1,
name::
* McsEngl.ethnet'etherscan.io@cptIt,
_DESCRIPTION:
EtherScan is a Block Explorer and Analytics Platform for Ethereum, which is a decentralized platform that runs smart contracts.
[http://etherscan.io/]
name::
* McsEngl.ethnet'Program (ethpgm)@cptIt,
* McsEngl.ethpgm@cptIt,
name::
* McsEngl.ethpgm'API.ethplorer@cptIt,
_ADDRESS.WPG:
* https://github.com/EverexIO/Ethplorer/wiki/ethplorer-api,
* https://api.ethplorer.io//
name::
* McsEngl.ethpgm'API.javascript (ethapijs)@cptIt,
* McsEngl.ethapijs@cptIt,
* McsEngl.ethereum-javascript-API@cptIt,
* McsEngl.ethjsapi@cptIt,
* McsEngl.ethnet'ApiJs@cptIt,
* McsEngl.web3.js@cptIt,
_DESCRIPTION:
To make your Πapp work on Ethereum, you can use the web3 object provided by the web3.js library.
Under the hood it communicates to a local node through RPC calls.
web3.js works with any Ethereum node, which exposes an RPC layer.
web3 contains the eth object - web3.eth (for specifically Ethereum blockchain interactions) and the shh object - web3.shh (for Whisper interaction). Over time we'll introduce other objects for each of the other web3 protocols. Working examples can be found here.
If you want to look at some more sophisticated examples using web3.js check out these useful Πapp patterns.
[https://github.com/ethereum/wiki/wiki/JavaScript-AP]
===
Ethereum JavaScript API
This is the Ethereum compatible JavaScript API which implements the Generic JSON RPC spec. It's available on npm as a node module, for bower and component as an embeddable js and as a meteor.js package.
You need to run a local Ethereum node to use this library.
[https://github.com/ethereum/web3.js]
name::
* McsEngl.ethapijs'oweb3@cptIt,
_API:
// MetaMask - injected web3
> Object.getOwnPropertyNames(web3).sort().join(", ")
"_extend, _requestManager, bzz, currentProvider, db, eth, net, personal, providers, setProvider, settings, shh, version"
> Object.getOwnPropertyNames(web3.__proto__).sort().join(", ")
"BigNumber, constructor, createBatch, fromAscii, fromDecimal, fromICAP, fromUtf8, fromWei, isAddress, isChecksumAddress, isConnected, isIBAN, reset, setProvider, sha3, toAscii, toBigNumber, toChecksumAddress, toDecimal, toHex, toUtf8, toWei"
===
> const web3 = require('web3')
> const ow3 = new web3(new web3.providers.HttpProvider("http://localhost:8545"));
undefined
> Object.getOwnPropertyNames(ow3).sort()
[ '_extend',
'_requestManager',
'bzz',
'currentProvider',
'db',
'eth',
'net',
'personal',
'providers',
'settings',
'shh',
'version' ]
===
> Object.getOwnPropertyNames(web3).sort()
[ 'arguments',
'caller',
'length',
'name',
'prototype',
'providers' ]
> Object.getOwnPropertyNames(web3.prototype).sort()
[ 'BigNumber',
'constructor',
'createBatch',
'fromAscii',
'fromDecimal',
'fromICAP',
'fromUtf8',
'fromWei',
'isAddress',
'isChecksumAddress',
'isConnected',
'isIBAN',
'reset',
'setProvider',
'sha3',
'toAscii',
'toBigNumber',
'toChecksumAddress',
'toDecimal',
'toHex',
'toUtf8',
'toWei' ]
> Object.getOwnPropertyNames(oW3.prototype.__proto__).sort()
[ '__defineGetter__',
'__defineSetter__',
'__lookupGetter__',
'__lookupSetter__',
'__proto__',
'constructor',
'hasOwnProperty',
'isPrototypeOf',
'propertyIsEnumerable',
'toLocaleString',
'toString',
'valueOf' ]
name::
* McsEngl.ethapijs'oweb3.eth@cptIt,
_API:
> Object.getOwnPropertyNames(ow3.eth).sort()
[ '_requestManager',
'accounts',
'blockNumber',
'call',
'coinbase',
'compile',
'estimateGas',
'gasPrice',
'getAccounts',
'getBalance',
'getBlock',
'getBlockNumber',
'getBlockTransactionCount',
'getBlockUncleCount',
'getCode',
'getCoinbase',
'getCompilers',
'getGasPrice',
'getHashrate',
'getMining',
'getProtocolVersion',
'getStorageAt',
'getSyncing',
'getTransaction',
'getTransactionCount',
'getTransactionFromBlock',
'getTransactionReceipt',
'getUncle',
'getWork',
'hashrate',
'iban',
'mining',
'protocolVersion',
'sendIBANTransaction',
'sendRawTransaction',
'sendTransaction',
'sign',
'submitWork',
'syncing' ]
name::
* McsEngl.ethapijs'oweb3.personal@cptIt,
_API:
> Object.getOwnPropertyNames(ow3.personal).sort()
[ '_requestManager',
'getListAccounts',
'listAccounts',
'lockAccount',
'newAccount',
'sendTransaction',
'unlockAccount' ]
name::
* McsEngl.ethapijs'oweb3.version@cptIt,
_API:
> Object.getOwnPropertyNames(ow3.version).sort()
[ 'api',
'ethereum',
'getEthereum',
'getNetwork',
'getNode',
'getWhisper',
'network',
'node',
'whisper' ]
===
> ow3.version.api
'0.18.2'
name::
* McsEngl.ethapijs'Transaction@cptIt,
A transaction object looks like this:
{
"blockHash": "0x361464a30ecc10640fd859bc90844a30f0ddff561e6805fb657aff0567da7b4f",
"blockNumber": 131494,
"from": "0x4cf24bf15bfead008b22ea33b7c99a82326031a7",
"gas": 90000,
"gasPrice": "20000000000",
"hash": "0xa11e9aa7aff1bd6cb6c7d886cc531e75a8bcdea1ddcf387937aae3f3a0addb20",
"input": "0x4326ee36000000000000000000000000000000000000000000000000000000000000034b",
"nonce": 1477,
"to": "0x58b671784f4fa6b02e3dcac9f9dd215b66b5669b",
"transactionIndex": 0,
"value": "0"
}
[http://hypernephelist.com/2016/06/21/a-simple-smart-contract-ui-web3.html]
name::
* McsEngl.ethapijs'Resource@cptIt,
_ADDRESS.WPG:
* <script src="https://cdn.rawgit.com/ethereum/web3.js/develop/dist/web3.js"></script>
<script src="https://raw.githubusercontent.com/ethereum/web3.js/0.16.0/dist/web3.min.js"></script>
* https://github.com/ethereum/web3.js,
* https://github.com/ethereum/wiki/wiki/JavaScript-API,
name::
* McsEngl.ethpgm.specific@cptIt,
* McsEngl.ethpgm.specific@cptIt,
_SPECIFIC:
* Contract-program,
* Ethpm#ql:idEthpgmPm#,
* EVM,
* Client,
* Mist-browser,
* Parity-browser,
* DAPP,
* Mix#ql:idEthpgmMix#,
* Truffle,
* Mining,
name::
* McsEngl.ethpgm.Mix@cptIt,
_DESCRIPTION:
Mix: The integrated development environment for DApp authoring. Quickly prototype and debug decentralised applications on the Ethereum platform. More information can be found at the Mix GitHub Page.
[http://ethdocs.org/en/latest/frequently-asked-questions/frequently-asked-questions.html#how-can-i-store-big-files-on-the-blockchain]
name::
* McsEngl.ethpgm.Ethpm@cptIt,
* McsEngl.ethpm@cptIt,
_DESCRIPTION:
The Ethereum Package Registry
A package index for Ethereum smart contract packages.
[https://www.ethpm.com/]
name::
* McsEngl.ethpm'Resource@cptIt,
_ADDRESS.WPG:
* https://www.ethpm.com//,
* https://www.ethpm.com/registry,
* https://www.ethpm.com/docs/integration-guide,
name::
* McsEngl.ethpgm.EVM (ethevm)@cptIt,
* McsEngl.Ethereum-Virtual-Machine@cptIt,
* McsEngl.EVM-of-ethereum@cptIt,
* McsEngl.ethEVM@cptIt,
_DESCRIPTION:
The EVM is not a register machine but a stack machine, so all computations are performed on an area called the stack.
It has a maximum size of 1024 elements and contains words of 256 bits. Access to the stack is limited to the top end in the following way: It is possible to copy one of the topmost 16 elements to the top of the stack or swap the topmost element with one of the 16 elements below it. All other operations take the topmost two (or one, or more, depending on the operation) elements from the stack and push the result onto the stack. Of course it is possible to move stack elements to storage or memory, but it is not possible to just access arbitrary elements deeper in the stack without first removing the top of the stack.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#storage-memory-and-the-stack]
===
The Ethereum Virtual Machine (EVM) is the runtime environment for smart contracts in Ethereum. It is not only sandboxed, but actually completely isolated, which means that code running inside the EVM has no access to network, filesystem, or other processes. Smart contracts even have limited access to other smart contracts.
Contracts live on the blockchain in an Ethereum-specific binary format (EVM bytecode). However, contracts are typically written in an Ethereum high level language, compiled into byte code using an EVM compiler, and finally uploaded on the blockchain using an Ethereum client.
[https://ethereum-homestead.readthedocs.org/en/latest/contracts-and-transactions/developer-tools.html#the-evm]
===
The Ethereum Virtual Machine is the primary innovation of the Ethereum project. This is a virtual machine designed to be run by all participants in a peer to peer network, it can read and write to a blockchain both executable code and data, Verify digital signatures, and is able to run code in a quasi-Turing complete manner. It will only execute code when it receives a message verified by a digital signature, and the information stored on the blockchain tells it is appropriate to do so.
[https://dappsforbeginners.wordpress.com/tutorials/introduction-to-development-on-ethereum/]
===
The Ethereum Virtual Machine or EVM is the runtime environment for smart contracts in Ethereum. It is not only sandboxed but actually completely isolated, which means that code running inside the EVM has no access to network, filesystem or other processes. Smart contracts even have limited access to other smart contracts.
[https://solidity.readthedocs.org/en/latest/introduction-to-smart-contracts.html#overview]
_WHOLE:
Ethereum enables this complexity by placing a virtual machine (called the Ethereum Virtual Machine, or EVM) in every node on the network.
The EVM is not conceptually different than any other virtual machine.
You may already be familiar with the Java Virtual Machine (JVM), for example.
Just like JVM code will run on any machine hosting a JVM and produce identical outputs over the same set of inputs, the EVM enables the Ethereum blockchain to reach consensus about the proper output of any EVM code based on a set of inputs.
[https://medium.com/@ConsenSys/ethereum-bitcoin-plus-everything-a506dc780106#.izxhgdxdt]
name::
* McsEngl.ethevm'Stack-area@cptIt,
* McsEngl.ethevm'Stack@cptIt,
* McsEngl.ethNet'Stack@cptIt,
_DESCRIPTION:
The EVM is not a register machine but a stack machine, so all computations are performed on an area called the stack.
It has a maximum size of 1024 elements and contains words of 256 bits.
Access to the stack is limited to the top end in the following way: It is possible to copy one of the topmost 16 elements to the top of the stack or swap the topmost element with one of the 16 elements below it.
All other operations take the topmost two (or one, or more, depending on the operation) elements from the stack and push the result onto the stack.
Of course it is possible to move stack elements to storage or memory, but it is not possible to just access arbitrary elements deeper in the stack without first removing the top of the stack.
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-10]
===
The Ethereum VM is stack-based.
This means the operands for the instructions are taken from the stack, and it is also where the results are added.
[https://github.com/androlo/solidity-workshop/blob/master/tutorials/2016-03-11-advanced-solidity-II.md#stack-machines]
===
Elements on the stack are 32-byte words,
[https://github.com/ebuchman/evm-tools/blob/master/analysis/guide.md#overview]
===
// Prefer loops to recursion (max call stack depth is 1024)
[https://learnxinyminutes.com/docs/solidity//]
name::
* McsEngl.ethevm'Storage-area (persistent)@cptIt,
* McsEngl.ethevm'Storage@cptIt,
* McsEngl.ethNet'Storage@cptIt,
* McsEngl.ethevm'Key-value-store@cptIt,
_DESCRIPTION:
_DESCRIPTION:
Each account has a persistent memory area which is called storage.
Storage is a key-value store that maps 256-bit words to 256-bit words.
It is not possible to enumerate storage from within a contract and it is comparatively costly to read and even more so, to modify storage.
A contract can neither read nor write to any storage apart from its own.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#storage-memory-and-the-stack]
===
Unlike stack and memory, which reset after computation ends, storage persists for the long term.
... While the Ethereum virtual machine is running, its full computational state can be defined by the tuple (block_state, transaction, message, code, memory, stack, pc, gas), where block_state is the global state containing all accounts and includes balances and storage.
[https://github.com/ethereum/wiki/wiki/White-Paper#code-execution]
===
Every account has a persistent key-value store mapping 256-bit words to 256-bit words called storage.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#accounts]
===
Complex types, i.e. types which do not always fit into 256 bits have to be handled more carefully than the value-types we have already seen. Since copying them can be quite expensive, we have to think about whether we want them to be stored in memory (which is not persisting) or storage (where the state variables are held).
[http://solidity.readthedocs.io/en/v0.4.9/types.html#index-13]
===
“Contracts” in Ethereum should not be seen as something that should be “fulfilled” or “complied with”; rather, they are more like “autonomous agents” that live inside of the Ethereum execution environment, always executing a specific piece of code when “poked” by a message or transaction, and having direct control over their own ether balance and their own key/value store to store their permanent state.
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#contract-accounts]
===
key-value storage (persisted in a merkle tree). ...
all keys and values in storage are 32 bytes.
[https://github.com/ebuchman/evm-tools/blob/master/analysis/guide.md#overview]
name::
* McsEngl.ethevm'Memory-area (non-persistent)@cptIt,
* McsEngl.ethevm'memory@cptIt,
* McsEngl.ethnet'memory@cptIt,
* McsEngl.ephemeral-memory-of-evm@cptIt,
_DESCRIPTION:
The second memory area is called memory, of which a contract obtains a freshly cleared instance for each message call.
Memory is linear and can be addressed at byte level, but reads are limited to a width of 256 bits, while writes can be either 8 bits or 256 bits wide.
Memory is expanded by a word (256-bit), when accessing (either reading or writing) a previously untouched memory word (ie. any offset within a word).
At the time of expansion, the cost in gas must be paid.
Memory is more costly the larger it grows (it scales quadratically).
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-10]
===
Memory is an expandable byte-array used to store data during program execution.
It can be accessed using the MSTORE and MLOAD#ql:ethopc'mload# instructions
[https://github.com/androlo/solidity-workshop/blob/master/tutorials/2016-03-11-advanced-solidity-III.md#memory]
===
Complex types, i.e. types which do not always fit into 256 bits have to be handled more carefully than the value-types we have already seen. Since copying them can be quite expensive, we have to think about whether we want them to be stored in memory (which is not persisting) or storage (where the state variables are held).
[http://solidity.readthedocs.io/en/v0.4.9/types.html#index-13]
name::
* McsEngl.ethevm'Calldata@cptIt,
* McsEngl.ethevm'calldata@cptIt,
* McsEngl.ethNet'calldata@cptIt,
_DESCRIPTION:
Calldata is a byte-array, just like memory, but it is read-only.
It contains the data from the transaction that triggered the code execution.
[https://github.com/androlo/solidity-workshop/blob/master/tutorials/2016-03-11-advanced-solidity-III.md#memory]
name::
* McsEngl.ethevm'Bytecode@cptIt,
_DESCRIPTION:
Contracts live on the blockchain in an Ethereum-specific binary format (EVM bytecode).
However, contracts are typically written in an Ethereum high level language, compiled into byte code using an EVM compiler, and finally uploaded on the blockchain using an Ethereum client.
[https://ethereum-homestead.readthedocs.org/en/latest/contracts-and-transactions/developer-tools.html#the-evm]
name::
* McsEngl.ethevm'Instruction (ethinn)@cptIt,
* McsEngl.ethevm'computation@cptIt,
* McsEngl.ethevm'instruction@cptIt,
* McsEngl.ethevm'opcode@cptIt,
* McsEngl.ethevm'operation@cptIt,
* McsEngl.ethopc@cptIt,
* McsEngl.operation-code-of-evm@cptIt,
_DESCRIPTION:
The instruction set of the EVM is kept minimal in order to avoid incorrect implementations which could cause consensus problems.
All instructions operate on the basic data type, 256-bit words.
The usual arithmetic, bit, logical and comparison operations are present.
Conditional and unconditional jumps are possible.
Furthermore, contracts can access relevant properties of the current block like its number and timestamp.
[http://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html#instruction-set, 0-4-11.6d4cb248]
===
Every single operation that is executed inside the EVM is actually simultaneously executed by every node in the network.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#262d]
name::
* McsEngl.ethinn'argument@cptIt,
_DESCRIPTION:
The table tells us how many arguments each opcode pops off the stack and pushes back onto the stack, as well as how much gas is consumed.
# schema: [opcode, ins, outs, gas]
opcodes = {
# arithmetic
ethinn.0x00: ['ethinn.STOP', 0, 0, 0],
ethinn.0x01: ['ethinn.ADD', 2, 1, 3],
ethinn.0x02: ['ethinn.MUL', 2, 1, 5],
ethinn.0x03: ['ethinn.SUB', 2, 1, 3],
ethinn.0x04: ['ethinn.DIV', 2, 1, 5],
ethinn.0x05: ['ethinn.SDIV', 2, 1, 5],
ethinn.0x06: ['ethinn.MOD', 2, 1, 5],
ethinn.0x07: ['ethinn.SMOD', 2, 1, 5],
ethinn.0x08: ['ethinn.ADDMOD', 3, 1, 8],
ethinn.0x09: ['ethinn.MULMOD', 3, 1, 8],
ethinn.0x0a: ['ethinn.EXP', 2, 1, 10],
ethinn.0x0b: ['ethinn.SIGNEXTEND', 2, 1, 5],
# boolean
ethinn.0x10: ['ethinn.LT', 2, 1, 3],
ethinn.0x11: ['ethinn.GT', 2, 1, 3],
ethinn.0x12: ['ethinn.SLT', 2, 1, 3],
ethinn.0x13: ['ethinn.SGT', 2, 1, 3],
ethinn.0x14: ['ethinn.EQ', 2, 1, 3],
ethinn.0x15: ['ethinn.ISZERO', 1, 1, 3],
ethinn.0x16: ['ethinn.AND', 2, 1, 3],
ethinn.0x17: ['ethinn.OR', 2, 1, 3],
ethinn.0x18: ['ethinn.XOR', 2, 1, 3],
ethinn.0x19: ['ethinn.NOT', 1, 1, 3],
ethinn.0x1a: ['ethinn.BYTE', 2, 1, 3],
# crypto
ethinn.0x20: ['ethinn.SHA3', 2, 1, 30],
# contract context
ethinn.0x30: ['ethinn.ADDRESS', 0, 1, 2],
ethinn.0x31: ['ethinn.BALANCE', 1, 1, 20],
ethinn.0x32: ['ethinn.ORIGIN', 0, 1, 2],
ethinn.0x33: ['ethinn.CALLER', 0, 1, 2],
ethinn.0x34: ['ethinn.CALLVALUE', 0, 1, 2],
ethinn.0x35: ['ethinn.CALLDATALOAD', 1, 1, 3],
ethinn.0x36: ['ethinn.CALLDATASIZE', 0, 1, 2],
ethinn.0x37: ['ethinn.CALLDATACOPY', 3, 0, 3],
ethinn.0x38: ['ethinn.CODESIZE', 0, 1, 2],
ethinn.0x39: ['ethinn.CODECOPY', 3, 0, 3],
ethinn.0x3a: ['ethinn.GASPRICE', 0, 1, 2],
ethinn.0x3b: ['ethinn.EXTCODESIZE', 1, 1, 20],
ethinn.0x3c: ['ethinn.EXTCODECOPY', 4, 0, 20],
# blockchain context
ethinn.0x40: ['ethinn.BLOCKHASH', 1, 1, 20],
ethinn.0x41: ['ethinn.COINBASE', 0, 1, 2],
ethinn.0x42: ['ethinn.TIMESTAMP', 0, 1, 2],
ethinn.0x43: ['ethinn.NUMBER', 0, 1, 2],
ethinn.0x44: ['ethinn.DIFFICULTY', 0, 1, 2],
ethinn.0x45: ['ethinn.GASLIMIT', 0, 1, 2],
# storage and execution
ethinn.0x50: ['ethinn.POP', 1, 0, 2],
ethinn.0x51: ['ethinn.MLOAD', 1, 1, 3],
ethinn.0x52: ['ethinn.MSTORE', 2, 0, 3],
ethinn.0x53: ['ethinn.MSTORE8', 2, 0, 3],
ethinn.0x54: ['ethinn.SLOAD', 1, 1, 50],
ethinn.0x55: ['ethinn.SSTORE', 2, 0, 0],
ethinn.0x56: ['ethinn.JUMP', 1, 0, 8],
ethinn.0x57: ['ethinn.JUMPI', 2, 0, 10],
ethinn.0x58: ['ethinn.PC', 0, 1, 2],
ethinn.0x59: ['ethinn.MSIZE', 0, 1, 2],
ethinn.0x5a: ['ethinn.GAS', 0, 1, 2],
ethinn.0x5b: ['ethinn.JUMPDEST', 0, 0, 1],
# logging
ethinn.0xa0: ['ethinn.LOG0', 2, 0, 375],
ethinn.0xa1: ['ethinn.LOG1', 3, 0, 750],
ethinn.0xa2: ['ethinn.LOG2', 4, 0, 1125],
ethinn.0xa3: ['ethinn.LOG3', 5, 0, 1500],
ethinn.0xa4: ['ethinn.LOG4', 6, 0, 1875],
# arbitrary length storage (proposal for metropolis hardfork)
ethinn.0xe1: ['ethinn.SLOADBYTES', 3, 0, 50],
ethinn.0xe2: ['ethinn.SSTOREBYTES', 3, 0, 0],
ethinn.0xe3: ['ethinn.SSIZE', 1, 1, 50],
# closures
ethinn.0xf0: ['ethinn.CREATE', 3, 1, 32000],
ethinn.0xf1: ['ethinn.CALL', 7, 1, 40],
ethinn.0xf2: ['ethinn.CALLCODE', 7, 1, 40],
ethinn.0xf3: ['ethinn.RETURN', 2, 0, 0],
ethinn.0xf4: ['ethinn.DELEGATECALL', 6, 0, 40],
ethinn.0xff: ['ethinn.SUICIDE', 1, 0, 0],
}
# push
for i in range(1, 33):
opcodes[0x5f + i] = ['PUSH' + str(i), 0, 1, 3]
# duplicate and swap
for i in range(1, 17):
opcodes[0x7f + i] = ['DUP' + str(i), i, i + 1, 3]
opcodes[0x8f + i] = ['SWAP' + str(i), i + 1, i + 1, 3]
[https://github.com/ebuchman/evm-tools/blob/master/analysis/guide.md#overview]
name::
* McsEngl.ethinn.SPECIFIC@cptIt,
_SPECIFIC:
There are over 100 opcodes,
[https://github.com/ebuchman/evm-tools/blob/master/analysis/guide.md#overview]
===
All of the opcodes and their complete descriptions are available in the Ethereum Yellow paper. For convenience, though, I've made a handy reference list of them all:
0s: Stop and Arithmetic Operations
0x00 ethinn'STOP Halts execution
0x01 ethinn'ADD Addition operation
0x02 ethinn'MUL Multiplication operation
0x03 ethinn'SUB Subtraction operation
0x04 ethinn'DIV Integer division operation
0x05 ethinn'SDIV Signed integer
0x06 ethinn'MOD Modulo
0x07 ethinn'SMOD Signed modulo
0x08 ethinn'ADDMOD Modulo
0x09 ethinn'MULMOD Modulo
0x0a ethinn'EXP Exponential operation
0x0b ethinn'SIGNEXTEND Extend length of two's complement signed integer
10s: Comparison & Bitwise Logic Operations
0x10 ethinn'LT Lesser-than comparison
0x11 ethinn'GT Greater-than comparison
0x12 ethinn'SLT Signed less-than comparison
0x13 ethinn'SGT Signed greater-than comparison
0x14 ethinn'EQ Equality comparison
0x15 ethinn'ISZERO Simple not operator
0x16 ethinn'AND Bitwise AND operation
0x17 ethinn'OR Bitwise OR operation
0x18 ethinn'XOR Bitwise XOR operation
0x19 ethinn'NOT Bitwise NOT operation
0x1a ethinn'BYTE Retrieve single byte from word
20s: SHA3
0x20 ethinn'SHA3 Compute Keccak-256 hash
30s: Environmental Information
0x30 ethinn'ADDRESS Get address of currently executing account
0x31 ethinn'BALANCE Get balance of the given account
0x32 ethinn'ORIGIN Get execution origination address
0x33 ethinn'CALLER Get caller address. This is the address of the account that is directly responsible for this execution
0x34 ethinn'CALLVALUE Get deposited value by the instruction/transaction responsible for this execution
0x35 ethinn'CALLDATALOAD Get input data of current environment
0x36 ethinn'CALLDATASIZE Get size of input data in current environment
0x37 ethinn'CALLDATACOPY Copy input data in current environment to memory This pertains to the input data passed with the message call instruction or transaction
0x38 ethinn'CODESIZE Get size of code running in current environment
0x39 ethinn'CODECOPY Copy code running in current environment to memory
0x3a ethinn'GASPRICE Get price of gas in current environment
0x3b ethinn'EXTCODESIZE Get size of an account's code
0x3c ethinn'EXTCODECOPY Copy an account's code to memory
40s: Block Information
0x40 ethinn'BLOCKHASH Get the hash of one of the 256 most recent complete blocks
0x41 ethinn'COINBASE Get the block's beneficiary address
0x42 ethinn'TIMESTAMP Get the block's timestamp
0x43 ethinn'NUMBER Get the block's number
0x44 ethinn'DIFFICULTY Get the block's difficulty
0x45 ethinn'GASLIMIT Get the block's gas limit
50s Stack, Memory, Storage and Flow Operations
0x50 ethinn'POP Remove item from stack
0x51 ethinn'MLOAD Load word from memory
0x52 ethinn'MSTORE Save word to memory
0x53 ethinn'MSTORE8 Save byte to memory
0x54 ethinn'SLOAD Load word from storage
0x55 ethinn'SSTORE Save word to storage
0x56 ethinn'JUMP Alter the program counter
0x57 ethinn'JUMPI Conditionally alter the program counter
0x58 ethinn'PC Get the value of the program counter prior to the increment
0x59 ethinn'MSIZE Get the size of active memory in bytes
0x5a ethinn'GAS Get the amount of available gas, including the corresponding reduction
0x5b ethinn'JUMPDEST Mark a valid destination for jumps
60s & 70s: Push Operations
ethinn.0x60 ethinn'PUSH1 Place 1 byte item on stack
0x61 ethinn'PUSH2 Place 2-byte item on stack
…
0x7f ethinn'PUSH32 Place 32-byte (full word) item on stack
80s: Duplication Operations
ethinn.0x80 ethinn'DUP1 Duplicate 1st stack item
0x81 ethinn'DUP2 Duplicate 2nd stack item
…
0x8f ethinn'DUP16 Duplicate 16th stack item
90s: Exchange Operations
ethinn.0x90 ethinn'SWAP1 Exchange 1st and 2nd stack items
0x91 ethinn'SWAP2 Exchange 1st and 3rd stack items
… …
0x9f ethinn'SWAP16 Exchange 1st and 17th stack items
a0s: Logging Operations
0xa0 ethinn'LOG0 Append log record with no topics
0xa1 ethinn'LOG1 Append log record with one topic
… …
0xa4 ethinn'LOG4 Append log record with four topics
f0s: System operations
0xf0 ethinn'CREATE Create a new account with associated code
0xf1 ethinn'CALL Message-call into an account
0xf2 ethinn'CALLCODE Message-call into this account with alternative account's code
0xf3 ethinn'RETURN Halt execution returning output data
0xf4 ethinn'DELEGATECALL Message-call into this account with an alternative account's code, but persisting the current values for `sender` and `value`
Halt Execution, Mark for deletion
0xff ethinn'SUICIDE Halt execution and register account for later deletion
[http://ethereum.stackexchange.com/a/120]
name::
* McsEngl.ethevm'Compiler@cptIt,
* McsEngl.EVM-compiler@cptIt,
_DESCRIPTION:
Contracts live on the blockchain in an Ethereum-specific binary format (EVM bytecode).
However, contracts are typically written in an Ethereum high level language, compiled into byte code using 'defn.an-EVM-compiler', and finally uploaded on the blockchain using an Ethereum client.
[https://ethereum-homestead.readthedocs.org/en/latest/contracts-and-transactions/developer-tools.html#the-evm]
name::
* McsEngl.ethevm'Security@cptIt,
_DESCRIPTION:
The EVM is a security oriented virtual machine, designed to permit untrusted code to be executed by a global network of computers. To do so securely, it imposes the following restrictions:
- Every computational step taken in a program's execution must be paid for up front, thereby preventing Denial-of-Service attacks.
- Programs may only interact with each other by transmitting a single arbitrary-length byte array; they do not have access to each other's state.
- Program execution is sandboxed; an EVM program may access and modify its own internal state and may trigger the execution of other EVM programs, but nothing else.
- Program execution is fully deterministic and produces identical state transitions for any conforming implementation beginning in an identical state.
These restrictions motivated many of the design decisions of the overall Ethereum state transition machine, and their enforcement is pervasive throughout the specification.
[https://github.com/ebuchman/evm-tools/blob/master/analysis/guide.md#security]
===
The Ethereum Virtual Machine or EVM is the runtime environment for smart contracts in Ethereum.
It is not only sandboxed but actually completely isolated, which means that code running inside the EVM has no access to network, filesystem or other processes.
Smart contracts even have limited access to other smart contracts.
[https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html#overview 0-4-10.6258fe71]
name::
* McsEngl.ethevm'Resource@cptIt,
_ADDRESS.WPG:
* https://github.com/ebuchman/evm-tools/blob/master/analysis/guide.md,
name::
* McsEngl.ethevm'Code-executing@cptIt,
* McsEngl.ethevm'execution@cptIt,
_DESCRIPTION:
In general, code execution is an infinite loop that consists of repeatedly carrying out the operation at the current program counter (which begins at zero) and then incrementing the program counter by one, until the end of the code is reached or an error or STOP or RETURN instruction is detected.
...
The code can also access the value, sender and data of the incoming message, as well as block header data, and the code can also return a byte array of data as an output.
The formal execution model of EVM code is surprisingly simple. While the Ethereum virtual machine is running, its full computational state can be defined by the tuple (block_state, transaction, message, code, memory, stack, pc, gas), where block_state is the global state containing all accounts and includes balances and storage. At the start of every round of execution, the current instruction is found by taking the pcth (Program Counter) byte of code (or 0 if pc >= len(code)), and each instruction has its own definition in terms of how it affects the tuple. For example, ADD pops two items off the stack and pushes their sum, reduces gas by 1 and increments pc by 1, and SSTORE pops the top two items off the stack and inserts the second item into the contract's storage at the index specified by the first item. Although there are many ways to optimize Ethereum virtual machine execution via just-in-time compilation, a basic implementation of Ethereum can be done in a few hundred lines of code.
[https://github.com/ethereum/wiki/wiki/White-Paper#code-execution]
===
... A commonly asked question is "where" contract code is executed, in terms of physical hardware.
This has a simple answer: the process of executing contract code is part of the definition of the state transition function, which is part of the block validation algorithm, so if a transaction is added into block B the code execution spawned by that transaction will be executed by all nodes, now and in the future, that download and validate block B.
[https://github.com/ethereum/wiki/wiki/White-Paper#blockchain-and-mining]
name::
* McsEngl.ethpgm.CLIENT (ethclt)@cptIt,
* McsEngl.ethclient@cptIt,
* McsEngl.ethclt@cptIt,
* McsEngl.ethereum-client@cptIt,
* McsEngl.ethnet'browser@cptIt,
* McsEngl.ethpgm.client@cptIt,
_DESCRIPTION:
The Ethereum clients are very analogous to a Java VM or .NET runtime.
They enable you to execute “Ethereum programs” on your computer. They are implemented to a written specification (the Yellow Paper) and by design are interoperable and somewhat “commodity”.
[https://ethereum-homestead.readthedocs.org/en/latest/ethereum-clients/choosing-a-client.html]
name::
* McsEngl.ethclt.specific@cptIt,
_SPECIFIC:
The Ethereum Foundation publishes the specifications for Ethereum clients on their Github page, and funds development of official clients written in Go (go-ethereum), C++ (cpp-ethereum) and Python (py-ethereum). There are also community contributed clients in many other languages, including Ruby, Java, Haskell and Rust.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
===
As of September 2016, the leading implementations are go-ethereum and Parity.
[http://ethdocs.org/en/latest/ethereum-clients/choosing-a-client.html]
===
Client Language Developers Homestead Release
go-ethereum Go Ethereum Foundation geth-v1.3.5
cpp-ethereum C++ Ethereum Foundation eth-v1.2.2
pyethapp Python Ethereum Foundation v1.2.0 release imminent
ethereumjs-lib Javascript Ethereum Foundation ethereumjs-lib-v3.0.0
Ethereum(J) Java <ether.camp> ethereumJ-v1.2.0-homestead-RC
ethereumH Haskell ConsenSys not available yet
Parity Rust Ethcore Parity-v1.0.0
ruby-ethereum Ruby Jan Xie not available yet
[https://ethereum-homestead.readthedocs.org/en/latest/ethereum-clients/choosing-a-client.html]
===
* command-line-client
name::
* McsEngl.ethclt.GO-ETHEREUM (ethgth)@cptIt,
* McsEngl.ethget@cptIt,
* McsEngl.ethgeth@cptIt,
* McsEngl.ethgth@cptIt,
* McsEngl.geth@cptIt,
* McsEngl.ethnet'geth@cptIt,
* McsEngl.ethnet'go-ethereum@cptIt,
_DESCRIPTION:
Go Ethereum is available either as a standalone client called Geth that you can install on pretty much any operating system, or as a library that you can embed in your Go, Android or iOS projects.
[https://geth.ethereum.org//]
name::
* McsEngl.ethgth'Synopsis@cptIt,
$ geth help
NAME:
geth - the go-ethereum command line interface
Copyright 2013-2016 The go-ethereum Authors
USAGE:
geth [options] command [command options] [arguments...]
VERSION:
1.5.5-unstable
COMMANDS:
init Bootstrap and initialize a new genesis block
import Import a blockchain file
export Export blockchain into file
upgradedb Upgrade chainblock database
removedb Remove blockchain and state databases
dump Dump a specific block from storage
monitor Monitor and visualize node metrics
account Manage accounts
wallet Manage Ethereum presale wallets
console Start an interactive JavaScript environment
attach Start an interactive JavaScript environment (connect to node)
js Execute the specified JavaScript files
makedag Generate ethash DAG (for testing)
version Print version numbers
license Display license information
help, h Shows a list of commands or help for one command
ETHEREUM OPTIONS:
--datadir "/home/tron/.ethereum" Data directory for the databases and keystore
--keystore Directory for the keystore (default = inside the datadir)
--networkid value Network identifier (integer, 0=Olympic (disused), 1=Frontier, 2=Morden (disused), 3=Ropsten) (default: 1)
--olympic Olympic network: pre-configured pre-release test network
--testnet Ropsten network: pre-configured test network
--dev Developer mode: pre-configured private network with several debugging flags
--identity value Custom node name
--fast Enable fast syncing through state downloads
--light Enable light client mode
--lightserv value Maximum percentage of time allowed for serving LES requests (0-90) (default: 0)
--lightpeers value Maximum number of LES client peers (default: 20)
--lightkdf Reduce key-derivation RAM & CPU usage at some expense of KDF strength
PERFORMANCE TUNING OPTIONS:
--cache value Megabytes of memory allocated to internal caching (min 16MB / database forced) (default: 128)
--trie-cache-gens value Number of trie node generations to keep in memory (default: 120)
ACCOUNT OPTIONS:
--unlock value Comma separated list of accounts to unlock
--password value Password file to use for non-inteactive password input
API AND CONSOLE OPTIONS:
--rpc Enable the HTTP-RPC server
--rpcaddr value HTTP-RPC server listening interface (default: "localhost")
--rpcport value HTTP-RPC server listening port (default: 8545)
--rpcapi value API's offered over the HTTP-RPC interface (default: "eth,net,web3")
--ws Enable the WS-RPC server
--wsaddr value WS-RPC server listening interface (default: "localhost")
--wsport value WS-RPC server listening port (default: 8546)
--wsapi value API's offered over the WS-RPC interface (default: "eth,net,web3")
--wsorigins value Origins from which to accept websockets requests
--ipcdisable Disable the IPC-RPC server
--ipcapi value APIs offered over the IPC-RPC interface (default: "admin,debug,eth,miner,net,personal,shh,txpool,web3")
--ipcpath "geth.ipc" Filename for IPC socket/pipe within the datadir (explicit paths escape it)
--rpccorsdomain value Comma separated list of domains from which to accept cross origin requests (browser enforced)
--jspath loadScript JavaScript root path for loadScript (default: ".")
--exec value Execute JavaScript statement (only in combination with console/attach)
--preload value Comma separated list of JavaScript files to preload into the console
NETWORKING OPTIONS:
--bootnodes value Comma separated enode URLs for P2P discovery bootstrap
--port value Network listening port (default: 30303)
--maxpeers value Maximum number of network peers (network disabled if set to 0) (default: 25)
--maxpendpeers value Maximum number of pending connection attempts (defaults used if set to 0) (default: 0)
--nat value NAT port mapping mechanism (any|none|upnp|pmp|extip:<IP>) (default: "any")
--nodiscover Disables the peer discovery mechanism (manual peer addition)
--v5disc Enables the experimental RLPx V5 (Topic Discovery) mechanism
--nodekey value P2P node key file
--nodekeyhex value P2P node key as hex (for testing)
MINER OPTIONS:
--mine Enable mining
--minerthreads value Number of CPU threads to use for mining (default: 8)
--autodag Enable automatic DAG pregeneration
--etherbase value Public address for block mining rewards (default = first account created) (default: "0")
--targetgaslimit value Target gas limit sets the artificial target gas floor for the blocks to mine (default: "4712388")
--gasprice value Minimal gas price to accept for mining a transactions (default: "20000000000")
--extradata value Block extra data set by the miner (default = client version)
GAS PRICE ORACLE OPTIONS:
--gpomin value Minimum suggested gas price (default: "20000000000")
--gpomax value Maximum suggested gas price (default: "500000000000")
--gpofull value Full block threshold for gas price calculation (%) (default: 80)
--gpobasedown value Suggested gas price base step down ratio (1/1000) (default: 10)
--gpobaseup value Suggested gas price base step up ratio (1/1000) (default: 100)
--gpobasecf value Suggested gas price base correction factor (%) (default: 110)
VIRTUAL MACHINE OPTIONS:
--jitvm Enable the JIT VM
--forcejit Force the JIT VM to take precedence
--jitcache value Amount of cached JIT VM programs (default: 64)
LOGGING AND DEBUGGING OPTIONS:
--ethstats value Reporting URL of a ethstats service (nodename:secret@host:port)
--metrics Enable metrics collection and reporting
--fakepow Disables proof-of-work verification
--verbosity value Logging verbosity: 0=silent, 1=error, 2=warn, 3=info, 4=core, 5=debug, 6=detail (default: 3)
--vmodule value Per-module verbosity: comma-separated list of <pattern>=<level> (e.g. eth/*=6,p2p=5)
--backtrace value Request a stack trace at a specific logging statement (e.g. "block.go:271") (default: :0)
--pprof Enable the pprof HTTP server
--pprofaddr value pprof HTTP server listening interface (default: "127.0.0.1")
--pprofport value pprof HTTP server listening port (default: 6060)
--memprofilerate value Turn on memory profiling with the given rate (default: 524288)
--blockprofilerate value Turn on block profiling with the given rate (default: 0)
--cpuprofile value Write CPU profile to the given file
--trace value Write execution trace to the given file
EXPERIMENTAL OPTIONS:
--shh Enable Whisper
--natspec Enable NatSpec confirmation notice
MISCELLANEOUS OPTIONS:
--solc value Solidity compiler command to be used (default: "solc")
--netrestrict value Restricts network communication to the given IP networks (CIDR masks)
--help, -h show help
[https://github.com/ethereum/go-ethereum/wiki/Command-Line-Options]
name::
* McsEngl.ethgth'Console@cptIt,
> exit
you exit with Ctrl D or exit
> eth.accounts
['0x407d73d8a49eeb85d32cf465507dd71d507100c1']
> checkAllBalances();
eth.accounts[0]: 0xd1ade25ccd3d550a7eb532ac759cac7be09c2719 balance: 63.11848 ether
eth.accounts[1]: 0xda65665fc30803cb1fb7e6d86691e20b1826dee0 balance: 0 ether
eth.accounts[2]: 0xe470b1a7d2c9c5c6f03bbaa8fa20db6d404a0c32 balance: 1 ether
eth.accounts[3]: 0xf4dd5c3794f1fd0cdc0327a83aa472609c806e99 balance: 6 ether
[https://github.com/ethereum/go-ethereum/wiki/Managing-your-accounts]
> admin.nodeInfo
To check the ports used by geth and also find your enode URI run:
> admin.setSolc("/usr/local/bin/solc")
solc, the solidity compiler commandline interface
Version: 0.2.2-02bb315d/.-Darwin/appleclang/JIT linked to libethereum-1.2.0-8007cef0/.-Darwin/appleclang/JIT
path: /usr/local/bin/solc
name::
* McsEngl.ethclt.METAMASK@cptIt,
* McsEngl.ethnet'metaMask@cptIt,
* McsEngl.MetaMask-ethereum-client@cptIt,
_DESCRIPTION:
I work on an Ethereum based key manager (coming soon, called MetaMask),
[https://medium.com/@danfinlay/daos-are-mere-identities-1f6247456561#.fgtcad2i8]
===
MetaMask is a bridge that allows you to visit the distributed web of tomorrow in your browser today. It allows you to run Ethereum dApps right in your browser without running a full Ethereum node.
MetaMask includes a secure identity vault, providing a user interface to manage your identities on different sites and sign blockchain transactions.
We’re initially building MetaMask as a Chrome plugin, but eventually plan to support Firefox and beyond. If you’re a developer, you can start developing with MetaMask today.
Our mission is to make Ethereum as easy to use for as many people as possible.
[https://metamask.io/#how-it-works]
name::
* McsEngl.ethmmk'Resource@cptIt,
_ADDRESS.WPG:
* https://medium.com/metamask/metamask-3-migration-guide-914b79533cdd#.ytw5dcxi2,
name::
* McsEngl.ethclt.TESTRPC@cptIt,
* McsEngl.ethtestrpc@cptIt,
* McsEngl.testrpc-ethereum-simulator@cptIt,
_DESCRIPTION:
There are many Ethereum clients to choose from.
We recommend using different clients when developing and deploying.
WHEN DEVELOPING
EthereumJS TestRPC: https://github.com/ethereumjs/testrpc
When developing your Truffle-based application, we recommend using the EthereumJS TestRPC. It's a complete blockchain-in-memory that runs only on your development machine. It processes transactions instantly instead of waiting for the default block time – so you can test that your code works quickly – and it tells you immediately when your smart contracts run into errors. It also makes a great client for automated testing, and Truffle knows how to use its special features to speed up test runtime by almost 90%.
[http://truffleframework.com/docs/getting_started/client]
===
There are various compatible clients for the protocol, the most popular being geth, a Go language implementation. However, it’s not the most developer-friendly. The best option I’ve found is the testrpc node (yes, the name sucks). Trust me, it will save you a lot of time. Install it and run it:
$ sudo npm install -g ethereumjs-testrpc
$ testrpc
You should run `testrpc` in a new terminal and leave it running while you develop. Each time you run testrpc, it will generate 10 new addresses with simulated test funds for you to use. This is not real money and you’re safe to try anything with no risk of losing funds.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#262d]
name::
* McsEngl.ethtrpc'Installing@cptIt,
NOTE:
As of version 3.0.2, testrpc requires at least Node 6.9.1 to run - this is because the ethereumjs-vm@2.0.1 dependency is now shipping using ES2015 language features.
[https://github.com/ethereumjs/testrpc]
name::
* McsEngl.ethpgm.Mist-browser (ethmst)@cptIt,
* McsEngl.ethereum-mist@cptIt,
* McsEngl.ethmist@cptIt,
* McsEngl.ethnet'mist@cptIt,
* McsEngl.Mist-browser@cptIt,
_DESCRIPTION:
The Mist browser is the tool of choice to browse and use Dapps.
[https://github.com/ethereum/mist]
===
Ethereum wallet is a wallet, Mist is a browser.
===
The Mist Browser includes the Ethereum Wallet. The Ethereum Wallet is the Mist Browser with the browser function disabled. If you plan on using contracts use the Mist, else if you're just holding ETH, use the Ethereum Wallet.
[https://www.reddit.com/r/ethereum/comments/53nifc/confusion_should_i_download_mist_or_ethereum/d7undsl/]
name::
* McsEngl.ethmst'API@cptIt,
API
mist.platform
mist.menu
mist.menu.setBadge(text)
mist.menu.add(id, options, callback)
mist.menu.update(id [, options] [, callback])
mist.menu.remove(id)
mist.menu.clear()
[https://github.com/ethereum/mist/blob/master/MISTAPI.md#api]
name::
* McsEngl.ethmst'data-folder@cptIt,
The data folder for Mist is stored in other places:
Windows %APPDATA%/Roaming/Mist (\Users\user\AppData\Roaming\Mist)
MacOSX ~/Library/Application Support/Mist
Linux ~/.config/Mist
[https://github.com/ethereum/mist]
name::
* McsEngl.ethmst'resource@cptIt,
_ADDRESS.WPG:
* https://blog.slock.it/the-ethereum-wallet-an-introduction-for-non-devs-9c530f75c018#.n1jtag8gq,
name::
* McsEngl.ethmst'doing@cptIt,
_Usage:
a GUI-based option for creating accounts: The “official” Mist Ethereum wallet.
name::
* McsEngl.ethmst'updating@cptIt,
_DESCRIPTION:
For updating simply download the new version and copy it over the old one (keep a backup of the old one if you want to be sure).
[https://github.com/ethereum/mist]
name::
* McsEngl.ethmst.EVOLUTING@cptIt,
Wallet 0.5.2 (Beta 10)
@frozeman frozeman released this 19 days ago · 69 commits to wallet since this release
This release adds some additional log information to the splash screen and adds a feature to send all ether for an account.
Full list of changes:
Added a send-all functionality to the send page.
Add German (thanks to @ColRad) and Portuguese (@alexvandesande) translation for the wallet!
Added log infos to the splash screen, so users can see what the node is currently doing...
Improved ether display precision on the confirmation screen
Added a check with NTP servers to see if the computer time is correct, if not it shows an error
Increased error timeout
If you should notice that your wallet links lead to a white page, please run the following script in the console:
https://gist.github.com/frozeman/ed41008f4d30900da3e8
This changes all your wallet addresses internally back to lowercase (we introduced that by accident).
[https://github.com/ethereum/mist/releases]
name::
* McsEngl.ethpgm.Parity-browser (ethparity)@cptIt,
* McsEngl.ethnet'parity@cptIt,
* McsEngl.ethparity@cptIt,
* McsEngl.parity-ethnet@cptIt,
_DESCRIPTION:
Parity is a full Ethereum node client and provides a wallet interface in it's web front-end.
[https://github.com/bokkypoobah/TokenTrader/wiki/Frequently-Asked-Questions]
===
http://127.0.0.1:8180/
PARITY
Our Best-in-Class Ethereum Browser
Parity is our fully-featured and integrated Ethereum browser. It is the first in a series of planned software releases by Ethcore and the culmination of more than two years of lessons learnt designing and implementing blockchains by the best minds in the industry. Implemented in Rust, it uses the cutting edge, highly sophisticated hybrid functional language to create a blockchain client which is uniquely high-performance, low-footprint and reliable.
[https://ethcore.io/index.html]
===
Next Generation Ethereum Browser
We've created the world's fastest and lightest Ethereum client and integrated it directly into your web browser. Using it you can access all the features of the Ethereum network including powerful Decentralised applications and the multitude of cryptocurrencies issued on ethereum.
We're happy to release our source code under the GPLv3 licence; we hope you'll have as much fun reading and using our code as we had designing and writing it. You can use it for any of your Ethereum needs.
[https://ethcore.io/parity.html]
name::
* McsEngl.ethparity'Server@cptIt,
_DESCRIPTION:
By default, Parity will also run a JSONRPC server on 127.0.0.1:8545. This is fully configurable and supports a number of RPC APIs.
[https://github.com/ethcore/parity]
name::
* McsEngl.ethparity'Wallet@cptIt,
_DESCRIPTION:
Parity comes with a built-in wallet.
To access Parity Wallet this simply go to http://127.0.0.1:8080/. It includes various functionality allowing you to:
create and manage your Ethereum accounts;
manage your Ether and any Ethereum tokens;
create and register your own tokens;
and much more.
[https://github.com/ethcore/parity]
name::
* McsEngl.ethparity'Directory@cptIt,
name::
* McsEngl.ethparity'Dapps-dir@cptIt,
_WIN:
\Users\synagonism\AppData\Roaming\Parity\Ethereum\dapps
===
mklink /D \Users\synagonism\AppData\Roaming\Parity\Ethereum\dapps\ethcoredap \dirBCN\ethcoredapp\dist
symbolic link created for \Users\synagonism\AppData\Roaming\Parity\Ethereum\dapps\ethcoredap <<===>> \dirBCN\ethcoredapp\dist
_MAC:
$HOME/Library/Application Support/io.parity.ethereum/dapps
name::
* McsEngl.ethparity'Proof-of-Authority@cptIt,
* McsEngl.Proof-of-Authority@cptIt,
_DESCRIPTION:
Proof of Authority Chains
Available only in 1.5 and above.
Parity supports a Proof-of-Authority consensus engine to be used with EVM based chains. Proof-of-Authority is a replacement for Proof-of-Work, which can be used for private chain setups.
It does not depend on nodes solving arbitrarily difficult mathematical problems, but instead uses a hard-configured set of "authorities" - nodes that are explicitly allowed to create new blocks and secure the blockchain. This makes it easier to maintain a private chain and keep the block issuers accountable.
[https://github.com/ethcore/parity/wiki/Proof-of-Authority-Chains]
name::
* McsEngl.ethparity'Problem@cptIt,
_DESCRIPTION:
If you run into an issue while using parity, feel free to file one in this repository or hop on our gitter chat room to ask a question. We are glad to help!
[https://github.com/ethcore/parity]
name::
* McsEngl.ethparity'Resource@cptIt,
_ADDRESS.WPG:
* https://ethcore.io/parity.html,
* https://github.com/ethcore/parity,
=== DOCS:
* https://github.com/ethcore/parity/wiki,
=== CHAT:
* gitter: https://gitter.im/ethcore/parity?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge?
name::
* McsEngl.ethparity'DOING@cptIt,
name::
* McsEngl.ethparity'Configuring@cptIt,
config.toml
# This config should be placed in following path:
# %UserProfile%\AppData\Roaming\Parity\Ethereum\config.toml
[parity]
# Test Network
chain = "ropsten"
[https://ethcore.github.io/parity-config-generator/]
name::
* McsEngl.ethparity.EVOLUTING@cptIt,
_ADDRESS.WPG:
* https://github.com/ethcore/parity/releases,
ethparity.1-5-7.2017-03-07:
arkpar released this 5 days ago · 700 commits to master since this release
This release resolves a single issue with failing auto-updates.
[https://github.com/ethcore/parity/releases/tag/v1.5.7]
name::
* McsEngl.ethpgm.TOKEN (ethtknbsr)@cptIt,
* McsEngl.ethtknbsr@cptIt,
_DESCRIPTION:
Access An Open Financial System
Token is a browser for the Ethereum network that provides universal access to financial services.
[https://www.tokenbrowser.com/]
name::
* McsEngl.ethtknbsr'Resource@cptIt,
_ADDRESS.WPG:
* {2017-04-18} Introducing Token: https://blog.tokenbrowser.com/introducing-token-2f2ceeab6d4c,
name::
* McsEngl.ethpgm.TRUFFLE (ethtfl)@cptIt,
* McsEngl.ethtfl@cptIt,
* McsEngl.truffle@cptIt,
* McsEngl.truffle-for-ethereum@cptIt,
_DESCRIPTION:
Truffle is a development environment, testing framework and asset pipeline for Ethereum, aiming to make life as an Ethereum developer easier.
[http://truffleframework.com/docs//]
===
Truffle is a development environment, testing framework and asset pipeline for Ethereum, aiming to make life as an Ethereum developer easier. With Truffle, you get:
Built-in smart contract compilation, linking, deployment and binary management.
Automated contract testing with Mocha and Chai.
Configurable build pipeline with support for custom build processes.
Scriptable deployment & migrations framework.
Network management for deploying to many public & private networks.
Interactive console for direct contract communication.
Instant rebuilding of assets during development.
External script runner that executes scripts within a Truffle environment.
[https://github.com/ConsenSys/truffle]
name::
* McsEngl.ethtfl'Synopsis@cptIt,
_DESCRIPTION:
PS \WINDOWS\system32> truffle -h
Truffle v3.1.2 - a development framework for Ethereum
Usage: truffle <command> [options]
Commands:
init Initialize new Ethereum project with example contracts and tests
compile Compile contract source files
migrate Run migrations to deploy contracts
build Execute build pipeline (if configuration present)
test Run Mocha and Solidity tests
console Run a console with contract abstractions and commands available
create Helper to create new contracts, migrations and tests
install Install a package from the Ethereum Package Registry
publish Publish a package to the Ethereum Package Registry
networks Show addresses for deployed contracts on each network
watch Watch filesystem for changes and rebuild the project automatically
serve Serve the build directory on localhost and watch for changes
exec Execute a JS module within this Truffle environment
version Show version number and exit
See more at http://truffleframework.com/docs
name::
* McsEngl.ethtfl'Command@cptIt,
* McsEngl.ethtflcmd@cptIt,
_SPECIFIC:
Commands:
init Initialize new Ethereum project with example contracts and tests
compile Compile contract source files
migrate Run migrations to deploy contracts
build Execute build pipeline (if configuration present)
test Run Mocha and Solidity tests
console Run a console with contract abstractions and commands available
create Helper to create new contracts, migrations and tests
install Install a package from the Ethereum Package Registry
publish Publish a package to the Ethereum Package Registry
networks Show addresses for deployed contracts on each network
watch Watch filesystem for changes and rebuild the project automatically
serve Serve the build directory on localhost and watch for changes
exec Execute a JS module within this Truffle environment
version Show version number and exit
name::
* McsEngl.ethtfl'Dapp@cptIt,
name::
* McsEngl.ethtfl'Dapp-structure@cptIt,
_STRUCTURE:
Once completed, you'll now have a project structure with the following items:
contracts/ - directory where Truffle expects to find solidity contracts.
migrations/ - directory to place scriptable deployment files.
test/ - location of test files for testing your application and contracts.
truffle.js - your main Truffle configuration file.
[http://truffleframework.com/docs/getting_started/project#initialize-your-project]
name::
* McsEngl.ethtfl'Directory@cptIt,
name::
* McsEngl.ethtfl'DirBuild@cptIt,
name::
* McsEngl.ethtfl'Artifact@cptIt,
_DESCRIPTION:
Artifacts of your compilation will be placed in the ./build/contracts directory, relative to your project.
This directory will be created if it does not exist.
These artifacts are integral to the inner workings of Truffle, and they play and important part to the successful deployment of your application.
You should not edit these files by hand as they'll be overwritten by contract compilation and deployment.
[http://truffleframework.com/docs/getting_started/compile]
name::
* McsEngl.ethtfl'DirContracts@cptIt,
_DESCRIPTION:
contracts/ should contain smart contracts written in Solidity,
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
name::
* McsEngl.ethtfl'DirMigrations@cptIt,
_DESCRIPTION:
migrations/ should contain scriptable deployment files.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
name::
* McsEngl.ethtfl'DirTests@cptIt,
_DESCRIPTION:
should contain unit tests written using Mocha and Chai,
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
name::
* McsEngl.ethtfl'File@cptIt,
name::
* McsEngl.ethtfl'FilMigration@cptIt,
_DESCRIPTION:
Migrations are Javascript files that help you deploy contracts to the Ethereum network.
These files are responsible for staging your deployment tasks, and they're written under the assumption that your deployment needs will change over time.
As your project evolves, you'll create new migration scripts to further this evolution on the blockchain.
A history of previously run migrations is recorded on-chain through a special Migrations contract, detailed below.
[http://truffleframework.com/docs/getting_started/migrations]
1_initial_migration.js:
var Migrations = artifacts.require("./Migrations.sol");
module.exports = function(deployer) {
deployer.deploy(Migrations);
};
name::
* McsEngl.ethtfl'FilTruffle.js@cptIt,
* McsEngl.ethtfl'truffle.js@cptIt,
_DESCRIPTION:
truffle.js is the main configuration file used by Truffle.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
===
module.exports =
{
networks: {
development: {
host: "localhost",
port: 8545,
network_id: "*" // Match any network id
}
}
};
name::
* McsEngl.ethtfl'Problem@cptIt,
truffle_migrate_test_frozen_testrpc:
Parity client run on background. We have to kill it.
name::
* McsEngl.ethtfl'Resource@cptIt,
_ADDRESS.WPG:
* http://truffleframework.com//
* http://truffleframework.com/docs//
* https://github.com/trufflesuite,
=== tutorial
* http://truffleframework.com/tutorials/truffle-and-metamask,
* https://steemit.com/ethereum/@brennanhm/ethereum-smart-contract-testing-installing-truffle-and-testrpc,
* https://leanpub.com/decentralizedapplicationswithethereum,
name::
* McsEngl.ethtfl'doing@cptIt,
name::
* McsEngl.ethtfl'Installing-truffle@cptIt,
_DESCRIPTION:
COMMAND
$ npm install -g truffle
REQUIREMENTS
NodeJS 5.0+ recommended.
Windows, Linux or Mac OS X
Truffle also requires that you have a running Ethereum client which supports the standard JSON RPC API (nearly all of them). There are many to choose from, and some better than others for development. We'll discuss them in detail in the next section.
RECOMMENDATIONS FOR WINDOWS
If you're a Windows user, we recommend installing and using Truffle via Windows PowerShell or Git BASH. These two shells provide features far beyond the standard Command Prompt, and will make your life on the command line much easier.
[http://truffleframework.com/docs/getting_started/installation]
===
RESOLVING NAMING CONFLICTS ON WINDOWS
When using the Command Prompt on Windows, the default configuration file name can cause a conflict with the truffle executable. If this is the case, we recommend using Windows PowerShell or Git BASH as these shells do not have this conflict. Alternatively, you can rename the configuration file to truffle-config.js to avoid this conflict.
[http://truffleframework.com/docs/advanced/configuration#resolving-naming-conflicts-on-windows]
name::
* McsEngl.ethpgm.MINING@cptIt,
* McsEngl.ethpgm.mining@cptIt,
name::
* McsEngl.ethpgm.Ethminer@cptIt,
* McsEngl.ethminer@cptIt,
* McsEngl.ethminer-genoil@cptIt,
* McsEngl.Genoil's-CUDA-miner@cptIt,
_DESCRIPTION:
ethminer-genoil
What is ethminer-0.9.41-genoil-1.x.x?
Formerly known as Genoil's CUDA miner, ethminer-0.9.41-genoil-1.x.x is a fork of the stock ethminer version 0.9.41. While native CUDA support is its most significant difference, it has the following additional features:
- realistic benchmarking against arbitrary epoch/DAG/blocknumber
- on-GPU DAG generation (no more DAG files on disk)
- stratum mining without proxy
- OpenCL devices picking
- farm failover (getwork + stratum)
[https://github.com/Genoil/cpp-ethereum]
===
Ethminer: A standalone miner. This can be used to mine or benchmark a mining set-up. It is compatible with eth, geth, and pyethereum. Check out the Mining page for more information.
[https://ethereum-homestead.readthedocs.io/en/latest/frequently-asked-questions/frequently-asked-questions.html#i-have-heard-of-ethereum-but-what-are-geth-mist-ethminer-mix]
name::
* McsEngl.ethpgm.sgminer@cptIt,
* McsEngl.sgminer@cptIt,
_DESCIRPTION:
Scrypt GPU miner
[https://github.com/sgminer-dev/sgminer]
name::
* McsEngl.ethnet'program.DAPP (ethdap)@cptIt,
* McsEngl.bapp.ethereum@cptIt,
* McsEngl.dapp.ethereum@cptIt,
* McsEngl.ethbapp@cptIt,
* McsEngl.ethdap@cptIt,
* McsEngl.ethdapp@cptIt,
* McsEngl.ethereum-application@cptIt,
* McsEngl.ethereum-blockchain-application@cptIt,
* McsEngl.ethnet'dapp@cptIt,
_DESCRIPTION:
What is the difference between smart contracts and dapps?
Anupam Vijayvergia
Written Nov 2
In simplest terms Dapps or rather decentralised apps is an app running on a decentralised network. Dapps has its backend and can have a front end code or user interface written on any language. However backend code runs on a decentralised network.
Smart contracts is a piece of code that is meant to do a specific purpose which is part of a decentralised application.
[https://www.quora.com/What-is-the-difference-between-smart-contracts-and-dapps/answer/Anupam-Vijayvergia?srid=uJVpm]
===
The Ethereum platform itself is featureless or value-agnostic. Similar to programming languages, it is up to entrepreneurs and developers to decide what it should be used for. However, it is clear that certain application types benefit more than others from Ethereum’s capabilities. Specifically, ethereum is suited for applications that automate direct interaction between peers or facilitate coordinated group action across a network. For instance, applications for coordinating peer-to-peer marketplaces, or the automation of complex financial contracts. Bitcoin allows for individuals to exchange cash without involving any middlemen like financial institutions, banks, or governments. Ethereum’s impact may be more far-reaching. In theory, financial interactions or exchanges of any complexity could be carried out automatically and reliably using code running on Ethereum. Beyond financial applications, any environments where trust, security, and permanence are important – for instance, asset-registries, voting, governance, and the internet of things – could be massively impacted by the Ethereum platform.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#what-is-ethereum]
name::
* McsEngl.ethdap'Backend (contract)@cptIt,
* McsEngl.ethdap'contract@cptIt,
name::
* McsEngl.ethdap'Structure@cptIt,
_DESCRIPTION:
A dapp ('decentralized app') consists of two parts: a frontend, written in HTML or QML, and a backend (think of it as the 'database' for your frontend). We'll focus here on an HTML dapp.
[https://forum.ethereum.org/discussion/1402/how-to-get-started-your-first-dapp-under-one-hour]
name::
* McsEngl.ethdap'tool.EMBARK (ethebk)@cptIt,
* McsEngl.Embark-ethdap-tool@cptIt,
_DESCRIPTION:
Framework for serverless Decentralized Applications using Ethereum, IPFS and other platforms
[https://github.com/iurimatias/embark-framework]
name::
* McsEngl.ethebk'Dapp-structure@cptIt,
_DESCRIPTION:
app/
|___ contracts/#solidity or serpent contracts
|___ html/
|___ css/
|___ js/
config/
|___ blockchain.json#environments configuration
|___ contracts.json #contracts configuration
test/
|___#contracts tests
Solidity/Serpent files in the contracts directory will automatically be deployed with embark run. Changes in any files will automatically be reflected in app, changes to contracts will result in a redeployment and update of their JS Bindings
[https://github.com/iurimatias/embark-framework#dapp-structure]
name::
* McsEngl.ethebk'EmbarkJS@cptIt,
_DESCRIPTION:
EmbarkJS is a javascript library meant to abstract and facilitate the development of DApps.
[https://github.com/iurimatias/embark-framework#embarkjs]
name::
* McsEngl.ethdap'Resource@cptIt,
_ADDRESS.WPG:
* http://dapps.ethercasts.com//
* https://blog.ethereum.org/2016/07/12/build-server-less-applications-mist//
=== tutorial
* https://medium.com/@mvmurthy/full-stack-hello-world-voting-ethereum-dapp-tutorial-part-1-40d2d0d807c2#.4b357annh,
=== tool:
* https://github.com/uzyn/ethereum-webpack-example-dapp,
* https://github.com/dapphub/dapple,
name::
* McsEngl.ethdap'DOING@cptIt,
name::
* McsEngl.ethdap.specific@cptIt,
* McsEngl.ethdap.specific@cptIt,
_SPECIFIC:
* https://github.com/ethereum/dapp-bin,
===
* CROWDFUNDING,
* EXCHANGE,
* FINANCIAL,
* STORAGE,
* VOTING,
* WEB_BASED,
===
* Aragon,
* Augur,
* Digix,
* Maker,
* Plutus,
* Swarm#ql:idEthSwarm#
name::
* McsEngl.ethdap.WEB-BASED@cptIt,
* McsEngl.ethdap.webapp@cptIt,
_DESCRIPTION:
To build web based dapps, Ethereum comes with a handy javascript library called web3.js which connects to your blockchain node. So you can just include this library in your famous js framework like reactjs, angularjs etc and start building.
[https://medium.com/@mvmurthy/ethereum-for-web-developers-890be23d1d0c#.ruvn38p8k]
_ADDRESS.WPG:
* http://hypernephelist.com/2016/06/21/a-simple-smart-contract-ui-web3.html,
name::
* McsEngl.ethdap.Aragon@cptIt,
* McsEngl.Aragon-dApp@cptIt,
_DESCRIPTION:
1.1. About Aragon Core
Aragon is a dApp that lets anyone create and manage any kind of organization (companies, open source projects, NGOs, foundations, hedge funds...) on the Ethereum blockchain.
Aragon implements basic features of an organization like a cap table, token transfers, voting, role assignments, fundraising, and accounting.
The behavior of an Aragon organization is easily customized by changing the bylaws.
In addition, Aragon organizations are extensible through third party modules that interact with the organizations' contracts.
[https://github.com/AragonOne/whitepaper/raw/master/Aragon%20Whitepaper.pdf]
_GENERIC:
* Ethereum-DAO-dApp#ql:idEthdapDao#
_ADDRESS.WPG:
* https://aragon.one//
* https://github.com/AragonOne/whitepaper/raw/master/Aragon%20Whitepaper.pdf,
* {2017-04-21} Spain’s Aragon Joins Ethereum Startups Eyeing Token Sale Glory: https://cointelegraph.com/news/spains-aragon-joins-ethereum-startups-eyeing-token-sale-glory,
name::
* McsEngl.ethdap.Ethlance@cptIt,
* McsEngl.ethlance@cptIt,
_DESCRIPTION:
Ethlance is a first of its kind platform for job market, built entirely on blockchain and using only cryptocurrency for payments. Thanks to those technologies, platform can sustainably run with 0% service fees. Ethlance will never take cut from transactions between freelancers and employers.
We're running on public Ethereum blockchain with front-end source files written in Clojurescript and served from decentralised file storage IPFS. Ethlance is completely open-source and you can find its code on github.com/madvas/ethlance. If you found a bug, please don't hesitate to open an issue there.
If you're unsure how to use Ethereum, please see How it works page
Ethlance backend logic consists of 8 smart-contracts, deployed on following addresses:
EthlanceUser at 0x85c1b0dc9e3443e06e5f1b09844631378825bb14
EthlanceJob at 0x3d3bb143a6ee72deb9646c14b403ccc3f6e3c2c8
EthlanceContract at 0x12f4abc6c7ae413618d348bfdc855bca8654037d
EthlanceInvoice at 0x917db76c206f744274375428e261fa6521ac1b05
EthlanceConfig at 0x613e3395622eabdb2b12f9b77a0e5eb2b9a57f36
EthlanceDB at 0x5371a8d8d8a86c76de935821ad1a3e9b908cfced
EthlanceViews at 0xb7b882d1ea87da8506ba10bfbe8b751246bc3259
EthlanceSearch at 0x8c8cf5f0fe7ce048baa9573278c4b44b7a8646e4
[http://ethlance.com/#/about]
name::
* McsEngl.ethdap.IDEX@cptIt,
_DESCRIPTION:
What is IDEX?
IDEX is a distributed cryptocurrency exchange powered by Ethereum smart contracts that provides the safest and most secure way to trade Ethereum tokens.
[http://idex.market/]
name::
* McsEngl.ethdap.DAO (ethdapDao)@cptIt,
* McsEngl.DAO-ethereum-dapp@cptIt,
* McsEngl.ethDAOdapp@cptIt,
* McsEngl.ethdapp.DAO@cptIt,
* McsEngl.Decentralized-Autonomous-Organization-dapp@cptIt,
_DESCRIPTION:
DAO is a-very-confused-concept.
The-fiasko of 'THE-DAO' is-not-unrelated with it.
DAO is an-entity very young and not yet stable.
Naturaly the-concept of a-DAO is double fluid.
A-DAO is an-organization, and an-organization has humans.
A-DAO is autonomous in the-sense that its managing-rules run autonomously as the-members have-set them and not as an-individual thinks.
Ethereum-smart-contracs COULD become the-managing-rules.
But "everything flows" and the-managing-rules must change and be-improved by the-human-members in a-decentralized-manner.
Then the-dao must-have builtin a-decentralized-governance-system.
Here I present the-dapp of a-DAO which COULD run autonomously the-managing-rules.
[hmnSngo.2017-04-20]
===
A DAO is purely software: in itself it does not have the capabilities to manufacture a product, write code, develop hardware or sweep the streets.
It requires actors in the physical world for this purpose, called Contractors.
[https://blog.slock.it/a-primer-to-the-decentralized-autonomous-organization-dao-69fb125bd3cd#.9wdemu25y]
===
The term decentralized autonomous organization (DAO) is often used in the same breath as "smart contract" or "blockchain".
DAOs are touted as a new form of legal structure in which ownership, management and control are automated and human involvement is limited or removed, based on a previously agreed upon set of rules.
[ http://www.coindesk.com/how-to-sue-a-decentralized-autonomous-organization//]
name::
* McsEngl.ethdapDao'Fund@cptIt,
* McsEngl.ethdao'ether@cptIt,
name::
* McsEngl.ethdapDao'Token@cptIt,
_DESCRIPTION:
Would-be participants in the DAO can for a period of time acquire DAO tokens by sending ETH to a DAO. These tokens will give them the right to vote on Proposals (proportional to the number of tokens acquired) as well the opportunity to receive rewards generated by the output of the work from the Contractors’ Proposals.
[https://blog.slock.it/a-primer-to-the-decentralized-autonomous-organization-dao-69fb125bd3cd#.9wdemu25y]
name::
* McsEngl.ethdapDao'Code@cptIt,
* McsEngl.ethdao'contract@cptIt,
* McsEngl.ethdao'smart-contract@cptIt,
name::
* McsEngl.ethdapDao'Law@cptIt,
* McsEngl.ethdao'law@cptIt,
_DESCRIPTION:
A word of caution, at the outset: the legal status of DAOs remains the subject of active and vigorous debate and discussion.
Not everyone shares the same definition.
[https://download.slock.it/public/DAO/WhitePaper.pdf]
name::
* McsEngl.ethdapDao'Member@cptIt,
* McsEngl.ethdao'participant@cptIt,
name::
* McsEngl.ethdapDao'Contractor@cptIt,
_DESCRIPTION:
A DAO stores ether and other Ethereum based tokens and transmits them based on the DAO’s code.
It does not do much else.
It cannot build a product, write code or develop hardware.
It requires a “Contractor” to accomplish these and other goals.
A DAO selects a Contractor by accepting a Contractor’s proposal.
[https://download.slock.it/public/DAO/WhitePaper.pdf]
===
A DAO is purely software: in itself it does not have the capabilities to manufacture a product, write code, develop hardware or sweep the streets.
It requires actors in the physical world for this purpose, called Contractors.
[https://blog.slock.it/a-primer-to-the-decentralized-autonomous-organization-dao-69fb125bd3cd#.9wdemu25y]
name::
* McsEngl.ethdapDao'Proposal@cptIt,
_DESCRIPTION:
Contractors submit Proposals for the development of product or services -- these take the form of smart contracts backed by plain English descriptions. To guarantee the Contractors will not act against the interest of the DAO, a group of signatories validates Contractors’ Proposals then add them to the list of addresses authorized to receive ether (ETH) from the DAO.
[https://blog.slock.it/a-primer-to-the-decentralized-autonomous-organization-dao-69fb125bd3cd#.9wdemu25y]
name::
* McsEngl.ethdapDao'Curator@cptIt,
_DESCRIPTION:
Contractors submit Proposals for the development of product or services -- these take the form of smart contracts backed by plain English descriptions. To guarantee the Contractors will not act against the interest of the DAO, a group of signatories validates Contractors’ Proposals then add them to the list of addresses authorized to receive ether (ETH) from the DAO.
This group of signatories is collectively referred to as a Curator. To maintain decentralization, the Curator can be fired by the DAO at any time and for any reason.
[https://blog.slock.it/a-primer-to-the-decentralized-autonomous-organization-dao-69fb125bd3cd#.9wdemu25y]
name::
* McsEngl.ethdapDao'Security@cptIt,
_DESCRIPTION:
We are making the generic DAO model we developed free and open source, so it can be reused by anyone wishing to put together a transparent organization where governance and decision making systems are immutably programmed in the Blockchain. This code been reviewed by hundreds of pairs of eyes from our community and by one of the most respected auditing companies in the world, Deja Vu.
This standard DAO framework is simple, decentralized and 100% secure.
[https://blog.slock.it/a-primer-to-the-decentralized-autonomous-organization-dao-69fb125bd3cd#.9wdemu25y]
name::
* McsEngl.ethdapDao'Resource@cptIt,
_ADDRESS.WPG:
* https://ethereum.org/dao,
* http://www.coindesk.com/how-to-sue-a-decentralized-autonomous-organization//
* {2014-05-06} Vitalik-Buterin: DAOs, DACs, DAs and More: An Incomplete Terminology Guide: https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide//
===
* https://slock.it/dao.html,
* code: https://github.com/slockit/DAO//
* https://github.com/FelixA/DAOhub,
===
* {2016-05-01+7} White Paper, https://blog.slock.it/daos-or-how-to-replace-both-the-kickstarter-and-token-presale-models-1b2b8898d6e7#.u8cp2obe5.
* {2016-05-03} Stephan Tual
Slock.it Founder, Blockchain and Smart Contract Expert, Former CCO Ethereum
Mar 3, 2016 Unlisted
A Primer to Decentralized Autonomous Organizations (DAOs)
https://blog.slock.it/a-primer-to-the-decentralized-autonomous-organization-dao-69fb125bd3cd#.v07q75f4w,
* {2016-05-01} Stephan Tual
Slock.it Founder, Blockchain and Smart Contract Expert, Former CCO Ethereum
Mar 1, 2016 Unlisted
DAOs, or how to Replace Obsolete Governance Models
https://blog.slock.it/daos-or-how-to-replace-both-the-kickstarter-and-token-presale-models-1b2b8898d6e7#.u8cp2obe5,
name::
* McsEngl.ethdapDao'resource.Whitepaper@cptIt,
_ADDRESS.WPG:
* https://download.slock.it/public/DAO/WhitePaper.pdf,
DECENTRALIZED AUTONOMOUS ORGANIZATION TO AUTOMATE GOVERNANCE
FINAL DRAFT - UNDER REVIEW
CHRISTOPH JENTZSCH
FOUNDER & CTO, SLOCK.IT
CHRISTOPH.JENTZSCH@SLOCK.IT
This paper describes the first implementation of Decentralized Autonomous Organization (DAO) code to automate organizational governance and decision-making.
The code can be used by individuals working together collaboratively outside of a traditional corporate form.
It can also be used by a registered corporate entity to automate formal governance rules contained in corporate bylaws or imposed by law.
First the DAO concept is described, then minority rights is discussed, and a solution to a “robbing the minority” attack vector is proposed.
Finally, a practical implementation of a first generation DAO entity is provided using smart contracts written in Solidity on the Ethereum blockchain.
Corporate entities of all kinds are governed by rules that describe permitted and proscribed conduct.
These rules may exist as private contracts (like bylaws or shareholder agreements) between corporate owners.
They may also be imposed by law in addition to or in the absence of a written agreement between participants.
Historically, corporations have only been able to act through people (or through corporate entities that were themselves ultimately controlled by people).
This presents two simple and fundamental problems.
Whatever a private contract or public law require: (1) people do not always follow the rules and (2) people do not always agree what the rules actually require.
Collaboration without a corporate form does not solve these problems, necessarily, and it may introduce others.
In the absence of a corporate form, an explicit written agreement is substituted for unclear informal “understandings” and the legal protections provided by a corporate form will not be available.
Rule-breaking within an organization not always obvious, and motives may not matter to stakeholders once their money has been lost.
While bad behavior may make a corporation or its management civilly or criminally liable, punishment can come as little comfort to an investor who has already lost their money.
Crowdfunding (Massolution-[2015]#ql:idMassolution2015#) amplifies the problem.
On the one hand, it has made it easier for small contributors to invest in large projects, and it has also made it possible for entrepreneurs to receive financial support that might not have been easily available in the past.
On the other hand, small investors remain vulnerable to financial mismanagement or outright fraud, and because they have a small stake in a venture, they may lack power to identify problems, participate in governance decisions, or to easily recover their investment (Knibbs-[2015]#ql:idKnibbs2015#, Biggs-[2015]#ql:idBiggs2015#).
At the same time, corporate leadership and management may be accused of malfeasance or mismanagement when they believe that they have acted in good faith, based on their understanding of their obligations and interpretation of applicable rules.
This paper presents a potential solution using Ethereum, (Buterin-[2013]#ql:idButerin2013#, Wood-[2014]#ql:idWood2014#) a blockchain technology which integrates a Turing complete programming language with smart contract processing functionality.
This paper illustrates a method that for the first time allows the creation of organizations in which (1) participants maintain direct real-time control of contributed funds and (2) governance rules are formalized, automated and enforced using software.
Specifically, standard smart contract code (Szabo-[1997]#ql:idSzabo1997#, Miller-[1997]#ql:idMiller1997#) has been written that can be used to form a Decentralized Autonomous Organization (DAO) on the Ethereum blockchain.
This paper explains how a DAO’s code works, focusing on some basic formation and governance features, including structure, creation and voting rights.
First a DAO’s Creation Phase and basic functionality are described.
Then minority owner rights are discussed and a solution to the “Majority Robbing the Minority Attack” problem is proposed: the “DAO split.”
The smart contract code is then explored in detail, and conclude with an explanation and detailed specification of the “DAO split.”
The code for the smart contracts is located at: https://github.com/slockit/DAO//
A word of caution, at the outset: the legal status of DAOs remains the subject of active and vigorous debate and discussion.
Not everyone shares the same definition.
Some have said that they are autonomous code and can operate independently of legal systems; others have said that they must be owned or operate by humans or human created entities.
There will be many uses cases, and the DAO code will develop over time.
Ultimately, how a DAO functions and its legal status will depend on many factors, including how DAO code is used, where it is used, and who uses it.
This paper does not speculate about the legal status of DAOs worldwide.
This paper is not intended to offer legal advice or conclusions.
Anyone who uses DAO code will do so at their own risk.
DAO code is written in the “Solidity” programming language.
A DAO is activated by deployment on the Ethereum blockchain.
Once deployed, a DAO’s code requires “ether” to engage in transactions on Ethereum.
Ether is the digital fuel that powers the Ethereum network.
Without ether, a DAO can not do anything so a DAO’s first order of business is to receive ether.
After a DAO’s code is deployed, ether may be sent to the DAO’s smart contract address during an initial Creation Phase which is defined in the DAO’s code.
In exchange for ether, a DAO’s code creates tokens that are assigned to the account of the person who sent the ether.
The token grants its holder voting and ownership rights.
The number of tokens created is proportional to the amount of ether transferred.
Token price varies over time (see section-5#ql:idEthddwpr5#).
Token ownership is freely transferable on the Ethereum blockchain, when the Creation Phase has ended.
A minimum DAO Creation goal and Creation Phase time-period are set as parameters in a DAO’s code at the time of deployment.
If the minimum DAO Creation goal is not reached at the close of the Creation Phase, all ether is returned.
After the Creation Phase has ended, the total ether raised is denoted by Ξraised and the total amount of tokens created is denoted by Ttotal.
A DAO stores ether and other Ethereum based tokens and transmits them based on the DAO’s code.
It does not do much else.
It cannot build a product, write code or develop hardware.
It requires a “Contractor” to accomplish these and other goals.
A DAO selects a Contractor by accepting a Contractor’s proposal.
Any DAO Token Holder may become a Contractor by submitting proposals to use a DAO’s ether, denoted by Ξtransfer.
If a proposal is approved, the DAO transmits ether to a smart contract representing the proposed project.
Such smart contracts can be parameterized and enable a DAO to interact with and influence the project it chose to support.
An example of such an agreement between a DAO and a project to be funded can be found in the-appendix-(A.4)#ql:idEthddwprA4#.
Members of a DAO cast votes weighted by the amount of tokens they control.
Tokens are divisible, indistinguishable and can easily be transferred between accounts.
Within the contracts, the individual actions of members, cannot be directly determined.
There is a set time frame tp to debate and vote on any given proposal.
In our example, this time frame is set by the creator of the proposal, and is required to be at least two weeks for a regular proposal.
After tp has passed, any token holder can call a function in the DAO contract that will verify that the majority voted in favor of the proposal and that quorum was reached; the function will execute the proposal if this is the case.
If this is not the case, the proposal will be closed.
# idEthddwpreqn1#The minimum quorum represents the minimum number of tokens required for a vote to be valid, is denoted by qmin, and calculated as follows:
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgEthddwprEqn1.png!# (eqn.1)
Where d is the minQuorumDivisor.
This parameter’s default value is 5, but it will double in the case the quorum has not been met for over a year.
ΞDAO is the amount of ether owned by a DAO and RDAO is the amount of reward tokens owned by this DAO, as explained in section-7#ql:idEthddwpr7# (also see rewardToken in A.3#ql:idEthddwprA3#).
The sum ΞDAO + RDAO is equal to the amount of ether used to Create DAO tokens plus the rewards received or said another way, the total amount of ether a DAO has ever received.
This means, initially, a quorum of 20% of all tokens is required for any proposal to pass.
In the event Ξtransfer equals the amount of ether a DAO has ever received, then a quorum of 53.33% is required.
In order to prevent “proposal spam,” a minimal deposit can be required to be paid when creating a proposal, which gets refunded if quorum is achieved.
If quorum is not achieved, the DAO keeps the proposal deposit.
The value of the proposal deposit can be changed from the default value by the DAO through another proposal.
Throughout this paper, Ξ always represents an amount of ether in its base unit wei.
This is defined as 1 Wei = 10^-18 Ether (Wood-[2014]#ql:idWood2014#).
Similarly, DAO tokens are denoted with T and always represent the amount of DAO tokens in its base unit, defined as 10^-16 DAO token.
Minority owner rights can be a problem in any corporate form.
Minority rights may be protected or addressed by provisions in corporate governance documents or by statute or judge-made law.
But many of these solutions fail because minority owners may lack voting rights or the ability to “vote with their feet” and easily retrieve their capital.
This paper presents a solution to this problem in the DAO’s code.
A problem every DAO has to mitigate is the ability for the majority to rob the minority by changing governance and ownership rules after DAO formation.
For example, an attacker with 51% of the tokens, acquired either during the fueling period or created afterwards, could make a proposal to send all the funds to themselves.
Since they would hold the majority of the tokens, they would always be able to pass their proposals.
To prevent this, the minority must always have the ability to retrieve their portion of the funds.
Our solution is to allow a DAO to split into two.
If an individual, or a group of token holders, disagree with a proposal and want to retrieve their portion of the ether before the proposal gets executed, they can submit and approve a special type of proposal to form a new DAO.
The token holders that voted for this proposal can then split the DAO moving their portion of the ether to this new DAO, leaving the rest alone only able to spend their own ether.
This idea originates from a blog post by Vitalik Buterin (Buterin-[2015]#ql:idButerin2015#).
A problem this simple fix doesn’t address is voter apathy:
some token holders might not be actively involved in their DAO and might not follow proposals closely.
An attacker could use this to their advantage.
Even though the minority has the chance to retrieve their funds and split the DAO, some could be unaware of the situation and fail to act.
For a DAO to be considered safe, it is required that inactive token holders must also be protected from losing their ether.
Our proposed solution is implemented by limiting each individual DAO to a single Curator.
This Curator controls the list of addresses that can receive ether from the DAO, across all proposals.
This gives the Curator of a DAO considerable power.
To prevent the abuse of this power, it is possible for a DAO to vote for a new Curator, which may result in a split of the DAO as described above.
Any token holder can make a proposal to vote for a new Curator.
In effect, even a single token holder is able to both retrieve their remaining portion of ether and maintain their right to any future rewards associated to their previous contribution, as these will be sent to the new DAO automatically.
Rewards are defined as any ether received by a DAO generated from products the DAO funded so far and are explained in further detail in section-7#ql:idEthddwpr7#.
The process of choosing a new Curator is as follows:
Any token holder can submit a proposal for a new Curator.
In this case, no proposal deposit is required, because an attacker could vote for an extremely high deposit, preventing any splits.
The debating period for this proposal is 7 days.
This is 7 days less than the minimum required for regular proposals, allowing anyone to retrieve their funds before a potentially malicious proposal goes through.
There is no quorum requirement, so that every token holder has the ability to split into their own DAO.
The debating period is used to discuss (on or off-chain) the new Curator and conduct a first vote that’s non-binding.
After this first vote, token holders can confirm its results or not.
In the case a majority opts to keep the original Curator, the minority can either keep the original Curator in order to avoid a split, or inversely they can confirm their vote for a new Curator and move their portion of the ether to a new DAO.
# idEthddwpreqn2-3#DAO Token Creation rate decreases over time.
This reflects an assumption that early acts of DAO Creation have greater risk, as they may have less information about the potential success of the DAO and do not know whether what contribution will lead to full fueling of the DAO.
The DAO described in this paper has the following Creation schedule:
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgEthddwprEqn2-3.png!# (eqn.2-3)
Here t is the unix time in seconds, tc is the closing time of the fueling period (see A.2#ql:idEthddwprA2# closingTime), w is a week in seconds and d a day in seconds.
Hence the number of tokens (in its base unit) each person Creates is calculated as: P(t)· Ξc.
Here Ξc stands for the amount of ether sent to fuel a DAO, denoted in wei.
This results in a constant Creation rate in the beginning, until 2 weeks before the end of the DAO Creation Phase.
At this time the amount of ether required to Create DAO tokens increases daily by 0.05 Ξc per base unit of DAO token.
Until 4 days before the closing time when there will be a constant Creation rate of 1.5 Ξc per base unit of DAO token.
Creation rate decreases during the Creation Phase could lead to a situation where a single contributor, having Created DAO tokens at the initial Creation rate, could split the DAO immediately after the Creation Phase ends, thereby receiving more ether than they put in due to other contributors having fueled a DAO at a higher Creation rate (idGreen2016).
In order to avoid that possibility, all ether that is used to fuel a DAO above the initial Creation rate, will be sent to an extra account.
Denoted as extraBalance in A.2#ql:idEthddwprA2#.
This ether can be sent back to the DAO through a proposal after the DAO has spent at least this amount of ether.
This rule is implemented in the internal function isRecipientAllowed in section-6.3#ql:idEthddwpr63#.
This section will detail the smart contracts implementing the aforementioned concept.
The contracts are written in the programming language Solidity (Reitwiessner-and-Wood-[2015]#ql:idReitwWood2015#).
Each contract has member variables and functions which can be externally called by sending a transaction to the Ethereum network with the DAO contract address as the recipient and the method ID (optional with parameters) as data.
This section will discuss the meaning of the variables and the functions in detail.
The main contract is called ’DAO’.
It defines the inner workings of the DAO and it derives the member variables and functions from ’Token’ and ’TokenCreation’.
Token defines the inner workings of the DAO Token and TokenCreation defines how the DAO token is created by fueling the DAO with ether.
In addition to these three contracts, there is the ’ManagedAccount’ contract, which acts as a helper contract to store the rewards which are to be distributed to the token holders and the extraBalance (see section-5#ql:idEthddwpr5#).
The contract ’SampleOffer’ (A.4#ql:idEthddwprA4#) is an example of what a proposal from a contractor to the DAO could look like.
contract TokenInterface {
mapping (address => uint256) balances;
mapping (address => mapping (address => uint256)) allowed;
uint256 public totalSupply;
function balanceOf(address _owner) constant returns (uint256 balance);
function transfer(address _to, uint256 _amount) returns (bool success);
function transferFrom(address _from, address _to, uint256 _amount) returns (bool success);
function approve(address _spender, uint256 _amount) returns (bool success);
function allowance(address _owner, address _spender) constant returns (uint256 remaining);
event Transfer(address indexed _from, address indexed _to, uint256 _amount);
event Approval(address indexed _owner, address indexed _spender, uint256 _amount);
}
Above is the interface of the Token contract.
The interfaces of these contracts are used in the text of this document to give a simple overview of the functions and variables used in the contract, the full implementation can be found in the-appendix-(A.1)#ql:idEthddwprA1#.
This contract represents the standard token as described here: https://github.com/ethereum/wiki/wiki/Standardized_Contract_APIs, and the contract https://github.com/ConsenSys/Tokens/blob/master/Token_Contracts/contracts/Standard_Token.sol was used as a starting point for the contracts creation.
The map balances stores the number of DAO tokens which are controlled by an address.
All contracts which derive from TokenInterface can directly modify this map, but only 4 functions do so: createTokenProxy, transfer, transferFrom and splitDAO.
The map allowed is used to track the previously specified addresses that are allowed to send tokens on someone else’s behalf.
The integer totalSupply is the total number of DAO tokens in existence.
The public keyword creates a function with the same name as the variable which returns its value so that it is publically available.
The function balanceOf returns the balance of the specified address.
The function transfer is used to send token from the sender of the message to another address.
The function transferFrom is used to transfer tokens on behalf of someone else who has approved the transfer in advance using the approve function.
The function approve can be used by the DAO token owner to specify a certain spender to transfer a specified value from their account using the transferFrom function.
To check whether a certain address is allowed to spend DAO tokens on behalf of someone else, the allowance function can be used, which returns the number of tokens which can be spent by the spender.
This is similar to writing a check.
The event Transfer is used to inform lightweight clients about changes in balances.
The event Approval is used to inform lightweight clients about changes in allowed.
contract TokenCreationInterface {
uint public closingTime;
uint public minTokensToCreate;
bool public isFueled;
address public privateCreation;
ManagedAccount extraBalance;
mapping (address => uint256) weiGiven;
function TokenCreation(uint _minTokensToCreate, uint _closingTime);
function createTokenProxy(address _tokenHolder) returns (bool success);
function refund();
function divisor() returns (uint divisor);
event FuelingToDate(uint value);
event CreatedToken(address indexed to, uint amount);
event Refund(address indexed to, uint value);
}
Above is the interface of the TokenCreation contract (A.2#ql:idEthddwprA2#).
The integer closingTime is the (unix) time at which the Creation Phase ends.
The integer minTokensToCreate is the number of weiequivalent tokens which are needed to be created by the DAO in order to be considered fueled.
The boolean isFueled is true if DAO has reached its minimum fueling goal, false otherwise.
The address privateCreation is used for DAO splits - if it is set to 0, then it is a public Creation, otherwise, only the address stored in privateCreation is allowed to
create tokens.
The managed account (A.5#ql:idEthddwprA5#) extraBalance is used to hold the excess ether which is received after the Creation rate is decreased during the Creation Phase.
Anything that has been paid above the initial price goes to this account.
The map weiGiven stores the amount of wei given by each contributor during the Creation Phase and is only used to refund the contributors if the Creation Phase does not reach its fueling goal.
The constructor TokenCreation initiates the Creation Phase with the arguments minTokensToCreate, closingtime and privateCreation, which will be set in the constructor of the DAO contract (A.3#ql:idEthddwprA3#) which is only executed once, when the DAO is deployed.
In order to interact with the contract the following functions can be used:
createTokenProxy.
This function creates one unit of the DAO tokens minimum denomination for every wei sent.
The price is calculated as
Ξc · 20/divisor
Here Ξc is the amount of wei given in order to create tokens, and divisor is calculated depending on the time: 20/P(t) , as described in section-5#ql:idEthddwpr5#.
The parameter tokenHolder defines the receiver of the newly minted tokens.
refund.
This function can be called by any contributor to receive their wei back if the Creation Phase failed to meet its fueling goal.
divisor.
This function is used to calculate the price of the token during the Creation Phase in the function createTokenProxy.
The events FuelingToDate, CreatedToken and Refund are used to inform lightweight clients of the status of the Creation Phase.
contract DAOInterface {
Proposal[] public proposals;
uint minQuorumDivisor;
uint lastTimeMinQuorumMet;
address public curator;
address[] public allowedRecipients;
mapping (address => uint) public rewardToken;
uint public totalRewardToken;
ManagedAccount public rewardAccount;
ManagedAccount public DAOrewardAccount;
mapping (address => uint) public paidOut;
mapping (address => uint) public DAOpaidOut;
mapping (address => uint) public blocked;
uint public proposalDeposit;
uint sumOfProposalDeposits;
DAO_Creator public daoCreator;
struct Proposal {
address recipient;
uint amount;
string description;
uint votingDeadline;
bool open;
bool proposalPassed;
bytes32 proposalHash;
uint proposalDeposit;
bool newCurator;
SplitData[] splitData;
uint yea;
uint nay;
mapping (address => bool) votedYes;
mapping (address => bool) votedNo;
address creator;
}
struct SplitData {
uint splitBalance;
uint totalSupply;
uint rewardToken;
DAO newDAO;
}
modifier onlyTokenholders {}
function DAO(
address _curator,
DAO_Creator _daoCreator,
uint _proposalDeposit,
uint _minTokensToCreate,
uint _closingTime,
address _privateCreation
)
function () returns (bool success);
function receiveEther() returns(bool);
function newProposal(
address _recipient,
uint _amount,
string _description,
bytes _transactionData,
uint _debatingPeriod,
bool __newCurator
) onlyTokenholders returns (uint _proposalID);
function checkProposalCode(
uint _proposalID,
address _recipient,
uint _amount,
bytes _transactionData
) constant returns (bool _codeChecksOut);
function vote(
uint _proposalID,
bool _supportsProposal
) onlyTokenholders returns (uint _voteID);
function executeProposal(
uint _proposalID,
bytes _transactionData
) returns (bool _success);
function splitDAO(
uint _proposalID,
address _newCurator
) returns (bool _success);
function newContract(address _newContract);
function changeAllowedRecipients(address _recipient, bool _allowed) external returns (bool _success);
function changeProposalDeposit(uint _proposalDeposit) external;
function retrieveDAOReward(bool _toMembers) external returns (bool _success);
function getMyReward() returns(bool _success);
function withdrawRewardFor(address _account) returns(bool _success);
function transferWithoutReward(address _to, uint256 _amount) returns (bool success);
function transferFromWithoutReward(
address _from,
address _to,
uint256 _amount
) returns (bool success);
function halveMinQuorum() returns (bool _success);
function numberOfProposals() constant returns (uint _numberOfProposals);
function getNewDAOAdress(uint _proposalID) constant returns (address _newDAO);
function isBlocked(address _account) internal returns (bool);
function unblockMe() returns (bool);
event ProposalAdded(
uint indexed proposalID,
address recipient,
uint amount,
bool newCurator,
string description
);
event Voted(uint indexed proposalID, bool position, address indexed voter);
event ProposalTallied(uint indexed proposalID, bool result, uint quorum);
event NewCurator(address indexed _newCurator);
event AllowedRecipientAdded(address indexed _recipient);
}
The original contract used as a starting point for the DAO was: http://chriseth.github.io/browser-solidity/?gist=192371538cf5e43e6dab as described in https://blog.ethereum.org/2015/12/04.
The main feature added is the splitting mechanism and all that comes with it.
This section will define the member variables and functions from the above smart contract one at a time.
The array proposals holds all the proposals ever made.
The integer minQuorumDivisor is used to calculate the quorum needed for a proposal to pass.
It is set to 5, but will double in the case a quorum has not been reached for over a year.
The integer lastTimeMinQuorumMet keeps track of the last time the quorum was reached.
The address curator is set at the creation of the DAO and defines the Curator.
The list allowedRecipients is commonly referred to as the whitelist.
The DAO can only send transactions to itself, the curator, extraBalance and addresses in the whitelist.
Only the curator can add/remove addresses to/from the whitelist.
The map rewardToken tracks the addresses that are owed rewards generated by the products of the DAO.
Those addresses can only be DAOs.
The integer totalRewardToken tracks the amount of reward tokens in existence.
The variable rewardAccount is of the type ManagedAccount , which will be discussed in A.5.
It is used to manage the rewards which are to be distributed to the DAO Token Holders.
Similar, DAOrewardAccount is also of the type ManagedAccount.
This account is used to receive all rewards from projects funded by the DAO.
It will then redistribute them amongst all splitted DAOs as well as itself using the function retrieveDAOReward.
The map paidOut is used to keep track how much wei a single token holder has already retrieved from rewardAccount.
Similar, the map DAOpaidOut is used to keep track how much a single DAO has already received from DAOrewardAccount.
The map blocked stores the addresses of the DAO Tokens that have voted and therefore are not allowed to be transferred until the vote has concluded.
The address points to the proposal ID.
The integer proposalDeposit specifies the minimum deposit to be paid in wei for any proposal that does not include a change of the Curator.
The integer sumOfProposalDeposits is the sum of all proposal deposits of open proposals.
The contract daoCreator is used to create a new DAO with the same code as this DAO, used in the case of a split.
A single proposal has the parameters:
recipient: The address where the amount of wei will go to if the proposal is accepted.
amount: The amount of wei to transfer to recipient if the proposal is accepted.
description: A plain text description of the proposal.
votingDeadline: A unix timestamp, denoting the end of the voting period.
open: A boolean which is false if the votes have already been counted, true otherwise.
proposalPassed: A boolean which is true if a quorum has been achieved with the majority approving the proposal.
proposalHash: A hash to check validity of a proposal.
Equal to sha3(_recipient, _amount, _transactionData).
proposalDeposit: The deposit (in wei) the creator of a proposal has send to submit a proposal.
It is taken from the msg.value of a newProposal call; its purpose is to prevent spam.
Its minimal value is set when the contract is deployed as constructor parameter.
But the creator of the proposal can send any amount above this for the deposit.
The proposals will be sorted by the proposal deposit in the GUI, so in the case that a proposal is considered important, the creator of the proposal can deposit extra ether to advertise their proposal.
The creator of the proposal will be refunded the entire deposit if quorum is reached, if it is not reached the deposit remains with the DAO.
newCurator: A boolean which is true if this proposal assigns a new Curator.
splitData: The data used to split the DAO.
This data is gathered from proposals when they require a new Curator.
yea: Number of tokens in favor of the proposal.
nay: Number of tokens opposed to the proposal.
votedYes: Simple mapping to check if a token holder has voted for it.
votedNo: Simple mapping to check if a token holder has voted against it.
creator: The address of the token holder that created the proposal.
The split data structure is used to split the DAO.
It contains:
splitBalance: The balance of the current DAO minus the proposal deposit at the time of split.
totalSupply: The total amount of DAO tokens in existence at the time of the split.
rewardToken: The amount of reward tokens owned by the original DAO at the time of split.
newDAO: The address of the new DAO contract (0 if not created yet).
Those are all the member variables which are stored in this smart contract on the blockchain.
This information can at any time be read from the blockchain using an Ethereum client.
This section will discuss the functions of the DAO contract in detail.
Many of the member variables that are used in this contract are defined in one of the other three contracts.
There is a special function which is called the constructor.
It has the same name as the contract “DAO.”
This function is only executed once, when the DAO is created.
In the DAO constructor, the following variables are set:
• curator
• daoCreator
• proposalDeposit
• rewardAccount
• DAOrewardAccount
• minTokensToCreate
• closingTime
• privateCreation
• lastTimeMinQuorumMet
• minQuorumDivisor
• allowedRecipients
In order to interact with the smart contract the following functions are used:
fallback function. The fallback function is a function without a specific name.
It is called when the contract receives a transaction without data (a pure value transfer).
There are no direct arguments for this function.
The fallback function will call createTokenProxy passing the address of the sender as an argument during the Creation Phase.
This will trigger the immediate creation of tokens.
In order to protect users, this function will send the ether received after the end of the Creation Phase back to the sender for a time period of 40 days.
After which this function is repurposed to receive ether as simple deposit to the DAO using the function receiveEther.
receiveEther. A simple function used to receive ether.
It does nothing but return true when the DAO receives ether.
newProposal. This function is used to create a new proposal.
The arguments of the function are:
recipient: The address of the recipient of the ether in the proposal (has to be the DAO address itself, the current Curator or an address on the whitelist allowedRecipients).
amount: The amount of wei to be sent in the proposed transaction.
description: A string describing the proposal.
transactionData: The data of the proposed transaction.
debatingPeriod: The amount of time to debate the proposal, at least 2 weeks for a normal proposal
and at least 1 week for a new Curator proposal.
newCurator: A boolean defining whether this proposal is for a new Curator or not.
After checking the sanity of the proposal (see code), this function creates a proposal which is open for voting for a certain amount of time.
The function will return a proposal ID which is used to vote.
checkProposalCode. This function is used to check that a certain proposal ID matches a certain transaction.
The arguments of the function are:
proposalID: The proposal ID.
recipient: The address of the recipient of the proposed transaction.
amount: The amount of wei to be sent with the proposed transaction.
transactionData: The data of the proposed transaction.
If the recipient, the amount and the transactionData match the proposal ID, the function will return true, otherwise it will return false.
This will be used to verify that the proposal ID matches what the DAO token holder thinks they are voting on.
vote. This function is used to vote on a proposal.
The arguments of the function are:
proposalID: The proposal ID.
supportsProposal: A boolean Yes/No does the DAO token holder support the proposal
The function simply checks whether the sender has yet to vote and whether the proposal is still open for voting.
If both requirements are met, it records the vote in the storage of the contract.
The tokens used to vote will be blocked, meaning they can not be transferred until the proposal is closed.
This is to avoid voting several times with different sender addresses.
executeProposal. This function can be called by anyone.
It counts the votes, in order to check whether the quorum is met, and executes the proposal if it passed, unless it is a proposal for a new Curator, than it does nothing.
The arguments of the function are:
proposalID: The proposal ID.
transactionData: The data of the proposed transaction
The function checks whether the voting deadline has passed and that the transactionData matches the proposal ID.
Then it checks whether the quorum has been met (see Eq. 1) and if the proposal had a majority of support.
If this is the case, it executes the proposal and refunds the proposal deposit.
If the quorum has been achieved, but the proposal was declined by the majority of the voters, the proposal deposit is refunded and the proposal closes.
splitDAO. After a new Curator has been proposed, and the debating period in which the token holders could vote for or against the proposal has passed, this function is called by each of the DAO token holders that want to leave the current DAO and move to a new DAO with the proposed new Curator.
This function creates a new DAO and moves a portion of the ether, as well as a portion of the reward tokens to the new DAO.
The arguments are:
proposalID: The proposal ID.
newCurator: The address of the new Curator of the new DAO.
After a sanity check (see code), this function will create the new DAO if it hasnt already been created using the contract daoCreator, updates the split data stored in the proposal and stores the address of the new DAO in the split data.
This function moves the portion of ether that belongs to the caller of this function in the original DAO to the new DAO.
This ether amount is denoted by Ξsender, stated in wei and is calculated as follows:
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgEthddwprEqn4.png!# (eqn.4)
Here Tsender is the amount of tokens of the caller of the function and ΞDAO is the balance of the DAO at the time of the split.
This will be used to effectively create tokens in the newly created DAO and fuel the new DAO just as the original DAO was fueled.
In addition to the ether which is moved to the new DAO, the reward tokens Rsender are also transferred.
They are calculated as follows:
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgEthddwprEqn5.png!# (eqn.5)
Where RDAO is the amount of reward tokens owned by the original DAO at the time of the split.
These tokens allow the new DAO to retrieve their portion of the reward using the retrieveDAOReward function of the original DAO.
At the end of this process all original DAO tokens of the sender account are destroyed.
It is important to notice that in all integer division descirbed above, there may be remainders which stay with the DAO.
newContract. This function can only be called by the DAO itself (through a proposal and a vote) and is used to move all remaining ether, as well as all rewardTokens to a new address.
This is used to update the contract.
The new address needs to be approved by the Curator.
transfer and transferFrom. These functions overload the functions defined in the Token contract.
They do call transfer / transferFrom function in the Token contract, but they additionally transfer information about the already paid out rewards attached to the tokens being transferred using the transferPaidOut function.
transferPaidOut. This function is called when making any transfer of DAO tokens using transfer or transferFrom and it updates the array paidOut to track the amount of rewards which has been paid out already, P, and is calculated as follows:
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgEthddwprEqn6.png!# (eqn.6)
Here Pfrom is the total amount of ether which has been paid out to the from address (the sender), Tamount is the amount of tokens to be transferred and Tfrom is the amount of tokens owned by the from address.
transferWithoutReward and transferFromWithoutReward.
The same as transfer and transferFrom, but it calls getMyReward prior to that.
getMyReward. Calls withdrawRewardFor with the sender as the parameter.
This is used to withdraw the portion of the rewards which belong to the sender from the rewardAccount.
withdrawRewardFor. This function is used to retrieve the portion of the rewards in the rewardAccount which belong to the address given as a parameter.
The amount of ether Ξreward which is then sent to the DAO token holder that
calls this function is:
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgEthddwprEqn7.png!# (eqn.7)
Here ΞrewardAccount is the total rewards ever received by the rewardAccount and ΞpaidOut[sender] is the total amount of wei which has already been paid out to the DAO token holder address, which is given as a parameter.
The reward tokens are further elaborated in section 8.
retrieveDAOReward. This function, when called by a DAO, sends the rewards which belong to this DAO from DAOrewardAccount to either the DAO itself, or to the rewardAccount of the respective DAO in order to be distributed among its token holders, depending on the parameter _toMembers.
changeAllowedRecipients. This function can add/remove an address to/from the whitelist, allowedRecipients.
It can only be executed by the Curator.
halveMinQuorum. When called, halves the minimum quorum in the case it has not been met for over 52 weeks, by doubling minQuorumDivisor.
Also the curator can call this function without the 52 weeks limit, but not more than once every other week.
numberOfProposals. Returns the total number of proposals ever created.
getNewDAOAdress. This is just a helper function to read the address of a newly created ‘split DAO‘.
It gets the proposal ID which was used for the split as input parameter and returns the address of the new DAO.
isBlocked. This function returns true when the address given as parameter is currently blocked to transfer tokens due to an ongoing vote it has participated in, otherwise it returns false.
It also unblocks the tokens in the case the voting deadline of the proposal is over.
unblockMe. Calling isBlocked with the address of the sender.
changeProposalDeposit. This function changes the parameter proposalDeposit. It can only be called by the DAO through a transaction which was proposed and voted for by a majority of the token holders.
contract ManagedAccountInterface {
address public owner;
bool public payOwnerOnly;
uint public accumulatedInput;
function payOut(address _recipient, uint _amount) returns (bool);
event PayOut(address _recipient, uint _amount);
}
This contract is used to manage the rewards and the extraBalance (as explained in section 5).
It has two member variables:
The address owner, is the only address with permission to withdraw from that account (in our case the DAO) and send ether to another address using the payOut function.
The bool payOwnerOnly specifies whether the owner is the only address which can receive ether from this account.
The integer, accumulatedInput, represents the total sum of ether (in wei) which has been sent to this contract so far.
The fallback function is called when the contract receives a transaction without data (a pure value transfer).
There are no direct arguments for this function.
When it is called it counts the amount of ether it receives and stores it in accumulatedInput.
The function payOut can only be executed by the owner (in our case the DAO).
It has two arguments: recipient and amount.
It is used to send amount wei to a recipient and is called by getMyReward in the DAO contract.
This section gives a description of how reward tokens are implemented in this contract.
Much of the information has already been explained, but it is restated here for clarity.
Reward tokens are used to divide the ether sent to DAOrewardAccount amongst the various DAOs that own reward tokens.
Reward tokens are only transferred in the event of a DAO split or an update of the contract, they can never be owned by anything other than the original DAO or a fork of the original DAO that generated the reward tokens.
Reward tokens are generated when the DAO makes any transaction spending ether.
When the DAOs products send ether back to the DAO, the ether is held within DAOrewardAccount.
The DAO can use these rewards to fund new proposals or to fairly distribute the rewards to the reward token holders (using a proposal which gets voted on by the DAO token holders).
Then the token holders of the DAOs will be able to claim the ether they have earned for their contribution to the original DAO that issued the reward token.
To do this the DAO retrieve its rewards by callling the retrieveDAOReward function, with the paramter _toMembers set to true, which send the rewards to the rewardAccount (a ManagedAccount contract) and keeps track of the payouts in DAOpaidOut.
Then and only then will the token holders of the DAOs be able to call the getMyReward function and receive their ether.
These payouts are tracked by the map paidOut which keeps track of which token holders have claimed their fair portion of the rewards.
This process guarantees that any DAO token holder whose ether was spent building a product will receive the rewards promised to them from that product even if they decide to split from the DAO.
This section formally describes a few important parameters and their behavior during a split.
The total amount of DAO tokens totalSupply is defined as follows:
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgEthddwprEqn8.png!# (eqn.8)
Where Ti is the amount of DAO tokens owned by an address i (balances[i]).
Note that 2^256 is the total number of possible addresses in Ethereum.
Similarly, the amount of reward tokens Rtotal is defined as follows:
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgEthddwprEqn9.png!# (eqn.9)
For every passed proposal that sends ether out of the DAO, an amount of reward tokens equal to the amount being spent (in wei) is created.
Lets assume that during the split, a fraction of DAO tokens, X, changes the Curator and leaves the DAO.
The new DAO created receives X · ΞDAO pre, a portion of the remaining ether from the original DAO.
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgEthddwprEqn10.png!# (eqn.10)
Here ΞDAO pre is the ether balance of the original DAO before the split and ΞDAO post is the ether balance of the original DAO after the split.
A portion of the reward tokens is transferred to the new DAO in a very similar manner:
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgEthddwprEqn11.png!# (eqn.11)
Here RDAO is the amount of reward tokens owned by the DAO (prior to the first split 100% of all rewards tokens ever created are owned by the DAO).
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgEthddwprEqn12.png!# (eqn.12)
The number of reward tokens owned by the new DAO are denoted by RnewDAO.
The total amount of reward tokens Rtotal stays constant during the split, no reward tokens are ever destroyed.
The original DAO tokens of the accounts that confirmed the new Curator are destroyed. Hence:
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgEthddwprEqn13.png!# (eqn.13)
This process allows DAO token holders to retrieve their ether from the DAO at any time without losing out on any of the future rewards.
They are entitled to receive even if they choose to leave the DAO.
Although the code of the contract specified at a certain address in the Ethereum blockchain can not be changed, there might still be a need for a single member or the DAO as a whole to change the contracts.
Every single member can always split the DAO as described above and move their funds to a new DAO.
From there they can move their funds to another new DAO with a new smart contract.
But in order to use a new code for the complete DAO one can simply create a new DAO contract with all the needed features and deploy it on the blockchain, and make a proposal to call the newContract function with the address of the new contract as parameter.
If accepted, the complete DAO moves to the new contract, meaning, all ether and reward tokens are transferred to the new contract.
In order to use the same underlying DAO tokens there, one can use the approve function and give the new DAO the right to move the tokens.
In the new contract this right should only be usable in restricted functions which are only callable by the owner of the tokens.
Another option is to create new tokens in the new contract based on the token distribution in the old contract.
This can also be achieved by a proof that the old tokens are destroyed (sending to the 0 address).
This process allows for the DAO to maintain static immutable code on the Ethereum blockchain, while still being able to be updated if the need arises.
I want to thank Stephan Tual and Simon Jentzsch for fruitful discussions and corrections, as well as Gavin Wood and Christian Reitwiessner for a review of the contracts and the development of Solidity, the programing language used to write the contracts.
Special thanks goes to Yoichi Hirai and Lefteris Karapetsas for reviewing the smart contracts and making significant improvements.
I also want to thank Griff Green for reviewing and editing the paper.
Last but not least I want to thank our community which has given feedback, corrections and encouragement.
# idBiggs2015#John Biggs. When Crowdfunding Fails The Backers Are Left With No Way Out. 2015. URL http://techcrunch.com/2015/11/19/when-crowdfunding-fails-the-backers-are-left-with-no-way-out//.
# idButerin2013#Vitalik Buterin. Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform. 2013. URL https://github.com/ethereum/wiki/wiki/White-Paper.
# idButerin2015#Vitalik Buterin. The Subjectivity / Exploitability Tradeoff. 2015. URL https://blog.ethereum.org/2015/02/14/subjectivity-exploitability-tradeoff//.
# idGreen2016#Griff Green. private discussion. 2016.
# idKnibbs2015#Kate Knibbs. The 9 Most Disgraceful Crowdfunding Failures of 2015. 2015. URL http://gizmodo.com/the-9-most-disgraceful-crowdfunding-failures-of-2015-1747957776.
# idMassolution2015#Massolution. 2015CF - Crowdfunding Industry Report. 2015. URL http://reports.crowdsourcing.org/index.php?route=product/product&path=0_20&product_id=54.
# idMiller1997#Mark Miller. The Future of Law. In paper delivered at the Extro 3 Conference (August 9), 1997.
# idReitwWood2015#Christian Reitwiessner and Gavin Wood. Solidity. 2015. URL http://solidity.readthedocs.org//.
# idSzabo1997#Nick Szabo. Formalizing and securing relationships on public networks. First Monday, 2(9), 1997.
# idWood2014#Gavin Wood. Ethereum: A Secure Decentralised Generalised Transaction Ledger. 2014. URL http://gavwood.com/paper.pdf.
https://github.com/slockit/DAO/blob/develop/TokenCreation.sol
name::
* McsEngl.ethdapDao'Doing@cptIt,
name::
* McsEngl.ethdapDao'Creating@cptIt,
_DESCRIPTION:
A DAO is activated by deployment on the Ethereum blockchain.
[https://download.slock.it/public/DAO/WhitePaper.pdf]
===
DAOs are formed by groups of like-minded individuals with specific projects and goals in mind.
[https://blog.slock.it/a-primer-to-the-decentralized-autonomous-organization-dao-69fb125bd3cd#.9wdemu25y]
name::
* McsEngl.ethdapDao.CHARITY@cptIt,
_ADDRESS.WPG:
* https://medium.com/charitydao/charity-dao-e9592dd80ab7#.rr9nxcvce,
name::
* McsEngl.ethdapDao.THE-DAO (eththedao)@cptIt,
* McsEngl.eththedao@cptIt,
* McsEngl.ethdao.the-DAO@cptIt,
* McsEngl.eththedao@cptIt,
_DESCRIPTION:
The DAO was[citation needed] a digital decentralized autonomous organization and a form of investor-directed venture capital fund.[5]
The DAO had an objective to provide a new decentralized business model for organizing both commercial and non-profit enterprises.[6][7] It was instantiated on the Ethereum blockchain, and had no conventional management structure or board of directors.[6] The code of the DAO is open-source.[8]
The DAO was stateless, and not tied to any particular nation state. As a result, many questions of how government regulators would deal with a stateless fund were yet to be dealt with.[9]
The DAO was crowdfunded via a token sale in May 2016. It set the record for the largest crowdfunding campaign in history.[5]
In June 2016, hackers exploited a vulnerability in the DAO code to enable them to siphon off one third of The DAO's funds to a subsidiary account. On the 20th July 2016, the Ethereum community decided to hard-fork the Ethereum blockchain to restore virtually all funds to the original contract.[10] This was controversial, and led to a fork in Ethereum, where the original unforked blockchain was maintained as Ethereum Classic, thus breaking Ethereum into two separate active cryptocurrencies.[11][12]
[https://en.wikipedia.org/wiki/The_DAO_(organization)]
name::
* McsEngl.eththedao'Resource@cptIt,
_ADDRESS.WPG:
* https://forum.daohub.org//
* https://github.com/slockit/DAO,
===
* {2016-08-24} https://blog.slock.it/the-history-of-the-dao-and-lessons-learned-d06740f8cfa5#.971tzwfa2,
* {2016-08-24} http://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit//
* http://vessenes.com/deconstructing-thedao-attack-a-brief-code-tour//
* {2016-05-29} What Is The DAO and Why Is It the Biggest Crowdfunding Project in History? May 29, 2016 By : Kate https://letstalkpayments.com/what-is-the-dao-and-why-is-it-the-biggest-crowdfunding-project-in-the-history//
name::
* McsEngl.eththedao.EVOLUTING@cptIt,
{time.2016-07-20}:
=== the-hard-fork:
The specs were implemented by the client’s developers (including Geth, Parity, EthereumJ, Eth, etc) and the choice whether to fork or not was left to the community by using a switch when starting their client. At block 1920000 (on July 20th), the hard fork became active as a majority of miners and nodes moved to the new version of the chain. The hard fork worked smoothly.
Original DAO token holders started to withdraw their ETH, while the signatories of the curator multisig started to work on the edge cases (note: this is still a work in progress)
Surprisingly, the old chain did receive more support than expected. Exchanges listed the token of the old chain (under the name “Ether classic”), and blockchain explorers were created. Users found themselves confronted with the choice of two chains, which challenged the former Robin Hood Group to start the process of also returning the ETC, an ongoing process.
[https://blog.slock.it/the-history-of-the-dao-and-lessons-learned-d06740f8cfa5#.ee5j2jh44]
{time.2016-06-17}:
=== the-hack:
On the 17th of June, the attacker withdrew around 3.5M ETH (~50M$) from the DAO and into a child DAO. Thus, started the long and difficult fight to recover the funds.
[https://blog.slock.it/the-history-of-the-dao-and-lessons-learned-d06740f8cfa5#.ee5j2jh44]
{time.2016-04-30-2016-05-28}:
=== The DAO ICO
April 30, 2016 - May 28, 2016
Crowdsale Details
The DAO, a distributed autonomous organization and future client of Slock.it, is holding an ICO. It is not quite a crowdsale: the DAO is selling ownership of itself and raising ETH in the process. The DAO’s first act will be to hire Slock.it to do their work.
How are funds collected? To obtain DAO tokens, follow the wizard here or send ETH from your Ethereum Wallet (NOT an exchange) to The DAO’s address, given on on the same page.
Coin Distribution All tokens will be distributed to those who contribute ETH. None are set aside for developers.
Escrow Used Unknown
Rate 100 DAO Tokens per ETH for the first 14 days (roughly $.08/token). Then a linear increase for the next 10 days. For last 14 days, 100 DAO Tokens per 1.5 ETH (roughly $.12/token)
Project Valuation Currently unknown, the valuation will be based on the amount of ETH raised.
Currencies used ETH
How do the coins or tokens work?
How are they used? The tokens represent ownership over the DAO, which includes being able to nominate and vote on DAO activities, nominate and vote on DAO curators. At any point, token holders can burn their tokens and retrieve their unspent ETH. Read more about token holder abilities here.
What is the market for these coins? Any profits the DAO makes on its investments will be given back to token holders as dividends.
How are they produced? The only way future DAO tokens are created is through vote of the token holders.
[https://www.smithandcrown.com/event/the-dao-ico//]
name::
* McsEngl.ethdapDao.Maker@cptIt,
* McsEngl.Maker-ethdao@cptIt,
_DESCRIPTION:
Maker is a decentralized autonomous organization on the Ethereum blockchain seeking to minimize the price volatility of its own stable token — the Dai — against the IMF’s international currency basket SDR.
[http://makerdao.com/]
name::
* McsEngl.ethdap.Plutus@cptIt,
* McsEngl.Plutus.it@cptIt,
_DESCRIPTION:
PAY WITH BITCOIN.
ANYWHERE.
Waiting for merchants to accept Bitcoin and Ethereum? You don't have to! With Plutus Tap & Pay, you can pay at any NFC-enabled merchant.
[https://plutus.it/]
===
Plutus operates by connecting to a decentralized exchange platform, which uses smart contracts to handle digital currency trading.
... Users send bitcoin to their Plutus account, which are then automatically transferred to trader(s) on the DEX network. Smart contracts verify the transaction before the resulting fiat (USD, EUR, etc.) from the trader’s funds in escrow is transferred to the user’s virtual debit card, which can then be spent at any merchant that accepts NFC payments.
[https://plutus.it/case-study]
name::
* McsEngl.ethdap.Swarm@cptIt,
* McsEngl.swarm-ethdap@cptIt,
_DESCRIPTION:
Swarm is a distributed storage platform and content distribution service, a native base layer service of the ethereum web 3 stack. The primary objective of Swarm is to provide a decentralized and redundant store of Ethereum's public record, in particular to store and distribute dapp code and data as well as block chain data.
From the end user's perspective, Swarm is not that different from WWW, except that uploads are not to a specific server. The objective is to peer-to-peer storage and serving solution that is DDOS-resistant, zero-downtime, fault-tolerant and censorship-resistant as well as self-sustaining due to a built-in incentive system which uses peer to peer accounting and allows trading resources for payment.
Swarm is designed to deeply integrate with the devp2p multiprotocol network layer of Ethereum as well as with the Ethereum blockchain for domain name resolution, service payments and content availability insurance.
[http://swarm-gateways.net/bzz:/theswarm.eth//]
name::
* McsEngl.ethdap.WeiFund.io@cptIt,
* McsEngl.WeiFund-dApp@cptIt,
_DESCRIPTION:
A Brief Overview
To use the WeiFund decentralized app (dApp), users will first open WeiFund in a web 3.0 enabled browser such as Ethereum's Mist.
A user would then immediately be able to start, contribute to, browse, and manage crowdfunding campaigns.
WeiFund's interface and user experience will be very similar to that of conventional crowdfunding platforms such as Kickstarter or GoFundMe, however, all funds raised on WeiFund will be accounted for in the Ether digital-currency.
Web 3.0 enabled browsers will come with their own wallet systems so that payments made on WeiFund to start and contribute to campaigns are done so in a secure and verifiable way.
[http://weifund.io//]
name::
* McsEngl.ethnet'program.CONTRACT-PROGRAM (ethctp)@cptIt,
* McsEngl.ethctp@cptIt, {2017-02-21}
* McsEngl.ethcrt@cptIt, {2017-02-11}
* McsEngl.ethcontract@cptIt,
* McsEngl.ethereum-contract@cptIt,
* McsEngl.ethereum-contract-code@cptIt,
* McsEngl.ethereum-contract-program@cptIt,
* McsEngl.ethereum-smart-contract@cptIt,
* McsEngl.ethsct@cptIt,
* McsEngl.ethsmart-contract@cptIt,
* McsEngl.ethsmc@cptIt,
* McsEngl.ethnet'contract@cptIt,
* McsEngl.ethnet'smart-contract@cptIt,
* McsEngl.smart-contract.ethereum@cptIt,
_DESCRIPTION:
The popular term “smart contracts” refers to code in a Contract Account#ql:idEthactCrt# – programs that execute when a transaction is sent to that account.
[https://ethereum-homestead.readthedocs.io/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]
===
One way of thinking about smart contracts, and the way we’re going to think about them here, is as extremely basic, stateless web-services. Webservices are units of functionality in a system (the internet), with a well defined API and an identifier (IP address) that can be used to call them. Similarly, a smart contract is a unit of functionality, the public functions exposed by their Solidity contracts is the API, and their public address is the identifier. A web-service is normally called by making an http request, and a contract is called by making a transaction. Also, in most cases everyone is allowed to call them the endpoints are exposed to the public, so security must be handled on a call-by-call basis, and the same thing goes for contracts and their functions. We can even utilize common patterns and architectures, such as for example the microservices architecture.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features//]
===
“Contracts” in Ethereum should not be seen as something that should be “fulfilled” or “complied with”; rather, they are more like “autonomous agents” that live inside of the Ethereum execution environment, always executing a specific piece of code when “poked” by a message or transaction, and having direct control over their own ether balance and their own key/value store to store their permanent state.
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#contract-accounts]
===
A contract is a collection of code (its functions) and data (its state) that resides at a specific address on the Ethereum blockchain.
Contract accounts are able to pass messages between themselves as well as doing practically Turing complete computation.
Contracts live on the blockchain in a Ethereum-specific binary format called Ethereum Virtual Machine (EVM) bytecode.
Contracts are typically written in some high level language such as Solidity and then compiled into bytecode to be uploaded on the blockchain.
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/contracts.html#contracts]
===
CT: Ethereum and smart contracts: Do you feel that in the real world it would be difficult to understand for lay people?
TG: I believe a large part of the misunderstanding with so-called smart contracts is that the name is partially a misnomer. Really what we're talking about is programs on blockchains. These programs can be coded to do just about anything, but have the added benefit of digital uniqueness without central point of failure. From this point, lots of things are possible from digital assets to autonomous assistants.
[https://cointelegraph.com/news/ethereum-co-founder-taylor-gerring-hard-fork-will-make-network-more-resilient]
===
Smart contracts are computer programs that can automatically execute the terms of a contract.
[http://www.ethereum.nz/]
===
So far, all contracts we listed were owned and executed by other accounts probably held by humans. But there is no discrimination against robots or humans in the Ethereum ecosystem and contracts can create arbitrary actions like any other account would. Contracts can own tokens, participate in crowdsales, and even be voting members of other contracts.
[https://www.ethereum.org/dao]
===
Our backend (referred to as a ‘contract’ in Ethereum) is going to use a language called Solidity. There are several other contract languages you can use when building Ethereum backend, LLL (similar to Lisp) and Serpent (similar to Python). We’ll use Solidity as it is the formally supported language by the ETHDEV team.
[https://dappsforbeginners.wordpress.com/tutorials/your-first-dapp/]
name::
* McsEngl.ethctp'Unit@cptIt,
* McsEngl.ethctp'unit@cptIt,
name::
* McsEngl.ethctp'Semantic-unit@cptIt,
* McsEngl.ethctp'semantic-unit@cptIt,
* McsEngl.ethctpsut@cptIt,
name::
* McsEngl.ethctpsut.Function (ethctpf)@cptIt,
* McsEngl.ethctp'function@cptIt,
* McsEngl.ethctpf@cptIt,
name::
* McsEngl.ethctpf.Constant@cptIt,
_DESCRIPTION:
It is important to distinguish two kinds of functions that can appear in a contract:
Read-only (constant) functions: functions that don’t perform any state changes. They only read state, perform computations, and return values. As these functions can be resolved locally by each node, they cost no gas. Marked with the keyword `constant`.
Transactional functions: functions that perform a state change in the contract or move funds. As these changes need to be reflected in the blockchain, transactional function execution requires sending a transaction to the network and spending gas.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#5ae8]
name::
* McsEngl.ethctpf.ConstantNO@cptIt,
* McsEngl.ethctpf.constantNo@cptIt,
_DESCRIPTION:
It is important to distinguish two kinds of functions that can appear in a contract:
Read-only (constant) functions: functions that don’t perform any state changes. They only read state, perform computations, and return values. As these functions can be resolved locally by each node, they cost no gas. Marked with the keyword `constant`.
Transactional functions: functions that perform a state change in the contract or move funds.
As these changes need to be reflected in the blockchain, transactional function execution requires sending a transaction to the network and spending gas.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#5ae8]
name::
* McsEngl.ethctp'Sentence@cptIt,
* McsEngl.ethctp'sentence@cptIt,
* McsEngl.ethctpstc@cptIt,
name::
* McsEngl.ethctp'Paragraph@cptIt,
* McsEngl.ethctp'paragraph@cptIt,
* McsEngl.ethctppgf@cptIt,
name::
* McsEngl.ethctp'Title-construction@cptIt,
* McsEngl.ethctp'title-construction@cptIt,
name::
* McsEngl.ethctp'Creator-account@cptIt,
* McsEngl.ethctp'creator@cptIt,
* McsEngl.ethctp'owner@cptIt,
_DESCRIPTION:
The-account (normal or contract) that created the-contract-program.
[hmnSngo.2017-03-05]
name::
* McsEngl.ethctp'Party@cptIt,
_DESCRIPTION:
The key property of a smart contract is simple: there is only a fixed number of parties.
The parties do not all have to be known at initialization-time; a sell order, where A offers to sell 50 units of asset A to anyone who can provide 10 units of asset B, is also a smart contract.
Smart contracts can run on forever; hedging contracts and escrow contracts are good examples there.
However, smart contracts that run on forever should still have a fixed number of parties (eg. an entire decentralized exchange is not a smart contract), and contracts that are not intended to exist forever are smart contracts because existing for a finite time necessarily implies the involvement of a finite number of parties.
[https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide/]
name::
* McsEngl.ethctp'Address@cptIt,
_DESCRIPTION:
Organizer address vs. Contract address.
Your deployed contract will have its own contract address (different from the organizer’s address) on the blockchain.
This address is accessible in a Solidity contract using this, as used inside the refundTicket function in the contract: address myAddress = this;
[http://consensys.github.io/developers/articles/101-noob-intro/]
name::
* McsEngl.ethctp'codeASSEMBLY (ethasm)@cptIt,
name::
* McsEngl.ethasm'tool.Binary-to-assembly@cptIt,
_ADDRESS.WPG:
* https://gist.github.com/anonymous/d3bbdc55159879046345,
* https://etherscan.io/opcode-tool,
name::
* McsEngl.ethctp'codeSOURCE@cptIt,
_DESCRIPTION:
Other languages also exist, notably Serpent and LLL, which are described further in the Ethereum high level languages section of this documentation.
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/contracts.html#contracts]
name::
* McsEngl.ethctp'Store-of-data@cptIt,
* McsEngl.ethctp'storage@cptIt,
_DESCRIPTION:
A contract can neither read nor write to any storage apart from its own.
[http://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html#storage-memory-and-the-stack, 0-4-11.6d4cb248]
name::
* McsEngl.ethctp'Message-call@cptIt,
* McsEngl.ethctp'message@cptIt,
* McsEngl.ethnet'message-call@cptIt,
_DESCRIPTION:
Smart-Contract Messages
Contracts have the ability to send “messages” to other contracts. Messages are virtual objects that are never serialized and exist only in the Ethereum execution environment.
A message contains:
- sender: The sender of the message.
- recipient: The recipient of the message.
- amount: The amount of ether to transfer.
- data: An optional data field.
- startgas: A STARTGAS value.
Essentially, a message is like a transaction, except it is produced by a contract and not an external actor. A message is produced when a contract currently executing code executes the CALL opcode, which produces and executes a message. Like a transaction, a message leads to the recipient account running its code. Thus, contracts can have relationships with other contracts in exactly the same way that external actors can.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
===
Message Calls
Contracts can call other contracts or send Ether to non-contract accounts by the means of message calls. Message calls are similar to transactions, in that they have a source, a target, data payload, Ether, gas and return data. In fact, every transaction consists of a top-level message call which in turn can create further message calls.
A contract can decide how much of its remaining gas should be sent with the inner message call and how much it wants to retain. If an out-of-gas exception happens in the inner call (or any other exception), this will be signalled by an error value put onto the stack. In this case, only the gas sent together with the call is used up. In Solidity, the calling contract causes a manual exception by default in such situations, so that exceptions “bubble up” the call stack.
As already said, the called contract (which can be the same as the caller) will receive a freshly cleared instance of memory and has access to the call payload - which will be provided in a separate area called the calldata. After it finished execution, it can return data which will be stored at a location in the caller’s memory preallocated by the caller.
Calls are limited to a depth of 1024, which means that for more complex operations, loops should be preferred over recursive calls.
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#message-calls]
===
What is a message?
Contracts have the ability to send “messages” to other contracts. Messages are virtual objects that are never serialized and exist only in the Ethereum execution environment. They can be conceived of as function calls.
A message contains:
- the sender of the message (implicit).
- the recipient of the message
- VALUE field - The amount of wei to transfer alongside the message to the contract address,
an optional data field, that is the actual input data to the contract
- a STARTGAS value, which limits the maximum amount of gas the code execution triggered by the message can incur.
Essentially, a message is like a transaction, except it is produced by a contract and not an external actor. A message is produced when a contract currently executing code executes the CALL or DELEGATECALL opcodes, which produces and executes a message. Like a transaction, a message leads to the recipient account running its code. Thus, contracts can have relationships with other contracts in exactly the same way that external actors can.
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#what-is-a-message]
_SPECIFIC:
Contracts can even create other contracts using a special opcode (i.e. they do not simply call the zero address). The only difference between these create calls and normal message calls is that the payload data is executed and the result stored as code and the caller / creator receives the address of the new contract on the stack.
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#create]
name::
* McsEngl.ethctp'Language@cptIt,
* McsEngl.ethereum-language-of-smart-contract@cptIt,
* McsEngl.ethereum-smart-contract-language@cptIt,
* McsEngl.ethnet'language@cptIt,
_SPECIFIC:
* LLL#ql:idEthlll#,
* Mutan#ql:idEthmtnlag#,
* Serpent#ql:idEthsrpt#,
* Solidity#ql:idEthsol#,
* Viper#ql:idEthctpvpr#
name::
* McsEngl.ethctp'Mutan (deprecated)@cptIt,
* McsEngl.ethmtn@cptIt,
* McsEngl.Mutan-ethctp-lang@cptIt,
Mutan (deprecated)
Mutan is a statically typed, C-like language designed and developed by Jeffrey Wilcke. It is no longer maintained.
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/contracts.html#mutan-deprecated]
name::
* McsEngl.ethctp'language.SOLIDITY (ethsol)@cptIt,
* McsEngl.ethnet'solidity@cptIt,
* McsEngl.ethsol@cptIt,
* McsEngl.ethsolidity@cptIt,
* McsEngl.lagSol@cptIt,
* McsEngl.lcp.solidity@cptIt,
* McsEngl.lcpSlt@cptIt,
* McsEngl.lgsl@cptIt,
* McsEngl.lsl@cptIt,
* McsEngl.solidity@cptIt,
* McsEngl.solidity-language@cptIt,
_DESCRIPTION:
Solidity is a high-level language whose syntax is similar to that of JavaScript and it is designed to compile to code for the Ethereum Virtual Machine.
As you will see, it is quite easy to create contracts for voting, crowdfunding, blind auctions, multi-signature wallets and more.
[https://solidity.readthedocs.org/en/latest/]
_GENERIC:
* LanguageComputerPrograming#cptIt248#
name::
* McsEngl.ethsol'Archetype@cptIt,
* McsEngl.ethsolarc@cptIt,
* McsEngl.ethsolarcho@cptIt,
_DESCRIPTION:
Solidity-archetype is a-description of a-smart-contract processing by a-human.
[hmnSngo.2017-04-20]
===
A-smart-contract as humans perceive and execute.
[hmnSngo.2017-03-14]
name::
* McsEngl.ethsol'Algorithm (contract)@cptIt,
* McsEngl.ethsolalg@cptIt,
* McsEngl.ethsolalgo@cptIt,
* McsEngl.ethsolcontract@cptIt,
* McsEngl.ethsolctp@cptIt,
* McsEngl.ethsolpgm@cptIt,
* McsEngl.ethsol'smart-contract@cptIt,
_DESCRIPTION:
Solidity-algorithm is a-description of a-smart-contract processing by a-machine.
[hmnSngo.2017-04-20]
name::
* McsEngl.ethsolalg'Architecture@cptIt,
_DESCRIPTION:
The-architecture of the-machine that will-execute smart-contracts is that of a-stack-virtual-machine.
[hmnSngo.2017-03-14]
name::
* McsEngl.ethsolalg'Structure@cptIt,
_DESCRIPTION:
Contracts have state and functions.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#5ae8]
name::
* McsEngl.ethsolalg.PROGRAM@cptIt,
* McsEngl.ethsol'program@cptIt,
* McsEngl.ethsolpgm@cptIt,
* McsEngl.ethsolprogram@cptIt,
_DESCRIPTION:
Ethsolalgo is the-description of a-smart-contract that the-EVM executes written in any language human or computer.
Ethsolprogram is the-description of a-smart-contract that the-EVM executes written in ethsol uncompiled or compiled.
[hmnSngo.2017-03-14]
name::
* McsEngl.ethsolpgm'Location@cptIt,
_DESCRIPTION:
A contract in the sense of Solidity is a collection of code (its functions) and data (its state) that resides at a specific address on the Ethereum blockchain.
[https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html 0-4-10.9aab3b86]
name::
* McsEngl.ethsolalg.BYTECODE-PROGRAM (ethsolbcp)@cptIt,
* McsEngl.ethsol'binary-program@cptIt,
* McsEngl.ethsol'bytecode-program@cptIt,
* McsEngl.ethsolbcp@cptIt,
_DESCRIPTION:
Ethsolbcp is an-EVM-binary-program compiled from an-ethsolscp.
[hmnSngo.2017-03-14]
name::
* McsEngl.ethsolalg.ASSEMBLY-PROGRAM (ethsolasp)@cptIt,
* McsEngl.ethsolacd@cptIt,
* McsEngl.ethsolasp@cptIt,
_DESCRIPTION:
Solidity defines an assembly language that can also be used without Solidity.
This assembly language can also be used as “inline assembly” inside Solidity source code.
We start with describing how to use inline assembly and how it differs from standalone assembly and then specify assembly itself.
TODO: Write about how scoping rules of inline assembly are a bit different and the complications that arise when for example using internal functions of libraries. Furhermore, write about the symbols defined by the compiler.
[https://solidity.readthedocs.io/en/v0.4.9/assembly.html]
name::
* McsEngl.ethsolasp'Ethsol-Assembly.STANDALONE@cptIt,
_DESCRIPTION:
The assembly language described as inline assembly above can also be used standalone and in fact, the plan is to use it as an intermediate language for the Solidity compiler.
In this form, it tries to achieve several goals:
- Programs written in it should be readable, even if the code is generated by a compiler from Solidity.
- The translation from assembly to bytecode should contain as few “surprises” as possible.
- Control flow should be easy to detect to help in formal verification and optimization.
[https://solidity.readthedocs.io/en/v0.4.9/assembly.html#standalone-assembly]
name::
* McsEngl.ethsolalg.SOURCECODE-PROGRAM (ethsolscd)@cptIt,
* McsEngl.ethsol'contract-program@cptIt,
* McsEngl.ethsol'contract-sourcecode@cptIt,
* McsEngl.ethsol'program@cptIt,
* McsEngl.ethsol'sourcecode-program@cptIt,
* McsEngl.ethsolpgm.source@cptIt,
* McsEngl.ethsolscd@cptIt,
* McsEngl.ethsolscp@cptIt, {2017-03-14}
_CODE.ETHSOL:
//simple contract
pragma solidity ^0.4.0;
contract SimpleStorage {
uint storedData;
function set(uint x) {
storedData = x;
}
function get() constant returns (uint) {
return storedData;
}
}
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html]
name::
* McsEngl.ethsolscp'SEMANTIC-UNIT (ethsolsut)@cptIt,
* McsEngl.ethsolsut@cptIt,
* McsEngl.ethsol'sut@cptIt,
* McsEngl.ethsol'type@cptIt,
* McsEngl.ethsolsut@cptIt,
name::
* McsEngl.ethsolsut'Location@cptIt,
* McsEngl.ethsol'location@cptIt,
_DESCRIPTION:
// Data locations: Memory#ql:ethevm'memory# vs. storage vs. stack - all complex types (arrays,
// structs) have a data location
// 'memory' does not persist, 'storage' does
// Default is 'storage' for local and state variables; 'memory' for func params
// stack holds small local variables
// for most types, can explicitly set which data location to use
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.ethsolsut'Visibility@cptIt,
* McsEngl.ethsol'visibility-attribute@cptIt,
* McsEngl.ethsolsut'access@cptIt,
_DESCRIPTION:
Since Solidity knows two kinds of function calls (internal ones that do not create an actual EVM call (also called a “message call”) and external ones that do), there are four types of visibilities for functions and state variables.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#visibility-and-getters]
name::
* McsEngl.ethsolsut'Visibility-specifier@cptIt,
* McsEngl.ethsol'visibility-specifier@cptIt,
name::
* McsEngl.ethsolsut'Public-vs@cptIt,
* McsEngl.ethsol'public-sut@cptIt,
* McsEngl.ethsolpublic@cptIt,
_DESCRIPTION:
public:
Public functions are part of the contract interface and can be either called internally or via messages.
For public state variables, an automatic getter function (see below) is generated.
...
Functions can be specified as being external, public, internal or private, where the default is public.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#visibility-and-getters]
===
The keyword public automatically generates a function that allows you to access the current value of the state variable. Without this keyword, other contracts have no way to access the variable. The function will look something like this:
function minter() returns (address) { return minter; }
Of course, adding a function exactly like that will not work because we would have a function and a state variable with the same name, but hopefully, you get the idea - the compiler figures that out for you.
... The getter function created by the public keyword is a bit more complex in this case. It roughly looks like the following:
function balances(address _account) returns (uint) {
return balances[_account];
}
[https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html 0-4-10.6258fe71]
===
'public' makes externally readable (not writeable) by users or contracts
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.ethsolsut'Private-vs@cptIt,
* McsEngl.ethsol'private-sut@cptIt,
_DESCRIPTION:
private:
Private functions and state variables are only visible for the contract they are defined in and not in derived contracts.
Note
Everything that is inside a contract is visible to all external observers. Making something private only prevents other contracts from accessing and modifying the information, but it will still be visible to the whole world outside of the blockchain.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#visibility-and-getters]
===
"private" means that other contracts can't directly query balances [sut] but data is still viewable to other parties on blockchain
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.ethsolsut'External-vs@cptIt,
* McsEngl.ethsol'external-sut@cptIt,
_DESCRIPTION:
external:
External functions are part of the contract interface, which means they can be called from other contracts and via transactions.
An external function f cannot be called internally (i.e. f() does not work, but this.f() works).
External functions are sometimes more efficient when they receive large arrays of data.
...
For state variables, external is not possible and the default is internal.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#visibility-and-getters]
name::
* McsEngl.ethsolsut'Internal-vs@cptIt,
* McsEngl.ethsol'internal-sut@cptIt,
_DESCRIPTION:
internal:
Those functions and state variables can only be accessed internally (i.e. from within the current contract or contracts deriving from it), without using this.
...
For state variables, external is not possible and the default is internal.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#visibility-and-getters]
name::
* McsEngl.ethsolsut'Indexed-visibility-attribute@cptIt,
_DESCRIPTION:
Notice that _from and _to have an additional attribute indexed.
This attribute causes those arguments to be treated as log topics, rather than data.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
name::
* McsEngl.ethsolsut'Doing@cptIt,
name::
* McsEngl.ethsolsut'Checking@cptIt,
_DESCRIPTION:
Types are checked at compile-time, so if you make a mistake you will get a compiler error. For example, this is not possible:
contract Test {
bool bVar;
function causesError(address addr){
bVar = addr;
}
}
The error it would throw is this: Error: Type address not implicitly convertible to expected type bool.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features/]
name::
* McsEngl.ethsosut'Converting@cptIt,
_DESCRIPTION:
Type conversion
The compiler allows you to convert between types in certain cases. Let’s say you have the number 1 stored in a uint variable, and you want to use it in another variable of type int. That is possible - but you generally have to do the conversion yourself. This is how you would do it:
uint x = 1;
int y = int(x);
Type conversion is also checked at compile time and will generally be caught but there are exceptions; the most important one is when converting an address to a contract type. These type of casts can lead to bugs. We will be looking at some examples in a later section.
Finally, type conversion is something that should be used with care. It’s good in some cases, but excessive and/or careless casting is usually a sign that the code is not well written and can sometimes have bad consequences (such as data-loss). Remember types are there for a reason.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features//]
name::
* McsEngl.ethsolsut.specific@cptIt,
* McsEngl.ethsolsut.specific@cptIt,
_SPECIFIC:
* address ad
* array a
* bool b
* bytes32 bt32
* contract c
* function f
* number:
* uint8
* string s
name::
* McsEngl.ethsolsut.REFERENCE-TYPE@cptIt,
* McsEngl.ethsol'reference-type@cptIt,
_DESCRIPTION:
Reference Types
Complex types, i.e. types which do not always fit into 256 bits have to be handled more carefully than the value-types we have already seen.
Since copying them can be quite expensive, we have to think about whether we want them to be stored in memory (which is not persisting) or storage (where the state variables are held).
- array
- stuct
[http://solidity.readthedocs.io/en/v0.4.9/types.html#reference-types]
name::
* McsEngl.ethsolsut'Data-location@cptIt,
_DESCRIPTION:
Data location
Every complex type, i.e. arrays and structs, has an additional annotation, the “data location”, about whether it is stored in memory or in storage. Depending on the context, there is always a default, but it can be overridden by appending either storage or memory to the type. The default for function parameters (including return parameters) is memory, the default for local variables is storage and the location is forced to storage for state variables (obviously).
There is also a third data location, “calldata”, which is a non-modifyable non-persistent area where function arguments are stored. Function parameters (not return parameters) of external functions are forced to “calldata” and it behaves mostly like memory.
Data locations are important because they change how assignments behave: Assignments between storage and memory and also to a state variable (even from other state variables) always create an independent copy. Assignments to local storage variables only assign a reference though, and this reference always points to the state variable even if the latter is changed in the meantime. On the other hand, assignments from a memory stored reference type to another memory-stored reference type does not create a copy.
[http://solidity.readthedocs.io/en/v0.4.9/types.html#data-location]
===
* storage
* memory
* calldata
name::
* McsEngl.ethsolsut.VALUE-TYPE@cptIt,
* McsEngl.ethsol'value-type@cptIt,
_DESCRIPTION:
Value Types
The following types are also called value types because variables of these types will always be passed by value, i.e. they are always copied when they are used as function arguments or in assignments.
- Booleans
- Integers
- Address
- Fixed-size byte arrays
- Dynamically-sized byte arrays
- Fixed point numbers
- Address-literals
- Rational and integer literals
- String literals
- Hexadecimal literals
- Enums
- Function types
[http://solidity.readthedocs.io/en/v0.4.9/types.html#value-types]
name::
* McsEngl.ethsolscpsut.ADDRESS (ethsolad)@cptIt,
* McsEngl.ethsol'address@cptIt,
* McsEngl.ethsoladdress@cptIt,
* McsEngl.ethsolad@cptIt,
_DESCRIPTION:
Represents an-ethereum-account-address#ql:ethact'address#.
===
The address type is a 160-bit value that does not allow any arithmetic operations.
It is suitable for storing addresses of contracts or keypairs belonging to external persons.
[https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html 0-4-10.6258fe71]
===
address which is a cryptographic hash (SHA3)
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
===
address: Holds a 20 byte value (size of an Ethereum address).
Address types also have members(see [Functions on addresses](#functions-on-addresses)) and serve as base for all contracts.
Operators:
<=, <, ==, !=, >= and >
[https://solidity.readthedocs.org/en/latest/types.html#address]
===
// Addresses - holds 20 byte/160 bit Ethereum addresses
// No arithmetic allowed
address public owner;
// Types of accounts:
// Contract account: address set on create (func of creator address, num transactions sent)
// External Account: (person/external entity): address created from public key
// Add 'public' field to indicate publicly/externally accessible
// a getter is automatically created, but NOT a setter
// All addresses can be sent ether
owner.send(SOME_BALANCE); // returns false on failure
if (owner.send) {} // REMEMBER: wrap in 'if', as contract addresses have
// functions executed on send and these can fail
// Also, make sure to deduct balances BEFORE attempting a send, as there is a risk of a recursive
// call that can drain the contract
// can override send by defining your own
// Can check balance
owner.balance; // the balance of the owner (user or contract)
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.ethsolad'balance-number@cptIt,
_DESCRIPTION:
It is possible to query the balance of an address using the property balance and to send Ether (in units of wei) to an address using the send function:
address x = 0x123;
address myAddress = this;
if (x.balance < 10 && myAddress.balance >= 10) x.send(10);
[http://solidity.readthedocs.io/en/latest/types.html#members-of-addresses]
name::
* McsEngl.ethsolad'call@cptIt,
_DESCRIPTION:
Furthermore, to interface with contracts that do not adhere to the ABI, the function call is provided which takes an arbitrary number of arguments of any type. These arguments are padded to 32 bytes and concatenated. One exception is the case where the first argument is encoded to exactly four bytes. In this case, it is not padded to allow the use of function signatures here.
address nameReg = 0x72ba7d8e73fe8eb666ea66babc8116a41bfb10e2;
nameReg.call("register", "MyName");
nameReg.call(bytes4(keccak256("fun(uint256)")), a);
call returns a boolean indicating whether the invoked function terminated (true) or caused an EVM exception (false). It is not possible to access the actual data returned (for this we would need to know the encoding and size in advance).
[http://solidity.readthedocs.io/en/latest/types.html#members-of-addresses]
name::
* McsEngl.ethsolad'send-function@cptIt,
_DESCRIPTION:
It is possible to query the balance of an address using the property balance and to send Ether (in units of wei) to an address using the send function:
address x = 0x123;
address myAddress = this;
if (x.balance < 10 && myAddress.balance >= 10) x.send(10);
[http://solidity.readthedocs.io/en/latest/types.html#members-of-addresses]
name::
* McsEngl.ethsolscpsut.ARRAY (ethsola)@cptIt,
* McsEngl.ethsola@cptIt,
* McsEngl.ethsolarray@cptIt,
_DESCRIPTION:
// Arrays
bytes32[5] nicknames; // static array
bytes32[] names; // dynamic array
uint newLength = names.push("John"); // adding returns new length of the array
// Length
names.length; // get length
names.length = 1; // lengths can be set (for dynamic arrays in storage only)
// multidimensional array
uint x[][5]; // arr with 5 dynamic array elements (opp order of most languages)
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.ethsolscpsut.BOOLEAN (ethsolb)@cptIt,
* McsEngl.ethsolb@cptIt,
_CODE.ETHSOL:
bool voted;
===
bool b = true; // or do 'var b = true;' for inferred typing
name::
* McsEngl.ethsolscpsut.BYTES (ethsolbt)@cptIt,
* McsEngl.ethsol'bytes-type@cptIt,
* McsEngl.ethsolbytes@cptIt,
* McsEngl.ethsolbt@cptIt,
_DESCRIPTION:
Variables of type bytes and string are special arrays.
A bytes is similar to byte[], but it is packed tightly in calldata.
string is equal to bytes but does not allow length or index access (for now).
So bytes should always be preferred over byte[] because it is cheaper.
[http://solidity.readthedocs.io/en/v0.4.9/types.html#index-14]
===
// Bytes available from 1 to 32
byte a; // byte is same as bytes1
bytes2 b;
bytes32 c;
// Dynamically sized bytes
bytes m; // A special array, same as byte[] array (but packed tightly)
// More expensive than byte1-byte32, so use those when possible
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.ethsolscpsut.CONTRACT-UNIT (ethsolc)@cptIt,
* McsEngl.ethsolc@cptIt,
* McsEngl.ethsol'contract-semantic-unit@cptIt,
* McsEngl.ethsol'contract-datatype@cptIt,
* McsEngl.sltcontract@cptIt,
* McsEngl.sltc@cptIt,
* McsEngl.ethsolc@cptIt,
_DESCRIPTION:
Solidity uses the contract data-type to model smart contracts. It is very similar to a class.
A contract has a number of fields and methods; for example, the contract type can have a constructor, it can inherit from other contracts, etc.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features//]
===
Contracts in Solidity are similar to classes in object-oriented languages.
Each contract can contain declarations of State Variables, Functions, Function Modifiers, Events, Structs Types and Enum Types.
Furthermore, contracts can inherit from other contracts.
[https://solidity.readthedocs.io/en/v0.4.9/structure-of-a-contract.html]
_EXAMPLE:
* https://github.com/fivedogit/solidity-baby-steps,
name::
* McsEngl.ethsolc'Stage@cptIt,
_DESCRIPTION:
State Machine
Contracts often act as a state machine, which means that they have certain stages in which they behave differently or in which different functions can be called. A function call often ends a stage and transitions the contract into the next stage (especially if the contract models interaction). It is also common that some stages are automatically reached at a certain point in time.
An example for this is a blind auction contract which starts in the stage “accepting blinded bids”, then transitions to “revealing bids” which is ended by “determine auction autcome”.
Function modifiers can be used in this situation to model the states and guard against incorrect usage of the contract.
[https://solidity.readthedocs.org/en/latest/common-patterns.html#state-machine]
name::
* McsEngl.ethsolc.SPECIFIC (derived)@cptIt,
_CODE.ETHSOL:
contract owned {
function owned() { owner = msg.sender; }
address owner;
// This contract only defines a modifier but does not use
// it - it will be used in derived contracts.
// The function body is inserted where the special symbol
// "_;" in the definition of a modifier appears.
// This means that if the owner calls this function, the
// function is executed and otherwise, an exception is
// thrown.
modifier onlyOwner {
if (msg.sender != owner)
throw;
_;
}
}
contract mortal is owned {
// This contract inherits the "onlyOwner"-modifier from
// "owned" and applies it to the "close"-function, which
// causes that calls to "close" only have an effect if
// they are made by the stored owner.
function close() onlyOwner {
selfdestruct(owner);
}
}
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#function-modifiers]
name::
* McsEngl.ethsolc.ABSTRACT@cptIt,
_DESCRIPTION:
Contract functions can lack an implementation as in the following example (note that the function declaration header is terminated by ;):
pragma solidity ^0.4.0;
contract Feline {
function utterance() returns (bytes32);
}
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#abstract-contracts]
name::
* McsEngl.ethsolscpsut.ENUM (ethsolen)@cptIt,
* McsEngl.ethsolen@cptIt,
* McsEngl.ethsolenum@cptIt,
_DESCRIPTION:
Enums are one way to create a user-defined type in Solidity.
They are explicitly convertible to and from all integer types but implicit conversion is not allowed.
[https://solidity.readthedocs.org/en/latest/types.html#enums]
_CODE.ETHSOL:
enum ActionChoices { GoLeft, GoRight, GoStraight, SitStill }
===
enum Status {maintenance, active, suspended, bankrupt}
===
// Enums
enum State { Created, Locked, Inactive }; // often used for state machine
State public state; // Declare variable from enum
state = State.Created;
// enums can be explicitly converted to ints
uint createdState = uint(State.Created); // 0
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.ethsolscpsut.EVENT (ethsole)@cptIt,
* McsEngl.ethsol'event@cptIt,
* McsEngl.ethsole@cptIt,
_DESCRIPTION:
Events are used to dump information from Solidity contract code into the blockchain clients log. It is a way of making that information available to the “outside world”. On top of the events themselves, most clients also have a way of capturing this output and encapsulating it in an event data-structures. This is particularly important for efficiency between the blockchain clients and the “outside world” which will rely upon these events in order for other things to happen.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features//]
===
event Transfer(address indexed _from, address indexed _to, uint256 _value);
Next we specify an event, which is how in Solidity we use the logging facility of the Ethereum Virtual Machine. When called, events cause the arguments to be stored in the transaction’s log. In this instance we are storing three parameters, _from which is of type address, _to_ which is another address, and _value which is a uint256 (256-bit unsigned integer). Notice that _from and _to have an additional attribute indexed. This attribute causes those arguments to be treated as log topics, rather than data.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
===
The line event Sent(address from, address to, uint amount); declares a so-called “event” which is fired in the last line of the function send. User interfaces (as well as server appliances of course) can listen for those events being fired on the blockchain without much cost.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#subcurrency-example]
_CODE.ETHSOL:
// Events allow light clients to react on
// changes efficiently.
event Sent(address from, address to, uint amount);
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#subcurrency-example]
===
// B. Events
// Events are notify external parties; easy to search and
// access events from outside blockchain (with lightweight clients)
// typically declare after contract parameters
// Typically, capitalized - and add Log in front to be explicit and prevent confusion
// with a function call
// Declare
event LogSent(address indexed from, address indexed to, uint amount); // note capital first letter
// Call
Sent(from, to, amount);
// For an external party (a contract or external entity), to watch:
Coin.Sent().watch({}, '', function(error, result) {
if (!error) {
console.log("Coin transfer: " + result.args.amount +
" coins were sent from " + result.args.from +
" to " + result.args.to + ".");
console.log("Balances now:\n" +
"Sender: " + Coin.balances.call(result.args.from) +
"Receiver: " + Coin.balances.call(result.args.to));
}
}
// Common paradigm for one contract to depend on another (e.g., a
// contract that depends on current exchange rate provided by another)
[https://learnxinyminutes.com/docs/solidity//]
name::
* McsEngl.ethsolscpsut.FUNCTION (ethsolf)@cptIt,
* McsEngl.ethsolf@cptIt,
* McsEngl.sltfunction@cptIt,
* McsEngl.sltf@cptIt,
* McsEngl.ethsolf@cptIt,
name::
* McsEngl.ethsolf'Output@cptIt,
_DESCRIPTION:
// Functions can return many arguments, and by specifying returned arguments
// name don't need to explicitly return
function increment(uint x, uint y) returns (uint x, uint y) {
x += 1;
y += 1;
}
// Call previous functon
uint (a,b) = increment(1,1);
[https://learnxinyminutes.com/docs/solidity//]
name::
* McsEngl.ethsolf'Call@cptIt,
_DESCRIPTION:
Since Solidity knows two kinds of function calls (internal ones that do not create an actual EVM call (also called a “message call”) and external ones that do), there are four types of visibilities for functions and state variables.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#visibility-and-getters]
name::
* McsEngl.ethsolf'Interface@cptIt,
_JSON:
{
"constant": true,
"inputs": [ { "name": "", "type": "address" } ],
"name": "versions",
"outputs": [ { "name": "", "type": "uint256" } ],
"payable": false,
"type": "function"
}
===
{
"payable": false,
"type": "fallback"
}
name::
* McsEngl.ethsolf.specific@cptIt,
* McsEngl.ethsolf.specific@cptIt,
_SPECIFIC:
ethsolf.addmod(uint x, uint y, uint k) returns (uint):
compute (x + y) % k where the addition is performed with arbitrary precision and does not wrap around at 2**256.
ethsolf.mulmod(uint x, uint y, uint k) returns (uint):
compute (x * y) % k where the multiplication is performed with arbitrary precision and does not wrap around at 2**256.
ethsolf.sha3(...) returns (bytes32):
compute the Ethereum-SHA-3 hash of the (tightly packed) arguments
ethsolf.sha256(...) returns (bytes32):
compute the SHA-256 hash of the (tightly packed) arguments
ethsolf.ripemd160(...) returns (bytes20):
compute RIPEMD-160 hash of the (tightly packed) arguments
ethsolf.ecrecover(bytes32, uint8, bytes32, bytes32) returns (address):
recover public key from elliptic curve signature - arguments are (data, v, r, s)
[https://solidity.readthedocs.org/en/latest/units-and-global-variables.html#mathematical-and-cryptographic-functions]
name::
* McsEngl.ethsolf.CONSTRUCTOR@cptIt,
_DESCRIPTION:
a special function which is a constructor, denoted by the function having the same name as the contract itself. Generally constructors are used to initialize contract member variables to their initial state once the contract has been deployed.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
==
The special function Coin is the constructor which is run during creation of the contract and cannot be called afterwards.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#subcurrency-example]
name::
* McsEngl.ethsolf.CONSTANT@cptIt,
_DESCRIPTION:
Constant Functions
Functions can be declared constant. These functions promise not to modify the state.
pragma solidity ^0.4.0;
contract C {
function f(uint a, uint b) constant returns (uint) {
return a * (b + 42);
}
}
Note
Getter methods are marked constant.
Warning
The compiler does not enforce yet that a constant method is not modifying state.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#constant-functions]
===
What is the difference between a function marked constant and one that is not?
constant functions can perform some action and return a value, but cannot change state (this is not yet enforced by the compiler). In other words, a constant function cannot save or update any variables within the contract or wider blockchain. These functions are called using c.someFunction(...) from geth or any other web3.js environment.
“non-constant” functions (those lacking the constant specifier) must be called with c.someMethod.sendTransaction({from:eth.accounts[x], gas: 1000000}); That is, because they can change state, they have to have a gas payment sent along to get the work done.
[https://solidity.readthedocs.org/en/latest/frequently-asked-questions.html#what-is-the-difference-between-a-function-marked-constant-and-one-that-is-not]
name::
* McsEngl.ethsolf.CONSTANT.NO@cptIt,
_DESCRIPTION:
What is the difference between a function marked constant and one that is not?
constant functions can perform some action and return a value, but cannot change state (this is not yet enforced by the compiler). In other words, a constant function cannot save or update any variables within the contract or wider blockchain. These functions are called using c.someFunction(...) from geth or any other web3.js environment.
“non-constant” functions (those lacking the constant specifier) must be called with c.someMethod.sendTransaction({from:eth.accounts[x], gas: 1000000}); That is, because they can change state, they have to have a gas payment sent along to get the work done.
[https://solidity.readthedocs.org/en/latest/frequently-asked-questions.html#what-is-the-difference-between-a-function-marked-constant-and-one-that-is-not]
name::
* McsEngl.ethsofl.INTERNAL@cptIt,
_DESCRIPTION:
internal:
Those functions and state variables can only be accessed internally (i.e. from within the current contract or contracts deriving from it), without using this.
name::
* McsEngl.ethsolf.FALLBACK@cptIt,
_DESCRIPTION:
Fallback Function
A contract can have exactly one unnamed function. This function cannot have arguments and cannot return anything. It is executed on a call to the contract if none of the other functions matches the given function identifier (or if no data was supplied at all).
Furthermore, this function is executed whenever the contract receives plain Ether (without data). In such a context, there is usually very little gas available to the function call (to be precise, 2300 gas), so it is important to make fallback functions as cheap as possible.
In particular, the following operations will consume more gas than the stipend provided to a fallback function:
Writing to storage
Creating a contract
Calling an external function which consumes a large amount of gas
Sending Ether
Please ensure you test your fallback function thoroughly to ensure the execution cost is less than 2300 gas before deploying a contract.
Warning
Contracts that receive Ether but do not define a fallback function throw an exception, sending back the Ether (this was different before Solidity v0.4.0). So if you want your contract to receive Ether, you have to implement a fallback function.
pragma solidity ^0.4.0;
contract Test {
// This function is called for all messages sent to
// this contract (there is no other function).
// Sending Ether to this contract will cause an exception,
// because the fallback function does not have the "payable"
// modifier.
function() { x = 1; }
uint x;
}
// This contract keeps all Ether sent to it with no way
// to get it back.
contract Sink {
function() payable { }
}
contract Caller {
function callTest(Test test) {
test.call(0xabcdef01); // hash does not exist
// results in test.x becoming == 1.
// The following call will fail, reject the
// Ether and return false:
test.send(2 ether);
}
}
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#fallback-function]
name::
* McsEngl.ethsolf.MODIFIER@cptIt,
* McsEngl.ethsolf.modifier@cptIt,
* McsEngl.ethsol'modifier-function@cptIt,
_DESCRIPTION:
Modifiers can be used to easily change the behaviour of functions, for example to automatically check a condition prior to executing the function. They are inheritable properties of contracts and may be overridden by derived contracts.
pragma solidity ^0.4.0;
contract owned {
function owned() { owner = msg.sender; }
address owner;
// This contract only defines a modifier but does not use
// it - it will be used in derived contracts.
// The function body is inserted where the special symbol
// "_;" in the definition of a modifier appears.
// This means that if the owner calls this function, the
// function is executed and otherwise, an exception is
// thrown.
modifier onlyOwner {
if (msg.sender != owner)
throw;
_;
}
}
contract mortal is owned {
// This contract inherits the "onlyOwner"-modifier from
// "owned" and applies it to the "close"-function, which
// causes that calls to "close" only have an effect if
// they are made by the stored owner.
function close() onlyOwner {
selfdestruct(owner);
}
}
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#function-modifiers]
===
// Modifiers validate inputs to functions such as minimal balance or user auth;
// similar to guard clause in other languages
// '_' (underscore) often included as last line in body, and indicates
// function being called should be placed there
modifier onlyAfter(uint _time) { if (now <= _time) throw; _ }
modifier onlyOwner { if (msg.sender == owner) _ }
// commonly used with state machines
modifier onlyIfState (State currState) { if (currState != State.A) _ }
// Append right after function declaration
function changeOwner(newOwner)
onlyAfter(someTime)
onlyOwner()
onlyIfState(State.A)
{
owner = newOwner;
}
// underscore can be included before end of body,
// but explicitly returning will skip, so use carefully
modifier checkValue(uint amount) {
_
if (msg.value > amount) {
uint amountToRefund = amount - msg.value;
if (!msg.sender.send(amountToRefund)) {
throw;
}
}
}
[https://learnxinyminutes.com/docs/solidity//]
name::
* McsEngl.ethsolf.OPERATOR@cptIt,
* McsEngl.ethsoloperator@cptIt,
_DESCRIPTION:
// 3. Simple operators
// Comparisons, bit operators and arithmetic operators are provided
// exponentiation: **
// exclusive or: ^
// bitwise negation: ~
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.ethsolf.selfdestruct@cptIt,
* McsEngl.ethsol'selfdestruct@cptIt,
* McsEngl.ethsolselfdestruct@cptIt,
_DESCRIPTION:
In Solidity, the command for removing (or suiciding) a contract is this: selfdestruct(addr).
The argument here is the address to which any remaining funds should be sent.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features//]
===
ether sent to selfdestructed contract is lost
[https://learnxinyminutes.com/docs/solidity//]
name::
* McsEngl.ethsolscpsut.LIBRARY (ethsoll)@cptIt,
* McsEngl.ethsol'library@cptIt,
* McsEngl.ethsoll@cptIt,
* McsEngl.ethsollibrary@cptIt,
_DESCRIPTION:
Libraries are similar to contracts, but their purpose is that they are deployed only once at a specific address and their code is reused using the DELEGATECALL (CALLCODE until Homestead) feature of the EVM. This means that if library functions are called, their code is executed in the context of the calling contract, i.e. this points to the calling contract, and especially the storage from the calling contract can be accessed. As a library is an isolated piece of source code, it can only access state variables of the calling contract if they are explicitly supplied (it would have no way to name them, otherwise).
...
Restrictions for libraries in comparison to contracts:
No state variables
Cannot inherit nor be inherited
Cannot recieve Ether
(These might be lifted at a later point.)
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#libraries]
name::
* McsEngl.ethsolscpsut.MAPPING (ethsolm)@cptIt,
* McsEngl.ethsol'dictionary@cptIt,
* McsEngl.ethsol'mapping@cptIt,
* McsEngl.ethsolm@cptIt,
_DESCRIPTION:
A mapping is a relational type, from keys to values,
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
===
Mapping types are declared as mapping _KeyType => _ValueType, where _KeyType can be almost any type except for a mapping and _ValueType can actually be any type, including mappings.
Mappings can be seen as hashtables which are virtually initialized such that every possible key exists and is mapped to a value whose byte-representation is all zeros. The similarity ends here, though: The key data is not actually stored in a mapping, only its sha3 hash used to look up the value.
Because of this, mappings do not have a length or a concept of a key or value being “set”.
Mappings are only allowed for state variables (or as storage reference types in internal functions).
[https://solidity.readthedocs.org/en/latest/types.html#mappings]
===
// Dictionaries (any type to any other type)
mapping (string => uint) public balances;
balances["charles"] = 1;
console.log(balances["ada"]); // is 0, all non-set key values return zeroes
// 'public' allows following from another contract
contractName.balances("charles"); // returns 1
// 'public' created a getter (but not setter) like the following:
function balances(string _account) returns (uint balance) {
return balances[_account];
}
// Nested mappings
mapping (address => mapping (address => uint)) public custodians;
// To delete
delete balances["John"];
delete balances; // sets all elements to 0
// Unlike other languages, CANNOT iterate through all elements in
// mapping, without knowing source keys - can build data structure
// on top to do this
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.ethsolscpsut.NUMBER (ethsoln)@cptIt,
* McsEngl.ethsoln@cptIt,
name::
* McsEngl.ethsolscpsut.number.INTEGER@cptIt,
* McsEngl.ethsol'integer@cptIt,
* McsEngl.ethsolinteger@cptIt,
_DESCRIPTION:
Integers in Solidity can be either signed or unsigned, and can be on the form intN/uintN, where N = 8*n for n = 1, 2, ... , 32. Some examples would be uint8, int32, int128, and uint240. Additionally, int and uint are shorthand for int256 and uint256, respectively.
[https://github.com/androlo/solidity-workshop/blob/master/tutorials/2016-03-14-advanced-solidity-V.md]
===
int• / uint•: Signed and unsigned integers of various sizes. Keywords uint8 to uint256 in steps of 8 (unsigned of 8 up to 256 bits) and int8 to int256. uint and int are aliases for uint256 and int256, respectively.
Operators:
Comparisons: <=, <, ==, !=, >=, > (evaluate to bool)
Bit operators: &, |, ^ (bitwise exclusive or), ~ (bitwise negation)
Arithmetic operators: +, -, unary -, unary +, *, /, % (remainder), ** (exponentiation)
Division always truncates (it just maps to the DIV opcode of the EVM), but it does not truncate if both operators are literals (or literal expressions).
[https://solidity.readthedocs.org/en/latest/types.html#integers]
name::
* McsEngl.ethsol'int (ethsoln)@cptIt,
* McsEngl.ethsolint@cptIt,
* McsEngl.ethsolint256@cptIt,
name::
* McsEngl.ethsol'int8 (ethsoln8)@cptIt,
* McsEngl.ethsoluint8@cptIt,
name::
* McsEngl.ethsol'uint (ethsolnu)@cptIt,
* McsEngl.ethsoluint@cptIt,
* McsEngl.ethsoluint256@cptIt,
_DESCRIPTION:
uint storedData;
//The line uint storedData; declares a state variable called storedData of type uint (unsigned integer of 256 bits).
===
uint used for currency amount (there are no doubles or floats) and for dates (in unix time)
...
uint constant VERSION_ID = 0x123A1; // A hex constant
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.ethsol'uint8 (ethsolnu8)@cptIt,
* McsEngl.ethsoluint8@cptIt,
name::
* McsEngl.ethsolscpsut.UNIT-OF-MEASUREMENT@cptIt,
* McsEngl.ethsol'unit-of-measurement@cptIt,
_DESCRIPTION:
// Currency units
// Currency is defined using wei, smallest unit of Ether
uint minAmount = 1 wei;
uint a = 1 finney; // 1 ether == 1000 finney
// Other units, see: http://ether.fund/tool/converter
// Time units
1 == 1 second
1 minutes == 60 seconds
// Can multiply a variable times unit, as units are not stored in a variable
uint x = 5;
(x * 1 days); // 5 days
// Careful about leap seconds/years with equality statements for time
// (instead, prefer greater than/less than)
[https://learnxinyminutes.com/docs/solidity//]
name::
* McsEngl.ethsolscpsut.STRING (ethsols)@cptIt,
* McsEngl.ethsols@cptIt,
* McsEngl.ethsolstring@cptIt,
_DESCRIPTION:
// same as bytes, but does not allow length or index access (for now)
string n = "hello"; // stored in UTF8, note double quotes, not single
// string utility functions to be added in future
// prefer bytes32/bytes, as UTF8 uses more storage
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.ethsolscpsut.STRUCT (ethsolsc)@cptIt,
* McsEngl.ethsol'struct@cptIt,
* McsEngl.ethsolsc@cptIt,
* McsEngl.ethsolstruct@cptIt,
_DESCRIPTION:
// Structs and enums
struct Bank {
address owner;
uint balance;
}
Bank b = Bank({
owner: msg.sender,
balance: 5
});
// or
Bank c = Bank(msg.sender, 5);
c.amount = 5; // set to new value
delete b;
// sets to initial value, set all variables in struct to 0, except mappings
[https://learnxinyminutes.com/docs/solidity/]
_CODE.ETHSOL:
// Defines a new type with two fields.
struct Funder {
address addr;
uint amount;
}
name::
* McsEngl.ethsolscpsut.NAME-VALUE-PAIR (variable)@cptIt,
* McsEngl.ethsol'name-value-pair@cptIt,
* McsEngl.ethsol'variable@cptIt,
* McsEngl.ethsolv@cptIt,
* McsEngl.ethsolvariable@cptIt,
_DESCRIPTION:
Solidity is a strongly-typed language which means that variables must have a type given to them.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
_CODE.ETHSOL:
address public minter;
// declares a state variable of type address that is publicly accessible.
===
mapping (address => uint) balances;
name::
* McsEngl.ethsolv'value@cptIt,
* McsEngl.ethsolvalue@cptIt,
_DESCRIPTION:
// by default, all values are set to 0 on instantiation
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.ethsolv.STATE-VARIABLE (storage)@cptIt,
* McsEngl.ethsol'local-variable@cptIt,
* McsEngl.ethsol'state-variable@cptIt,
* McsEngl.ethsol'storage-variable@cptIt,
* McsEngl.ethsolv.local@cptIt,
_DESCRIPTION:
The Ethereum Virtual Machine has three areas where it can store items.
The first is “storage”, where all the contract state variables reside.
Every contract has its own storage and it is persistent between function calls and quite expensive to use.
[http://solidity.readthedocs.io/en/develop/frequently-asked-questions.html#what-is-the-memory-keyword-what-does-it-do]
===
contract Test {
int a = 999; // That's storage
function doIt() {
int b; // That's memory
assembly {
b := sload(a);
}
}
}
[http://ethereum.stackexchange.com/a/11677]
===
The Ethereum Virtual Machine has three areas where it can store items. ...
The third one is the stack, which is used to hold small local variables. It is almost free to use, but can only hold a limited amount of values.
...
local variables always reference storage
...
A common mistake is to declare a local variable and assume that it will be created in memory, although it will be created in storage:
[http://solidity.readthedocs.io/en/develop/frequently-asked-questions.html#what-is-the-memory-keyword-what-does-it-do]
name::
* McsEngl.ethsolv.MEMORY-VARIABLE@cptIt,
* McsEngl.ethsol'memory-variable@cptIt,
* McsEngl.ethsolv.memory@cptIt,
_DESCRIPTION:
contract Test {
int a = 999; // That's storage
function doIt() {
int b; // That's memory
assembly {
b := sload(a);
}
}
}
[http://ethereum.stackexchange.com/a/11677]
name::
* McsEngl.ethsolv.VAR@cptIt,
* McsEngl.ethsolvar@cptIt,
_DESCRIPTION:
// Type inferrence
// var does inferred typing based on first assignment,
// can't be used in functions parameters
var a = true;
// use carefully, inference may provide wrong type
// e.g., an int8, when a counter needs to be int16
// var can be used to assign function to variable
function a(uint x) returns (uint) {
return x * 2;
}
var f = a;
f(22); // call
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.ethsolv.CONSTANT@cptIt,
* McsEngl.ethsol'constant@cptIt,
* McsEngl.ethsolconstant@cptIt,
_DESCRIPTION:
Constant State Variables
State variables can be declared as constant (this is not yet implemented for array and struct types and not possible for mapping types).
pragma solidity ^0.4.0;
contract C {
uint constant x = 32**22 + 8;
string constant text = "abc";
}
This has the effect that the compiler does not reserve a storage slot for these variables and every occurrence is replaced by their constant value.
The value expression can only contain integer arithmetics.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#constant-functions]
===
uint constant VERSION_ID = 0x123A1; // A hex constant
// with 'constant', compiler replaces each occurrence with actual value
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.ethsolv.GLOBAL@cptIt,
* McsEngl.ethsol'global-variable@cptIt,
* McsEngl.ethsolv.global@cptIt,
_DESCRIPTION:
msg (together with tx and block) is a magic global variable that contains some properties which allow access to the blockchain. msg.sender is always the address where the current (external) function call came from.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#subcurrency-example]
_SPECIFIC:
* block##
* msg##
* now##
* this##
* tx##
name::
* McsEngl.ethsolv.this@cptIt,
* McsEngl.ethsolv.this@cptIt,
_DESCRIPTION:
// ** this **
this; // address of contract
// often used at end of contract life to send remaining balance to party
this.balance;
this.someFunction(); // calls func externally via call, not via internal jump
[https://learnxinyminutes.com/docs/solidity/]
name::
* McsEngl.ethsolv.block@cptIt,
* McsEngl.ethsol'block@cptIt,
_API:
block.blockhash(uint blockNumber) returns (bytes32): hash of the given block - only works for 256 most recent blocks excluding current
block.coinbase (address): current block miner’s address
block.difficulty (uint): current block difficulty
block.gaslimit (uint): current block gaslimit
block.number (uint): current block number
block.timestamp (uint): current block timestamp
[http://solidity.readthedocs.io/en/latest/units-and-global-variables.html#block-and-transaction-properties]
===
// ** block - Information about current block **
now; // current time (approximately), alias for block.timestamp (uses Unix time)
block.number; // current block number
block.difficulty; // current block difficulty
block.blockhash(1); // returns bytes32, only works for most recent 256 blocks
block.gasLimit();
[https://learnxinyminutes.com/docs/solidity//]
name::
* McsEngl.ethsolv.msg@cptIt,
* McsEngl.ethsol'msg@cptIt,
_DESCRIPTION:
msg (together with tx and block) is a magic global variable that contains some properties which allow access to the blockchain. msg.sender is always the address where the current (external) function call came from.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#subcurrency-example]
===
// ** msg - Current message received by the contract ** **
msg.sender; // address of sender
msg.value; // amount of ether provided to this contract in wei
msg.data; // bytes, complete call data
msg.gas; // remaining gas
[https://learnxinyminutes.com/docs/solidity//]
_API:
msg.data (bytes): complete calldata
msg.gas (uint): remaining gas
msg.sender (address): sender of the message (current call)
msg.sig (bytes4): first four bytes of the calldata (i.e. function identifier)
msg.value (uint): number of wei sent with the message
[http://solidity.readthedocs.io/en/latest/units-and-global-variables.html#block-and-transaction-properties]
name::
* McsEngl.ethsolv.tx@cptIt,
* McsEngl.ethsol'tx@cptIt,
_API:
tx.gasprice (uint): gas price of the transaction
tx.origin (address): sender of the transaction (full call chain)
[http://solidity.readthedocs.io/en/latest/units-and-global-variables.html#block-and-transaction-properties]
name::
* McsEngl.ethsolsv.storage@cptIt,
* McsEngl.ethsolstorage@cptIt,
_DESCRIPTION:
// ** storage - Persistent storage hash **
storage['abc'] = 'def'; // maps 256 bit words to 256 bit words
[https://learnxinyminutes.com/docs/solidity//]
name::
* McsEngl.ethsolscpsut.API@cptIt,
* McsEngl.ethsolAPI@cptIt,
name::
* McsEngl.ethsolapi.msg@cptIt,
ethsolapi.msg.sender:
special variable msg.sender, which is, intuitively, the address of the message sender.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
name::
* McsEngl.ethsolapi.tx@cptIt,
ethsolapi.tx.origin:
Here we use a special variable called tx.origin which is of type address and contains the sender of the transaction,
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
name::
* McsEngl.ethsolscpsut.JSON-INTERFACE (ABI)@cptIt,
* McsEngl.ABI.ethsol@cptIt,
* McsEngl.ethsol'ABI@cptIt,
* McsEngl.ethsol'JSON-interface@cptIt,
* McsEngl.ethsolscpsut.ABI@cptIt,
_DESCRIPTION:
The-interface of the-functions of a-contract in JSON-format.
===
[
{
"constant": true,
"inputs": [],
"name": "t32Hash_of_will",
"outputs": [ { "name": "", "type": "bytes32", "value": "0x0000000000000000000000000000000000000000000000000000000000000000", "displayName": "" } ],
"type": "function",
"displayName": "t32 Hash<span class=\"punctuation\">_</span>of<span class=\"punctuation\">_</span>will"
},
{
"constant": false,
"inputs": [ { "name": "sWillIn", "type": "string", "typeShort": "string", "bits": "", "displayName": "s Will In", "template": "elements_input_string" } ],
"name": "fWillNew",
"outputs": [],
"type": "function",
"displayName": "f Will New"
},
{
"constant": true,
"inputs": [],
"name": "aWill_owner",
"outputs": [ { "name": "", "type": "address", "value": "0x0998c9a0c7224ec2ed782a3ecfef53a0e25fa9fc", "displayName": "" } ],
"type": "function",
"displayName": "a Will<span class=\"punctuation\">_</span>owner"
},
{ "constant": true, "inputs": [ { "name": "sWillUserIn", "type": "string", "typeShort": "string", "bits": "", "displayName": "s Will User In", "template": "elements_input_string" } ], "name": "fWillCheck", "outputs": [ { "name": "bWill_correct", "type": "bool" } ],
"type": "function", "displayName": "f Will Check"
},
{
"inputs": [],
"type": "constructor"
}
]
name::
* McsEngl.ethsolscp'SENTENCE (ethsolstc)@cptIt,
* McsEngl.ethsolstc@cptIt,
* McsEngl.ethsol'sentence@cptIt,
name::
* McsEngl.ethsolstc.ASSIGNMENT@cptIt,
* McsEngl.ethsolstc.assignment@cptIt,
* McsEngl.ethsol'assignment-sentence@cptIt,
_DESCRIPTION:
// Destructuring/Tuples
(x, y) = (2, 7); // assign/swap multiple value
[https://learnxinyminutes.com/docs/solidity//]
name::
* McsEngl.ethsolstc.BRANCHING@cptIt,
* McsEngl.ethsolstc.branching@cptIt,
_CODE.ETHSOL:
// 6. BRANCHING AND LOOPS
// All basic logic blocks work - including if/else, for, while, break, continue
// return - but no switch
// Syntax same as javascript, but no type conversion from non-boolean
// to boolean (comparison operators must be used to get the boolean val)
[https://learnxinyminutes.com/docs/solidity//]
name::
* McsEngl.ethsolstc.LOOP@cptIt,
* McsEngl.ethsolstc.loop@cptIt,
_CODE.ETHSOL:
// For loops that are determined by user behavior, be careful - as contracts have a maximal
// amount of gas for a block of code - and will fail if that is exceeded
// For example:
for(uint x = 0; x < refundAddressList.length; x++) {
if (!refundAddressList[x].send(SOME_AMOUNT)) {
throw;
}
}
// Two errors above:
// 1. A failure on send stops the loop from completing, tying up money
// 2. This loop could be arbitrarily long (based on the amount of users who need refunds), and
// therefore may always fail as it exceeds the max gas for a block
// Instead, you should let people withdraw individually from their subaccount, and mark withdrawn
[https://learnxinyminutes.com/docs/solidity//]
name::
* McsEngl.ethsolstc.pragma@cptIt,
* McsEngl.ethsol'pragma@cptIt,
* McsEngl.ethsolpragma@cptIt,
* McsEngl.ethsolstc.pragma@cptIt,
_CODE.ETHSOL:
pragma solidity ^0.4.0;
//The first line simply tells that the source code is written for Solidity version 0.4.0 or anything newer that does not break functionality (up to, but not including, version 0.5.0).
This is to ensure that the contract does not suddenly behave differently with a new compiler version.
[https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html 0-4-10.9aab3b86]
name::
* McsEngl.ethsolstc.import@cptIt,
* McsEngl.ethsol'import@cptIt,
* McsEngl.ethsolimport@cptIt,
_DESCRIPTION:
Solidity supports import statements that are very similar to those available in JavaScript (from ES6 on), although Solidity does not know the concept of a “default export”.
At a global level, you can use import statements of the following form:
import "filename";
This statement imports all global symbols from “filename” (and symbols imported there) into the current global scope (different than in ES6 but backwards-compatible for Solidity).
import * as symbolName from "filename";
...creates a new global symbol symbolName whose members are all the global symbols from "filename".
import {symbol1 as alias, symbol2} from "filename";
...creates new global symbols alias and symbol2 which reference symbol1 and symbol2 from "filename", respectively.
Another syntax is not part of ES6, but probably convenient:
import "filename" as symbolName;
which is equivalent to import * as symbolName from "filename";.
[https://solidity.readthedocs.io/en/v0.4.9/layout-of-source-files.html#syntax-and-semantics]
name::
* McsEngl.ethsol'path-of-files@cptIt,
_DESCRIPTION:
Paths
In the above, filename is always treated as a path with / as directory separator, . as the current and .. as the parent directory. When . or .. is followed by a character except /, it is not considered as the current or the parent directory. All path names are treated as absolute paths unless they start with the current . or the parent directory ...
To import a file x from the same directory as the current file, use import "./x" as x;. If you use import "x" as x; instead, a different file could be referenced (in a global “include directory”).
It depends on the compiler (see below) how to actually resolve the paths. In general, the directory hierarchy does not need to strictly map onto your local filesystem, it can also map to resources discovered via e.g. ipfs, http or git.
[https://solidity.readthedocs.io/en/v0.4.9/layout-of-source-files.html#paths]
name::
* McsEngl.ethsolstc.using-for@cptIt,
* McsEngl.ethsol'using-for@cptIt,
_DESCRIPTION:
Using For
The directive using A for B; can be used to attach library functions (from the library A) to any type (B). These functions will receive the object they are called on as their first parameter (like the self variable in Python).
The effect of using A for *; is that the functions from the library A are attached to any type.
In both situations, all functions, even those where the type of the first parameter does not match the type of the object, are attached. The type is checked at the point the function is called and function overload resolution is performed.
The using A for B; directive is active for the current scope, which is limited to a contract for now but will be lifted to the global scope later, so that by including a module, its data types including library functions are available without having to add further code.
Let us rewrite the set example from the Libraries in this way:
pragma solidity ^0.4.0;
// This is the same code as before, just without comments
library Set {
struct Data { mapping(uint => bool) flags; }
function insert(Data storage self, uint value)
returns (bool)
{
if (self.flags[value])
return false; // already there
self.flags[value] = true;
return true;
}
function remove(Data storage self, uint value)
returns (bool)
{
if (!self.flags[value])
return false; // not there
self.flags[value] = false;
return true;
}
function contains(Data storage self, uint value)
returns (bool)
{
return self.flags[value];
}
}
contract C {
using Set for Set.Data; // this is the crucial change
Set.Data knownValues;
function register(uint value) {
// Here, all variables of type Set.Data have
// corresponding member functions.
// The following function call is identical to
// Set.insert(knownValues, value)
if (!knownValues.insert(value))
throw;
}
}
It is also possible to extend elementary types in that way:
pragma solidity ^0.4.0;
library Search {
function indexOf(uint[] storage self, uint value) returns (uint) {
for (uint i = 0; i < self.length; i++)
if (self[i] == value) return i;
return uint(-1);
}
}
contract C {
using Search for uint[];
uint[] data;
function append(uint value) {
data.push(value);
}
function replace(uint _old, uint _new) {
// This performs the library function call
uint index = data.indexOf(_old);
if (index == uint(-1))
data.push(_new);
else
data[index] = _new;
}
}
Note that all library calls are actual EVM function calls. This means that if you pass memory or value types, a copy will be performed, even of the self variable. The only situation where no copy will be performed is when storage reference variables are used.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#using-for]
name::
* McsEngl.ethsolstc.comment@cptIt,
* McsEngl.ethsol'comment@cptIt,
_DESCRIPTION:
Single-line comments (//) and multi-line comments (/*...*/) are possible.
// This is a single-line comment.
/*
This is a
multi-line comment.
*/
[https://solidity.readthedocs.io/en/v0.4.9/layout-of-source-files.html#comments]
name::
* McsEngl.ethsolscp'Error@cptIt,
_DESCRIPTION:
Errors
There is no real error handling system in Solidity (yet). There are no try - catch or throw statements, or something to that effect. Contract designers need to deal with errors themselves. Solidity does some sanity checks on arrays and such, but will often respond simply by executing the (STOP) instruction. According to the developers, this is just put in as a placeholder until a more sophisticated error handling and recovery system is put in place.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features//]
name::
* McsEngl.ethsolscp'Style@cptIt,
_DESCRIPTION:
// 13. STYLE NOTES
// Based on https://www.python.org/dev/peps/pep-0008/
// Quick summary:
// 4 spaces for indentation
// Two lines separate contract declarations (and other top level declarations)
// Avoid extraneous spaces in parentheses
// Can omit curly braces for one line statement (if, for, etc)
// else should be placed on own line
[https://learnxinyminutes.com/docs/solidity//]
name::
* McsEngl.ethsolscp.SPECIFIC@cptIt,
* McsEngl.ethsolscp.specific@cptIt,
_SPECIFIC:
* https://github.com/fivedogit/solidity-baby-steps/tree/master/contracts,
* https://github.com/ConsenSys/dapp-store-contracts,
===
As you will see, it is possible to create contracts for voting, crowdfunding, blind auctions, multi-signature wallets and more.
[https://solidity.readthedocs.io/en/latest/ 0-4-10.9aab3b86]
name::
* McsEngl.ethsolscp.CROWDFUNDING@cptIt,
* McsEngl.ethsolscp.crowdfunding@cptIt,
_CODE.ETHSOL:
// *** EXAMPLE: A crowdfunding example (broadly similar to Kickstarter) ***
// ** START EXAMPLE **
// CrowdFunder.sol
/// @title CrowdFunder
/// @author nemild
contract CrowdFunder {
// Variables set on create by creator
address public creator;
address public fundRecipient; // creator may be different than recipient
uint public minimumToRaise; // required to tip, else everyone gets refund
string campaignUrl;
byte constant version = 1;
// Data structures
enum State {
Fundraising,
ExpiredRefund,
Successful
}
struct Contribution {
uint amount;
address contributor;
}
// State variables
State public state = State.Fundraising; // initialize on create
uint public totalRaised;
uint public raiseBy;
uint public completeAt;
Contribution[] contributions;
event LogFundingReceived(address addr, uint amount, uint currentTotal);
event LogWinnerPaid(address winnerAddress);
modifier inState(State _state) {
if (state != _state) throw;
_
}
modifier isCreator() {
if (msg.sender != creator) throw;
_
}
// Wait 6 months after final contract state before allowing contract destruction
modifier atEndOfLifecycle() {
if(!((state == State.ExpiredRefund || state == State.Successful) &&
completeAt + 6 months < now)) {
throw;
}
_
}
function CrowdFunder(
uint timeInHoursForFundraising,
string _campaignUrl,
address _fundRecipient,
uint _minimumToRaise)
{
creator = msg.sender;
fundRecipient = _fundRecipient;
campaignUrl = _campaignUrl;
minimumToRaise = _minimumToRaise;
raiseBy = now + (timeInHoursForFundraising * 1 hours);
}
function contribute()
public
inState(State.Fundraising)
{
contributions.push(
Contribution({
amount: msg.value,
contributor: msg.sender
}) // use array, so can iterate
);
totalRaised += msg.value;
LogFundingReceived(msg.sender, msg.value, totalRaised);
checkIfFundingCompleteOrExpired();
return contributions.length - 1; // return id
}
function checkIfFundingCompleteOrExpired() {
if (totalRaised > minimumToRaise) {
state = State.Successful;
payOut();
// could incentivize sender who initiated state change here
} else if ( now > raiseBy ) {
state = State.ExpiredRefund; // backers can now collect refunds by calling getRefund(id)
}
completeAt = now;
}
function payOut()
public
inState(State.Successful)
{
if(!fundRecipient.send(this.balance)) {
throw;
}
LogWinnerPaid(fundRecipient);
}
function getRefund(id)
public
inState(State.ExpiredRefund)
{
if (contributions.length <= id || id < 0 || contributions[id].amount == 0 ) {
throw;
}
uint amountToRefund = contributions[id].amount;
contributions[id].amount = 0;
if(!contributions[id].contributor.send(amountToSend)) {
contributions[id].amount = amountToSend;
return false;
}
return true;
}
function removeContract()
public
isCreator()
atEndOfLifecycle()
{
selfdestruct(msg.sender);
// creator gets all money that hasn't be claimed
}
function () { throw; }
}
// ** END EXAMPLE **
[https://learnxinyminutes.com/docs/solidity//]
name::
* McsEngl.ethsolscp.STORAGE@cptIt,
* McsEngl.ethsolscp.storage@cptIt,
_CODE.ETHSOL:
pragma solidity ^0.4.0;
contract SimpleStorage {
uint storedData;
function set(uint x) {
storedData = x;
}
function get() constant returns (uint) {
return storedData;
}
}
[https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html]
name::
* McsEngl.ethsolscp.SUBCURRENCY@cptIt,
* McsEngl.ethsolscp.cryptocurrency@cptIt,
* McsEngl.ethsolscp.subcurrency@cptIt,
_DESCRIPTION:
The following contract will implement the simplest form of a cryptocurrency. It is possible to generate coins out of thin air, but only the person that created the contract will be able to do that (it is trivial to implement a different issuance scheme). Furthermore, anyone can send coins to each other without any need for registering with username and password - all you need is an Ethereum keypair.
pragma solidity ^0.4.0;
contract Coin {
// The keyword "public" makes those variables
// readable from outside.
address public minter;
mapping (address => uint) public balances;
// Events allow light clients to react on
// changes efficiently.
event Sent(address from, address to, uint amount);
// This is the constructor whose code is
// run only when the contract is created.
function Coin() {
minter = msg.sender;
}
function mint(address receiver, uint amount) {
if (msg.sender != minter) return;
balances[receiver] += amount;
}
function send(address receiver, uint amount) {
if (balances[msg.sender] < amount) return;
balances[msg.sender] -= amount;
balances[receiver] += amount;
Sent(msg.sender, receiver, amount);
}
}
This contract introduces some new concepts, let us go through them one by one.
The line address public minter; declares a state variable of type address that is publicly accessible. The address type is a 160-bit value that does not allow any arithmetic operations. It is suitable for storing addresses of contracts or keypairs belonging to external persons. The keyword public automatically generates a function that allows you to access the current value of the state variable. Without this keyword, other contracts have no way to access the variable. The function will look something like this:
function minter() returns (address) { return minter; }
Of course, adding a function exactly like that will not work because we would have a function and a state variable with the same name, but hopefully, you get the idea - the compiler figures that out for you.
The next line, mapping (address => uint) public balances; also creates a public state variable, but it is a more complex datatype. The type maps addresses to unsigned integers. Mappings can be seen as hashtables which are virtually initialized such that every possible key exists and is mapped to a value whose byte-representation is all zeros. This analogy does not go too far, though, as it is neither possible to obtain a list of all keys of a mapping, nor a list of all values. So either keep in mind (or better, keep a list or use a more advanced data type) what you added to the mapping or use it in a context where this is not needed, like this one. The getter function created by the public keyword is a bit more complex in this case. It roughly looks like the following:
function balances(address _account) returns (uint) {
return balances[_account];
}
As you see, you can use this function to easily query the balance of a single account.
The line event Sent(address from, address to, uint amount); declares a so-called “event” which is fired in the last line of the function send. User interfaces (as well as server appliances of course) can listen for those events being fired on the blockchain without much cost. As soon as it is fired, the listener will also receive the arguments from, to and amount, which makes it easy to track transactions. In order to listen for this event, you would use
Coin.Sent().watch({}, '', function(error, result) {
if (!error) {
console.log("Coin transfer: " + result.args.amount +
" coins were sent from " + result.args.from +
" to " + result.args.to + ".");
console.log("Balances now:\n" +
"Sender: " + Coin.balances.call(result.args.from) +
"Receiver: " + Coin.balances.call(result.args.to));
}
}
Note how the automatically generated function balances is called from the user interface.
The special function Coin is the constructor which is run during creation of the contract and cannot be called afterwards. It permanently stores the address of the person creating the contract: msg (together with tx and block) is a magic global variable that contains some properties which allow access to the blockchain. msg.sender is always the address where the current (external) function call came from.
Finally, the functions that will actually end up with the contract and can be called by users and contracts alike are mint and send. If mint is called by anyone except the account that created the contract, nothing will happen. On the other hand, send can be used by anyone (who already has some of these coins) to send coins to anyone else. Note that if you use this contract to send coins to an address, you will not see anything when you look at that address on a blockchain explorer, because the fact that you sent coins and the changed balances are only stored in the data storage of this particular coin contract. By the use of events it is relatively easy to create a “blockchain explorer” that tracks transactions and balances of your new coin.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#subcurrency-example]
name::
* McsEngl.ethsolscp.WILL@cptIt,
* McsEngl.ethsolscp.will@cptIt,
_CODE.ETHSOL:
contract CMgrWill {
address public aWill_owner;
bytes32 public t32Hash_of_will;
function fMgrWill(){
aWill_owner = msg.sender;
}
function fWillNew(string sWillIn) {
if (msg.sender != aWill_owner) throw;
t32Hash_of_will = sha3(sWillIn);
}
function fWillCheck(string sWillUserIn) constant returns (bool bWill_correct) {
return (sha3(sWillUserIn) == t32Hash_of_will);
}
}
name::
* McsEngl.ethsol'Human@cptIt,
Human.Reitwiessner.Cristian:
Dr. Christian Reitwieίner, the creator of the Ethereum smart contract language Solidity,
[https://blog.slock.it/creator-of-solidity-joins-slock-it-team-as-advisor-76b77d0aa459#.mqoj2umze]
name::
* McsEngl.ethsol'Tool@cptIt,
* McsEngl.ethsol'tool@cptIt,
* McsEngl.ethsoltool@cptIt,
_SPECIFIC:
* Solidity Parser in Javascript: https://github.com/ConsenSys/solidity-parser#ql:Solidity Parser in Javascript#
name::
* McsEngl.ethsoltool.BROWSER-COMPILER@cptIt,
* McsEngl.ethsol'browser-compiler@cptIt,
_ADDRESS.WPG:
* https://ethereum.github.io/browser-solidity/#version=soljson-v0.4.9+commit.364da425.js,
_DESCRIPTION:
The best way to try out Solidity right now is using the Browser-Based Compiler (it can take a while to load, please be patient).
[https://solidity.readthedocs.io/en/v0.4.9/]
name::
* McsEngl.ethsoltool.solcjs@cptIt,
* McsEngl.solcjs@cptIt,
_DESCRIPTION:
npm / Node.js
This is probably the most portable and most convenient way to install Solidity locally.
A platform-independent JavaScript library is provided by compiling the C++ source into JavaScript using Emscripten. It can be used in projects directly (such as Browser-Solidity). Please refer to the solc-js repository for instructions.
It also contains a commandline tool called solcjs, which can be installed via npm:
npm install -g solc
Note
The comandline options of solcjs are not compatible with solc and tools (such as geth) expecting the behaviour of solc will not work with solcjs.
[https://solidity.readthedocs.io/en/v0.4.9/installing-solidity.html#npm-node-js]
===
> solcjs --help
Usage: \Users\synagonism\AppData\Roaming\npm\node_modules\solc\solcjs
[options] [input_file...]
Options:
--version Show version number [boolean]
--optimize Enable bytecode optimizer. [boolean]
--bin Binary of the contracts in hex. [boolean]
--abi ABI of the contracts. [boolean]
--output-dir, -o Output directory for the contracts. [string]
--help Show help [boolean]
name::
* McsEngl.ethsoltool.Dapple@cptIt,
* McsEngl.ethsoltool.dapple@cptIt,
_DESCRIPTION:
Dapple is a Solidity developer multitool designed to manage the growing complexity of interconnected smart contract systems.
Its core functionality encompasses three main areas:
Package management
Contract building
Deployment scripting
[http://dapple.readthedocs.io/en/master/]
name::
* McsEngl.ethsoltool.Populus@cptIt,
* McsEngl.ethsoltool.populus@cptIt,
_DESCRIPTION:
Populus is a smart contract development framework for the Ethereum blockchain.
[http://populus.readthedocs.io/en/latest/]
name::
* McsEngl.ethsoltool.REPL@cptIt,
* McsEngl.ethsol'REPL@cptIt,
* McsEngl.ethsoltool.REPL@cptIt,
_DESCRIPTION:
Ethereum Solidity REPL.
[https://github.com/raineorshine/solidity-repl]
_Installation:
$ npm install -g solidity-repl
[https://github.com/raineorshine/solidity-repl]
_Usage:
$ solr
Welcome to the Solidity REPL!
> uint a = 10
> uint b = 20
> a + b
30
> msg.sender
0x2f42491c0a08e4bc0cd3d5a96533a69727e16911
[https://github.com/raineorshine/solidity-repl]
name::
* McsEngl.ethsoltool.Solgraph@cptIt,
* McsEngl.ethsoltool.solgraph@cptIt,
_DESCRIPTION:
Visualize Solidity control flow for smart contract security analysis.
[https://github.com/raineorshine/solgraph]
name::
* McsEngl.ethsol'Resource@cptIt,
* McsEngl.ethsol'resource@cptIt,
_ADDRESS.WPG:
* https://github.com/ethereum/solidity,
=== tutorial
* https://solidity.readthedocs.org/en/latest//
* http://solidity.readthedocs.io/en/v0.4.9//
* https://github.com/androlo/solidity-workshop,
* https://karl.tech/learning-solidity-part-1-deploy-a-contract// metamask,
* https://ethereumbuilders.gitbooks.io/guide/content/en/solidity_tutorials.html,
* https://learnxinyminutes.com/docs/solidity//
=== community
* https://gitter.im/ethereum/solidity//
name::
* McsEngl.ethsol.EVOLUTING (0.4.9-2017-01-31)@cptIt,
_ADDRESS.WPG:
* https://github.com/ethereum/solidity/blob/develop/Changelog.md,
ethsol.0-4-10.2017-03-15:
Features:
Add assert(condition), which throws if condition is false (meant for internal errors).
Add require(condition), which throws if condition is false (meant for invalid input).
Commandline interface: Do not overwrite files unless forced.
Introduce .transfer(value) for sending Ether.
Code generator: Support revert() to abort with rolling back, but not consuming all gas.
Inline assembly: Support revert (EIP140) as an opcode.
Parser: Support scientific notation in numbers (e.g. 2e8 and 200e-2).
Type system: Support explicit conversion of external function to address.
Type system: Warn if base of exponentiation is literal (result type might be unexpected).
Type system: Warn if constant state variables are not compile-time constants.
Bugfixes:
Commandline interface: Always escape filenames (replace /, : and . with _).
Commandline interface: Do not try creating paths . and ...
Commandline interface: Allow long library names.
Parser: Disallow octal literals.
Type system: Fix a crash caused by continuing on fatal errors in the code.
Type system: Disallow compound assignment for tuples.
Type system: Detect cyclic dependencies between constants.
Type system: Disallow arrays with negative length.
Type system: Fix a crash related to invalid binary operators.
Type system: Disallow var declaration with empty tuple type.
Type system: Correctly convert function argument types to pointers for member functions.
Type system: Move privateness of constructor into AST itself.
Inline assembly: Charge one stack slot for non-value types during analysis.
Assembly output: Print source location before the operation it refers to instead of after.
Optimizer: Stop trying to optimize tricky constants after a while.
[https://github.com/ethereum/solidity/blob/develop/Changelog.md]
ethsol.0-4-9.2017-01-31:
Features:
Compiler interface: Contracts and libraries can be referenced with a file: prefix to make them unique.
Compiler interface: Report source location for "stack too deep" errors.
AST: Use deterministic node identifiers.
Inline assembly: introduce invalid (EIP141) as an opcode.
Type system: Introduce type identifier strings.
Type checker: Warn about invalid checksum for addresses and deduce type from valid ones.
Metadata: Do not include platform in the version number.
Metadata: Add option to store sources as literal content.
Code generator: Extract array utils into low-level functions.
Code generator: Internal errors (array out of bounds, etc.) now cause a reversion by using an invalid instruction (0xfe - EIP141) instead of an invalid jump. Invalid jump is still kept for explicit throws.
Bugfixes:
Code generator: Allow recursive structs.
Inline assembly: Disallow variables named like opcodes.
Type checker: Allow multiple events of the same name (but with different arities or argument types)
Natspec parser: Fix error with @param parsing and whitespace.
ethsol.0-4-8.2017-01-13:
Features:
Optimiser: Performance improvements.
Output: Print assembly in new standardized Solidity assembly format.
Bugfixes:
Remappings: Prefer longer context over longer prefix.
Type checker, code generator: enable access to events of base contracts' names.
Imports: import ".dir/a" is not a relative path. Relative paths begin with directory . or ...
Type checker, disallow inheritances of different kinds (e.g. a function and a modifier) of members of the same name
ethsol.0-4-7.2016-12-15:
Features:
Bitshift operators.
Type checker: Warn when msg.value is used in non-payable function.
Code generator: Inject the Swarm hash of a metadata file into the bytecode.
Code generator: Replace expensive memcpy precompile by simple assembly loop.
Optimizer: Some dead code elimination.
Bugfixes:
Code generator: throw if calling the identity precompile failed during memory (array) copying.
Type checker: string literals that are not valid UTF-8 cannot be converted to string type
Code generator: any non-zero value given as a boolean argument is now converted into 1.
AST Json Converter: replace VariableDefinitionStatement nodes with VariableDeclarationStatement
AST Json Converter: fix the camel case in ElementaryTypeNameExpression
AST Json Converter: replace public field with visibility in the function definition nodes
ethsol.0-4-6.2016-11-22:
Bugfixes:
Optimizer: Knowledge about state was not correctly cleared for JUMPDESTs (introduced in 0.4.5)
ethsol.0-4-5.2016-11-21:
Features:
Function types
Do-while loops: support for a do <block> while (<expr>); control structure
Inline assembly: support invalidJumpLabel as a jump label.
Type checker: now more eagerly searches for a common type of an inline array with mixed types
Code generator: generates a runtime error when an out-of-range value is converted into an enum type.
Bugfixes:
Inline assembly: calculate stack height warning correctly even when local variables are used.
Code generator: check for value transfer in non-payable constructors.
Parser: disallow empty enum definitions.
Type checker: disallow conversion between different enum types.
Interface JSON: do not include trailing new line.
ethsol.0-4-4.2016-10-31:
Bugfixes:
Type checker: forbid signed exponential that led to an incorrect use of EXP opcode.
Code generator: properly clean higher order bytes before storing in storage.
ethsol.0-4-3.2016-10-25:
Features:
Inline assembly: support both suicide and selfdestruct opcodes (note: suicide is deprecated).
Inline assembly: issue warning if stack is not balanced after block.
Include keccak256() as an alias to sha3().
Support shifting constant numbers.
Bugfixes:
Commandline interface: Disallow unknown options in solc.
Name resolver: Allow inheritance of enum definitions.
Type checker: Proper type checking for bound functions.
Type checker: fixed crash related to invalid fixed point constants
Type checker: fixed crash related to invalid literal numbers.
Type checker: super.x does not look up x in the current contract.
Code generator: expect zero stack increase after super as an expression.
Code generator: fix an internal compiler error for L.Foo for enum Foo defined in library L.
Code generator: allow inheritance of enum definitions.
Inline assembly: support the address opcode.
Inline assembly: fix parsing of assignment after a label.
Inline assembly: external variables of unsupported type (such as this, super, etc.) are properly detected as unusable.
Inline assembly: support variables within modifiers.
Optimizer: fix related to stale knowledge about SHA3 operations
ethsol.0-4-2.2016-09-17:
Bugfixes:
Code Generator: Fix library functions being called from payable functions.
Type Checker: Fixed a crash about invalid array types.
Code Generator: Fixed a call gas bug that became visible after version 0.4.0 for calls where the output is larger than the input.
ethsol.0-4-1.2016-09-09:
Build System: Fixes to allow library compilation.
ethsol.0-4-0.2016-09-08:
This release deliberately breaks backwards compatibility mostly to enforce some safety features.
The most important change is that you have to explicitly specify if functions can receive ether via the payable modifier.
Furthermore, more situations cause exceptions to be thrown.
Minimal changes to be made for upgrade:
Add payable to all functions that want to receive Ether (including the constructor and the fallback function).
Change _ to _; in modifiers.
Add version pragma to each file: pragma solidity ^0.4.0;
Breaking Changes:
Source files have to specify the compiler version they are compatible with using e.g. pragma solidity ^0.4.0; or pragma solidity >=0.4.0 <0.4.8;
Functions that want to receive Ether have to specify the new payable modifier (otherwise they throw).
Contracts that want to receive Ether with a plain "send" have to implement a fallback function with the payable modifier. Contracts now throw if no payable fallback function is defined and no function matches the signature.
Failing contract creation through "new" throws.
Division / modulus by zero throws.
Function call throws if target contract does not have code
Modifiers are required to contain _ (use if (false) _ as a workaround if needed).
Modifiers: return does not skip part in modifier after _.
Placeholder statement _ in modifier now requires explicit ;.
ecrecover now returns zero if the input is malformed (it previously returned garbage).
The constant keyword cannot be used for constructors or the fallback function.
Removed --interface (Solidity interface) output option
JSON AST: General cleanup, renamed many nodes to match their C++ names.
JSON output: srcmap-runtime renamed to srcmapRuntime.
Moved (and reworked) standard library contracts from inside the compiler to github.com/ethereum/solidity/std (import "std"; or import owned; do not work anymore).
Confusing and undocumented keyword after was removed.
New reserved words: abstract, hex, interface, payable, pure, static, view.
Features:
Hexadecimal string literals: hex"ab1248fe"
Internal: Inline assembly usable by the code generator.
Commandline interface: Using - as filename allows reading from stdin.
Interface JSON: Fallback function is now part of the ABI.
Interface: Version string now semver compatible.
Code generator: Do not provide "new account gas" if we know the called account exists.
Bugfixes:
JSON AST: Nodes were added at wrong parent
Why3 translator: Crash fix for exponentiation
Commandline Interface: linking libraries with underscores in their name.
Type Checker: Fallback function cannot return data anymore.
Code Generator: Fix crash when sha3() was used on unsupported types.
Code Generator: Manually set gas stipend for .send(0).
Lots of changes to the documentation mainly by voluntary external contributors.
ethsol.0-3-6.2016-08-10:
Features:
Formal verification: Take external effects on a contract into account.
Type Checker: Warning about unused return value of low-level calls and send.
Output: Source location and node id as part of AST output
Output: Source location mappings for bytecode
Output: Formal verification as part of json compiler output.
Bugfixes:
Commandline Interface: Do not crash if input is taken from stdin.
Scanner: Correctly support unicode escape codes in strings.
JSON output: Fix error about relative / absolute source file names.
JSON output: Fix error about invalid utf8 strings.
Code Generator: Dynamic allocation of empty array caused infinite loop.
Code Generator: Correctly calculate gas requirements for memcpy precompile.
Optimizer: Clear known state if two code paths are joined.
ethsol.0-3-5.2016-06-10:
Features:
Context-dependent path remappings (different modules can use the same library in different versions)
Bugfixes:
Type Checking: Dynamic return types were removed when fetching data from external calls, now they are replaced by an "unusable" type.
Type Checking: Overrides by constructors were considered making a function non-abstract.
ethsol.0-3-4.2016-05-31:
No change outside documentation.
ethsol.0-3-3.2016-05-27:
Allow internal library functions to be called (by "inlining")
Fractional/rational constants (only usable with fixed point types, which are still in progress)
Inline assembly has access to internal functions (as jump labels)
Running solc without arguments on a terminal will print help.
Bugfix: Remove some non-determinism in code generation.
Bugfix: Corrected usage of not / bnot / iszero in inline assembly
Bugfix: Correctly clean bytesNN types before comparison
ethsol.0-3-2.2016-04-18:
Bugfix: Inline assembly parser: byte opcode was unusable
Bugfix: Error reporting: tokens for variably-sized types were not converted to string properly
Bugfix: Dynamic arrays of structs were not deleted correctly.
Bugfix: Static arrays in constructor parameter list were not decoded correctly.
ethsol.0-3-1.2016-03-31:
Inline assembly
Bugfix: Code generation: array access with narrow types did not clean higher order bits
Bugfix: Error reporting: error reporting with unknown source location caused a crash
ethsol.0.3.0.2016-03-11:
BREAKING CHANGES:
Added new keywords assembly, foreign, fixed, ufixed, fixedNxM, ufixedNxM (for various values of M and N), timestamp
Number constant division does not round to integer, but to a fixed point type (e.g. 1 / 2 != 1, but 1 / 2 == 0.5).
Library calls now default to use DELEGATECALL (e.g. called library functions see the same value as the calling function for msg.value and msg.sender).
<address>.delegatecall as a low-level calling interface
Bugfixes:
Fixed a bug in the optimizer that resulted in comparisons being wrong.
ethsol.0-2-2.2016-02-17:
Index access for types bytes1, ..., bytes32 (only read access for now).
Bugfix: Type checker crash for wrong number of base constructor parameters.
ethsol.0-2-1.2016-01-30:
Inline arrays, i.e. var y = [1,x,f()]; if there is a common type for 1, x and f(). Note that the result is always a fixed-length memory array and conversion to dynamic-length memory arrays is not yet possible.
Import similar to ECMAScript6 import (import "abc.sol" as d and import {x, y} from "abc.sol").
Commandline compiler solc automatically resolves missing imports and allows for "include directories".
Conditional: x ? y : z
Bugfix: Fixed several bugs where the optimizer generated invalid code.
Bugfix: Enums and structs were not accessible to other contracts.
Bugfix: Fixed segfault connected to function paramater types, appeared during gas estimation.
Bugfix: Type checker crash for wrong number of base constructor parameters.
Bugfix: Allow function overloads with different array types.
Bugfix: Allow assignments of type (x) = 7.
Bugfix: Type uint176 was not available.
Bugfix: Fixed crash during type checking concerning constructor calls.
Bugfix: Fixed crash during code generation concerning invalid accessors for struct types.
Bugfix: Fixed crash during code generating concerning computing a hash of a struct type.
ethsol.0.2.0.2015-12-02:
Breaking Change: new ContractName.value(10)() has to be written as (new ContractName).value(10)()
Added selfdestruct as an alias for suicide.
Allocation of memory arrays using new.
Binding library functions to types via using x for y
addmod and mulmod (modular addition and modular multiplication with arbitrary intermediate precision)
Bugfix: Constructor arguments of fixed array type were not read correctly.
Bugfix: Memory allocation of structs containing arrays or strings.
Bugfix: Data location for explicit memory parameters in libraries was set to storage.
ethsol.0-1-7.2015-11-17:
Improved error messages for unexpected tokens.
Proof-of-concept transcompilation to why3 for formal verification of contracts.
Bugfix: Arrays (also strings) as indexed parameters of events.
Bugfix: Writing to elements of bytes or string overwrite others.
Bugfix: "Successor block not found" on Windows.
Bugfix: Using string literals in tuples.
Bugfix: Cope with invalid commit hash in version for libraries.
Bugfix: Some test framework fixes on windows.
ethsol.0-1-6.2015-10-16:
.push() for dynamic storage arrays.
Tuple expressions ((1,2,3) or return (1,2,3);)
Declaration and assignment of multiple variables (var (x,y,) = (1,2,3,4,5); or var (x,y) = f();)
Destructuring assignment ((x,y,) = (1,2,3))
Bugfix: Internal error about usage of library function with invalid types.
Bugfix: Correctly parse Library.structType a at statement level.
Bugfix: Correctly report source locations of parenthesized expressions (as part of "tuple" story).
ethsol.0-1-5.2015-10-07:
Breaking change in storage encoding: Encode short byte arrays and strings together with their length in storage.
Report warnings
Allow storage reference types for public library functions.
Access to types declared in other contracts and libraries via ..
Version stamp at beginning of runtime bytecode of libraries.
Bugfix: Problem with initialized string state variables and dynamic data in constructor.
Bugfix: Resolve dependencies concerning new automatically.
Bugfix: Allow four indexed arguments for anonymous events.
Bugfix: Detect too large integer constants in functions that accept arbitrary parameters.
ethsol.0-1-4.2015-09-30:
Bugfix: Returning fixed-size arrays.
Bugfix: combined-json output of solc.
Bugfix: Accessing fixed-size array return values.
Bugfix: Disallow assignment from literal strings to storage pointers.
Refactoring: Move type checking into its own module.
ethsol.0-1-3.2015-09-25:
throw statement.
Libraries that contain functions which are called via CALLCODE.
Linker stage for compiler to insert other contract's addresses (used for libraries).
Compiler option to output runtime part of contracts.
Compile-time out of bounds check for access to fixed-size arrays by integer constants.
Version string includes libevmasm/libethereum's version (contains the optimizer).
Bugfix: Accessors for constant public state variables.
Bugfix: Propagate exceptions in clone contracts.
Bugfix: Empty single-line comments are now treated properly.
Bugfix: Properly check the number of indexed arguments for events.
Bugfix: Strings in struct constructors.
ethsol.0-1-2.2015-08-20:
Improved commandline interface.
Explicit conversion between bytes and string.
Bugfix: Value transfer used in clone contracts.
Bugfix: Problem with strings as mapping keys.
Bugfix: Prevent usage of some operators.
ethsol.0-1-1.2015-08-04:
Strings can be used as mapping keys.
Clone contracts.
Mapping members are skipped for structs in memory.
Use only a single stack slot for storage references.
Improved error message for wrong argument count. (#2456)
Bugfix: Fix comparison between bytesXX types. (#2087)
Bugfix: Do not allow floats for integer literals. (#2078)
Bugfix: Some problem with many local variables. (#2478)
Bugfix: Correctly initialise string and bytes state variables.
Bugfix: Correctly compute gas requirements for callcode.
ethsol.0.2014.10:
Solidity was started in October 2014 when neither the Ethereum network nor the virtual machine had any real-world testing, the gas costs at that time were even drastically different from what they are now.
Furthermore, some of the early design decisions were taken over from Serpent.
[https://blog.ethereum.org/2016/06/10/smart-contract-security/]
name::
* McsEngl.ethctp'language.Serpent (ethspt)@cptIt,
* McsEngl.ethspt@cptIt,
* McsEngl.serpent-ethctp-lang@cptIt,
_DESCRIPTION:
Serpent is a language similar to Python which can be used to develop contracts and compile to EVM bytecode. It is intended to be maximally clean and simple, combining many of the efficiency benefits of a low-level language with ease-of-use in programming style, and at the same time adding special domain-specific features for contract programming. Serpent is compiled using LLL.
Serpent on the ethereum wiki
Serpent EVM compiler
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/contracts.html#serpent]
_ADDRESS.WPG:
* https://github.com/ethereum/serpent,
* https://github.com/ethereum/wiki/wiki/Serpent,
* http://mc2-umd.github.io/ethereumlab/docs/serpent_tutorial.pdf {2015-05-21},
name::
* McsEngl.ethctp'language.LLL (ethlll)@cptIt,
* McsEngl.ethlll@cptIt,
* McsEngl.lecLll@cptIt,
* McsEngl.ethnet'LLL@cptIt,
* McsEngl.Lisp-Like-Language@cptIt,
* McsEngl.LLL-ethctp-lang@cptIt,
_DESCRIPTION:
LLL is a thin layer on top of the EVM that resembles Lisp. All EVM opcodes are available in LLL. On top of that it provides control structures (for, when, if, etc.) that are difficult and confusing to do in assembler. It also provides other convenient abstractions such a macros, and has the ability to include other source files as well.
[http://blog.syrinx.net/the-resurrection-of-lll-part-1//]
===
Lisp Like Language (LLL) is a low level language similar to Assembly. It is meant to be very simple and minimalistic; essentially just a tiny wrapper over coding in EVM directly.
LIBLLL in GitHub
Examples of LLL
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/contracts.html#id4]
===
There does not appear to be active development on LLL as the Ethereum Foundation has identified Solidity as it's primary language that will receive development support from them. However, it is not "dead" in the sense that there are still bug fixes and small changes happening to the repository infrequently.
Interesting side note: Inline ASM may be eventually supported in the Solidity Ethereum language.
Vitalik Buterin said in Nov. 2015:
LLL was always meant to be very simple and minimalistic; essentially just a tiny wrapper over coding in ASM directly. In my opinion just use serpent; it has direct access to opcodes so it is a superset of LLL but it also has a whole bunch of high-level features as well for when you want them. The downside is that the compiler is more complex and so theoretically might contain more bugs.
[http://ethereum.stackexchange.com/a/519]
name::
* McsEngl.ethlll'Compiler@cptIt,
_DESCRIPTION:
Solidity has been separated from the cpp-ethereum repository. For now, all LLL libraries and the compiler itself are contained in the Solidity repository.
[http://blog.syrinx.net/the-resurrection-of-lll-part-7//]
===
The LLL compiler is contained in the Ethereum C++ client, cpp-ethereum. This page [http://www.ethdocs.org/en/latest/ethereum-clients/cpp-ethereum/] has extensive instructions on its installation for various platforms.
[http://blog.syrinx.net/the-resurrection-of-lll-part-2//]
name::
* McsEngl.ethlll'Resource@cptIt,
_ADDRESS.WPG:
* forum: https://forum.ethereum.org/categories/lll,
* examples: http://ether.fund/contracts/lll,
* examples: https://github.com/androlo/EthereumContracts,
* http://blog.syrinx.net/the-resurrection-of-lll-part-1//
* https://github.com/ethereum/cpp-ethereum/wiki/LLL-PoC-6/04fae9e627ac84d771faddcf60098ad09230ab58,
* https://github.com/ethereum/cpp-ethereum/wiki/LLL-Examples-for-PoC-5/04fae9e627ac84d771faddcf60098ad09230ab58,
name::
* McsEngl.ethctp'language.VIPER (ethvpr)@cptIt,
* McsEngl.ethvpr@cptIt,
* McsEngl.lagViper@cptIt,
* McsEngl.Viper-ethctp-lang@cptIt,
_DESCRIPTION:
Viper is an experimental programming language that aims to provide the following features:
Bounds and overflow checking, both on array accesses and on arithmetic
Support for signed integers and decimal fixed point numbers
Decidability - it's possible to compute a precise upper bound on the gas consumption of any function call
Strong typing, including support for units (eg. timestamp, timedelta, seconds, wei, wei per second, meters per second squared)
Maximally small and understandable compiler code size
Limited support for pure functions - anything marked constant is NOT allowed to change the state
[https://github.com/ethereum/viper]
name::
* McsEngl.ethctp'ABI (ethabi)@cptIt,
* McsEngl.ethABI@cptIt,
* McsEngl.ethevm'ABI@cptIt,
* McsEngl.ABI-EVM@cptIt,
* McsEngl.Application-Binary-Interface@cptIt,
_DESCRIPTION:
The JSON is called an ABI.
You do need the source code, as you have, and one way to get the ABI is to paste it in Solidity Browser, then copy the Interface value.
[http://ethereum.stackexchange.com/a/3150]
===
ABI stands for application binary interface.
In general, an ABI is the interface between two program modules, one of which is often at the level of machine code. The interface is the de facto method for encoding/decoding data into/out of the machine code.
In ethereum, it's basicly how you can encode solidity contracts for the EVM and backwards how to read the data out of transactions.
[http://ethereum.stackexchange.com/a/235]
name::
* McsEngl.ethabi'Resource@cptIt,
_ADDRESS.WPG::
* https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI,
* http://ethereum.stackexchange.com/questions/234/what-is-an-abi-and-why-is-it-needed-to-interact-with-contracts,
* http://ethereum.stackexchange.com/questions/3149/how-do-you-get-a-json-file-abi-from-a-known-contract-address,
name::
* McsEngl.ethctp'Security@cptIt,
* McsEngl.ethctp'security@cptIt,
_DESCRIPTION:
But we've recently seen how easy it is to cause chaos with one misplaced line of code.
Add to that the myriad of security concerns and the difficulty in addressing them and you have a system not suitable for casual developers, especially with real money at stake.
You have to be invested, so to speak, to develop secure contracts.
[http://blog.syrinx.net/the-resurrection-of-lll-part-1/]
===
Some problems you should be aware of (and avoid):
Reentrancy [http://hackingdistributed.com/2016/07/13/reentrancy-woes/]: Do not perform external calls in contracts. If you do, ensure that they are the very last thing you do.
Send can fail [http://vessenes.com/ethereum-griefing-wallets-send-w-throw-considered-harmful//]: When sending money, your code should always be prepared for the send function to fail.
Loops can trigger gas limit [http://solidity.readthedocs.io/en/latest/security-considerations.html#gas-limit-and-loops]: Be careful when looping over state variables, which can grow in size and make gas consumption hit the limits.
Call stack depth limit [https://ethereum.stackexchange.com/questions/6260/solidity-callstack-attack]: Don’t use recursion, and be aware that any call can fail if stack depth limit is reached.
Timestamp dependency [https://github.com/ConsenSys/smart-contract-best-practices#timestamp-dependence]: Do not use timestamps in critical parts of the code, because miners can manipulate them.
These are provided just as examples of unexpected behaviors that can lead for theft or destruction of funds in your smart contract. The morale is: if you’re writing smart contracts, you’re writing code that handles real money. You should be very careful! Write tests, do code reviews, and audit your code.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#5ae8]
_ADDRESS.WPG:
* {2016-10-16} https://medium.com/@MyPaoG/explaining-the-dao-exploit-for-beginners-in-solidity-80ee84f0d470#.r1xgn4jov,
* {>2016.06} Making Smart Contracts Smarter http://www.comp.nus.edu.sg/~loiluu/papers/oyente.pdf,
* {2016-06-21} https://medium.com/@hrishiolickel/why-smart-contracts-fail-undiscovered-bugs-and-what-we-can-do-about-them-119aa2843007#.rucpuv5wz,
* {2016-06-19} https://blog.ethereum.org/2016/06/19/thinking-smart-contract-security//
* {2016-06-10} https://blog.ethereum.org/2016/06/10/smart-contract-security//
* {2016-05-27} A Call for a Temporary Moratorium on The DAO http://hackingdistributed.com/2016/05/27/dao-call-for-moratorium//
_DESCRIPTION:
Dynamic Analysis is the process of executing code and data in real-time with the hope of finding issues during execution. It's a similar process to exploratory testing, with the same goals, but perhaps more technical.Dynamic analysis on the Ethereum blockchain has historically been costly at worst and tedious at best. If you were to perform dynamic analysis on the live Ethereum chain, transactions would cost you hard-earned Ether, which might limit the tests you perform. Moving away from the live chain is possible, but it's a tedious process to move the live data over to a separate chain, and you'd have to perform this process multiple times if you end up mucking with the chain state during testing.
[http://truffleframework.com/tutorials/chain-forking-exploiting-the-dao#what-is-dynamic-analysis-]
name::
* McsEngl.ethctp'Tool@cptIt,
name::
* McsEngl.ethctp'tool.DISASSEMBLER@cptIt,
* McsEngl.ethctp'disassember@cptIt,
_SPECIFIC:
* https://github.com/Arachnid/evmdis,
name::
* McsEngl.ethctp'Organization@cptIt,
name::
* McsEngl.DappHub-ogn@cptIt,
_DESCRIPTION:
DappHub is one of the oldest smart contract development firms in the Ethereum space, first formed to create the MakerDAO stablecoin contract system. As a group with a profound understanding of Ethereum’s smart contracts ecosystem, they were a natural choice when looking for a code audit.
[http://www.newsbtc.com/2017/02/13/makerdao-saviour-nikolai-mushegian-audit-time-lh-tokens/]
name::
* McsEngl.ethctp'Resource@cptIt,
_ADDRESS.WPG:
* https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial,
* A 101 Noob Intro to Programming Smart Contracts on Ethereum
http://consensys.github.io/developers/articles/101-noob-intro//
* http://etherparty.io// Etherparty is a platform that removes the complexity and management of creating and executing smart contracts
* {2015-10-29} https://medium.com/@ConsenSys/a-101-noob-intro-to-programming-smart-contracts-on-ethereum-695d15c1dab4#.mnbfhharn,
* {2016-07-29} https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05,
name::
* McsEngl.ethctp'STATE@cptIt,
_DESCRIPTION:
Contracts have state and functions.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#5ae8]
name::
* McsEngl.ethctp'DOING@cptIt,
name::
* McsEngl.ethctp'doing.EXECUTING@cptIt,
* McsEngl.ethctp'executing@cptIt,
_DESCRIPTION:
The-Ethereum-Virtual-Machine-(EVM)#ql:ethevm# is where smart contracts run in Ethereum.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#262d]
name::
* McsEngl.ethctp'doing.DEVELOPING@cptIt,
* McsEngl.ethctp'developing@cptIt,
_DESCRIPTION:
Well, smart contract development is not a breeze, but it can be made much more efficient by the use of testrpc. Running a full Ethereum client (geth, eth, pyethapp, parity, etc.) can be a drain on a developer's resources, especially if running on an under-powered machine. Also, unless you set up a private network and tweak the settings, you have to wait a while for blocks to be mined before checking the results of your transactions. If you're connected to the main Homestead network you'll also be paying for your development testing with real digital currency. No, it's better to start simply and install ethereumjs/testrpc. Go ahead and follow the instructions in the README file to install it on your local machine.
[http://blog.syrinx.net/the-resurrection-of-lll-part-7//]
name::
* McsEngl.ethctp'doing.CREATING@cptIt,
* McsEngl.entmsmc'creating@cptIt,
* McsEngl.ethctp'creating@cptIt,
* McsEngl.ethctp'writing@cptIt,
_DESCRIPTION:
Finally, before we get started it is important to know this: Writing smart contracts can be tricky. The transition from normal code writing to smart contract writing is not seamless. The environment in which smart contract code runs is different from that of normal code. The analogy with webservices is good, because it makes smart contracts and systems of smart contracts more tangible, and it makes it simpler to use already existing concepts and tools when working with them, but writing the actual code is still difficult.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features//]
===
In part 1 of this series I introduced the idea that we may need to change the mindset of smart contract development to emphasize its difference from, well, almost every other type of software development.
[http://blog.syrinx.net/the-resurrection-of-lll-part-2//]
_SPECIFIC:
Contracts can even create other contracts using a special opcode (i.e. they do not simply call the zero address). The only difference between these create calls and normal message calls is that the payload data is executed and the result stored as code and the caller / creator receives the address of the new contract on the stack.
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#create]
name::
* McsEngl.ethctp'doing.COMPILING@cptIt,
* McsEngl.ethctp'compiling@cptIt,
name::
* McsEngl.ethctp'doing.TESTING@cptIt,
* McsEngl.ethctp'testing@cptIt,
name::
* McsEngl.ethctp'doing.DEPLOYING@cptIt,
* McsEngl.ethctp'adding@cptIt,
* McsEngl.ethctp'deploying@cptIt,
* McsEngl.ethctp'uploading@cptIt,
_DESCRIPTION:
When contracts are created, a new account is first made, then the code is loaded into a VM which runs the constructor part, initializes fields etc., and then adds the runtime portion (or body) of the contract to the account.
[https://monax.io/docs/tutorials/solidity/solidity_7_updating_solidity_contracts//]
_ADDRESS.WPG:
* http://hypernephelist.com/2017/01/19/deploy-ethereum-smart-contract-using-client-signature.html,
name::
* McsEngl.ethctp'doing.INTERACTING@cptIt,
* McsEngl.ethctp'interacting@cptIt,
_DESCRIPTION:
Ethereum contracts are stored in special contract accounts, and the contract code is executed when the account is the target of a (successful) transaction.
If I, as a user, want to execute a contract, I first need to find out the address to the account in which the contract is stored, and then transact to it.
The parameters for a transaction are:
The gas-price I want to pay (gasPrice).
The maximum amount of gas that may be spent (gas).
The amount of ether I want to transfer (value).
My account address (from).
The target account address (to).
The nonce (nonce).
The transaction data (data).
Alternatively, it is possible to create the transaction object itself on the caller side, sign it locally, and pass in the signed bytes.
The parameters used above is used when making RPC calls, and the client will then create (and sign) the transaction object for you.
Anyways, if my transaction is valid, the Ethereum client will put that transaction data into a context, along with the current block data and some other things.
It then passes the code of the contract account and the context into a new instance of the EVM, and execute it.
[https://github.com/androlo/solidity-workshop/blob/master/tutorials/2016-03-09-advanced-solidity-I.md#accounts-transactions-and-code-execution]
===
Furthermore, every execution of a smart contract happens in public and, in addition to that, the source code is often available.
[https://solidity.readthedocs.io/en/v0.4.9/security-considerations.html#security-considerations]
===
The popular term “smart contracts” refers to code in a Contract Account – programs that execute when a transaction is sent to that account.
[https://ethereum-homestead.readthedocs.io/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]
name::
* McsEngl.ethctp'doing.UPDATING@cptIt,
* McsEngl.ethctp'updating@cptIt,
_DESCRIPTION:
Introduction
This tutorial series looks at modular systems of smart-contracts, and how to continuously update the code in a reliable way. Most contracts in your application will become obsolete at some point, and will require an update. Same as in other applications. It could be because new features must be added, a bug is found, or because a better, more optimized version has been made. Updating could of course cause problems so it must be done with care. Some of the things one must ensure is that:
- updating is possible.
- the new contract works as intended.
- all the calls made during the replacement procedure was executed successfully.
- replacing the contract has no side-effects in other parts of the system.
The first point may seem obvious but it usually requires a lot of work, because updating is not possible by default; the reason is because of how accounts, code and storage works.
Accounts, Code and Storage
A very important property of EVM contracts is that when a contract has been uploaded to the chain, the code can never be changed. Contracts are stored in special account objects, and these object has references to the contract (byte) code, and a database, and some other things. The database is a key-value store, also known as ‘storage’, and is where data such as the values of contract fields is stored.
When contracts are created, a new account is first made, then the code is loaded into a VM which runs the constructor part, initializes fields etc., and then adds the runtime portion (or body) of the contract to the account. After that is done, there is no way to change the code, and there is no way to update the database except through that code.
But what if you want to change the code? What if a bug is discovered?
The way you solve that is by connecting several contracts. Contract C could call contract D as part of its functionality, and the address to D could be settable in C, meaning it would be possible to change what D is. This is best explained through a series of simple examples.
A simple storage contract
contract Data {
uint public data;
function addData(uint data_) {
if(msg.sender == 0x692a70d2e424a56d2c6c27aa97d1a86395877b3a)
data = data_;
}
}
This simple contract allows a user to add and read an unsigned integer. The only account that is allowed to add data is the account with address 0x692a.... This address is a hex literal, so is added to the bytecode when the contract is compiled.
A potential problem is that we might want to replace this address later, or even the entire validation procedurer, but we can’t because of how code and storage works. A simple way of making the contract more flexible is to store the current owner address in storage instead, and make it possible to change.
contract DataOwnerSettable {
uint public data;
address public owner = msg.sender;
function addData(uint data_) {
if(msg.sender == owner)
data = data_;
}
function setOwner(address owner_) {
if(msg.sender == owner)
owner = owner_;
}
}
This contract has an owner field (mapped to storage). It is initialized with the address of the account that creates the contract, and can later be changed by the current owner by calling setOwner. The guard inside addData is still the same; the only thing that changed is that the owner address is no longer hard-coded.
Delegation
What if a settable owner is not enough, though? What if we want to be able to update not only the owner address, but the entire validation process? That is possible. We will do it in two steps. First we move the account validation code into a different contract.
contract AccountValidator {
address public owner = msg.sender;
function validate(address addr) constant returns (bool) {
return addr == owner;
}
function setOwner(address owner_) {
if(msg.sender == owner)
owner = owner_;
}
}
contract DataExternalValidation {
uint public data;
AccountValidator _validator;
function DataExternalValidation(address validator) {
_validator = AccountValidator(validator);
}
function addData(uint data_) {
if(_validator.validate(msg.sender))
data = data_;
}
function setValidator(address validator) {
if(_validator.validate(msg.sender))
_validator = AccountValidator(validator);
}
}
To use this, we first create an AccountValidator contract; it has the owner field now, and that field is automatically initialized with an account address. Then we create a DataExternalValidation-contract and inject the address of the validator through the contract constructor. When someone tries to write to data, it will call the validate function of the current validator contract to do the check rather then storing (or hard coding) the owner address and doing the equality check internally. Everything that has to do with access control is now delegated to the validator contract.
This is very nice, because it is now possible to replace the contract that does the actual check. Not only does it decouple this from the data, but since the AccountValidator is its own contract, we could potentially use that contract in other contracts as well and thus give owner control over more contracts then just one.
One thing remains though. We still can’t replace the code! All we have done is move the validation code out of the contract. The code of the AccountValidator contract can’t be changed anymore then that of the data contract. Fortunately, Solidity provides a very simple and powerful workaround - abstract functions.
Abstract Functions
Using abstract functions, the validator contract could be changed into this:
contract AccountValidator {
function validate(address addr) constant returns (bool);
}
contract SingleAccountValidator is AccountValidator {
address public owner = msg.sender;
function validate(address addr) constant returns (bool) {
return addr == owner;
}
function setOwner(address owner_) {
if(msg.sender == owner)
owner = owner_;
}
}
With these contracts, the data contract no longer works with a concrete validator contract, but an abstract (interface) representation. This makes sense, because it does not really needs to know what the validate function actually does, it only needs to know the signature.
Interfaces works the same way as it does in most other object-oriented languages, just declare functions without a body and they become abstract.
We still can’t change the code stored in a contract account, but we can change the code that is executed when a function is called, by delegating some functionality to other contract which are allowed to be replaced; all we need to do is change the validator contract to a different contract. For example, if we want to allow more owners then one we could use an instance of this contract:
contract MultiAccountValidator is AccountValidator {
mapping(address => bool) public owners;
function MultiAccountValidator() {
owners[msg.sender] = true;
}
function validate(address addr) constant returns (bool) {
return owners[addr];
}
function addOwner(address addr) {
if(owners[msg.sender])
owners[addr] = true;
}
}
Summary
Proper delegation is an important part of smart-contract systems. It is also something one has to consider from the very start, because the rules for how a set of contracts can be updated is generally contained in the contracts themselves. Also, the more contracts that are in the system the harder they become to manage, and a strategy that makes a small system work may not be suitable for a medium-sized or large one.
Another thing to keep in mind is that modularity comes with a cost, because it requires more code, storage variables and calls. On the public chain, where the gas limitations are quite severe (for obvious reasons), even a small modular system could be hard to deploy and run. Generally, when it comes to scalability vs. efficiency I tend to go with scalability. The large, expensive contracts in an excessively modular system can after all be improved and replaced, but if the contracts are locked down that may not be an option.
In our opinion, it is very important to at least acknowledge that the code is going to need updates, and at some point there must be a good policy for how it can be done. The alternative is to not have a plan and fail. And then maybe fail again, and again, until eventually it becomes clear.
[https://monax.io/docs/tutorials/solidity/solidity_7_updating_solidity_contracts//]
name::
* McsEngl.ethctp'doing.REMOVING@cptIt,
* McsEngl.ethctp'removing@cptIt,
_DESCRIPTION:
The HelloSystem contract can be deployed as-is without any problems, but once it’s been deployed it will remain on the chain for good. We need a way to remove it. In Solidity, the command for removing (or suiciding) a contract is this: selfdestruct(addr). The argument here is the address to which any remaining funds should be sent. In order to expose this functionality, we need to put it inside a (implicitly public) function. This is what a selfdestruct function could look like in HelloSystem:
contract HelloSystem {
function remove() {
selfdestruct(msg.sender);
}
}
What this would do is to remove the contract when the remove function is called, and it would return any funds it may have to the caller. Needless to say, this is not ideal. Normally when you add a selfdestruct function you want to restrict the access to it. The simplest way of doing it is to store the address of the contract creator when the contract is deployed, and only allow the creator to call selfdestruct on it. Here is how that could be implemented:
contract HelloSystem {
address owner;
// Constructor
function HelloSystem(){
owner = msg.sender;
}
function remove() {
if (msg.sender == owner){
selfdestruct(owner);
}
}
}
Note that msg.sender is not the same in the constructor as it is in the remove function. The constructor is called when the contract is added, so msg.sender will be the contract creator, but in all other functions it will be the address of the account that is calling it.
name::
* McsEngl.ethctp'doing.SERVICE@cptIt,
* McsEngl.ethctp'service@cptIt,
_SPECIFIC:
As you will see, it is possible to create contracts for voting, crowdfunding, blind auctions, multi-signature wallets and more.
[https://solidity.readthedocs.io/en/v0.4.9/]
===
Think of a “contract” as a program that provides services such as: voting systems, domain
name registries, financial exchanges, crowdfunding platforms, company governance, selfenforcing
contracts and agreements, intellectual property, smart property, and distributed
autonomous organizations.
[http://mc2-umd.github.io/ethereumlab/docs/serpent_tutorial.pdf]
===
Early work on smart contracts has been done by Szabo[1997] and Miller [1997].
Around the 1990s it became clear that algorithmic enforcement of agreements could become a significant force in human cooperation.
Though no specific system was proposed to implement such a system, it was proposed that the future of law would be heavily affected by such systems.
In this light, Ethereum may be seen as a general implementation of such a crypto-law system.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
name::
* McsEngl.ethctp.specific@cptIt,
* McsEngl.ethctp.specific@cptIt,
_SPECIFIC:
* examples: https://github.com/fivedogit/solidity-baby-steps,
name::
* McsEngl.ethctp.SPECIFIC-DIVISION.code@cptIt,
_SPECIFIC:
* Binary-program#ql:idEthctpBnr#,
* Assembly-program#ql:idEthctpAsm#,
* Sourcecode-program#ql:idEthctpScc#
name::
* McsEngl.ethctp.SPECIFIC-DIVISION.5-types-model@cptIt,
_SPECIFIC:
There are many different ways to classify contracts, but we’re going to use what I call “the five types model”. It is a simple model where contracts are divided up into five basic categories:
1) Database contracts
These are used only as data storage. The only logic they need is functions that allow other contracts to write, update and get data, and some simple way of checking caller permissions (whatever those permissions may be).
2) Controller contracts
These contracts operate on the storage contracts. In a flexible system, both controllers and databases can be replaced by other, similar contracts that share the same public api (although this is not always needed). Controllers can be advanced, and could for example do batched reads/writes, or read from and write to multiple different databases instead of just one.
3) Contract managing contracts (CMCs)
The purpose of these contracts is only to manage other contracts. Their main tasks is to keep track of all the contracts/components of the system, handle the communication between these components, and to make modular design easier. Keeping this functionality separate from normal business logic should be considered good practice, and has a number of positive effects on the system (as we will see later).
4) Application logic contracts (ALCs)
Application logic contracts contains application-specific code. Generally speaking, if the contract utilizes controllers and other contracts to perform application specific tasks it’s an ALC.
5) Utility contracts
These type of contracts usually perform a specific task, and can be called by other contracts without restrictions. It could be a contract that hashes strings using some algorithm, provide random numbers, or other things. They normally don’t need a lot of storage, and often have few or no dependencies.
The rationale for this division will be laid out after we’ve tried to apply it to the fund manager system, as it will be a lot more clear then.
[https://monax.io/docs/tutorials/solidity/solidity_1_the_five_types_model//]
name::
* McsEngl.ethctp.code.BINARY (ethctpbnr)@cptIt,
* McsEngl.ethact'code@cptIt,
* McsEngl.ethctp.binary@cptIt,
* McsEngl.ethctp.bytecode@cptIt,
* McsEngl.ethctpbnr@cptIt,
* McsEngl.ethevm'contract@cptIt,
* McsEngl.eth'evm-bytecode@cptIt,
* McsEngl.ethevm'code@cptIt,
* McsEngl.ethevm'codeBinary@cptIt,
* McsEngl.EVM-bytecode@cptIt,
_DESCRIPTION:
Contracts live on the blockchain in an Ethereum-specific binary format (EVM bytecode).
However, contracts are typically written in an Ethereum high level language, compiled into byte code using an EVM compiler, and finally uploaded on the blockchain using an Ethereum client.
[https://ethereum-homestead.readthedocs.org/en/latest/contracts-and-transactions/developer-tools.html#the-evm]
_DESCRIPTION:
Note that in reality the contract code is written in the low-level EVM code;
[https://github.com/ethereum/wiki/wiki/White-Paper#ethereum-state-transition-function]
===
When Ethereum contracts are compiled down to byte-code the convention is not to represent them as binary, but instead to represent them as a single long hex string like the following:
6060604052600a8060106000396000f360606040526008565b00
This is the compiled byte-code for the following solidity contract:
contract Test {
}
[https://ericscrivner.me/2016/07/lets-write-ethereum-virtual-machine-disassembler//]
name::
* McsEngl.ethctpbnr'Storage@cptIt,
_DESCRIPTION:
Programs are not stored in memory, but instead can be considered to be stored in a separate virtual read-only memory (ROM) that is accessible only through a special instruction – CODECOPY – which copies the program into main memory.
[https://ericscrivner.me/2016/07/lets-write-ethereum-virtual-machine-disassembler//]
name::
* McsEngl.ethctp.code.ASSEMBLY (ethctpasm)@cptIt,
* McsEngl.ethctp.assembly@cptIt,
* McsEngl.ethctpasm@cptIt,
_DESCRIPTION:
A program in EVM is a sequence of opcodes, like this:
PUSH1 0 CALLDATALOAD SLOAD NOT PUSH1 9 JUMPI STOP JUMPDEST PUSH1 32 CALLDATALOAD PUSH1 0 CALLDATALOAD SSTORE
[https://ethereum.gitbooks.io/frontier-guide/content/opcodes,_costs,_and_gas.html]
name::
* McsEngl.ethctp.code.SOURCE@cptIt,
* McsEngl.ethctp.sourcecode@cptIt,
name::
* McsEngl.ethctp.VERIFIED@cptIt,
_DESCRIPTION:
Verify and Publish your Solidity Source Code
Step 1 : Enter your Contract Source Code below.
Step 2 : If the Bytecode generated matches the existing Creation Address Bytecode, the contract is then Verified.
Step 3 : Contract Source Code is published online and publicably verifiable by anyone.
NOTES
1. To verify Contracts that accept Constructor arguments, please enter the ABI-encoded Arguments in the last box below.
2. For debugging purposes if it compiles correctly at Browser Solidity, it should also compile correctly here.
3. Contracts that use "imports" will need to have the code concatenated into one file as we do not support "imports" in separate files
[https://etherscan.io/verifyContract]
_ADDRESS.WPG:
* https://etherscan.io/contractsVerified,
* https://etherchain.org/account_verify//
name::
* McsEngl.ethctp.BUY.ICO@cptIt,
_ADDRESS.WPG:
* https://etherscan.io/address/0xcc89405e3cfd38412093840a3ac2f851dd395dfb#code,
name::
* McsEngl.ethctp.DAO@cptIt,
_DESCRIPTION:
Here is just one example: imagine you own a small business with your friends. Lawyers and accountants are expensive, and trusting a single partner to oversee the books can be a source of tension (even an opportunity for fraud). Complying strictly with a system in which more than one partner oversees the books can be trying and is subject to fraud whenever the protocol isn’t followed exactly.
Using a smart contract, ownership in your company and terms for the disbursal of funds can be specified at the outset. The smart contract can be written such that it is only changeable given the approval of a majority of owners. Smart contracts like these will likely be available as open source software, so you won’t even need to hire your own programmer in stead of an accountant/lawyer.
A smart contract like this scales instantly. A couple of teenagers can split revenue from a lemonade stand just as transparently as a sovereign wealth fund can disburse funds to the hundred million citizens who are entitled to it. In both cases the price of this transparency is likely to be fractions of a penny per dollar.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/web3.html#dao]
name::
* McsEngl.ethctp.EMPLOYMENT-AGGREMENT@cptIt,
_DESCRIPTION:
One example of a smart contract would be an employment agreement: A wants to pay $500 to B to build a website. The contract would work as follows: A puts $500 into the contract, and the funds are locked up. When B finishes the website, B can send a message to the contract asking to unlock the funds. If A agrees, the funds are released. If B decides not to finish the website, B can quit by sending a message to relinquish the funds. If B claims that he finished the website, but A does not agree, then after a 7-day waiting period it’s up to judge J to provide a verdict in A or B’s favor.
[https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide/]
name::
* McsEngl.ethctp.EXCHANGE@cptIt,
_ADDRESS.WPG:
* https://github.com/bokkypoobah/TokenTrader/wiki,
name::
* McsEngl.ethctp.NAME-REGISTRY@cptIt,
_DESCRIPTION:
Name registry, or “namereg” contracts generally lets people associate a name with an user account address. This is an example of such a contract:
contract Users {
// Here we store the names. Make it public to automatically generate an
// accessor function named 'users' that takes a fixed-length string as argument.
mapping (bytes32 => address) public users;
// Register the provided name with the caller address.
// Also, we don't want them to register "" as their name.
function register(bytes32 name) {
if(users[name] == 0 && name != ""){
users[name] = msg.sender;
}
}
// Unregister the provided name with the caller address.
function unregister(bytes32 name) {
if(users[name] != 0 && name != ""){
users[name] = 0x0;
}
}
}
When this contract is called, it will use msg.sender and a provided name as parameters. msg.sender refers to the address of the account that made the transaction. name is a fixed-length string that the sender includes in the transaction data. If the name is not already taken, it will be written into users.
This is a very basic but useful contract. It lets you refer to users by name instead of having to use their public address. It could be used as a basis for almost anything. It could use some more functionality, such as being able to list all the registered users, and maybe also make it possible to get a name by address, and not just address by name, and other things.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features//]
name::
* McsEngl.ethctp.WILL-MANAGER@cptIt,
_CODE.
contract WillManager {
address public willOwner;
bytes32 public hashOfWill;
function WillManager(){
willOwner = msg.sender;
}
function newWill(string will) {
if (msg.sender != willOwner) throw;
hashOfWill = sha3(will);
}
function checkWill(string willUserIsChecking) constant returns (bool willIsCorrect) {
return (sha3(willUserIsChecking) == hashOfWill);
}
}
name::
* McsEngl.ethctp.EVOLUTING@cptIt,
_LIFETIME:
Contracts will exist and run as long as the whole network exists, and will only stop if they run out of gas or if they were programmed to self destruct.
[https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial]
name::
* McsEngl.ethnet'Wallet (ethwlt)@cptIt,
* McsEngl.ethnet'wallet@cptIt,
* McsEngl.ethwlt@cptIt,
_SPECIFIC:
* Mist-Ethereum-wallet#ql:idEthwltMst#,
* MyEtherWallet#ql:idEthwltMew#,
* Parity-wallet#ql:idEthpritwlt#,
* Jaxx-wallet#ql:idJaxwlt#
name::
* McsEngl.ethwlt.Mist-ethereum-wallet (ethwltMst)@cptIt,
* McsEngl.ethwlt.ethereum-wallet@cptIt,
* McsEngl.ethwltMst@cptIt, {2017-04-02}
* McsEngl.mist-ethereum-wallet@cptIt,
* McsEngl.mewlt@cptIt,
_DESCRIPTION:
Ethereum wallet is a wallet, Mist is a browser.
===
The Mist Browser includes the Ethereum Wallet. The Ethereum Wallet is the Mist Browser with the browser function disabled. If you plan on using contracts use the Mist, else if you're just holding ETH, use the Ethereum Wallet.
[https://www.reddit.com/r/ethereum/comments/53nifc/confusion_should_i_download_mist_or_ethereum/d7undsl/]
name::
* McsEngl.ethwltMst'Data-folder@cptIt,
The data folder for Mist is stored in other places:
Windows %APPDATA%/Roaming/Mist (\Users\user\AppData\Roaming\Mist)
MacOSX ~/Library/Application Support/Mist
Linux ~/.config/Mist
[https://github.com/ethereum/mist]
name::
* McsEngl.ethwltMst'Resource@cptIt,
_ADDRESS.WPG:
* https://blog.ethereum.org/2015/09/16/ethereum-wallet-developer-preview//
* https://blog.slock.it/the-ethereum-wallet-an-introduction-for-non-devs-9c530f75c018#.n1jtag8gq,
name::
* McsEngl.ethwltMst'Updating@cptIt,
For updating simply download the new version and copy it over the old one (keep a backup of the old one if you want to be sure).
[https://github.com/ethereum/mist]
name::
* McsEngl.ethwltMst.MULTISIG@cptIt,
_DESCRIPTION:
A multisig wallet – allows you to add any number of owner accounts and set a daily limit.
Every owner can send money from that account as long as it is under the daily limit. If above you need the signatures of the required other owners.
[https://blog.ethereum.org/2015/09/16/ethereum-wallet-developer-preview/]
name::
* McsEngl.ethwltMst.EVOLUTING@cptIt,
Wallet 0.5.2 (Beta 10)
@frozeman frozeman released this 19 days ago · 69 commits to wallet since this release
This release adds some additional log information to the splash screen and adds a feature to send all ether for an account.
Full list of changes:
Added a send-all functionality to the send page.
Add German (thanks to @ColRad) and Portuguese (@alexvandesande) translation for the wallet!
Added log infos to the splash screen, so users can see what the node is currently doing...
Improved ether display precision on the confirmation screen
Added a check with NTP servers to see if the computer time is correct, if not it shows an error
Increased error timeout
If you should notice that your wallet links lead to a white page, please run the following script in the console:
https://gist.github.com/frozeman/ed41008f4d30900da3e8
This changes all your wallet addresses internally back to lowercase (we introduced that by accident).
[https://github.com/ethereum/mist/releases]
name::
* McsEngl.ethwlt.MyEtherWallet@cptIt,
* McsEngl.MyEtherWallet@cptIt,
_DESCRIPTION:
Open-Source, client-side tool for easily & securely interacting with the Ethereum network.
Created by kvhnuke & tayvano.
[https://www.myetherwallet.com/]
name::
* McsEngl.ethnet'Human@cptIt,
* McsEngl.ethhmn@cptIt,
* McsEngl.ethhuman@cptIt,
* McsEngl.ethhmn@cptIt,
_SPECIFIC:
Mihai Alisie,
Vitalik Buterin,
Taylor Gerring
name::
* McsEngl.ethhmn.DEVELOPER@cptIt,
_FOUNDER:
In 2014, Ethereum founders Vitalik Buterin, Gavin Wood and Jeffrey Wilcke began work on a next-generation blockchain that had the ambitions to implement a general, fully trustless smart contract platform.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#a-next-generation-blockchain]
name::
* McsEngl.ethhmn.USER@cptIt,
* McsEngl.ethereum-user@cptIt,
* McsEngl.ethusr@cptIt,
_DESCRIPTION:
Like in Bitcoin, users must pay small transaction fees to the network.
[https://ethereum-homestead.readthedocs.io/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]
name::
* McsEngl.ethhmn.Gitter-community@cptIt,
_DESCRIPTION:
Gitter Rooms
Gitter is our forum of choice for daily chat. It is the virtual coworking space where devs hang out, so it is where you can get quick help and a bit of handholding in needed.
Gitter uses Github accounts, offers Github integration (notification of pull requests etc), private channels, provides markdown formatting, and more.
Most Gitter channels are organised around particular repositories, or generic topics like research or governance. Please choose the appropriate room and keep discussions on topic.
See the full list of gitter rooms for the Ethereum organisation. Below is the list of active public channels:
go-ethereum - about geth (and tools related to the go implementation)
cpp-ethereum - about eth (and tools related to the C++ implementation)
web3.js - about web3.js, Ethereum JavaScript API library
Solidity - The Solidity Contract-Oriented Programming Language
serpent - The Serpent language for contract development
mist - GUI dapp browser, official wallet app
light-client - about light client and the LES protocol
research - Ethereum research
governance - about dev governance
whisper - anonymous datagram publishing
swarm - decentralised content storage and distribution network
EIPs - discussion of Ethereum Improvement Proposals (EIPs)
ethereumjs-lib - a JavaScript library of core Ethereum functions
devp2p - Π?V’s p2p network protocol & framework
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/community.html#gitter-rooms]
name::
* McsEngl.ethhmn.Reddit@cptIt,
_DESCRIPTION:
Reddit
The Ethereum subreddit is the most inclusive Ethereum forum, where most of the community discussion is happening and where core devs are also active. This is your forum of choice for generic discussion of news, media coverage, announcements, brainstorming. In general all things Ethereum relevant to the wider community.
Strictly no price discussion.
Also, this is not the ideal place to ask for hands-on help or post questions you expect there are clear immediate answers to (use Gitter Rooms and Stack Exchange for these, respectively).
Read the Ethereum subreddit rules before posting.
Further specialised subreddits:
/r/EthTrader - Ether trading, price and market
/r/EtherMining - Ether mining discussion
/r/Ethmarket - Marketplace for individuals looking to exchange goods and services for Ether
/r/Ethinvestor - News and prospects for Ethereum investors. Following the long term trends in the Ethereum marketplace.
/r/ethereumism/ - a bit more ism, ostic, ical, ist and tinfoil hats, pyramids and crystal ball type of views - the ethereal side of Ethereum
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/community.html#reddit]
name::
* McsEngl.ethhmn.Stack-Exchange@cptIt,
_ADDRESS.WPG:
* http://ethereum.stackexchange.com//
_DESCRIPTION:
Stack Exchange
The Ethereum Stack Exchange is part of the StackExchange network of Q&A communities. StackExchange is a free Q&A site where all the questions and answers are preserved for posterity.
This is the best place to ask technical questions. Help your fellow etherians by answering questions and collect reputation points.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/community.html#stack-exchange]
name::
* McsEngl.ethhmn.Buterin.Vitalik (hmnBtnVtk founder {1994})@cptIt,
* McsEngl.Buterin.Vitalik@cptIt,
* McsEngl.humanBtnVtk@cptIt,
* McsEngl.human.Buterin.Vitalik@cptIt,
* McsEngl.human.Vitalik-Buterin@cptIt,
* McsEngl.Vitalik-Buterin@cptIt,
_DESCRIPTION:
I was born in 1994 in Russia and moved to Canada in 2000, where I went to school. I went to theAbelard school in 2008 and entered the University of Waterloo in 2012, but quickly left in order to go on a six-month journey around the world and simultaneously engage in cryptocurrency-related projects on a full-time basis. The result of the journey was the idea behind Ethereum, a concept for a generalized cryptoeconomically secured state machine architecture, for which I continue to serve as Chief Scientist.
My primary academic interest consists of studying and exploring the complicated intersection between information theory, cryptography, sociology, epistemology, politics and economics, where mechanisms such as prediction markets, cryptoeconomic state machines (for the layman: "blockchains"), security deposits, consumer protection and reputation systems, multi-key personal security architectures and sampling-and-fallback scalability games sit at the core.
In general, I am trying to move beyond just being "a cryptocurrency person" and acquiring a more holistic and long-tail perspective of what role technology can play in helping to build more secure and trustworthy systems and reduce inefficiency and waste in society; I find that individuals that identify themselves around a particular solution (eg. cryptocurrency, progressivism, authoritarianism, libertarianism, radical decentralization) are likely to be more susceptible to confirmation biases and generally less interesting than people who identity themselves around a problem, and dedicate themselves to the search for a solution to that problem no matter where the search takes them.
I also enjoy learning languages (started Mandarin a year ago) and exploring interesting places like the one that's the background of this screen.
#informationtheory
#economics
#philosophy
#Coreology
#mechanismdesign
[https://about.me/vitalik_buterin]
name::
* McsEngl.hmnBtnVtk'Resource@cptIt,
_DESCRIPTION:
* https://blog.ethereum.org/author/vitalik-buterin//
* https://medium.com/@VitalikButerin,
name::
* McsEngl.ethhmn.Karapetsas.Lefteris@cptIt,
* McsEngl.Karapetsas.Lefteris@cptIt,
* McsEngl.Lefteris-Karapetsas@cptIt,
_DESCRIPTION:
Lefteris Karapetsas
Developer located in Berlin. University of Tokyo graduate.#emacs user.#ethereum core developer http://lefteris.refu.co,
===
Lefteris is the Technical Lead of slock.it
After graduating from the University of Tokyo, Lefteris has been developing backend software for various companies including Oracle and Acmepacket. He is an all-around tinkerer who loves to takes things apart and put them back together learning how they work in the process.
He has been part of Ethereum as a C++ core developer since November 2014, having worked on Solidity, the ethash algorithm, the core client and the CI system and is now leading the technical side of things towards revolutionizing the IoT world with the use of blockchains in Slock.it
[https://blog.slock.it/why-we-are-building-the-ethereum-framework-for-ubuntu-core-41b53ba685da#.q8n52h58t]
_ADDRESS.WPG:
Twitter: @lefterisjp
contact: lefteris@slock.it
* http://lefteris.refu.co//
* https://blog.slock.it/a-dao-counter-attack-613548408dd7#.s0ebn5fjx,
name::
* McsEngl.ethhmn.Vessenes.Peter@cptIt,
* McsEngl.human.Vessenes.Peter@cptIt,
* McsEngl.Peter-Vessenes-hmn@cptIt,
_DESCRIPTION:
Peter Vessenes, the global blockchain and smart contracts expert who first drew attention to the vulnerability in The DAO, will be checking ChronoBank’s code to ensure it is secure.
[https://blog.chronobank.io/number-one-smart-contracts-security-expert-to-audit-chronobank-34f1289c9e4?goal=0_c14d97ba45-618679cae7-32550077#.89dwu8sch]
name::
* McsEngl.ethhmn.Wood.Gavin founder@cptIt,
* McsEngl.human.Wood.Gavin@cptIt,
* McsEngl.Gavin-Wood@cptIt,
_DESCRIPTION:
Since my childhood economics and game theory have always interested me, even to the point of co-publishing a strategy board game of my own design. When I first read about Bitcoin in 2011, I was largely uninterested, focusing too much on the currency aspect rather than the technology. However, when I revisited it in early 2013, I began to realise new possibilities opening up between the fields of ITC and game theory, and the inevitable social change to which this would lead. A mutual friend made the introduction to Vitalik in late 2014 and Ethereum has dominated my life since.
I coded the first functional implementation of Ethereum and wrote the Yellow Paper, the first formal specification of any blockchain protocol and one of the key ways Ethereum separates itself from other blockchain-based systems. My original ideas for web three date back to early 2013, but my first post on the topic was in April 2014, later followed by a less-techy version.
Prior to Ethereum, I accrued a masters degree and doctorate in computer science. I consulted for Microsoft Reseach on technical aspects of embedded domain-specific languages, designed and implemented the first truly smart lighting controller for one of London's top nightclubs, designed and implemented most of the world's first C++ language workbench, and built the software systems of OxLegal, a smart text contract-editor.
[http://gavwood.com/]
name::
* McsEngl.ethhmn.Wilcke.Jeffrey founder@cptIt,
* McsEngl.Wilcke.Jeffrey@cptIt,
* McsEngl.Jeffrey-Wilcke@cptIt,
_DESCRIPTION:
In 2014, Ethereum founders Vitalik Buterin, Gavin Wood and Jeffrey Wilcke began work on a next-generation blockchain that had the ambitions to implement a general, fully trustless smart contract platform.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#a-next-generation-blockchain]
name::
* McsEngl.ethnet'Organization (ethogn)@cptIt,
* McsEngl.ethnet'organization@cptIt,
* McsEngl.ethogn@cptIt,
name::
* McsEngl.ethogn.EEA@cptIt,
* McsEngl.EEA@cptIt,
* McsEngl.Enterprice-Ethereum-Alliance@cptIt,
_DESCRIPTION:
The Enterprise Ethereum Alliance connects Fortune 500 enterprises, startups, academics, and technology vendors with Ethereum subject matter experts.
Together, we will learn from and build upon the only smart contract supporting blockchain currently running in real-world production – Ethereum – to define enterprise-grade software capable of handling the most complex, highly demanding applications at the speed of business.
[http://entethalliance.org/]
_ADDRESS.WPG:
* https://cointelegraph.com/news/ethereum-alliance-formed-by-microsoft-intel-ubs-secures-support-of-eth-foundation,
name::
* McsEngl.ethogn.ETHCORE@cptIt,
* McsEngl.ethcore@cptIt,
* McsEngl.ethcore-ogn@cptIt,
_DESCRIPTION:
Ethcore is the creator of Parity: The worlds fastest ethereum client that integrates directly into your browser.
...
Ethcore is dedicated to helping you get the most out of open source blockchain technology.
We come from a wide variety of backgrounds; computer science, engineering, consulting, finance and law.
We've lived through the expansive growth in capabilities that blockchain has seen over the last few years.
We are the people that brought the world the most advanced blockchain technology to date.
We are the thinkers, makers and coders that can help you realise your blockchain potential.
[https://ethcore.io/index.html]
name::
* McsEngl.ethcore'Human@cptIt,
Dr. Gavin Wood, founder of Parity Technologies and lead developer of the acclaimed Parity Ethereum client
[https://ethcore.io/press.html]
name::
* McsEngl.ethogn.Slock.it@cptIt,
* McsEngl.ethnet'Slock.it@cptIt,
* McsEngl.slock.it@cptIt,
_DESCRIPTION:
Slock.it UG is a German company building the future infrastructure of the sharing economy. Our first product, the Ethereum Computer, brings blockchain technology to the entire home, making it possible to rent access to any compatible smart object and accept payments without intermediaries. We aim for this product and its ecosystem to be funded by a Decentralized Autonomous Organization (DAO), a type of digital company or trust where token holders benefit financially from the revenue of the products they supported - think of it as a Kickstarter on steroids.
The DAO model is free and open source for anyone to reproduce and study, and our white paper can be downloaded here.
Slock.it UG will soon make the Ethereum Computer proposal to the DAO available to the public. Once ready, it will be posted on this website.
[https://slock.it/faq.md]
===
Slock.it brings the benefits of the Blockchain - transparency, security and auditablity - to real-world objects.
Our technology can be embedded in almost any device and the first prototypes are already in the hands of developers.
[https://slock.it/]
name::
* McsEngl.ethogn.Ethereum-Foundation {2014}@cptIt,
* McsEngl.ethfdn@cptIt,
* McsEngl.ethereum-foundation@cptIt,
* McsEngl.ethnet'Ethereum-Foundation@cptIt,
* McsEngl.ethfdn@cptIt,
_DESCRIPTION:
The Ethereum Foundation is a non-profit organization registered in Switzerland, and has the purpose of managing the funds that were raised from the Ether Sale in order to best serve the Ethereum and decentralized technology ecosystem.
Founded July 2014 in Switzerland, Stiftung Ethereum’s mission is the promotion of developments of new technologies and applications, especially in the fields of new open and decentralized software architectures.
It is the aim that decentralized and open technologies will be developed, nurtured, promoted and maintained. A dominating, but not exclusive, focus is set on the promotion of the development of the Ethereum Protocol and the relevant technology to it as well as the promotion and support of applications using the Ethereum technology or protocol. Stiftung Ethereum will additionally support and advocate for a decentralized Internet in a variety of forms.
[https://ethereum-homestead.readthedocs.org/en/latest/ethereum-ecosystem/foundation.html]
name::
* McsEngl.ethnet'Evaluation@cptIt,
Nick Szabo ?@NickSzabo4 7m7 minutes ago
Ethereum can solve any problem a computer can solve: but with far greater reliability and security and far less performance and efficiency.
[2016-02-10]
This massive parallelisation of computing across the entire Ethereum network is not done to make computation more efficient. In fact, this process makes computation on Ethereum far slower and more expensive than on a traditional “computer”. Rather, every Ethereum node runs the EVM in order to maintain consensus across the blockchain. Decentralized consensus gives Ethereum extreme levels of fault tolerance, ensures zero downtime, and makes data stored on the blockchain forever unchangeable and censorship-resistant.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#ethereum-virtual-machine]
One issue with Bitcoin, being a hardwired protocol, is that you can’t easily introduce many competing currency models on the same platform, and we know how hard it is to create a new network for each new protocol and a system to easily exchange value between networks, hence why softwired platforms like Ethereum are enticing – sure Ether’s issuance algorithm is fixed, but it is trivial to create almost an unlimited number of alternative easily exchangable currency models on the same platform without incurring the cost of creating a brand new network every time. Exciting times!
[https://www.linkedin.com/pulse/crypto-20-musings-bitcoin-money-creation-alex-batlin?]
name::
* McsEngl.ethnet'Resource (ethrsc)@cptIt,
* McsEngl.ethresource@cptIt,
* McsEngl.ethrsc@cptIt,
_ADDRESS.WPG:
* http://www.ethereum.org// Main site,
* ETHDEV: https://ethdev.com
* https://github.com/ethereum,
===
* {2017-03-20} https://medium.com/blockchannel/tools-and-technologies-in-the-ethereum-ecosystem-e5b7e5060eb9#.1nva0vm84,
* https://karl.tech/intro-to-ethereum//
* {2016-06-22} http://cointelegraph.com/news/ethereum-101-from-idea-to-release,
* http://cointelegraph.com/news/ethereum-to-open-blockchain-research-center-in-russias-silicon-valley,
* yellowpaper: http://gavwood.com/Paper.pdf,
* whitepaper: https://github.com/ethereum/wiki/wiki/White-Paper,
* https://ethereum.gitbooks.io/frontier-guide/content//
* https://github.com/ethereum/wiki/wiki/Glossary,
* https://medium.com/boost-vc/boost-vc-is-now-investing-in-products-built-using-ethereum-79cd72b7bd71,
=== docs
* https://ethereum-homestead.readthedocs.org/en/latest//
* http://ethdocs.org/en/latest//
* https://forum.ethereum.org//
=== developer:
* https://dappsforbeginners.wordpress.com//
=== evaluation:
* http://cointelegraph.com/news/eight-months-since-release-ethereum-is-second-only-to-bitcoin,
name::
* McsEngl.ethrsc'Book@cptIt,
_ADDRESS.WPG:
* https://leanpub.com/decentralizedapplicationswithethereum,
name::
* McsEngl.ethrsc'EIP (etheip)@cptIt,
* McsEngl.ethnet'EIP@cptIt,
* McsEngl.ethnet'Ethereum-Improvement-Proposal@cptIt,
* McsEngl.EIP-ethnet@cptIt,
_DESCRIPTION:
Ethereum Improvement Proposal. EIPs propose and describe changes made to Ethereum Protocol.
People wishing to submit EIPs first should propose their idea as an issue and then formalize it using a PR. After discussion it will be published here. Having an EIP here does not make it a formally accepted standard until its status becomes Active. For a EIP to become Active requires the mutual consent of the community. An EIP is not finalized until it has been implemented and is in use. Those proposing changes should consider that ultimately consent may rest with the consensus of the Ethereum users.
[https://github.com/ethereum/EIPs]
_ADDRESS.WPG:
* The EIP (Ethereum Improvement Proposal) system has been updated
- https://www.reddit.com/r/ethereum/comments/5rp8mr/update_to_eip_ethereum_improvement_proposal_system//
name::
* McsEngl.ethrsc'ERC@cptIt,
* McsEngl.ethERC@cptIt,
* McsEngl.ethnet'ERC@cptIt,
* McsEngl.ethnet'Ethereum-request-for-comment@cptIt,
* McsEngl.ERC-ethnet@cptIt,
_ADDRESS.WPG:
* https://github.com/ethereum/EIPs/issues/16,
* https://en.wikipedia.org/wiki/Request_for_Comments,
name::
* McsEngl.ethnet'DOING@cptIt,
* McsEngl.ethnet'doing@cptIt,
_DESCRIPTION:
Doing is any internal and as a whole (=service) doing.
[hmnSngo.2017-02-12]
name::
* McsEngl.ethnet'doing.SERVICE (ethsvc)@cptIt,
* McsEngl.ethereum-service@cptIt,
* McsEngl.ethnet'service@cptIt,
* McsEngl.ethnet'usage@cptIt,
* McsEngl.ethsvc@cptIt,
_DESCRIPTION:
In general, there are three types of applications on top of Ethereum.
The first category is financial applications, providing users with more powerful ways of managing and entering into contracts using their money.
This includes sub-currencies, financial derivatives, hedging contracts, savings wallets, wills, and ultimately even some classes of full-scale employment contracts.
The second category is semi-financial applications, where money is involved but there is also a heavy non-monetary side to what is being done; a perfect example is self-enforcing bounties for solutions to computational problems.
Finally, there are applications such as online voting and decentralized governance that are not financial at all.
[https://github.com/ethereum/wiki/wiki/White-Paper#applications]
===
The Ethereum platform itself is featureless or value-agnostic.
Similar to programming languages, it is up to entrepreneurs and developers to decide what it should be used for.
However, it is clear that certain application types benefit more than others from Ethereum’s capabilities.
Specifically, ethereum is suited for applications that automate direct interaction between peers or facilitate coordinated group action across a network.
For instance, applications for coordinating peer-to-peer marketplaces, or the automation of complex financial contracts.
Bitcoin allows for individuals to exchange cash without involving any middlemen like financial institutions, banks, or governments.
Ethereum’s impact may be more far-reaching.
In theory, financial interactions or exchanges of any complexity could be carried out automatically and reliably using code running on Ethereum.
Beyond financial applications, any environments where trust, security, and permanence are important – for instance, asset-registries, voting, governance, and the internet of things – could be massively impacted by the Ethereum platform.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#ethereum-virtual-machine]
SPECIFIC:
The stated purpose of the Ethereum project is to "decentralize the web" by introducing four components as part of its roadmap: static content publication, dynamic messages, trustless transactions and an integrated user-interface.
Each of these services are designed to replace some aspect of the systems currently used in the modern web, but to do so in a fully decentralised and pseudonymous manner.
[https://en.wikipedia.org/wiki/Ethereum]
name::
* McsEngl.ethsvc.GOAL@cptIt,
* McsEngl.ethnet'doing.goal@cptIt,
* McsEngl.ethnet'goal@cptIt,
_DESCRIPTION:
The stated purpose of the Ethereum project is to "decentralize the web" by introducing four components as part of its roadmap: static content publication, dynamic messages, trustless transactions and an integrated user-interface.[5]
Each of these services are designed to replace some aspect of the systems currently used in the modern web, but to do so in a fully decentralised and pseudonymous manner.[6]
[https://en.wikipedia.org/wiki/Ethereum]
===
Driving Factors.
There are many goals of this project; one key goal is to facilitate transactions between consenting individuals who would otherwise have no means to trust one another.
This may be due to geographical separation, interfacing difficulty, or perhaps the incompatibility, incompetence, unwillingness, expense, uncertainty, inconvenience or corruption of existing legal systems.
By specifying a state-change system through a rich and unambiguous language, and furthermore architecting a system such that we can reasonably expect that an agreement will be thus enforced autonomously, we can provide a means to this end.
Dealings in this proposed system would have several attributes not often found in the real world.
The incorruptibility of judgement, often difficult to find, comes naturally from a disinterested algorithmic interpreter.
Transparency, or being able to see exactly how a state or judgement came about through the transaction log and rules or instructional codes, never happens perfectly in humanbased systems since natural language is necessarily vague, information is often lacking, and plain old prejudices are difficult to shake.
Overall, I wish to provide a system such that users can be guaranteed that no matter with which other individuals, systems or organisations they interact, they can do so with absolute confidence in the possible outcomes and how those outcomes might come about.
[http://gavwood.com/Paper.pdf]
name::
* McsEngl.ethsvc.EXCHANGE-VALUE-TOKEN@cptIt,
_DESCRIPTION:
In general, there are three types of applications on top of Ethereum.
The first category is financial applications, providing users with more powerful ways of managing and entering into contracts using their money.
This includes sub-currencies, financial derivatives, hedging contracts, savings wallets, wills, and ultimately even some classes of full-scale employment contracts.
The second category is semi-financial applications, where money is involved but there is also a heavy non-monetary side to what is being done; a perfect example is self-enforcing bounties for solutions to computational problems.
Finally, there are applications such as online voting and decentralized governance that are not financial at all.
[https://github.com/ethereum/wiki/wiki/White-Paper#applications]
name::
* McsEngl.ethsvc.ENS@cptIt,
* McsEngl.ethENS@cptIt,
* McsEngl.Ethereum-Name-Service@cptIt,
_DESCRIPTION:
ENS is the Ethereum Name Service, a distributed, open, and extensible naming system based on the Ethereum blockchain.
ENS can be used to resolve a wide variety of resources. The initial standard for ENS defines resolution for Ethereum addresses, but the system is extensible by design, allowing more resource types to be resolved in future without the core components of ENS requiring upgrades.
[https://ens.readthedocs.io/en/latest/introduction.html]
name::
* McsEngl.ethsvc.Colony@cptIt,
_DESCRIPTION:
Whatever you do, join Colony.
Colony makes it easy for people all over the world to build companies together online.
[https://colony.io//]
name::
* McsEngl.ethsvc.WEB3@cptIt,
_DESCRIPTION:
Many have come to believe that an open, trustless blockchain platform like Ethereum is perfectly suited to serve as the shared “back end” to a decentralized, secure internet - Web 3.0.
An internet where core services like DNS and digital identity are decentralized, and where individuals can engage in economic interactions with each other.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/web3.html]
name::
* McsEngl.ethnet.specific@cptIt,
* McsEngl.ethnet.specific@cptIt,
name::
* McsEngl.ethnet.TEST@cptIt,
name::
* McsEngl.ethnet.MORDEN@cptIt,
* McsEngl.morden-ethtestnet@cptIt,
_DESCRIPTION:
The Morden testnet has been running since the launch of the Ethereum blockchain (July 2015). At that time, concerns about replay-attacks between Morden and Mainnet were addressed by using a nonce-offset. All accounts on Morden used a starting nonce of 2^20 instead of 0, ensuring that any transaction valid on one chain would not be valid on the other.
[https://blog.ethereum.org/2016/11/20/from-morden-to-ropsten/]
===
Morden
Morden is a name for one of the most popular public Ethereum TestNets. It is the same as the Ethereum network, but ETH on Morden is worth nothing. You can get ETH for free on Morden from many Morden "ETH faucets".
[https://karl.tech/learning-solidity-part-1-deploy-a-contract/]
name::
* McsEngl.ethnet.ROPSTEN@cptIt,
* McsEngl.ropsten-ethtestnet@cptIt,
_DESCRIPTION:
Before the current hard forks, there were already discussions about restarting the test network from a new genesis block in order to make full syncing simpler and less resource intensive. And due to the low difficulty of the testnet, the difficulty bomb was already causing noticeable increases in block times, which would continue to grow if unaddressed. So the time is now right to leave Morden behind and start a new test network.
[https://blog.ethereum.org/2016/11/20/from-morden-to-ropsten/]
name::
* McsEngl.ethnet.CLASSIC (ETCnet)@cptIt,
* McsEngl.etcnet@cptIt,
* McsEngl.ethereum-classic-network@cptIt,
name::
* McsEngl.etcnet'Resource@cptIt,
_ADDRESS.WPG:
* {2016-09-27} https://cointelegraph.com/news/microsoft-supports-ethereum-classic-hosts-meetup-with-charles-hoskinson,
* {2016-07-28} http://www.coindesk.com/ethereum-classic-explained-blockchain//
* {2016-07-24} http://www.coindesk.com/ethereum-hard-fork-creates-competing-currencies-support-ethereum-classic-rises//
name::
* McsEngl.ethnet.SERENITY@cptIt,
* McsEngl.ethnet.serenity@cptIt,
* McsEngl.ethserenity@cptIt,
_DESCRIPTION:
Version 1.0 of Ethereum aka Frontier was released on July 30th 2015!
Development continues towards the versions named Homestead, Metropolis and Serenity (v1.1).
Frontier is aimed at exchangers and miners.
Homestead is aiming for Πapps developers, while Metropolis is aiming for end users with the release of the Mist browser.
Serenity is meant to move from consensus through Proof-of-Work to Proof-of-Stake.
[https://github.com/ethereum/wiki/wiki#frontier]
name::
* McsEngl.ethnet.METROPOLIS@cptIt,
* McsEngl.ethmetropolis@cptIt,
_DESCRIPTION:
Version 1.0 of Ethereum aka Frontier was released on July 30th 2015! Development continues towards the versions named Homestead, Metropolis and Serenity (v1.1).
Frontier is aimed at exchangers and miners.
Homestead is aiming for Πapps developers, while Metropolis is aiming for end users with the release of the Mist browser.
Serenity is meant to move from consensus through Proof-of-Work to Proof-of-Stake.
[https://github.com/ethereum/wiki/wiki#frontier]
name::
* McsEngl.ethnet.HOMESTEAD@cptIt,
* McsEngl.ethnet.homestead@cptIt,
* McsEngl.ethhomestead@cptIt,
_DESCRIPTION:
Released 16.02.29, hard fork 16.03.14
[https://docs.google.com/presentation/d/1JKKef7NVjgtRZFsTcAteS4VtHG0aYu7TApZhWUENbWQ/edit#slide=id.gf6277fbfe_0_13]
===
Homestead is the second major version of the Ethereum platform and is the first production release of Ethereum. It includes several protocol changes and a networking change that provides the ability to do further network upgrades. The first version of Ethereum, called the Frontier release, was essentially a beta release that allowed developers to learn, experiment, and begin building Ethereum decentralized apps and tools.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/the-homestead-release.html]
===
Version 1.0 of Ethereum aka Frontier was released on July 30th 2015! Development continues towards the versions named Homestead, Metropolis and Serenity (v1.1).
Frontier is aimed at exchangers and miners.
Homestead is aiming for Dapps developers, while Metropolis is aiming for end users with the release of the Mist browser.
Serenity is meant to move from consensus through Proof-of-Work to Proof-of-Stake.
[https://github.com/ethereum/wiki/wiki#frontier]
name::
* McsEngl.ethnet.FRONTIER (ethnet.1-0.2015-07-26)@cptIt,
* McsEngl.ethereum.frontier@cptIt,
* McsEngl.ethfrontier@cptIt,
* McsEngl.ethnet.frontier.2015-07-26@cptIt,
_DESCRIPTION:
Frontier (Released 15.07.26, Genesis 15.07.30)
[https://docs.google.com/presentation/d/1JKKef7NVjgtRZFsTcAteS4VtHG0aYu7TApZhWUENbWQ/edit#slide=id.gf6277fbfe_0_13]
===
Version 1.0 of Ethereum aka Frontier was released on July 30th 2015! Development continues towards the versions named Homestead, Metropolis and Serenity (v1.1).
Frontier is aimed at exchangers and miners.
Homestead is aiming for Πapps developers, while Metropolis is aiming for end users with the release of the Mist browser.
Serenity is meant to move from consensus through Proof-of-Work to Proof-of-Stake.
[https://github.com/ethereum/wiki/wiki#frontier]
name::
* McsEngl.ethnet.PUBLIC.NO@cptIt,
* McsEngl.ethnet.private@cptIt,
* McsEngl.ethnet.publicNo@cptIt,
_ADDRESS.WPG:
* http://hypernephelist.com/2016/05/30/deploying-a-private-Ethereum-blockchain.html,
name::
* McsEngl.ethnet.EVOLUTING@cptIt,
* McsEngl.ethnet.evoluting@cptIt,
{time.2016.07}
=== Ethereum’s successful hard fork, Coinbase integration
The partial price and market cap recovery can be traced to Ethereum’s successful hard fork. The fork was agreed upon in response to the DAO hack, which resulted in the theft of a large amount of Ether. A proposed hard fork in the currency, isolating the stolen funds and rendering them without value, was readily agreed to by the Ethereum mining community and subsequently implemented, restoring confidence, and with it, value.
Additionally, cryptocurrency exchange/wallet provider/merchant solution Coinbase recently announced Ethereum integration, solidifying the currency’s place as being respected by the cryptocurrency “establishment.”
[https://cointelegraph.com/news/ethereum-shoots-up-as-bitcoin-drops-below-80-market-dominance]
{time.2015.11}
===
With the widening interest beyond the core Ethereum community, it was time to spread our collective wings to help the rest of the world see the same ideas that many early adopters had. Following a short delay, DEVCON1 was announced to take place in London, England for a week in November 2015. Almost 400 people joined together at this location for an entire week, totaling 80 talks and topics about the Ethereum ecosystem.
[https://blog.ethereum.org/2016/02/09/cut-and-try-building-a-dream/]
{time.2015-07-30}
=== FRONTIER
Version 1.0 of Ethereum aka Frontier was released on July 30th 2015! Development continues towards the versions named Homestead, Metropolis and Serenity (v1.1).
Frontier is aimed at exchangers and miners.
Homestead is aiming for Πapps developers, while Metropolis is aiming for end users with the release of the Mist browser.
Serenity is meant to move from consensus through Proof-of-Work to Proof-of-Stake.
[https://github.com/ethereum/wiki/wiki#frontier]
{time.2014.11}
===
Only two months later, in November 2014, the majority of the Ethereum project team was assembled and descended upon Berlin to participate in the first Ethereum conference: DEVCON0. Although many had spoke via Skype, this was a time when most of the project members met for the first time. At this proto-conference, in a modest but beautiful space, developers took turns standing in front of peers explaining their vision for any given segment of the many protocols that would be necessary to develop “Web3”.
[https://blog.ethereum.org/2016/02/09/cut-and-try-building-a-dream/]
{time.2014.07}
=== ETHER INITIAL ALLOCATION:
Beginning in July 2014, Ethereum distributed the initial allocation of ether via a 42-day public ether presale, netting 31,591 bitcoins, worth $18,439,086 at that time, in exchange for about 60,102,216 ether. The results of the sale were initially used to pay back mounting legal debts and also for the months of developer effort that had yet to be compensated, and to finance the ongoing development of the Ethereum.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/history-of-ethereum.html#the-ethereum-foundation-and-the-ether-presale]
{time.2014.04}
===
By April of 2014, Dr. Gavin Wood published the Ethereum Yellow Paper that would serve as the technical bible and de-facto specification for the Ethereum Virtual Machine (EVM).
[https://blog.ethereum.org/2016/02/09/cut-and-try-building-a-dream/]
{time.2014-01-25}
===
Ethereum was formally announced on January 25, 2014.
[https://blog.ethereum.org/2016/02/09/cut-and-try-building-a-dream/]
{time.2013}
Many of these took the form of “alt coins” - separate blockchains with cryptocurrencies of their own which improved on the original bitcoin protocol to add new features or capabilities.
In late 2013, Ethereum’s inventor Vitalik Buterin proposed that a single blockchain with the capability to be reprogrammed to perform any arbitrarily complex computation could subsume these many other projects.
[https://ethereum-homestead.readthedocs.io/en/latest/introduction/what-is-ethereum.html]
===
Buterin [2013a] first proposed the kernel of this work in late November, 2013.
Though now evolved in many ways, the key functionality of a blockchain with a Turing-complete language and an effectively unlimited inter-transaction storage capability remains unchanged.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
_ORIGING:
Ethereum was designed as a smart contract platform. Its origin is actually linked to a critique made by Vitalik Buterin on bitcoin as a very limited smart contract platform.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#262d]
name::
* McsEngl.bcnnet.time.NEM (XEMnet {2015-03-29})@cptIt,
* McsEngl.bcnnetNEM@cptIt,
* McsEngl.nemnet@cptIt,
* McsEngl.netNEM@cptIt,
* McsEngl.New-Economy-Movement-bcnnet@cptIt,
* McsEngl.xemnet@cptIt,
_DESCRIPTION:
NEM XEM
NEM is a peer to peer platform providing solutions for blockchain multisigns, payments, messaging, naming system, asset making and other services.
One of the key features of NEM is that it doesn't require much computing power as other cryptos and has a low entry barrier for developers.
The main point of NEM is to provide cheap and super secure services worldwide.
NEM is fueled by its own cryptocurrency, named XEM.
[https://changelly.com/supported-currencies]
===
NEM (New Economy Movement) was originally conceived as a clone of the well-known Nxt blockchain, but rapidly developed into a completely new project with its own codebase. It has since grown into a thriving community and ecosystem with a market cap of around $45 million, placing it in the top 10 of all cryptocurrencies.
[https://blog.chronobank.io/chronobank-partners-with-nem-to-create-chrononem-wallet-eebdc176351d]
===
Features
- NEM is built 100% from scratch (not a fork of any existing project)
- NEM is built with test-driven development
- NEM uses innovative Proof-of-Importance algorithm: first reputation based blockchain algorithm
- NEM has customizable assets called Mosaics. Editable supply, levies, description, transferability and more.
- NEM has Namespaces to help maintain reputation of Mosaics
- NEM improves different features of POW and POS coins, being more efficient and environmentally friendly
- NEM one minute average block times
- NEM is the first crypto with delegated harvesting
- NEM is the first with localized spam protection
- NEM is the first with Eigentrust peer reputation management
- NEM is the first editable m-of-n multisig with blockchain based alerts
- NEM is the first every P2P network with nodes time syncing in a decentralized manner
- NEM offers encrypted, unencrypted and hex messaging
- NEM is easy to install with a one click installer
- NEM zero monetary inflation (fixed supply, all 9 billion coins released at launch).
- NEM relatively large egalitarian distribution
- NEM will offer a mobile wallet for both iOS and Android (coming soon)
[http://wiki.nem.io/index.php/About:_General]
===
NEM is an advanced, bitcoin 2.0+ system that has been in development since January of 2014. The development team is comprised of professional software engineers and scientists who went to great lengths to study ways to improve existing blockchain platforms and created NEM from scratch to be more secure and easier to develop for than any other platform. Instead of using Proof-of-Work mining, which is wasteful and not eco-friendly, a new concensus algorithm, Proof-of-Importance was developed, which uses low energy and also rewards participation in the economy. NEM was developed using modern software engineering practices such as test-driven development, has over 3,000 unit tests, and was tested on an open network for over 9 months before its release on 2015/3//31.
The currency of NEM is called XEM, but the transfer of XEM is far from the only utility of the NEM blockchain platform. NEM mosaics provide the most advance implementation of digital assets to date and can be associated with blockchain-level domain names. A reputation system and smart contracts/decentralized computing systems are also in development, which will make NEM the most comprehensive block chain platform to date when completed.
[http://mijin.io/en/about-mijin]
name::
* McsEngl.xemnet'Protocol@cptIt,
name::
* McsEngl.xemprl'Implementation-language@cptIt,
_DESCRIPTION:
NEM is a global open source project.
It is a peer-to-peer blockchain platform and is written in Java and JavaScript with 100% original source code.
[http://wiki.nem.io/index.php/About:_General]
name::
* McsEngl.xemprl'Resource@cptIt,
_ADDRESS.WPG:
* NEM Technical Reference, Version 1.0, May 15, 2015: https://www.nem.io/NEM_techRef.pdf,
* Apostille White Paper: https://www.nem.io/ApostilleWhitePaper.pdf,
* Catapult White Paper: https://www.nem.io/catapultwhitepaper.pdf,
name::
* McsEngl.xemnet'Node@cptIt,
name::
* McsEngl.xemnod'Node-server (NIS)@cptIt,
* McsEngl.xemnet'NIS@cptIt,
* McsEngl.xemnet'NEM-Infrastructure-Server@cptIt,
* McsEngl.xemnet'NIS@cptIt,
_DESCRIPTION:
NEM 2-Tier Architecture
NEM's design architecture consists of two components. One is the Node server or NEM Infrastructure Server (NIS). The other is the NEM Client. The NIS is connected to the p2p network and acts as a gateway for the Client. NEM’s platform is therefore, a two-tier solution, following the convention of the web architecture.The first version of the NEM Client is called the NEM Community Client (NCC).The NCC is basically a client software that includes a wallet. Both the NCC and NIS can be configured to run off the same machine. As it is run from the same machine, both the NCC and the NIS will be exposed to the Internet. A second use case is to separate the NIS from the NCC.
The NIS can thus be configured to act as an additional layer of protection to the NCC thereby making the NCC reasonably protected within its own confines as it can be made not to connect to the Internet. In addition, one can have the option of putting a firewall between the NCC and the NIS, the NCC is therefore two steps away from the Internet. This means that the NCC can be made to work in stealth mode. This type of modular design makes the NCC insulated from external attacks. It is almost impossible to break into the NCC if the NCC is only connected to the NIS through another firewall. If there is any attack on the wallet, it is almost certain that the attack is from within the network rather than from outside the network. Another feature of this architecture is that the NCC acts as a wallet and can be used on any computer, whereas the NIS represents a node on the NEM network and can be hosted from remote locations. Additionally, the client can be loaded onto any computer and a person's wallet can be reloaded as long as this person has her private keys.
The NIS can be placed on a Demilitarized Zone (DMZ) behind a firewall and therefore itself is protected from the Internet. Hence, there exists many options and configurations. This makes NEM's architecture secure.
Subsequent to the NCC, more wallets have been created. These are the mobile wallets (to be released soon), the light-wallet that was created using Javascript, and the nanowallet, which is an augmented and amended version of the light wallet.
The NIS has a full set of APIs. The initial NCC has a webserver with useful APIs. These two layers create a firewall of security in between the wallet where all important information is stored and signed, while the NIS announces transactions.
[http://wiki.nem.io/index.php/NEM_2-Tier_Architecture]
name::
* McsEngl.xemnet'Blockchain@cptIt,
_DESCRIPTION:
A ‘Blockchain’ is sort of like that piece of paper in a checkbook that allows you to keep track of everything. The NEM ‘Blockchain’ keeps track of how much was spent, with whom, on what day, and even keeps track of the exact time. Now imagine if everyone in the world shared a piece of paper like this. It has everyone's spending on it. If you make changes everyone can see it, but you can only make changes if everyone agrees that this change actually happened. Everyone, at any time, can look at it and check to make sure it's right. Now, we all agree that this piece of paper is right. Usually, 'Blockchains' keep track of who owns what money and when it is moved around. In NEM, this is still true - but NEM also keeps track of other kinds of things, which will be talked about at the end of this blog.
[https://blog.nem.io/the-beginners-guide-to-nem/]
name::
* McsEngl.xembcn'Block (xemblk)@cptIt,
name::
* McsEngl.xemblk'Block-time@cptIt,
GENERATION_TIME:
- NEM one minute average block times
[http://wiki.nem.io/index.php/About:_General]
name::
* McsEngl.xembcn'Block-Explorer (xembex)@cptIt,
_ADDRESS.WPG:
* http://explorer.ournem.com/#//
* http://chain.nem.ninja/#/blocks/0,
* BlockH1 http://explorer.ournem.com/#/s_block?height=1,
- http://chain.nem.ninja/#/block/1,
name::
* McsEngl.xemnet'Consensus-algorithm@cptIt,
* McsEngl.proof-of-importance-xemnet@cptIt,
* McsEngl.xemnet'proof-of-importance@cptIt,
_DESCRIPTION:
'Proof of Importance' is a way in NEM to make sure that all the computers on a network agree with each other and helps decide who can ‘harvest’. This helps to keep everything safe from hackers and keeps NEM working well. It’s a big part of how we make sure people are telling the truth about the things that our ‘Blockchain’ keeps track of, like how much money a person owns. ‘Proof of Importance’ helps to make sure that every person using NEM can agree on everything and stops people from spending more than they have. It uses mathematical formulas made from information about an account to decide how important a person is to the group.
The more important you are, the better chance you have of getting that free money when you’re ‘Harvesting’! That means people want to be important, so they won’t lie! Once you are important, there are a couple more things that decide just how important you actually are. Your ‘Vested Balance’, who you send money with, how often you send money, and how much you send are all considered when figuring out how important you are. To fake all of these things would take more money than a liar would stand to make. The best part? This means we can always trust an important person.
[https://blog.nem.io/the-beginners-guide-to-nem/]
name::
* McsEngl.xembcn'Address@cptIt,
* McsEngl.xemnet'address@cptIt,
_DESCRIPTION:
A NEM address is a base-323 encoded triplet consisting of
- a network byte
- a 160-bit hash of the account’s public key
- a 4 byte checksum
The checksum allows for quick recognition of mistyped addresses. It is possible to send XEM to any valid address even if the address has not previously participated in any transaction. If nobody owns the private key of the account to which the XEM is sent, the XEM is most likely lost forever.
However, you are unlikely to send XEM to an unowned address, because it would have to be generated with the right checksum. This means that the more likely scenario is that the owner lost the key, which caused all the XEM to be lost.
[http://wiki.nem.io/index.php/About:_Addresses]
name::
* McsEngl.xemnet'Consensus-evt (XEMcevt)@cptIt,
* McsEngl.XEM@cptIt,
* McsEngl.xemcevt@cptIt,
_DESCRIPTION:
NEM (XEM)
$0.034570 (30.59%)
0.00002862 BTC (31.14%) Buy / Sell Instantly
Rank 6
Currency
Market Cap
$311,128,200
257,544 BTC
Volume (24h)
$9,820,020
8,129 BTC
Circulating Supply
8,999,999,999 XEM
[https://coinmarketcap.com/currencies/nem//] {2017-04-19}
===
NEM XEM
NEM is a peer to peer platform providing solutions for blockchain multisigns, payments, messaging, naming system, asset making and other services.
One of the key features of NEM is that it doesn't require much computing power as other cryptos and has a low entry barrier for developers.
The main point of NEM is to provide cheap and super secure services worldwide. NEM is fueled by its own cryptocurrency, named XEM.
[https://changelly.com/supported-currencies]
===
What is XEM?
"XEM" is NEM's currency code. It is similar to USD, EUR, CNY, JPY etc.
[https://www.nem.io/faq.html#whatsXem]
name::
* McsEngl.xemcevt'OgnExchange@cptIt,
_DESCRIPTION:
Buy XEM at one of these exchanges
POLONIEX
BTC38
BITCOIN.co.id
Changelly
===
Buy XEM directly with cash
Zaif
BTC38
name::
* McsEngl.xemcevt'Exchange-rate@cptIt,
_ADDRESS.WPG:
* https://coinmarketcap.com/currencies/nem//
name::
* McsEngl.xemcevt'Distribution@cptIt,
_DESCRIPTION:
- NEM relatively large egalitarian distribution
[http://wiki.nem.io/index.php/About:_General]
name::
* McsEngl.xemcevt'Issuance@cptIt,
_DESCRIPTION:
- NEM zero monetary inflation (fixed supply, all 9 billion coins released at launch).
[http://wiki.nem.io/index.php/About:_General]
name::
* McsEngl.xemcevt.SPECIFIC@cptIt,
How many XEM are in circulation?
The total amount is 8,999,999,999 XEM.
[https://www.nem.io/faq.html]
name::
* McsEngl.xemnet'Program@cptIt,
name::
* McsEngl.xempgm.Client@cptIt,
_DESCRIPTION:
NEM 2-Tier Architecture
NEM's design architecture consists of two components. One is the Node server or NEM Infrastructure Server (NIS). The other is the NEM Client. The NIS is connected to the p2p network and acts as a gateway for the Client. NEM’s platform is therefore, a two-tier solution, following the convention of the web architecture.The first version of the NEM Client is called the NEM Community Client (NCC).The NCC is basically a client software that includes a wallet. Both the NCC and NIS can be configured to run off the same machine. As it is run from the same machine, both the NCC and the NIS will be exposed to the Internet. A second use case is to separate the NIS from the NCC.
Subsequent to the NCC, more wallets have been created. These are the mobile wallets (to be released soon), the light-wallet that was created using Javascript, and the nanowallet, which is an augmented and amended version of the light wallet.
[http://wiki.nem.io/index.php/NEM_2-Tier_Architecture]
name::
* McsEngl.xemnet'Wallet@cptIt,
name::
* McsEngl.xemnet'Organization@cptIt,
name::
* McsEngl.xemnet'NEM-Foundation@cptIt,
_DESCRIPTION:
In July 2016 the NEM community agreed (consensus of the community with blockchain-based voting) to set up a Company Limited by Guarantee (CLG) in Singapore, NEM.io Foundation Ltd. (“NEM Foundation”) to represent the roof international organisation. This CLG is set up in December 2016 and will lead country/regional chapters which are being registered as local non-profit societies.
[https://blog.nem.io/nem-mijin-blockchain-technology-briefing-january-2017/]
name::
* McsEngl.xemnet'Problem@cptIt,
1- If you are syncing but an your machine says something like "NIS is synchronizing. At block 221896, est. 126 days behind. (at block 221896)" and doesn't move and sync but seems stuck, please try to delete your database and start a new chain. You can speed up this process by just downloading a new chain and inserting it manually. Here are some tutorials with step by step instructions. http://blog.nem.io/how-to-delete-your-local-copy-of-the-blockchain/7 http://blog.nem.io/how-to-import-the-database-file-provided-by-developers/4
2- If there is a major problem, you might have to delete all NEM software on the computer and start over from scratch installing. Here is a tutorial for that. http://blog.nem.io/how-to-remove-old-nem-software-versions/12
Generally speaking the installer is the most buggy. Most people that have a problem with the installer find that using the stand alone works. Instructions for the stand alone are here. http://blog.nem.io/nem-tutorial-list/8
If you have your private key backed up, or want to make a new wallet with a pass phrase, the Lightwallet is also very safe and easy to use. http://nem.io/install.html8
At some point NEM will fully transition away from NCC to Lightwallet and mobile apps for iOS and Android and there will no longer be any of these problems.
3- If you are having trouble logging in.
Go to \Users\yourname\nem\ncc and delete the ncc.cfg file and the accounts_cache_mainnet.json file.
4. If NIS wont start. Go to \Users\yourname\nem and delete the nis.lock file.
5- If you are having a problem with Java, please try to update your Java.
[http://wiki.nem.io/index.php/Tutorial:_Common_Problems]
name::
* McsEngl.xemnet'Resource@cptIt,
_ADDRESS.WPG:
* https://www.nem.io//
* https://www.nem.io/faq.html,
* https://blog.nem.io//
* {2017-03-14} Xhai Studios Integrates NEM Blockchain To Ditch Middlemen, Payment Processor: https://cointelegraph.com/news/xhai-studios-integrates-nem-blockchain-to-ditch-middlemen-payment-processor,
name::
* McsEngl.xemnet'Service@cptIt,
_DESCRIPTION:
NEM is a peer to peer platform providing solutions for blockchain multisigns, payments, messaging, naming system, asset making and other services.
[https://changelly.com/supported-currencies]
name::
* McsEngl.xemnet'Namespace@cptIt,
_DESCRIPTION:
The basic things you need to know about NEM’s recent fork are Namespaces and Mosaics features. The easiest way to appreciate it is the domain and file analogy on the internet. Imagine that a domain address has to be unique in a root (lowest level). Namespace addresses this unique feature. If one creates a namespace, that namespace will appear unique in the NEM ecosystem. For example, if one were to create a namespace called “foo” that namespace cannot be created by a second person. Just like on the internet, a domain can have a sub-domain, namespaces can have sub-namespaces. And it is possible to create multiple sub-namespaces with the same name (example: “foo.bar” and “foo2.bar”, “bar” is the sub-namespace/sub-domain). A namespace and a domain name is the same in this document and shall be used interchangeably. Namespaces can have up to 3 levels, a namespace and its two levels of sub-namespace domains.
[https://blog.nem.io/mosaics-and-namespaces-2/]
===
NEM has a built in system for people to register names called Namespaces. These names can be used to run a business on the blockchain.
[https://blog.nem.io/the-beginners-guide-to-nem/]
name::
* McsEngl.xemnet'Mosaic@cptIt,
_DESCRIPTION:
The basic things you need to know about NEM’s recent fork are Namespaces and Mosaics features. The easiest way to appreciate it is the domain and file analogy on the internet.
...
A mosaic is like a file hosted on a domain and represents an asset, and like a website and directory, a mosaic can have the same name as other files on other domains. But a total address of a namespace + mosaic will always be unique as the root namespace is unique even if the rest of it isn't.
[https://blog.nem.io/mosaics-and-namespaces-2//]
Significance of Namespaces and Mosaics
Namespaces gives rise to a unique naming convention. Mosaics gives rise to the creation of assets. Some call it a colored coin while others may call it a token. We call it a mosaic it will take on many types of properties when it is full blown (hence we call it a mosaic as it evolves to form the “big picture”) .
Our initial release is a mosaic that has the following properties:
description
Free-text description of the mosaic up to 128 characters, changeable by the owner.
divisibility
Adding this makes a quantity divisible, up to 6 decimal places. A divisibility of 2 means 2 decimal places.
information
Arbitrary byte array that can be in the property, with a size limit; this is the same as “messages” in NEM.
domain name or namespace (required)
Globally unique fully qualified domain name that is registered and owned by the mosaic creator. A top level namespace has a size limit of 16 characters, sub-namespaces have a limit of 64 characters.
name (required)
Name of the mosaic, up to a size limit of 32 characters; must be unique under the domain name.
mutable quantity
The amount of mosaic in circulation. If immutable, it is fixed, otherwise it is dynamic, i.e., more can be created or destroyed later.
transferability
If no, it means it can only be transferred between user and creator. Otherwise, it is freely transferable between third parties.
levy
A levy allows the creator of a mosaic to set a tax on any subsequent transactions of that mosaic. This levy is sent to an account of the creators choosing. Any mosaic or XEM may be used as a levy.
In the future Mosaics might have their feature set expanded to among other things include dividends, reputation, recallability, composability (ability to put assets in assets), issuer covered fees on trades, expansion of the non-transferable white list, levies to be redefinable, variable expirations, smart contracts, storage, and processing power. In addition to discussing these up grades to Mosaics, we have also discussed making Namespaces have transferable names.
[https://blog.nem.io/mosaics-and-namespaces-2/]
name::
* McsEngl.xemnet.EVOLUTING@cptIt,
{time.2015}:
NEM finally launched on March 31, 2015.
[http://wiki.nem.io/index.php/About:_General]
{time.2014}:
NEM has gone through extensive open alpha testing starting June 25, 2014, followed by lengthy and comprehensive beta testing starting on October 20, 2014.
[http://wiki.nem.io/index.php/About:_General]
name::
* McsEngl.bcnnet.time.Dash (DASHnet {2014-01-19})@cptIt,
* McsEngl.netCbc.dash@cptIt,
* McsEngl.dash-cryptocurrency-net@cptIt,
* McsEngl.dashnet@cptIt,
* McsEngl.netDash@cptIt,
=== _NOTES: Dash , which stands for ‘Digital Cash’
[https://www.dash.org/binaries/evo/DashPaper-v13-v1.pdf]
_DESCRIPTION:
What is Dash?
Dash (DASH) is a privacy-centric digital currency with instant transactions. It is based on the Bitcoin software, but it has a two tier network that improves it. Dash allows you to remain anonymous while you make transactions, similar to cash.
With Bitcoin, transactions are published to the blockchain and you can prove who made them or to whom, but with Dash the anonymization technology makes it impossible to trace them. This is important because the blockchain is accessible to anyone with an internet connection – a significant drawback for those don’t wish their transaction history and balances to be publicly available. Dash does this through a mixing protocol utilizing an innovative decentralized network of servers called Masternodes, avoiding the need for a trusted third party that could compromise the integrity of the system.
Dash transactions are almost instantly confirmed by the Masternodes network. This is a great improvement on Bitcoin’s system, where confirmations take much longer because all the work is done by the miners.
For full details please read the Dash whitepaper.
[https://www.dash.org/what-is-dash//]
_GENERIC:
* Blockchain-network-with-builtin-decentralized-governance#ql:idBcnnetBig#,
* Exchange-value-token-blockchain-network#ql:idBcnnetEvtkn#
name::
* McsEngl.dashnet'Protocol (dashprl)@cptIt,
name::
* McsEngl.dashnet'White-paper (dashwpr)@cptIt,
_ADDRESS.WPG:
* https://www.dash.org/wp-content/uploads/2015/04/Dash-WhitepaperV1.pdf,
* https://github.com/dashpay/dash/wiki/Whitepaper,
Dash: A PrivacyCentric CryptoCurrency
Evan Duffield evan@dashpay.io
Daniel Diaz daniel@dashpay.io
A cryptocurrency based on Bitcoin, the work of Satoshi Nakamoto, with various improvements such as a twotier incentivized network, known as the Masternode network.
Included are other improvements such as Darksend, for increasing fungibility and InstantX which allows instant transaction confirmation without a centralized authority.
Bitcoin[-1-#ql:idDashwprref1#] is a cryptocurrency that has emerged as a popular medium of exchange and is the first digital currency that has attracted a substantial number of users[-2-#ql:idDashwprref2#].
Since it’s inception in 2009, Bitcoin has been rapidly growing in mainstream adoption and merchant usage[-3-#ql:idDashwprref3#].
A main issue with the acceptance of Bitcoin in pointofsale situations is the time required to wait for the network to confirm the transaction made is valid, alternatively payment companies have created methods to allow vendors to take zeroconfirmation transactions, but these solutions utilize a trusted counterparty to mediate the transaction outside of the protocol.
Bitcoin provides pseudonymous transactions in a public ledger, with a onetoone relationship between sender and receiver.
This provides a permanent record of all transactions that have ever taken place on the network[-5-#ql:idDashwprref5#].
Bitcoin is widely known in academic circles to provide a low level of privacy, although with this limitation many people still entrust their financial history to it’s blockchain.
Dash is the first privacycentric cryptographic currency based on the work of Satoshi Nakamoto.
In this paper we propose a series of improvements to Bitcoin resulting in a decentralized, strongly anonymous cryptocurrency, with tamperproof instant transactions and a secondary peertopeer network incentivized to provide services to the Dash Network.
Full nodes are servers running on a p2p network, that allow peers to use them to receive updates about the events on the network.
These nodes require significant amounts of traffic and other resources that carry substantial cost.
As a result, on the Bitcoin network a steady decrease in the amount of these nodes has been observed for some time[-7-#ql:idDashwprref7#] and as a result block propagation have been upwards of 40 seconds[-14#ql:idDashwprref14#].
Many solutions have beenproposed such as a new reward scheme by Microsoft Research[-4-#ql:idDashwprref4#] and the Bitnodes incentive program[-6-#ql:idDashwprref6#].
# idDashwprfig1#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgDashwprFig1.png!#
Figure 1: Full nodes in the spring of 2014
These nodes are very important to the health of the network.
They provide clients with the ability to synchronize and quick propagation of messages throughout the network.
We propose adding a secondary network, known as the Dash Masternode network.
These nodes will have high availability and provide a required level of service to the network in order to take part in the Masternode Reward Program.
Much of the reason for the decrease of full nodes on the Bitcoin network, is the lack of incentive to run one.
Over time the cost of running a full node increases as the network gets used more, creating more bandwidth and costing the operator more money.
As the cost rises, operators consolidate their services to be cheaper to run or run a light client, which doesn’t help the network at all.
Masternodes are full nodes, just like in the Bitcoin network, except they must provide a level of service to the network and have a bond of collateral to participate.
Collateral is never forfeit and is safe while the Masternode is operating.
This allows investors to provide a service to the network, earn interest on their investment and reduce the volatility of the currency.
To run a Masternode, the node must store 1000 DASH.
When active, nodes provide services to clients on the network and in return are paid in the form of a dividend.
This allows the users to pay for the services and earn a return on investment. Masternodes are all paid from the same pool of money, approximately 45% [footnote] of the total block reward is dedicated to this program.
Due to the fact that the Masternode rewards program is a fixed percentage and the Masternode network nodes are fluctuating, expected Masternode rewards will vary according to the current total count of active Masternodes.
Payments for a standard day for running a Masternode can be calculated by using the following formula:
(n/t) * r * b * a
Where:
n is the number of Masternodes an operator controls
t is the total number of Masternodes
r is the current block reward (presently averaging about 5 DASH)
b is blocks in an average day. For the Dash network this usually is 576.
a is the average Masternode payment (45% of the average block amount)
Return on investment for running a Masternode can be calculated as
((n/t) * r * b * a * 365) / 1000
Where variables are the same as above.
The cost associated with running a Masternode creates a hard and soft limit of active nodes on the network.
Currently with 5.3 million DASH in circulation, only 5300 nodes could possibly be running on the network.
The soft limit is imposed by the price it costs to acquire a node and the limited liquidity on exchanges due to usage of Dash as a currency and not merely an investment.
A special deterministic algorithm is used to create a pseudorandom ordering of the Masternodes.
By using the hash from the proofofwork for each block, security of this functionality will be provided by the mining network.
Pseudo Code, for selecting a Masternode:
For(mastenode in masternodes){
n = masternode.CalculateScore();
if(n > best_score){
best_score = n;
winning_node = masternode;
}}
CMasterNode::CalculateScore(){
n1 = GetProofOfWorkHash(nBlockHeight); // get the hash of this block
n2 = Hash(n1); //hash the POW hash to increase the entropy
n3 = abs(n2 masternode_vin);
return n3;
}
The example code can be extended further to provide rankings of Masternodes also, a “second”, “third”, “fourth” Masternode in the list to be selected.
Currently the Dash network has ~2400 active Masternodes[-8-#ql:idDashwprref8#].
By requiring 1000 DASH collateral to become an active Masternode, we create a system in which no one can control the entire network of Masternodes.
For example, if someone wants to control 50% of the Masternode network, they would have to buy 2,300,000 DASH from the open market.
This would raise the price substantially and it would become impossible to acquire the needed DASH.
With the addition of the Masternode network and the collateral requirements, we can use this secondary network to do highly sensitive tasks in a trustless way, where no single entity can control the outcome.
By selecting N pseudo random Masternodes from the total pool to perform the same task, these nodes can act as an oracle, without having the whole network do the task.
For an example implementation of a trustless quorum see InstantX[-9-#ql:idDashwprref9#], which uses quorums to approve transactions and lock the inputs or the proofofservice implementation[-10#ql:idDashwprref10#].
Another example use for trustless quorums can include utilizing the masternode network as a decentralized oracle for financial markets, making secure decentralized contracts a possibility.
As an example contract, if AAPL is over $300 on Dec 31, 2016 pay public key A, otherwise pay public key B.
Masternodes can provide any number of extra services to the network.
As a proofofconcept, our first implementation included Darksend and InstantX.
By utilizing what we call proofofservice, we can require that these nodes are online, responding and even at the correct block height.
Bad actors could also run Masternodes, but not provide any of the quality service that is required of the rest of the network.
To reduce the possibility of people using the system to their advantage nodes must ping the rest of the network to ensure they remain active.
This work is done by the Masternode network by selecting 2 quorums per block.
Quorum A checks the service of Quorum B each block.
Quorum A are the closest nodes to the current block hash, while Quorum B are the furthest nodes from said hash.
Masternode A (1) checks Masternode B (rank 2300)
Masternode A (2) checks Masternode B (rank 2299)
Masternode A (3) checks Masternode B (rank 2298)
All work done to check the network to prove that nodes are active is done by the Masternode network itself.
Approximately 1% of the network will be checked each block.
This results in the entire network being checked about six times per day.
In order to keep this system trustless, we select nodes randomly via the Quorum system, then we also require a minimum of six violations in order to deactivate a node.
In order to trick this system, an attacker will need to be selected six times in a row.
Otherwise, violations will be cancelled out by the system as other nodes are selected by the quorum system.
| Attacker Controlled
Masternodes / Total Masternodes | Required Picked
Times In A Row | Probability of
success (n/t)^r | DASH Required |
| 1/2300 | 6 | 6.75e21 | 1000DASH |
| 10/2300 | 6 | 6.75e15 | 10,000DASH |
| 100/2300 | 6 | 6.75e09 | 100,000DASH |
| 500/2300 | 6 | 0.01055% | 500,000DASH |
| 1000/2300 | 6 | 0.6755% | 1,000,000DASH |
#idDashwprtbl1#Table 1. The probability of tricking the system representing one individual Masternode as failing proofofservice
Where:
n is the total number of nodes controlled by the attacker
t is the total number of Masternodes in the network
r is the depth of the chain
The selection of Masternodes is pseudo random based on the Quorum system
The Masternodes are propagated around the network using a series of protocol extensions including a Masternode announce message and Masternode ping message.
These two messages are all that’s needed to make a node active on the network, beyond these there are other messages for executing a proofofservice request, Darksend and InstantX.
Masternodes are originally formed by sending 1000 DASH to a specific address in a wallet that will “activate” the node making it capable of being propagated across the network.
A secondary private key is created that is used for signing all further messages.
The latter key allows the wallet to be completely locked when running in a standalone mode.
A cold mode is made possible by utilizing the secondary private key on two separate machines.
The primary “hot” client signs the 1000 DASH input including the secondary signing private key in the message.
Soon after the “cold” client sees a message including its secondary key and activates as a Masternode.
This allows the “hot” client to be deactivated (client turned off) and leaves no possibility of an attacker gaining access to the 1000 DASH by gaining access to the Masternode after activation.
Upon starting a Masternode sends a “Masternode Announce” message to the network, containing:
Message: (1K DASH Input, Reachable IP Address, Signature, Signature Time, 1K Dash Public Key, Secondary Public Key, Donation Public Key, Donation Percentage)
Every 15 minutes thereafter, a ping message is sent proving the node is still alive.
Message: (1K DASH Input, Signature (using secondary key), Signature Time, Stop?)
After a timetolive has expired the network will remove an inactive node from the network, causing the node to not be used by clients or paid.
Nodes can also ping the network constantly, but if they do not have their ports open, they will eventually be flagged as inactive and not be paid.
New clients entering the Dash network must be made aware of the currently active Masternodes on the network to be able to utilize their services.
As soon as they join the meshnetwork, a command is sent to their peers asking for the known list of Masternodes.
A cache object is used for clients to record Masternodes and their current status, so when clients restart they will simply load this file rather than asking for the full list of Masternodes.
To ensure that each Masternode is paid it’s fair share of the block reward, the network must enforce that blocks pay the correct Masternode.
If a miner is noncompliant their blocks must be rejected by the network, otherwise cheating will be incentivized.
We propose a strategy where Masternodes form quorums, select a winning Masternode and broadcast their message.
After N messages have been broadcast to select the same target payee, a consensus will be formed and that block in question will be required to pay that Masternode.
When mining on the network, pool software (websites that merge the efforts of individual miners) use the RPC API interface to get information about how to make a block.
To pay the Masternodes this interface must be extended by adding a secondary payee to GetBlockTemplate.
Pools then propagate their successfully mined blocks, with a split payment between themselves and a Masternode.
We believe it’s important to have a standard trustless implementation for improving the privacy of it’s users in the reference client that provides a high degree of privacy.
Other clients such as electrum, Android and iPhone will also have the same anonymity layer implemented directly and utilize the protocol extensions.
This allows users a common experience anonymizing funds using a well understood system.
Darksend is an improved and extended version of the CoinJoin.
In addition to the core concept of CoinJoin, we employ a series of improvements such as decentralization, strong anonymity by using a chaining approach , denominations and passive aheadoftime mixing.
The greatest challenge when improving privacy and fungibility of a cryptocurrency is doing it in a way that does not obscure the entire blockchain.
In Bitcoin based crypto currencies, one can tell which outputs are unspent and which are not, commonly called UTXO, which stands for unspent transaction output.
This results in a public ledger that allows any user to act as guarantor of the integrity of transactions.
The Bitcoin protocol is designed to function without the participation of trusted counterparties, in their absence, it is critical that auditing capabilities remain readily accessible to the users through the public blockchain.
Our goal is to improve privacy and fungibility without losing these key elements that we believe make a successful currency.
By having a decentralized mixing service within the currency we gain the ability to keep the
currency itself perfectly fungible. Fungibility is an attribute of money, that dictates that all units
of a currency should remain equal. When you receive money within a currency, it shouldn’t
come with any history from the previous users of the currency or the users should have an
easy way to disassociate themselves from that history, thus keeping all coins equal. At the
same time, any user should be able to act as an auditor to guarantee the financial integrity of
the public ledger without compromising others privacy.
To improve the fungibility and keep the integrity of the public blockchain, we propose using an
aheadoftime decentralized trustless mixing strategy. To be effective at keeping the currency
fungible, this service is directly built into the currency, easy to use and safe for the average
user.
A common strategy in existing Bitcoin implementations of Coinjoin is simply merging
transactions together. This exposes the users to various methods of following the the users
coins through these joined transaction.
# idDashwprfig2#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgDashwprFig2.png!#
Figure 2: An example Coinjoin transaction with 2 users [11][12]
In this transaction, 0.05BTC was sent through the mixer. To identify the source of the money,
one simply has to add up the values on the right until they match one of the values on the left.
Breaking apart the transaction:
0.05+0.0499+0.0001(fee) = 0.10BTC.
0.0499+0.05940182+0.0001(fee) = 0.10940182BTC.
This gets exponentially more difficult as more users are added to the mixer. However, these
sessions can be retroactively deanonymized at any point in the future.
In other proposed implementations of Coinjoin, it’s possible that a user anonymizes money
then eventually sends change from that transaction to an exchange or other entity that knows
the users identity. This breaks the anonymity and allows the entity to walk backwards through
that users transactions. We call this type of attack “Forward Linking”
# idDashwprfig3#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgDashwprFig3.png!#
Figure 3: Forward Change Linking
In this example, Alice anonymizes 1.2BTC, which goes to 2 outputs, 1BTC and 0.2BTC. She
then spends .7BTC from the 1BTC output, receiving change of 0.3BTC. That 0.3BTC then
goes to an identifiable source, confirming Alice also spent the .7BTC in the prior transaction.
To identify the sender of the anonymous transaction, start at the “exchange” transaction and
go backwards in the blockchain till you get to the “Alice sends 0.7BTC anonymously”. As the
exchange, you know it was your user who just recently bought something anonymously, thus
breaking the anonymity completely. We call this type of attack “Through Change Linking”.
# idDashwprfig4#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgDashwprFig4.png!#
Figure 4: Through Change Linking
In the second example, Alice buys 1.2 BTC from coinbase, then anonymizes this amount into
a 1BTC output. She then spends the 1BTC, receives change in the amount of 0.3BTC and
then combines that with her 0.2BTC earlier change.
By combining the change from the anonymous transaction (0.3BTC) and the change she
received from the CoinJoin transaction, you can link the entire history before and after,
completely breaking the anonymity.
Darksend uses the fact that a transaction can be formed by multiple parties and made out to
multiple parties to merge funds together in a way where they can’t be uncoupled thereafter.
Given that all Darksend transactions are setup for users to pay themselves, the system is
highly secure against theft and users coins always remain safe. Currently to mix using
DarkSend requires at least 3 participants.
# idDashwprfig5#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgDashwprFig5.png!#
Figure 5: Three users submit denominated funds into a common transaction. Users pay themselves back in the form of new outputs, which are randomly ordered.
To improve the privacy of the system as a whole we propose using common denominations of
0.1DASH, 1DASH, 10DASH AND 100DASH. In each mixing session, all users should submit
the same denominations as inputs and outputs. In addition to denominations, fees should be
removed from the transactions and charged in bulk in separate, sporadic unlinkable
transactions.
To address the possible DOS attacks, we propose all users submit a transaction as collateral
to the pool when joining. This transaction will be made out to themselves and will pay a high
fee to miners. In the case when a user submits a request to the mixing pool, they must
provide collateral at the beginning of this exchange. If at any point any user fails to cooperate,
by refusing to sign for example, the collateral transaction will automatically be broadcasted.
This will make it expensive to do a sustained attack on the privacy network.
Darksend is limited to 1000 DASH per session and requires multiple sessions to thoroughly
anonymize significant amounts of money. To make the user experience easy and make timing
attacks very difficult, Darksend runs in a passive mode. At set intervals, a user’s client will
request to join with other clients via a Masternode. Upon entry into the Masternode, a queueobject is propagated throughout the network detailing the denominations the user is looking to
anonymize, but no information that can be used to identify the user.
Each Darksend session can be thought of as an independent event increasing the anonymity
of user’s funds. However each session is limited to three clients, so an observer has a one in
three chance of being able to follow a transaction. To increase the quality of anonymity
provided, a chaining approach is employed, which funds are sent through multiple
Masternodes, one after another.
| Depth Of The Chain | Possible Users (n)^r |
| 2 | 9 |
| 4 | 81 |
| 8 | 6561 |
#idDashwprtbl2#Table 2. How many users could possibly be involved in N mixing sessions.
As transactions are merged, Masternodes can possibly “snoop” on users funds as they pass
through. This is not considered a serious limitation due to the requirement for Masternode’s to
hold 1000 DASH and the fact that users utilize random Masternodes that they select to host
their joins. The probability of following a transaction throughout a chaining event can be
calculated as follows
| Attacker Controlled
Masternodes / Total Masternodes | Depth Of The Chain | Probability of
success (n/t)^r | DASH Required |
| 10/1010 | 2 | 9.80e05 | 10,000DASH |
| 10/1010 | 4 | 9.60e09 | 10,000DASH |
| 10/1010 | 8 | 9.51e11 | 10,000DASH |
| 100/1100 | 2 | 8.26e03 | 100,000DASH |
| 100/1100 | 4 | 6.83e05 | 100,000DASH |
| 100/1100 | 8 | 4.66e09 | 100,000DASH |
| 1000/2000 | 2 | 25% | 1,000,000DASH |
| 1000/2000 | 4 | 6.25% | 1,000,000DASH |
| 1000/2000 | 8 | 0.39% | 1,000,000DASH |
| 2000/3000 | 2 | 44.4% | 2,000,000DASH |
| 2000/3000 | 4 | 19.75% | 2,000,000DASH |
| 2000/3000 | 8 | 3.90% | 2,000,000DASH |
#idDashwprtbl3#Table 3. The probability of follow a Darksend transaction on the network given the attacker controls N Nodes.
Where:
n is the total number of nodes controlled by the attacker
t is the total number of Masternodes in the network
r is the depth of the chain
The selection of Masternodes is random
Considering the limited supply of DASH (5.3 million at the time of writing) and the low liquidity
available on the market, it becomes an impossibility to attain a large enough number of
Masternodes to succeed at such an attack.
Extending the system by blinding Masternodes to the transactions taking place on their node
will also greatly enhance the security of the system.
In section 3.4 we describe the probabilities of following a single transaction through multiple
sessions of Darksend mixing. This can further be addressed by blinding Masternodes, so they
can’t see which inputs/outputs belong to which users. To do this we propose a simple relay
system that users can use to protect their identity.
Instead of a user submitting the inputs and outputs directly into the pool, they will pick a
random Masternode from the network and request that it relays the inputs/outputs/signatures
to the target Masternode. This means that the Masternode will receive N sets of
inputs/outputs and N sets of signatures. Each set belongs to one of the users, but the
Masternode can’t know which belongs to which.
By utilizing Masternode quorums, users are able to send and receive instant irreversible transactions.
Once a quorum has been formed, the inputs of the transaction are locked to only be spendable in a specific transaction, a transaction lock takes about 4 seconds to be set currently on the network.
If consensus is reached on a lock by the Masternode network, all conflicting transactions or conflicting blocks would be rejected thereafter, unless they matched the exact transaction ID of the lock in place.
This will allow vendors to use mobile devices in place of traditional POS systems for real world commerce and users to quickly settle facetoface non commercial transactions as with traditional cash.
This is done without a central authority.
An extensive overview of this feature can be found in the InstantX white paper[-10#ql:idDashwprref10#].
x11 is a widely used hashing algorithm, which takes a different approach, known as algorithm chaining.
x11 consists of all 11 SHA3 contestants[-13#ql:idDashwprref13#], each hash is calculated then submitted to the next algorithm in the chain.
By utilizing multiple algorithms, the likelihood that an ASIC is created for the currency is minimal until a later part of it’s life cycle.
In the life cycle of Bitcoin, mining began with hobbyists which used CPUs to mine the currency, then shortly after GPU software was created, which quickly replaced the CPUs.
Years after the GPUs cycle, ASICs or Application Specific Integrated Circuits were created, which quickly replaced the GPUs.
Due to the complexity and die size required to create an ASIC for mining x11, we expect that it will take considerably longer than it did in Bitcoin, allowing for hobbyists to take part in the mining for a longer period of time.
We believe this is highly important for good distribution and growth of a cryptocurrency.
Another benefit of the chaining hashing approach is high end CPUs give an average return similar to that of GPUs.
Also GPUs have been reported to run 3050% cooler, with less wattage than the Scrypt algorithm used by most current cryptocurrencies.
A different approach to restricting the inflation of mining is taken in Dash, using a 7% reduction of the supply per year.
This is done as opposed to halving implemented by other currencies.
In addition supply each block is directly tied to the amount of miners on the network; more miners result in lower mining rewards.
Production of Dash is scheduled to carry on throughout this century and onto the next, slowly grinding down until finally near the year 2150, production will cease.
# idDashwprfig6#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgDashwprFig6.png!#
Figure 6: Mining Reward Schedule
This paper introduces various concepts to improve the design of bitcoin resulting in improved privacy and fungibility for the average user, less price volatility and quicker message propagation throughout the network.
This is all accomplished by utilizing an incentivized twotier model, rather than the existing singletier model in other cryptocurrencies such as Bitcoin.
By utilizing this alternative network design it becomes possible to add many types of services such as decentralized mixing of coins, instant transactions and decentralized oracles using masternode quorums.
# idDashwprref1#1. A peertopeer electronic cash system (2008)
# idDashwprref2#2. http://eprints.qut.edu.au/69169/1/Boyen_accepted_draft.pdf
# idDashwprref3#3. https://www.cryptocoinsnews.com/3solutionsinstantbitcoinconfirmations/
# idDashwprref4#4. http://research.microsoft.com/pubs/156072/bitcoin.pdf
# idDashwprref5#5. http://www0.cs.ucl.ac.uk/staff/s.meiklejohn/files/imc13.pdf
# idDashwprref6#6. https://getaddr.bitnodes.io/nodes/incentive/
# idDashwprref7#7. https://medium.com/zapchainmagazine/whydontpeoplerunbitcoinnodesanymored4da0b45aae5
# idDashwprref8#8. https://dashninja.pl//
# idDashwprref9#9. https://www.dashpay.io/wpcontent/uploads/2014/09/InstantTX.pdf
# idDashwprref10#10. https://github.com/dashpay/dash/blob/master/src/Masternodepos.cpp,
# idDashwprref11#11. https://blockchain.info/tx/4eb3b2f9fe597d0aef6e43b58bbaa7b8fb727e645fa89f922952
f3e57ee6d603
# idDashwprref12#12. https://blockchain.info/tx/1694122b34c8543d01ad422ce600d59f8d8fde495ac9ddd894
edc7139aed7617
# idDashwprref13#13. http://en.wikipedia.org/wiki/NIST_hash_function_competition#Finalists
# idDashwprref14#14. http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf
name::
* McsEngl.dashnet'Masternode@cptIt,
_ADDRESS.WPG:
* https://www.youtube.com/watch?v=hm7IYkgIOXc,
name::
* McsEngl.dashnet'Blockchain (dashbcn)@cptIt,
name::
* McsEngl.dashbcn'Block-Explorer (dashbex)@cptIt,
_ADDRESS.WPG:
* https://chainz.cryptoid.info/dash//
* Block#1 https://chainz.cryptoid.info/dash/block.dws?1.htm,
name::
* McsEngl.dashnet'Consensus-exchange-Value-Token (DASHcevt)@cptIt,
* McsEngl.dashcev@cptIt,
* McsEngl.mnyDash@cptIt,
* McsEngl.mnyDarkcoin@cptIt,
_GENERIC:
* consensus-token#ql:idBcncet#
_DESCRIPTION:
Dash DASH
Dash is a cryptocurrency previously known as Darkcoin or XCoin.
It uses a coin-mixing service called Darksend that prevents transactions from being traced and adds privacy to the network.
Quick confirmation makes Dash payments an effective way to send money worldwide.
Two-Tier network opens new possibilities to integrate various services unavailable for other currencies.
[https://changelly.com/supported-currencies]
===
Dash (formerly known as Darkcoin) is an open source peer-to-peer cryptocurrency that uses a system called Darksend to add privacy to transactions.[1] It was rebranded from "Darkcoin" to "Dash" on March 25, 2015, a portmanteau of "Digital Cash".[2]
Dash uses a chained hashing algorithm approach called X11 for the proof-of-work. Instead of using the SHA-256 (from well-known Secure Hash Algorithm family) or scrypt it uses 11 rounds of different hashing functions.[3]
With chained hashing, high end CPUs give an average return similar to that of GPUs. Another side effect of the algorithm is that GPUs run at about 30% less electrical power than scrypt and 30% to 50% cooler, putting less stress on the computing setup and ensuring lower energy bills for miners.[4]
[https://en.wikipedia.org/wiki/Dash_%28cryptocurrency%29]
name::
* McsEngl.dashcevt'ogn.EXCHANGE@cptIt,
_SPECIFIC:
* https://poloniex.com/
* https://www.xbtce.com/
* https://btc-e.com/
* https://www.livecoin.net/
* https://exmo.com/
* https://bittrex.com//
* http://www.btc38.com/
name::
* McsEngl.dashnet'Governance-system (dashdgbb)@cptIt,
* McsEngl.Decentralized-Governance-By-Blockchain@cptIt,
* McsEngl.DGBB@cptIt,
_DESCRIPTION:
Governance in a decentralized project is difficult, because by definition there are no central authorities to make decisions for the project.
In Dash, such decisions are made by the network, that is, by the owners of masternodes.
The DGBB system allows masternodes to vote for or against proposals, which can then be implemented (or not) by Dash’s developers. A key example is early in 2016, when Dash’s Core Team submitted a proposal to the network asking whether the blocksize should be increased to 2 MB. Within 24 hours, consensus had been reached to approve this change. Compare this to Bitcoin, where debate on the blocksize has been raging for nearly three years.
[https://www.dash.org/governance/]
===
DDGB consists of three components: Proposals, Votes, and Budgets.
Anyone can submit a Proposal for a small fee.
Shareholders (owners of network Masternodes) cast votes for or against proposals.
Approved Proposals become Budgets.
Budgets are paid directly from the blockchain.
[https://dashpay.atlassian.net/wiki/display/DOC/Using+Decentralized+Governance%3A+Proposals%2C+Voting%2C+and+Budgets]
_DESCRIPTION:
Dash names the system Decentralized Governance by Blockchain (DGBB ) and since DGBB’s release in August 2015 all Dash operations have been under the control of the Dash network via the DGBB system, with new proposals made and funded each month autonomously by the network.
In fact since the inception of this system, the Dash network has funded the promotion of Dash conferences around the world, acquired highvalue property directly from the blockchain (dash.org) and many other projects that were important to the long term success of the ecosystem.
[https://www.dash.org/binaries/evo/DashPaper-v13-v1.pdf]
_DESCRIPTION:
Recently, new blockchains equipped with built in governance system tried to cope with this problem. Dash is the forerunner to implement governance system in their blockchain. Dash, who call themselves as the “First Self Governing, Self Funding Protocol”,proposed a decentralized management system based on the masternode voting mechanism in 2015. Dash has been steadily developed using this governance system. Recently the price of Dash surpassed over $100 (March 16th, 2017). A stable governance structure may be the reason for the increased value.
[http://cryptocentral.info/topic/913/boscoin-bos-a-congressional-cryptocurrency-platform-for-trust-contracts/4]
_DESCRIPTION:
Governance and Funding[edit]
Dash is the first decentralized autonomous organization powered by a Sybil proof decentralized governance and funding system.[3]
DGBB or Decentralized Governance By Blockchain as it's called is a decentralized process by which the network determines where money is spent.
Each Masternode operator is given the ability to use 1 vote on each governance proposal, which is a completely open and decentralized process.[15]
Community interaction with proposal submitters is done usually through community driven websites, like DashWhale.[16]
These websites allow proposal submitters to provide multiple drafts, then lobby for community support before finally submitting their project to the network for a vote.
After the submitter has enough support, the network will automatically pay out the required funds in the next super block, which happen monthly.
Although, only in use a few months, the funding system has seen growth of it's month revenue, from originally ~$14 thousands in September 2015, to nearly $30 thousands in March 2016.[17]
Eventually the budget system can theoretically scale to $9M per month at a market cap of $500M.[18]
Since it's inception, the project has used the system for important assets like acquiring dash.org,[19] adoption into the Lamassu ATM[20][21] and the Dash N' Drink instant soda machine,[22] along with funding many public events.[23][24][25]
[https://en.wikipedia.org/wiki/Dash_(cryptocurrency)#Governance_and_Funding]
name::
* McsEngl.dashdgbb'Funding@cptIt,
* McsEngl.dash-funding@cptIt,
* McsEngl.dashnet'funding@cptIt,
_DESCRIPTION:
The DGBB also provides a means for Dash to fund its own development. While other projects have to depend on donations or premined endowments, Dash uses 10% of the block reward to fund its own development. Every time a block is mined, 45% of the reward goes to the miner, 45% goes to a masternode, and the remaining 10% is not created until the end of the month. During the month, anybody can make a budget proposal to the network. If that proposal is approved by at least 10% of the masternode network, then at the end of the month a series of "superblocks" will be created. At that time, the block rewards that were not paid out (10% of each block) will be used to fund approved proposals. The network thus funds itself by reserving 10% of the block reward for budget projects.
[https://www.dash.org/governance/]
name::
* McsEngl.dashdgbb'Owner-of-masternode@cptIt,
_DESCRIPTION:
Governance in a decentralized project is difficult, because by definition there are no central authorities to make decisions for the project.
In Dash, such decisions are made by the network, that is, by the owners of masternodes.
[https://dashpay.atlassian.net/wiki/pages/viewpage.action?pageId=84672534]
name::
* McsEngl.dashdgbb'Proposal (dashppl)@cptIt,
* McsEngl.dashppl@cptIt,
_DESCRIPTION:
During the month, anybody can make a budget proposal to the network. If that proposal is approved by at least 10%* of the masternode network, then at the end of the month a series of "superblocks" will be created. At that time, the block rewards that were not paid out (10% of each block) will be used to fund approved proposals. The network thus funds itself by reserving 10% of the block reward for budget projects.
*The actual calculation is (YES VOTES - NO VOTES) > (Total Number of Masternodes / 10)
[https://dashpay.atlassian.net/wiki/pages/viewpage.action?pageId=84672534]
name::
* McsEngl.dashppl'Structure@cptIt,
_STRUCTURE:
The following information is required to create a proposal:
proposal-name -- a unique label, 20 characters or less
url -- a proposer-created webpage or forum post containing detailed proposal information
payment-count -- how many cycles the proposal is requesting payment
block-start -- the requested start of proposal payments
dash-address -- the address to receive proposal payments
monthly-payment-dash -- the requested payment amount
[https://dashpay.atlassian.net/wiki/display/DOC/Using+Decentralized+Governance%3A+Proposals%2C+Voting%2C+and+Budgets]
name::
* McsEngl.dashppl.BUDGET@cptIt,
* McsEngl.dash-budget-proposal@cptIt,
_DESCRIPTION:
Budgets
Budgets are proposals which receive 10% of the possible votes (currently about 410 out of 4100) more yes votes than no votes.
Budgets can be nullified at any time if vote totals (cast or re-cast) fall below the approval threshold.
Budgets are processed (paid) in order of yes minus no votes. More popular budgets get payment priority.
Approximately 7500 dash (in 2016) are available for each budget cycle, declining by %7.1 per year.
[https://dashpay.atlassian.net/wiki/display/DOC/Using+Decentralized+Governance%3A+Proposals%2C+Voting%2C+and+Budgets]
name::
* McsEngl.dashdgbb'Vote@cptIt,
_DESCRIPTION:
Votes
Votes are cast by Masternode owners.
Votes can be changed at any time.
Votes are counted approximately every 28.8 days. (16616 blocks)
[https://dashpay.atlassian.net/wiki/display/DOC/Using+Decentralized+Governance%3A+Proposals%2C+Voting%2C+and+Budgets]
name::
* McsEngl.dashdgbb'Resource@cptIt,
_ADDRESS.WPG:
* https://www.dash.org/governance//
* https://dashpay.atlassian.net/wiki/pages/viewpage.action?pageId=84672534,
name::
* McsEngl.dashnet'Statistics (dashstat)@cptIt,
* McsEngl.dashnet'statistics@cptIt,
* McsEngl.dash-network-statistics@cptIt,
name::
* McsEngl.dashnet'Wallet (dashwlt)@cptIt,
* McsEngl.dashwlt@cptIt,
* McsEngl.dashwallet@cptIt,
_GENERIC:
* blockchain-wallet#ql:idBcnwlt#
_SPECIFIC:
* DashCore-wallet,
* Electrum-wallet,
* Mobile-wallet,
* Hardware-wallet,
* Paper-wallet,
* Online-wallet,
_ADDRESS.WPG:
* https://dashpay.atlassian.net/wiki/pages/viewpage.action?pageId=1146941,
name::
* McsEngl.dashnet'Human (dashhmn)@cptIt,
* McsEngl.dashhmn@cptIt,
* McsEngl.dashnet'human@cptIt,
name::
* McsEngl.dashnet'Resource@cptIt,
_ADDRESS.WPG:
* https://www.dash.org//
* https://github.com/dashpay/dash,
* https://www.dashcentral.org/gettingstarted,
===
* {2016-05-03} http://cointelegraph.com/news/dash-aims-to-surpass-bitcoin-and-become-the-future-of-money,
* {2014-03-29} https://www.dash.org/forum/threads/the-birth-of-darkcoin.162/
name::
* McsEngl.dashnet.EVOLUTING@cptIt,
name::
* McsEngl.dashnet.EVOLUTION (v13)@cptIt,
* McsEngl.Dash-Evolution@cptIt,
_DESCRIPTION:
In the third major iteration of Dash named Dash Evolution (v13), additional architectural and functional improvements are being developed such as
the addition of a 3rd network tier (T3) comprised of a decentralized API (DAPI) that provides users with trustless remoteaccess via direct HTTP and RPC connections into the Dash network that are serviced by randomly comprised Masternode Quorums,
a decentralized wallet protocol that enables users to buy merchandise from the web in a trustless way (DashPay) without the need to host their own fullnode or use a centralized payment gateway,
a 2ndtier highperformance shardbased filestorage system that provides improved methods for transaction confirmation and doublespend prevention (DashDrive),
Primitives for representing users and accounts as objects to enable users to connect and transact with friends using aliases and rate each other to build trust networks (Social Wallet),
decentralized network administration by Masternode operators (DNA),
a new dynamic query language for use across Dash Evolution components providing an extensible objectbased crosstier communications standard (DSQL),
addition of a historical chain of all signatures used on the Masternode network for use in secure quorum selection (Quorum Chains),
improved Privacy architecture,
automatic instant transactions (AutoIX) and
ratedservices provided by network operators such as fiat converters.
[https://www.dash.org/binaries/evo/DashPaper-v13-v1.pdf]
name::
* McsEngl.bcnnet.time.FairCoop (FAIRnet {2014-01-07})@cptIt,
* McsEngl.bcnnet.FairCoop@cptIt,
* McsEngl.FairCoop-network@cptIt,
* McsEngl.fairnet@cptIt,
* McsEngl.faircoin-network@cptIt,
_DESCRIPTION:
Faircoin, the Faircoop ecosystem cryptocurrency
FairCoin is the monetary base system for FairCoop.
The key purposes of FairCoin is to be used as a tool for economic redistribution, increasing justice, the empowerment of grassroots groups, the transformation of social and economic relations and the creation of commons.
[https://fair.coop/faircoin/]
name::
* McsEngl.fairnet'Protocol@cptIt,
name::
* McsEngl.FairCoin V2 white paper {2015.05}@cptIt,
_ADDRESS.WPG:
* https://chain.fair-coin.org/download/FairCoin2-Draft.pdf,
FairCoin V2 white paper
DRAFT
Document version 1.0
Thomas Kφnig, May 2015
tom@fair-coin.org
FairCoin is the monetary base system for FairCoop The Earth Cooperative for a Fair Economy (see https://fair.coop).
In FairCoop we develop tools and transfer knowledge that enable everybody to participate in a fair global economy.
The existing version of the FairCoin wallet relies on mining and minting technology to secure the block chain.
The problem is that neither mining nor minting can truly be considered fair, because both confer an advantage on the already rich.
Therefore we decided to create a new version of FairCoin which corrects these issues.
With FairCoin2 (in short FC2) we can create block chain-based software that is fair, secure and power-saving.
It is based on cooperation and not on competition.
It is built on the code-base of a recent version of the Bitcoin core client.
This enables us to benefit from the latest developments made by the dedicated Bitcoin developers.
Also the comprehensive infrastructure that already exists around Bitcoin can be adopted for FairCoin with minimal effort.
This document describes the design concepts we have implemented in FairCoin2.
Some knowledge about how Bitcoin works is required to fully understand the contents of this document.
The first paragraphs provide a rather high-level view of the FC2 concept and the further you read the more technical and detailed it becomes.
In contrast to other cryptocurrencies FC2 does not implement any mining or minting (aka. staking) functionality, which are both competitive systems.
Block generation is instead performed by so-called certified validation nodes (in short CVN).
These nodes cooperate to secure the network.
To run a CVN one needs to complete a certification procedure which is called node certification procedure (in short NCP) that is operated by FairCoop (https://fair.coop/node-certificationprocedure/).
The requirements to operate such a node are described in chapter-3.1#ql:idFairwpr31#.
Please note that definition of the NCP is out of the scope of this document and will be defined in a separate document.
In the long run the NCP should be powered by a reputation system.
There is no reward for block creation (no coinbase/stake transaction).
Therefore the money supply does not change over time and is fixed at the time we migrate to FC2.
Nevertheless, the transaction fees go to the respective block creators to compensate their efforts for running a CVN.
Certain chain parameters, e.g. the transaction fee will be dynamically adjustable (without the need of releasing a new wallet version) by democratic community consensus.
The FairCoin team needs the approval (digital signatures) of a high percentage of all the active CVN.
Block generation takes place in a collaborative way.
All CVN work together to bundle pending transactions into transaction blocks.
These blocks can only be created by CVN every 3 minutes.
Which CVN will generate the next block is determined by its time-weight.
The time-weight describes how much time has passed since a CVN created its last block.
If for example CVN A created a block 50 blocks ago and CVN B created it 55 blocks ago CVN B will be chosen to create the next block in the network.
There can always only be exactly one CVN with the highest timeweight.
If a new CVN joins the network for the first time it will be elected to create the next block.
Between two blocks only one new CVN can join in.
Block generation is performed in 3 phases.
New transactions are accepted during all these phases.
In this phase all nodes relay transactions they receive from other nodes to any node they are currently connected to.
This phase lasts at least 170 sec.
If there are no pending transactions in the network it takes as long as the next transaction hits the network.
In other words, this phase only ends when there is at least 1 pending transaction in the network.
In this phase each CVN determines its own time-weight based on the local block chain information and announces it to all other connected nodes.
Announcement messages are relayed by all nodes just like transactions.
The higher the nodes time-weight the sooner the announce message is sent to the network according to the following simple formula:
delay=10-(10*otw/tn)
Where:
delay is the time in seconds to wait before a CVN sends its own time-weight
otw is the CVN calculated own time-weight
tn is the total number of active nodes
10 is the constant of ten seconds, which is the duration of this phase
This will greatly reduce the amount of announcement packets sent over the network because if a CVN receives and correctly validates a time-weight announcement message from an other node with a higher time-weight it will not send its weight to the network.
Every CVN verifies that each time-weight announcement it receive is correct using the local block chain data (bogus announcements are discarded and a DoS ban score of 50 is proposed).
Time-weight announcements are used to determine the node with the highest time weight that is currently connected to the network.
This phase starts 10 sec. before the actual block target time.
This phase starts right after the Time-weight announcement phase.
Every CVN determines the CVN with the greatest time-weight according to the announcements it received.
It then signs and sends their candidate vote message to the network, which is relayed by every node just like transactions.
This phase has no defined length.
It stops once the elected CVN has received enough vote messages for its own id from over 90% of all active nodes.
This is the point in time when the collaboratively-elected CVN finally creates the next block in the chain containing all pending transactions from the so called “rawmempool”.
Also parts of the signed vote messages are incorporated into the block to prove that optimally 100% but at least 90% of all active connected nodes agreed on the elected CVN.
The aim of the CVNs is to secure the network by validating all the transactions that had been sent to the network and put them into a transaction block chain.
Blocks are created each 3 minutes (180 sec.).
Transactions are confirmed after they have been added to a block.
If there are no pending transactions no further blocks are created, which will not happen anymore after FairCoin has been widely adopted.
A CVN is a standard FairCoin core client configured with additional information namely certification data issued by FairCoop which “upgrades” it to a CVN.
Every node will be assigned a unique id.
Every entity running a CVN must agree upon the following technical requirements and must carry the responsibility to full fill these rules.
1. The system must be connected to the Internet all the time (24/7) and the TCP port 46392 must be reachable by all remote nodes from the Internet
2. The system must use a public NTP server to synchronize its system time to, preferably pool.ntp.org to ensure that the system time is always correct
3. The entity must have an account at the FairCoop web site
4. The wallet software must be configured with certification data issued by FairCoop
Further requirements might be defined after public discussion.
But this will be subject to the NCP document.
But why would we need certification at all?
A decent certification procedure ensures that a high percentage of all CVNs are honest creator nodes.
At the moment the author sees no easy way of ensuring that each node has only one identity without a well established reputation system.
If every node was a creator node a skilled attacker could modify the client software in such a way to create thousands of different identities and could then perform numerous different attacks against the network.
The transaction fees go to the node which created the block.
Transaction fees exist to avoid block chain spam and give block creators a small reward for taking the effort to leave their node running and pass through the certification procedure.
Fees should be dynamically adjustable to satisfy any change in the value of FairCoin.
name::
* McsEngl.fairnet'Node@cptIt,
name::
* McsEngl.fairnet'CVN@cptIt,
* McsEngl.Fairnet'Certified-validation-node@cptIt,
* McsEngl.Fairnet'CVN@cptIt,
_DESCRIPTION::
In contrast to other cryptocurrencies FairCoin does not implement any mining or minting
functionality, which are both competitive systems. Block generation is instead performed by socalled
certified validation nodes (in short CVN). These nodes cooperate to secure the network.
Therefore we call this system proof-of-cooperation (PoC).
To run a CVN one needs to complete a certification procedure which is called a node certification
procedure that is operated by FairCoop (https://fair.coop/node-certification-procedure/). The
requirements to operate such a node are described in chapter 3.1. Please note that the definition of
the certification procedure is not covered here but in a separate document.
[https://chain.fair-coin.org/download/FairCoin2-white-paper-V1.1.pdf]
_RESOURCE::
* https://github.com/faircoin/faircoin/blob/faircoin2/doc/CVN-operators-guide.md,
name::
* McsEngl.fairnet'Blockchain@cptIt,
name::
* McsEngl.fairbcn'Block-explorer@cptIt,
_ADDRESS.WPG:
* https://chain.fair-coin.org/chain/FairCoin,
* BlockH0: https://chain.fair-coin.org/block/f1ae188b0c08e296e45980f9913f6ad2304ff02d5293538275bacdbcb05ef275,
name::
* McsEngl.fairnet'Consensus-evt (FAIRcevt)@cptIt,
* McsEngl.Faircoin@cptIt,
* McsEngl.mnyFair@cptIt,
* McsEngl.mnyFaircoin@cptIt,
_DESCRIPTION:
FairCoin is the monetary base system for FairCoop. We constantly drive development of the FairCoop/FairCoin ecosystem further and shape the individual components to fit our vision: building tools to enable everyone to participate in a fair economy on a global scale.
We decided to create a new version of FairCoin which corrects issues we encountered. The current version of FairCoin relies on PoS (proof-of-stake) which cannot be considered fair, because it confer an advantage on the already rich. Therefore we needed to come up with a new way to secure the network. We call it PoC (proof-of-cooperation). This innovation will finally make FairCoin fair, secure, and sustainable.
The draft we present here is meant to start a discussion on what the new version would look like. Many hours of voluntary work have already been put into building the basic concept and the white paper. The focus of the draft paper is mainly on the technical and implementation side of the FairCoin2 project. Many more aspects besides the technical have to be taken into account and elaborated on.
So, here it is the first draft of the FairCoin V2.0 white paper. Enter the fair dimension of cryptocurrency and download the PDF file now.
[https://fair-coin.org/faircoin2.html]
===
FairCoin (FAIR)
$0.037195 (1.64%)
0.00003150 BTC (0.58%)
Rank 116
Currency
Market Cap
$1,972,825
1,671 BTC
Volume (24h)
$2,277
1.93 BTC
Circulating Supply
53,040,622 FAIR
[https://coinmarketcap.com/currencies/faircoin/] {2017-04-16}
name::
* McsEngl.fairnet'Human@cptIt,
name::
* McsEngl.fairnet'Resource@cptIt,
_ADDRESS.WPG:
* https://fair-coin.org//
* https://fair.coop,
* https://getfaircoin.net/,
* https://use.fair-coin.org/,
===
* https://github.com/faircoin,
* {2016-06} https://chain.fair-coin.org/download/FairCoin2-white-paper-V1.1.pdf,
name::
* McsEngl.bcnnet.time.Next (NXTnet {2013-11-24})@cptIt,
name::
* McsEngl.nxtnet'DESCRIPTION@cptIt,
_DESCRIPTION:
Nxt is more than just a digital currency. It’s the infrastructure for a digital economy.
[http://nxt.org/about/what-is-nxt/]
===
Nxt makes sending money as easy as sending an email. But it’s far more than a digital currency. It’s a platform for transactions of all kinds and the foundation of something much bigger than P2P cash.
[http://nxt.org/about/what-is-nxt//]
name::
* McsEngl.nxtnet'NAME@cptIt,
* McsEngl.netNext@cptIt,
* McsEngl.netNxt@cptIt,
* McsEngl.Nxt-platform@cptIt,
* McsEngl.nxtnet@cptIt,
* McsEngl.sihNxt@cptIt,
name::
* McsEngl.nxtnet'GENERIC@cptIt,
_GENERIC:
* Exchange-value-token-blockchain-network#ql:idBcnnetEvtkn#
name::
* McsEngl.nxtnet'Blockchain (nxtbcn)@cptIt,
name::
* McsEngl.nxtbcn'Block-Explorer (nxtbex)@cptIt,
_ADDRESS.WPG:
* https://www.mynxt.info/blockexplorer//
* Block#1 https://mynxt.info/block/1,
* https://nxtportal.org/monitor//
* http://www.peerexplorer.com//
name::
* McsEngl.nxtnet'Exchange-value-token (nxtevt)@cptIt,
_DESCRIPTION:
MONETARY SYSTEM
The Nxt Monetary System allows you to create and trade user-defined Tokens called Currencies.
Currencies are a specific class of Asset which have several extra parameters, such as the ability to back them with the NXT crypto-currency to stabilise their value.
Monetary System currencies can be freely traded both within the Nxt system using the decentralized Exchange Booth feature and outside the Nxt core on external exchanges or projects that support the MS Currency system
The Monetary System allows an individual or project that needs a digital currency to quickly create one ‘off the shelf’ and then immediately begin using it, taking advantage of the established Nxt blockchain, software and network.
[https://nxt.org/what-is-nxt/monetary-system/]
name::
* McsEngl.nxtevt.Ardor (ARDRevt)@cptIt,
* McsEngl.mnyArdor@cptIt,
* McsEngl.mnyARDR@cptIt,
_DESCRIPTION:
Ardor ARDR
Ardor is a scalable blockchain platform based on Child Chains, allowing to build cost-savvy and stable decentralized applications for any purposes.
Ardor is powered by the cryptocurrency of the same name, based on the NXT blockchain technology.
[https://changelly.com/supported-currencies]
name::
* McsEngl.nxtnet'Consensus-evt (NXTcevt)@cptIt,
* McsEngl.mnyNext@cptIt,
* McsEngl.mnyNxt@cptIt,
* McsEngl.nxtmny@cptIt,
_DESCRIPTION:
Next NXT
The developers of Nxt deem it a second-generation cryptocurrency dramatically different from Bitcoin and all the altcoins.
It is written from scratch, based on PoS mechanism and can be considered an eco-friendly coin as it does not require great amounts of hashing power.
Its efficient feature "Transparent Forging" minimizes the transaction time as it determines which server node will generate the next block, so the transaction is sent straight to this node.
[https://changelly.com/supported-currencies]
_DESCRIPTION:
Nxt (NXT)
$0.020194 (3.77%)
0.00001656 BTC (4.36%) Buy / Sell Instantly
Rank 36
Currency
Market Cap
$20,173,806
16,539 BTC
Volume (24h)
$305,907
250.79 BTC
Circulating Supply
998,999,983 NXT
Max Supply
1,000,000,000 NXT
[https://coinmarketcap.com/currencies/nxt/] {2017-04-22}
===
Nxt is an open source[5] cryptocurrency and payment network launched in November 2013 by anonymous software developer BCNext.[6] It uses proof-of-stake to reach consensus for transactions - as such there is a static money supply and no mining as with Bitcoin. Nxt is specifically conceived as flexible platform to build applications and financial services around.[7] It has an integrated asset-exchange[8] (comparable to shares), messaging system and marketplace. Users can also create new currencies within the system. The last major release enabled Multisignature capabilities and a plugin-system for the client.[9]
[https://en.wikipedia.org/wiki/Nxt]
name::
* McsEngl.nxtcevt.AGGREGATE@cptIt,
Nxt is a scam because all Nxt coins are pre-mined:
First, it's important to note that Nxt is a 100% Proof-of-Stake (PoS) coin.
The only way to implement this form of currency is to issue all available coins in the genesis block.
To do otherwise would force the implementation of some form of Proof-of-Work scheme in order to prevent attacks on the network that "fake" stake.
Since the creator of Nxt wanted a 100% PoS platform, this was not a desirable course of action.
Second, the term "pre-mined" is a misnomer because Nxt coins are not being mined at all.
The original stakeholders in Nxt contributed Bitcoin in order to seed the creation of the 1 billion coins represented in the genesis block, and these coins were distributed among the original stakeholders.
The stakeholders are expected to distribute coins by donating them, using them as "bounties" to pay for work on the coin (software, documentation, translations, support, etc.) that is done by the community.
Even the creator of Nxt (BCNxt ) made an investment.
The coins were not generated from nothing!
Third, the creation of the genesis block was fully public, and all of the original account numbers and their assigned amounts of Nxt are visible: see https://bitcointalk.org/index.php?topic=303898.msg3652710#msg3652710
[http://nxtwiki.org/wiki/FAQ#Nxt_is_a_scam_because_all_Nxt_coins_are_pre-mined]
Why is it called forging instead of mining?
With Bitcoin and many other cryptocurrencies, the act of securing and verifying the blockchain results in new coins being created. With Nxt, however, all possible coins already exist, and accounts earn coins from transaction fees alone. As a result, it was felt that a new word - "forge" - was needed to describe the manner in which coins are earned.
[http://nxtwiki.org/wiki/FAQ#Why_is_it_called_forging_instead_of_mining.3F]
name::
* McsEngl.nxtnet'Program@cptIt,
name::
* McsEngl.nxtpgm.IMPLEMENTATION@cptIt,
_DESCRIPTION:
What is the difference between the Nxt Server and Nxt Client?
The Nxt Server is the software that implements the core features of Nxt. When we talk about "version 1.1.2 of Nxt" being released, we are talking about the server. It is written in Java, and runs on a command-line interface. The Nxt Client is the web-based interface you use when interacting with Nxt at http://127.0.0.1:7876/ (or http://localhost:7876/). Developers keep working on new clients for all platforms (even mobile devices!). It's likely that most client softwares will also include the core server software so that you can easily set up and operate Nxt.
[http://nxtwiki.org/wiki/FAQ#What_is_the_difference_between_the_Nxt_Server_and_Nxt_Client.3F]
_ADDRESS.WPG:
* http://nxtwiki.org/wiki/For_Programmers,
* https://bitbucket.org/JeanLucPicard/nxt/src,
name::
* McsEngl.nxtnet'Wallet@cptIt,
_DESCRIPTION:
Where is my wallet?
Unlike Bitcoin or other altcoins, there is no local wallet with Nxt. More specifically, the coin uses a "brain wallet", which is to say that wallets are decentralized and kept on the network. When you create an account in Nxt, your secret passphrase is used to create your account number. Once your account number is generated, you can unlock it and access it by using your passphrase on any running Nxt node.
[http://nxtwiki.org/wiki/FAQ#Where_is_my_wallet.3F]
name::
* McsEngl.nxtnet'Security@cptIt,
_DESCRIPTION:
Improved security. This property also protects the network from the problems of mining power being concentrated in a few big pools or organisations, which renders it vulnerable to a ‘51 percent’ attack. Nxt’s proof-of-stake means that even if one person owns 90 percent of all the coins available, the network remains secure.
[http://nxt.org/about/what-is-nxt/]
name::
* McsEngl.nxtnet'Human@cptIt,
name::
* McsEngl.nxthmn.BCNext@cptIt,
* McsEngl.BCNext@cptIt,
_DESCRIPTION:
BCNext
BCNext is the founder of Nxt and wrote the initial version of Nxt's code. BCNext saw Bitcoin as a failed attempt to create a digital economy and so created Nxt as a platform to build a digital economy upon. He first appeared on Bitcointalk with a post announcing Nxt on 28th September 2013 and was a self-declared Sockpuppet of a long-standing Bitcointalk member. BCNext was involved in the early development of Nxt but their last post was on the 8th November 2013. BCNext then began to communicate through http://nxtwiki.org/wiki/Glossary#Come-from-Beyond. BCNext left the project once he was satisfied the community had established itself in April/May 2014. Come-from-Beyond now has his notes and planned implementation of the announced and unannounced features of Nxt.
[http://nxtwiki.org/wiki/Glossary#BCNext]
name::
* McsEngl.nxthmn.Come-from-Beyond@cptIt,
_DESCRIPTION:
Come-from-Beyond
Come-from-Beyond is an important developer for the initial implementation of Nxt and is a continuing forum member and Nxt development contributer. He was originally employed on contract directly by BCNext from the start of Nxt in late 2013. After BCNext stopped posting from the BCNext account, he was the conduit through which BCNext communicated. Come-from-Beyond’s contract came to an end on the 3rd April 2014, the day before the beginning of George Orwell’s book ‘1984’. He now works as freelance developer to complete the ideas BCNext passed on, and to build his own projects on top of the Nxt Platform.
[http://nxtwiki.org/wiki/Glossary#Come-from-Beyond]
name::
* McsEngl.nxthmn.FOUNDER@cptIt,
_DESCRIPTION:
Founder
Nxt's founders are the 73 people who sent bitcoin to secure an initial stake in Nxt.
All of Nxt's coins were generated on November 25, 2013 and distributed in the genesis block to the founders, based on the amount of bitcoin sent.
[http://nxtwiki.org/wiki/Glossary#Founder]
name::
* McsEngl.nxtnet'Organization@cptIt,
name::
* McsEngl.nxtogn.Exchange-organization@cptIt,
_SPECIFIC:
Poloniex
Bter
BTC38
Nxt Multigateway
CCEX
HitBTC
Changelly
Litebit (buy with IDEAL)
name::
* McsEngl.nxtogn.NXT-Foundation@cptIt,
NXT Foundation
Mauvestraat 44-4
Amsterdam, MA 1073RM
Netherlands
name::
* McsEngl.nxtnet'Resource@cptIt,
_ADDRESS.WPG:
* http://nxt.org//
* https://cointelegraph.com/news/nxtardor-platform-to-make-blockchain-cheaper-and-safer, {2016-07-27}
* http://nxt.org/about/what-is-nxt/
* https://en.wikipedia.org/wiki/Nxt,
name::
* McsEngl.nxtnet'Doing@cptIt,
_DESCRIPTION:
Nxt takes a different approach.
Instead of building on the Bitcoin protocol, Nxt started with a vision of a radical new digital economy and was designed from the ground up to create a platform to realise it.
Not only does it open up new possibilities – everything from digital cash and property ownership records to smart contracts and online transfer of stocks and shares – but it addresses all of the most serious deficiencies in existing cryptocurrencies.
Most altcoins aim to fix one or two of these.
Nxt was developed to allow a sustainable, fair and versatile platform that would benefit everyone.
[http://nxt.org/about/what-is-nxt/]
===
Nxt is an open source[5] cryptocurrency and payment network launched in November 2013 by anonymous software developer BCNext.[6] It uses proof-of-stake to reach consensus for transactions - as such there is a static money supply and no mining as with Bitcoin. Nxt is specifically conceived as flexible platform to build applications and financial services around.[7] It has an integrated asset-exchange[8] (comparable to shares), messaging system and marketplace. Users can also create new currencies within the system. The last major release enabled Multisignature capabilities and a plugin-system for the client.[9]
[https://en.wikipedia.org/wiki/Nxt]
name::
* McsEngl.nxtsvc.ASSET-EXCHANGE@cptIt,
_DESCRIPTION:
ASSET EXCHANGE
The Nxt Asset Exchange is a peer-to-peer exchange built directly into the Nxt software, allowing secure and fast decentralized trading in Nxt Assets. This eliminates the need to transfer assets or to put trust in an outside agency or business, and as Nxt Assets can be used to represent literally anything (from Bitcoin to coffee beans) there are a wide range of potential investments or trades to be made on the Asset Exchange.
[https://nxt.org/what-is-nxt/asset-exchange/]
name::
* McsEngl.nxtsvc.MARKETPLACE@cptIt,
_DESCRIPTION:
MARKETPLACE
The Nxt Marketplace feature allows you to list items for sale and make sales on the blockchain.
You do not need to rely on external market sites to conduct your business. Instead, transactions are done between seller and buyer directly.
[https://nxt.org/what-is-nxt/marketplace/]
name::
* McsEngl.nxtsvc.STORAGE@cptIt,
_DESCRIPTION:
DATA CLOUD
The Nxt Data Cloud is a decentralised data storage system.
In addition to keeping a record of Nxt transactions, the blockchain can also be used to store user-defined data. All forms of data can be uploaded to the Nxt blockchain, providing a secure (and, if desired, permanent) method of storing, retrieving and publishing information. Nxt Messaging makes use of this ability to embed data in the blockchain, and the Data Cloud can be seen as an extension of the Messaging system.
One of the most important features of data storage on the blockchain is that the Nxt blockchain is a permanent and immutable record that provides a tamper-proof time stamp. This allows for legal records (such as contracts) to be embedded in the blockchain, with absolute certainty about the time at which they were created.
[https://nxt.org/what-is-nxt/data-cloud/]
name::
* McsEngl.nxtsvc.ALIAS-SYSTEM@cptIt,
_Description
The Alias System feature of Nxt essentially allows one piece of text to be substituted for another, so that keywords or keyphrases can be used to represent other things – names, telephone numbers, physical addresses, web sites, account numbers, email addresses, product SKU codes... almost anything you can think of.
For example, you could ask Nxt to associate "search" with "www.google.com". Once this is done, all you have to do to get to Google is type "nxt:search" into a Nxt-capable browser, and it will translate your request in one for "www.google.com".
Immediate applications are simple: you can create an easy-to-remember alias for your Nxt account number, for example. But since the Alias System is open-ended, it can be used to implement a decentralized DNS system, shopping cart applications, and more.
Creating aliases is
A user sends a transaction that states "ThisText = ThatText"
If the alias is to be changed, just send another transaction with a new definition. Only the account that created an alias can change it.
[http://nxtwiki.org/wiki/Alias_System]
name::
* McsEngl.bcnnet.time.Peercoin (PPCnet {2012-08-19})@cptIt,
_DESCRIPTION:
Peercoin seeks to be the most secure cryptocoin at the lowest cost, rewarding all users for strengthening the network by giving them a 1% annual PPC return when minting.
?Built to Last
?The world's first Proof-of-Stake coin.
?Fair Distribution
?No insider pre-sale or instant mining.
?Energy Efficient
?Mint Peercoins on any device.
?Stable and Secure
?Protecting your investment since 2012.
[https://peercoin.net/]
name::
* McsEngl.ppcnet'Protocol@cptIt,
name::
* McsEngl.ppcprl'White-paper {2012}@cptIt,
_ADDRESS.WPG:
* https://peercoin.net/assets/paper/peercoin-paper.pdf,
PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake
Sunny King, Scott Nadal
(sunnyking9999@gmail.com, scott.nadal@gmail.com)
August 19th, 2012
A peer-to-peer crypto-currency design derived from Satoshi Nakamoto’s#ql:idBtchmnSnt# Bitcoin.
Proof-of-stake replaces proof-of-work to provide most of the network security.
Under this hybrid design proof-of-work mainly provides initial minting and is largely non-essential in the long run.
Security level of the network is not dependent on energy consumption in the long term thus providing an energy efficient and more cost-competitive peer-to-peer crypto-currency.
Proof-of-stake is based on coin age and generated by each node via a hashing scheme bearing similarity to Bitcoin’s but over limited search space.
Block chain history and transaction settlement are further protected by a centrally broadcasted checkpoint mechanism.
Since the creation of Bitcoin (Nakamoto 2008), proof-of-work has been the predominant design of peer-to-peer crypto currency.
The concept of proof-of-work has been the backbone of minting and security model of Nakamoto’s design.
In October 2011, we have realized that, the concept of coin age can facilitate an alternative design known as proof-of-stake, to Bitcoin’s proof-of-work system.
We have since formalized a design where proof-of-stake is used to build the security model of a peer-to-peer crypto currency and part of its minting process, whereas proof-of-work mainly facilitates the initial part of the minting process and gradually reduces its significance.
This design attempts to demonstrate the viability of future peer-to-peer crypto-currencies with no dependency on energy consumption.
We have named the project ppcoin.
The concept of coin age was known to Nakamoto at least as early as 2010 and used in Bitcoin to help prioritize transactions, for example, although it didn’t play much of an critical role in Bitcoin’s security model.
Coin age is simply defined as currency amount times holding period.
In a simple to understand example, if Bob received 10 coins from Alice and held it for 90 days, we say that Bob has accumulated 900 coin-days of coin age.
Additionally, when Bob spent the 10 coins he received from Alice, we say the coin age Bob accumulated with these 10 coins had been consumed (or destroyed).
In order to facilitate the computation of coin age, we introduced a timestamp field into each transaction.
Block timestamp and transaction timestamp related protocols are strengthened to secure the computation of coin age.
Proof-of-work helped to give birth to Nakamoto’s major breakthrough, however the nature of proof-of-work means that the crypto-currency is dependent on energy consumption, thus introducing significant cost overhead in the operation of such networks, which is borne by the users via a combination of inflation and transaction fees.
As the mint rate slows in Bitcoin network, eventually it could put pressure on raising transaction fees to sustain a preferred level of security.
One naturally asks whether we must maintain energy consumption in order to have a decentralized crypto-currency?
Thus it is an important milestone both theoretically and technologically, to demonstrate that the security of peer-to-peer crypto-currencies does not have to depend on energy consumption.
A concept termed proof-of-stake was discussed among Bitcoin circles as early as 2011.
Roughly speaking, proof-of-stake means a form of proof of ownership of the currency.
Coin age consumed by a transaction can be considered a form of proof-of-stake.
We independently discovered the concept of proof-of-stake and the concept of coin age in October 2011, whereby we realized that proof-of-stake can indeed replace most proof-ofwork’s functions with careful redesign of Bitcoin’s minting and security model.
This is mainly because, similar to proof-of-work, proof-of-stake cannot be easily forged.
Of course, this is one of the critical requirements of monetary systems - difficulty to counterfeit.
Philosophically speaking, money is a form of ‘proof-of-work’ in the past thus should be able to substitute proof-of-work all by itself.
In our hybrid design, blocks are separated into two different types, proof-of-work blocks and proof-of-stake blocks.
Kernel input
Stake input Stake output (pay to stake owner himself)
Stake input
Figure: Structure of Proof-of-Stake (Coinstake) Transaction
The proof-of-stake in the new type of blocks is a special transaction called coinstake (named after Bitcoin’s special transaction coinbase).
In the coinstake transaction block owner pays himself thereby consuming his coin age, while gaining the privilege of generating a block for the network and minting for proof-of-stake.
The first input of coinstake is called kernel and is required to meet certain hash target protocol, thus making the generation of proof-of-stake blocks a stochastic process similar to proof-ofwork blocks.
However an important difference is that the hashing operation is done over a limited search space (more specifically one hash per unspent wallet-output per second) instead of an unlimited search space as in proof-of-work, thus no significant consumption of energy is involved.
The hash target that stake kernel must meet is a target per unit coin age (coin-day) consumed in the kernel (in contrast to Bitcoin’s proof-of-work target which is a fixed target value applying to every node).
Thus the more coin age consumed in the kernel, the easier meeting the hash target protocol.
For example, if Bob has a wallet-output which accumulated 100 coin-years and expects it to generate a kernel in 2 days, then Alice can roughly expect her 200 coin-year wallet-output to generate a kernel in 1 day.
In our design both proof-of-work hash target and proof-of-stake hash target are adjusted continuously rather than Bitcoin’s two-week adjustment interval, to avoid sudden jump in network generation rate.
A new minting process is introduced for proof-of stake blocks in addition to Bitcoin’s proof-of-work minting.
Proof-of-stake block mints coins based on the consumed coin age in the coinstake transaction.
A mint rate of 1 cent per coin-year consumed is chosen to give rise to a low future inflation rate.
Even though we kept proof-of-work as part of the minting process to facilitate initial minting, it is conceivable that in a pure proof-of-stake system initial minting can be seeded completely in genesis block via a process similar to stock market initial public offer (IPO).
The protocol for determining which competing block chain wins as main chain has been switched over to use consumed coin age.
Here every transaction in a block contributes its consumed coin age to the score of the block.
The block chain with highest total consumed coin age is chosen as main chain.
This is in contrast to the use of proof-of-work in Bitcoin’s main chain protocol, whereas the total work of the block chain is used to determine main chain.
This design alleviates some of the concerns of Bitcoin’s 51% assumption, where the system is only considered secure when good nodes control at least 51% of network mining power.
First the cost of controlling significant stake might be higher than the cost of acquiring significant mining power, thus raising the cost of attack for such powerful entities.
Also attacker’s coin age is consumed during the attack, which may render it more difficult for the attacker to continue preventing transactions from entering main chain.
One of the disadvantages of using total consumed coin age to determine main chain is that it lowers the cost of attack on the entire block chain of history.
Even though Bitcoin has relatively strong protection over the history Nakamoto still introduced checkpoints in 2010 as a mechanism to solidify the block chain history, preventing any possible changes to the part of block chain earlier than the checkpoint.
Another concern is that the cost of double-spending attack may have been lowered as well, as attacker may just need to accumulate certain amount of coin age and force reorganization of the block chain.
To make commerce practical under such a system, we decided to introduce an additional form of checkpoints that are broadcasted centrally, at much shorter intervals such as a few times daily, to serve to freeze block chain and finalize transactions.
This new type of checkpoint is broadcasted similar to Bitcoin’s alert system.
Laurie (2011) has argued that Bitcoin has not completely solved the distributed concensus problem as the mechanism for checkpointing is not distributed.
We attempted to design a practical distributed checkpointing protocol but found it difficult to secure against network split attack.
Although the broadcasted checkpointing mechanism is a form of centralization, we consider it acceptable before a distributed solution is available.
Another technical reason entails the use of centrally broadcasted checkpointing.
In order to defend against a type of denial-of-service attack coinstake kernel must be verified before a proof-of-stake block can be accepted into the local database (block tree) of each node.
Due to Bitcoin node’s data model (transaction index specifically) a deadline of checkpointing is needed to ensure all nodes’ capability of verifying connection of each coinstake kernel before accepting a block into the block tree.
Because of the above practical considerations we decided not to modify node’s data model but use central checkpointing instead.
Our solution is to modify the coin age computation to require a minimum age, such as one month, below which the coin age is computed as zero.
Then the central checkpointing is used to ensure all nodes can agree upon past transactions older than one month thus allowing the verification of coinstake kernel connection as a kernel requires non-zero coin age thus must use an output from more than one month ago.
Each block must be signed by its owner to prevent the same proof-of-stake from being copied and used by attackers.
A duplicate-stake protocol is designed to defend against an attacker using a single proofof-stake to generate a multitude of blocks as a denial-of-service attack.
Each node collects the (kernel, timestamp) pair of all coinstake transactions it has seen.
If a received block contains a duplicate pair as another previously received block, we ignore such duplicate-stake block until a successor block is received as an orphan block.
When the proof-of-work mint rate approaches zero, there is less and less incentive to mint proof-of-work blocks. Under this long term scenario energy consumption in the network may drop to very low levels as disinterested miners stop mining proof-of-work blocks.
The Bitcoin network faces such risk unless transaction volume/fee rises to high enough levels to sustain the energy consumption.
Under our design even if energy consumption approaches zero the network is still protected by proof-of-stake.
We call a crypto-currency long-term energy-efficient if energy consumption on proof-of-work is allowed to approach zero.
We modified the proof-of-work mint rate to be not determined by block height (time) but instead determined by difficulty.
When mining difficulty goes up, proof-of-work mint rate is lowered.
A relatively smooth curve is chosen as opposed to Bitcoin’s step functions, to avoid artificially shocking the market.
More specifically, a continuous curve is chosen such that each 16x raise of mining difficulty halves the block mint amount.
Over longer term the proof-of-work mint curve would not be too dissimilar to that of Bitcoin in terms of the inflationary behavior, given the continuation of Moore’s Law.
We consider it wise to follow the traditional observation that the Market favors a low inflation currency over a high-inflation one, despite of significant criticism of Bitcoin from some mainstream economists due to ideological reasons in our opinion.
Babaioff et al. (2011) studied the effect of transaction fee and argued that transaction fee is an incentive to not cooperate between miners.
Under our system this attack is exacerbated so we no longer give transaction fees to block owner.
We decided to destroy transaction fees instead.
This removes the incentive to not acknowledge other minter’s blocks.
It also serves as a deflationary force to counter the inflationary force from the proof-of-stake minting.
We also choose to enforce transaction fees at protocol level to defend against block bloating attack.
During our research we have also discovered a third possibility besides proof-of-work and proof-of-stake, which we termed proof-of-excellence.
Under this system typically a tournament is held periodically to mint coins based on the performance of the tournament participants, mimicking the prizes of real-life tournaments.
Although this system tends to consume energy as well when artificial intelligence excels at the game involved, we still found the concept interesting even under such situation as it provides a somewhat intelligent form of energy consumption.
Upon validation of our design in the Market, we expect proof-of-stake designs to become a potentially more competitive form of peer-to-peer crypto-currency to proof-of-work designs due to the elimination of dependency on energy consumption, thereby achieving lower inflation/lower transaction fees at comparable network security levels.
Many thanks to Richard Smith for helping out with testing and various network/fork
related work.
We would like to thank Satoshi Nakamoto#ql:idBtchmnSnt# and Bitcoin developers whose brilliant
pioneering work opened our minds and made a project like this possible.
Babaioff M. et al. (2011): On Bitcoin and red balloons.
Laurie B. (2011): Decentralised currencies are probably impossible (but let’s at least make them efficient). (http://www.links.org/files/decentralised-currencies.pdf)
Nakamoto S. (2008): Bitcoin: A peer-to-peer electronic cash system. (http://www.bitcoin.org/bitcoin.pdf)
name::
* McsEngl.ppcnet'Concensous-exval-tokent (PPCcevt)@cptIt,
* McsEngl.mny.Peercoin@cptIt,
* McsEngl.mny.PPCoin@cptIt,
* McsEngl.mny.PPC@cptIt,
* McsEngl.peercoin@cptIt,
* McsEngl.PPCoin@cptIt,
_DESCRIPTION:
PPCoin (code: PPC), also known as Peercoin and Peer-to-Peer Coin is the first known cryptocurrency based on an implementation of a combined proof-of-stake/proof-of-work system.[1]
As of 2 July 2013, one PPCoin had a value of approximately 0.14 USD, giving PPCoin a money supply with a value of $2.9 million USD, making it roughly level with Namecoin as the third largest cryptocurrency.[3][4][5]
Central bank None. The PPCoin peer-to-peer network regulates and distributes through consensus in protocol.[1]
Date of introduction 12 August 2012, 17:57:38 UTC
User(s) International
Inflation Limited release (Geometric series, rate halves every 4 years), there is also 1% inflation due to the proof-of-stake system.[1][2]
Subunit
0.001 mPPC (millicoin)
0.000001 µPPC (microcoin)
0.00000001 Smallest unit
Symbol ?, PPC
Nickname Peercoin, P2PCoin
Plural PPCoin, PPCoins
[http://en.wikipedia.org/wiki/PPCoin]
===
PPCoin:
AKA Peercoin or P2P coin.
An altcoin using the proof of stake mechanism in conjunction with proof of work.
Based on a paper produced by Sunny King and Scott Nadal.
[http://www.coindesk.com/information/bitcoin-glossary//]
===
Peercoin (PPC)
$0.836138 (-0.66%)
0.00070832 BTC (-1.28%)
Rank 35
Mineable Currency
Market Cap
$20,078,420
17,009 BTC
Volume (24h)
$257,009
217.72 BTC
Circulating Supply
24,013,285 PPC
[https://coinmarketcap.com/currencies/peercoin/] {2017-04-16}
name::
* McsEngl.ppcnet'Resource@cptIt,
_ADDRESS.WPG:
* https://chainz.cryptoid.info/ppc//
* Block#1: https://chainz.cryptoid.info/ppc/block.dws?1.htm,
* http://peercoin.net/assets/paper/peercoin-paper.pdf,
name::
* McsEngl.bcnnet.time.Ripple (XRPnet {2012})@cptIt,
* McsEngl.conceptIt51.11,
* McsEngl.netXrp@cptIt,
* McsEngl.digital-currency-system.ripple@cptIt51.11,
* McsEngl.ripple-distributed-network@cptIt51.11,
* McsEngl.ripple-network@cptIt51.11,
* McsEngl.ripple-system@cptIt,
* McsEngl.stmRpl@cptIt,
* McsEngl.xrpnet@cptIt,
_GENERIC:
* stmIthCrypto#cptItsoft51.12#
_DESCRIPTION:
Ripple is a real-time gross settlement system (RTGS), currency exchange and remittance network by Ripple Labs. Also called the Ripple Transaction Protocol (RTXP) or Ripple protocol,[3] it is built upon a distributed open source Internet protocol, consensus ledger and native currency called XRP (ripples). Released in 2012, Ripple purports to enable "secure, instant and nearly free global financial transactions of any size with no chargebacks." It supports tokens representing fiat currency, cryptocurrency, commodity or any other unit of value such as frequent flier miles or mobile minutes.[4][5] At its core, Ripple is based around a shared, public database or ledger,[6] which uses a consensus process that allows for payments, exchanges and remittance in a distributed process.[7] The security of the Ripple consensus algorithm was challenged by rivals in 2014,[8] with Ripple Labs defending the safety of the system.[9] As of 2014, Ripple is the second-largest cryptocurrency by market capitalization,[10][11] after Bitcoin.[12][13][14][15] Currently implemented by companies such as Fidor Bank, the Ripple protocol has been increasingly adopted by banks and payment networks as settlement infrastructure technology,[16] with American Banker explaining that "from banks' perspective, distributed ledgers like the Ripple system have a number of advantages over cryptocurrencies like Bitcoin," including price and security.[17]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
===
Ripple:
A payment network that can be used to transfer any currency (including ad hoc currencies that have been created by users).
The network consists of payment nodes and gateways operated by authorities.
Payments are made using a series of IOUs, and the network is based on trust relationships.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.xrpnet'Protocol (rtxp)@cptIt,
* McsEngl.Ripple-Transaction-Protocol@cptIt,
* McsEngl.RTXP@cptIt,
name::
* McsEngl.xrpnet'Node (xrpnod)@cptIt,
name::
* McsEngl.xrpnod'UNL@cptIt,
* McsEngl.Ripple-UNL@cptIt,
_DESCRIPTION:
Unique Node List (UNL): Each server, s, maintains a unique node list, which is a set of other servers that s queries when determining consensus.
Only the votes of the other members of the UNL of s are considered when determining consensus (as opposed to every node on the network).
Thus the UNL represents a subset of the network which when taken collectively, is “trusted” by s to not collude in an attempt to defraud the network.
Note that this definition of “trust” does not require that each individual member of the UNL be trusted (see section 3.2).
[https://ripple.com/files/ripple_consensus_whitepaper.pdf]
name::
* McsEngl.xrpnod.FAULTY@cptIt,
* McsEngl.xrpnet'malicious-node@cptIt,
_DESCRIPTION:
We use the term nonfaulty to refer to nodes in the network that behave honestly and without error.
Conversely, a faulty node is one which experiences errors which may be honest (due to data corruption, implementation errors, etc.), or malicious (Byzantine errors).
[https://ripple.com/files/ripple_consensus_whitepaper.pdf]
name::
* McsEngl.xrpnod.FAULTY.NO@cptIt,
_DESCRIPTION:
We use the term nonfaulty to refer to nodes in the network that behave honestly and without error.
Conversely, a faulty node is one which experiences errors which may be honest (due to data corruption, implementation errors, etc.), or malicious (Byzantine errors).
[https://ripple.com/files/ripple_consensus_whitepaper.pdf]
name::
* McsEngl.xrpnod.SERVER@cptIt,
_DESCRIPTION:
Server: A server is any entity running the Ripple Server software (as opposed to the Ripple Client software which only lets a user send and receive funds), which participates in the consensus process.
[https://ripple.com/files/ripple_consensus_whitepaper.pdf]
name::
* McsEngl.xrpnod.server.PROPOSER@cptIt,
_DESCRIPTION:
Proposer: Any server can broadcast transactions to be included in the consensus process, and every server attempts to include every valid transaction when a new consensus round starts.
During the consensus process, however, only proposals from servers on the UNL of a server s are considered by s.
[https://ripple.com/files/ripple_consensus_whitepaper.pdf]
name::
* McsEngl.xrpnet'Blockchain (xrpbcn)@cptIt,
* McsEngl.xrpnet'database@cptIt,
* McsEngl.xrpnet'distributed-ledger@cptIt,
* McsEngl.xrpnet'public-database@cptIt,
* McsEngl.xrpnet'shared-database@cptIt,
_DESCRIPTION:
The ledger is a record of the amount of currency in each user’s account and represents the “ground truth” of the network.
The ledger is repeatedly updated with transactions that successfully pass through the consensus process.
[https://ripple.com/files/ripple_consensus_whitepaper.pdf]
===
At its core, Ripple is based around a shared, public database or ledger that has its contents decided on by consensus.[6] In addition to balances, the ledger holds information about offers to buy or sell currencies and assets, creating the first distributed exchange.[53]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
name::
* McsEngl.xrpbcn'Consensus-algorithm@cptIt,
_DESCRIPTION:
The Ripple Protocol consensus algorithm (RPCA), is applied every few seconds by all nodes, in order to maintain the correctness and agreement of the network.
Once consensus is reached, the current ledger is considered “closed” and becomes the last-closed ledger.
Assuming that the consensus algorithm is successful, and that there is no fork in the network, the last-closed ledger maintained by all nodes in the network will be identical.
[https://ripple.com/files/ripple_consensus_whitepaper.pdf]
_DESCRIPTION:
We begin by defining the components of the Ripple Protocol.
In order to prove correctness, agreement, and utility properties, we first formalize those properties into axioms.
These properties, when grouped together, form the notion of consensus: the state in which nodes in the network reach correct agreement.
[https://ripple.com/files/ripple_consensus_whitepaper.pdf]
_DESCRIPTION:
The strength of a consensus algorithm is usually measured in terms of the fraction of faulty processes it can tolerate.
[https://ripple.com/files/ripple_consensus_whitepaper.pdf]
name::
* McsEngl.xrpbcn'Transaction@cptIt,
name::
* McsEngl.xrpbcn.LAST-CLOSED@cptIt,
_DESCRIPTION:
The last-closed ledger is the most recent ledger that has been ratified by the-consensus-process#ql:stmrpl'consensus# and thus represents the current state of the network.
[https://ripple.com/files/ripple_consensus_whitepaper.pdf]
name::
* McsEngl.xrpbcn.OPEN@cptIt,
_DESCRIPTION:
The open ledger is the current operating status of a node (each node maintains its own open ledger).
Transactions initiated by end users of a given server are applied to the open ledger of that server, but transactions are not considered final until they have passed through the consensus process, at which point the open ledger becomes the last-closed ledger.
[https://ripple.com/files/ripple_consensus_whitepaper.pdf]
name::
* McsEngl.xrpnet'Consensus-evt (XRPcevt)@cptIt,
* McsEngl.mnyRipple@cptIt,
* McsEngl.mnyXrp@cptIt,
* McsEngl.mnyRipple@cptIt,
* McsEngl.mnyXrp@cptIt,
_DESCRIPTION:
Ripple XRP
Ripple is a digital currency of Ripple payment network created to support fast and secure financial transactions worldwide. This currency is present uniquely within the system and cannot be mined. It helps avoid counterparty risk and serves as the network’s native asset.
[https://changelly.com/supported-currencies]
===
XRP is the native currency of the Ripple network that only exists within the Ripple system.[82] XRP are currently divisible to 6 decimal places, and the smallest unit is called a drop with 1 million drops equaling 1 XRP.[82] There were 100 billion XRP created at Ripple's inception, with no more allowed to be created according to the protocol's rules.[83] As such, the system was designed so XRP is a scarce asset with decreasing available supply.[83] Not dependent on any third party for redemption, XRP is the only currency in the Ripple network that does not entail counterparty risk, and it is the only native digital asset. The other currencies in the Ripple network are debt instruments (i.e. liabilities), and exist in the form of balances.[2] Users of the Ripple network are not required to use XRP as a store of value or a medium of exchange. Each Ripple account is required, however, to have a small reserve of 20 XRP[84] (US$0.38 as of January 28, 2014[85]). The purpose for this requirement is discussed in the anti-spam section.
XRP distribution
Of the 100 billion created, 20 billion XRP were retained by the creators, who were also the founders of Ripple Labs. The creators gave the remaining 80% of the total to Ripple Labs, with the XRP intended to fund operations.[83] Ripple Labs also had a short-lived 2013 giveaway of under 200 million XRP (0.002% of all XRP) via World Community Grid.[86] As of November 30, 2012, 7.2 billion XRP of Ripple Lab's amounts had been distributed,[87] with some of the amount given to charities such as the Computing for Good initiative, which began offering XRP in exchange for time volunteered on research projects.[88] As of March 2015, 67% of Ripple Labs's original 80% was still retained by the company,[83] with Ripple Labs stating that "we will engage in distribution strategies that we expect will result in a stable or strengthening XRP exchange rate against other currencies."[89] The amount of XRP distributed and their movement can be tracked through the Ripple Charts website.[90]
XRP as a bridge currency
One of the specific functions of XRP is as a bridge currency,[73] which can be necessary if no direct exchange is available between two currencies at a specific time,[91] for example when transacting between two rarely traded currency pairs.[81] Within the network’s currency exchange, XRP are traded freely against other currencies, and its market price fluctuates against dollars, euros, yen, bitcoin, etc. Ripple's design focus is as a currency exchange and a distributed-RTGS, as opposed to emphasizing XRP as an alternative currency.[81] In April 2015, Ripple Labs announced that a new feature called autobridging had been added to Ripple, with the intent of making it easier for market makers to transact between rarely traded currency pairs. The feature is also intended to expose more of the network to liquidity and better FX rates.[92]
XRP as an anti-spam measure
When a user conducts a financial transaction in a non-native currency, Ripple charges a transaction fee. The purpose of the fees is to protect against network flooding by making the attacks too expensive for hackers. If Ripple were completely free to access, adversaries could broadcast large amounts of "ledger spam" (i.e. fake accounts) and "transaction spam" (i.e. fake transactions) in an attempt to overload the network. This could cause the size of the ledger to become unmanageable and interfere with the network’s ability to quickly settle legitimate transactions. Thus, to engage in trade, each Ripple account is required to have a small reserve of 20 XRP,[84] (US$0.38 as of January 28, 2014[85]), and a transaction fee starting at .00001 XRP (US$.0000002 as of January 28, 2014[85]) must be spent for each trade. This transaction fee is not collected by anyone; the XRP is destroyed and ceases to exist.[93] The transaction fee rises if the user posts trades at an enormous rate (many thousands per minute), and resettles after a period of inactivity.[58]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
name::
* McsEngl.xrpcevt'Exchange-rate@cptIt,
{2017-04-22}
Ripple (XRP)
$0.032565 (7.90%)
0.00002665 BTC (8.45%)
[https://coinmarketcap.com/currencies/ripple/]
name::
* McsEngl.xrpcevt'OgnEXCANGE@cptIt,
_SPECIFIC:
XRP is listed on Bitstamp, GateHub and Kraken.
[https://ripple.com/xrp-portal/how-to-buy-xrp/]
name::
* McsEngl.xrpcevt.AGGREGATE@cptIt,
{time.2021forcast}:
If market conditions permit, we expect our company to hold approximately 50 billion XRP by the end of 2021. This schedule is indicative and discretionary.
[https://ripple.com/xrp-portal/ {2017-01-28}]
{time.2017-01-22}:
TOTAL XRP HELD BY RIPPLE 63,139,536,437
TOTAL XRP HELD BY OTHERS 36,856,524,148*
As of January 22nd, 2017
*Total includes business development agreements that are still pending.
name::
* McsEngl.xrpnet'Statistics@cptIt,
_DESCRIPTION:
Ripple Charts provides visualizations of the information on the Ripple Network, including a live trade feed, trends, and historical metrics. Ripple Charts is available for anyone to use, alter, or embed.
[https://ripple.com/knowledge_center/about-ripple-os-products/]
name::
* McsEngl.xrpnet'Program@cptIt,
_DESCRIPTION:
As of 2015, the current release of Ripple Trade is version 0.2.48-3 and the server (known as rippled) is version 0.24.0.[1]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
name::
* McsEngl.xrppgm.Riple-Trade@cptIt,
_DESCRIPTION:
With Ripple Trade, users can trade currency with minimal configuration.
Ripple Trade is available for anyone to use, alter, or embed.
[https://ripple.com/knowledge_center/about-ripple-os-products/]
name::
* McsEngl.xrpnet'Security@cptIt,
_DESCRIPTION:
In May 2011 they began developing a digital currency system in which transactions were verified by consensus among members of the network, rather than by the mining process used by Bitcoin, which relies on blockchain ledgers.[21] This new version of the Ripple system[20] was therefore designed to eliminate Bitcoin's reliance on centralized exchanges, use less electricity than Bitcoin, and perform transactions much more quickly than Bitcoin.
...
To maintain security OpenCoin programmed Ripple to rely on a common ledger that is "managed by a network of independent validating servers that constantly compare their transaction records." Servers could belong to anyone, including banks or market makers.[26]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
name::
* McsEngl.xrpnet'Human@cptIt,
Original author(s) Arthur Britto, David Schwartz, Ryan Fugger
Britto.Arthur:
Arthur Britto, for his work on transaction sets,
McCaleb.Jed:
Jed McCaleb, for the original Ripple Protocol consensus concept,
Schwartz.David:
David Schwartz, for his work on the “failure to agree is agreement to defer” aspect of consensus.
name::
* McsEngl.xrpnet'Organization@cptIt,
name::
* McsEngl.xrpogn.Ripple-Labs@cptIt,
* McsEngl.Ripple-Labs@cptIt,
_DESCRIPTION:
For its creation and development of the Ripple protocol (RTXP) and the Ripple payment/exchange network, the Massachusetts Institute of Technology (MIT) recognized Ripple Labs as one of 2014's 50 Smartest Companies in the February 2014 edition of MIT Technology Review.[99]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
name::
* McsEngl.xrpogn'Gateway@cptIt,
* McsEngl.Ripple-gateway@cptIt,
_DESCRIPTION:
Gateways are the businesses that link the Ripple network to the rest of the world.
By becoming a Ripple gateway, existing online financial services, such as payment systems and digital currency exchange, can gain several advantages:
By enabling its users to send and receive value in Ripple, the business increases its value proposition to users.
By accepting payments from the Ripple network, the business increases the number of ways that users can fund accounts at its business, even internationally.
The business can use Ripple-related services as a new source of revenue.
[https://ripple.com/build/gateway-guide/]
name::
* McsEngl.xrpnet'Resource@cptIt,
_ADDRESS.WPG:
* https://ripple.com// Join the Global Settlement Network
Instant, certain, low-cost international payments
* https://ripple.com/files/ripple_consensus_whitepaper.pdf,
name::
* McsEngl.xrpnet.EVOLUTING@cptIt,
{time.2014.12}:
=== Earthport:
By December Ripple Labs began working with global payments service Earthport, combining Ripple's software with Earthport's payment services system. Earthport's clients include banks such as Bank of America and HSBC, and it operates in 65 countries. The partnership marked the first network usage of the Ripple protocol.[45] In December 2014 alone, the XRP price value rose over 200%, helping Ripple surpass litecoin to become the second biggest crypto-currency, and setting Ripple's market cap at close to half a billion.[46]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
{time.2014.07}:
=== CODIUS:
In July 2014, Ripple Labs proposed Codius, a project to develop a new smart contract system that is "programming language agnostic."[42]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
{time.2014.early}:
=== Fidor-Bank:
The first bank to use Ripple was Fidor Bank in Munich, which announced the partnership in early 2014. Fidor is an online-only bank based in Germany.[44]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
{time.2013.10}:
=== ZipZap partnership:
In October 2013, Ripple partnered further with ZipZap, with the relationship called a threat to Western Union in the press.[37]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
{time.2013-09-26}:
=== Ripple Labs Inc:
On September 26, 2013, OpenCoin Inc. changed its name to Ripple Labs Inc.,[25] with Chris Larsen remaining CEO.[35] On the same day the Ripple reference server and client became free software, released as open source under the terms of the ISC License.[2] Ripple Labs continued as the primary contributors of code to the consensus verification system behind Ripple, which can "integrate with banks’ existing networks."[36]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
{time.2013-07-01}:
=== XRP-II:
On July 1, 2013, XRP Fund II, LLC (now called simply XRP II)[31] was incorporated as a wholly owned subsidiary of OpenCoin, and headquartered in South Carolina.[31]
The following day, Ripple Labs announced its linking of the Bitcoin and Ripple protocols via the Bitcoin Bridge. The Bitcoin Bridge allows Ripple users to send a payment in any currency to a Bitcoin address
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
{time.2012.09}:
=== OpenCoin:
This led to the conception of a new system by Jed McCaleb of eDonkey network,[23] which was designed and built by Arthur Britto and David Schwartz.[24] In May 2011 they began developing a digital currency system in which transactions were verified by consensus among members of the network, rather than by the mining process used by Bitcoin, which relies on blockchain ledgers.[21] This new version of the Ripple system[20] was therefore designed to eliminate Bitcoin's reliance on centralized exchanges, use less electricity than Bitcoin, and perform transactions much more quickly than Bitcoin.[20] Chris Larsen,[21] who had previously founded the lending services companies E-Loan and Prosper, joined the team in August 2012,[23] and together McCaleb and Larsen approached Ryan Fugger with their digital currency idea. After discussions with long-standing members of the Ripple community, Fugger handed over the reins.[21] In September 2012 the team co-founded the corporation OpenCoin,[21] or OpenCoin Inc.[23][25]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
{time.2004}:
=== RipplePay:
The predecessor to the Ripple payment protocol, Ripplepay, was first developed in 2004 by Ryan Fugger,[18][19] a web developer in Vancouver, British Columbia.[20] Fugger conceived of the idea after working on a local exchange trading system in Vancouver, and his intent was to create a monetary system that was decentralized and could effectively allow individuals and communities to create their own money. Fugger's first iteration of this system, RipplePay.com,[21] debuted in 2005 as a financial service to provide secure payment options to members of an online community via a global network.[20][22]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
name::
* McsEngl.bcnnet.time.Litecoin (LTCnet {2011-10-07})@cptIt,
name::
* McsEngl.ltcnet'Consensus-evt (LTCcevt)@cptIt,
* McsEngl.litecoin-consensus-exval-token@cptIt, {2017-03-31}
* McsEngl.ltccevt@cptIt, {2017-03-31}
* McsEngl.Litecoin@cptIt,
* McsEngl.bcnevt.litecoin@cptIt,
* McsEngl.mnyLitecoin@cptIt,
* McsEngl.mnyLtc@cptIt,
* McsEngl.mnyLitecoin@cptIt,
* McsEngl.mnyLTC@cptIt,
_DESCRIPTION:
Litecoin is a peer-to-peer Internet currency that enables instant payments to anyone in the world. It is based on the Bitcoin protocol but differs from Bitcoin in that it can be efficiently mined with consumer-grade hardware. Litecoin provides faster transaction confirmations (2.5 minutes on average) and uses a memory-hard, scrypt-based mining proof-of-work algorithm to target the regular computers with GPUs most people already have. The Litecoin network is scheduled to produce 84 million currency units. One of the aims of Litecoin was to provide a mining algorithm that could run at the same time, on the same hardware used to mine Bitcoins. With the rise of specialized ASICs for Bitcoin, Litecoin continues to satisfy these goals. It is unlikely for ASIC mining to be developed for Litecoin until the currency becomes more widely used.
[https://changelly.com/supported-currencies]
===
Litecoin (sign: L; code: LTC) is a peer-to-peer cryptocurrency and open source software project released under the MIT/X11 license.[1] Inspired by and technically nearly identical to Bitcoin (BTC),[2] Litecoin creation and transfer is based on an open source encryption protocol and is not managed by any central authority.[1][3] Litecoin is intended by its developers to improve upon Bitcoin[4] and offers three key differences.[5][6]
Each Litecoin is subdivided into 100,000,000 smaller units, defined by eight decimal places.
Central bank None. The Litecoin peer-to-peer network regulates and distributes through consensus in protocol.
Date of introduction 7 October 2011
User(s) International
Inflation Limited release (geometric series, rate halves every 4 years reaching a final total of 84 million LTC)
Subunit
0.001 mLTC (millicoin)
0.000001 µLTC (microcoin)
0.00000001 Smallest unit
Symbol L
Nickname LTC
Plural Litecoin, litecoins
[http://en.wikipedia.org/wiki/Litecoin]
===
Το Litecoin γεννήθηκε το 2011 (2009 το Bitcoin), από έναν απόφοιτο του ΜΙΤ και πρώην εργαζόμενο της Google – θεωρείται δε ως το «ασήμι» της αγοράς, εάν θεωρηθεί ως ο «χρυσός» το Bitcoin. Συνολικά υπολογίζεται να τοποθετηθούν στην αγορά 21 εκ. Bitcoins έως το 2040, καθώς επίσης 84 εκ. Litecoins – ενώ οι συναλλαγές με το δεύτερο είναι κατά πολύ γρηγορότερες (2,5 λεπτά της ώρας), από ότι με το πρώτο (10 λεπτά).
[http://www.analyst.gr/2013/12/02/4959/]
name::
* McsEngl.ltcnet'Resource@cptIt,
_ADDRESS.WPG:
* https://litecoin.com//
* mining: https://bitcointalk.org/index.php?topic=2125643.msg21230912#msg21230912,
name::
* McsEngl.bcnnet.time.Namecoin (NMCnet {2011-04-17})@cptIt,
name::
* McsEngl.nmcnet'Blockchain (nmcbcn)@cptIt,
name::
* McsEngl.nmcnet'Block-explorer@cptIt,
_ADDRESS.WPG:
* http://explorer.namecoin.info//
* BlockH0: http://explorer.namecoin.info/b/0,
name::
* McsEngl.nmcnet'Concensus-evt (NMCcevt)@cptIt,
* McsEngl.namecoin@cptIt,
* McsEngl.nmccevt@cptIt,
_DESCRIPTION:
Namecoin (NMC)
$0.827300 (-0.32%)
0.00069793 BTC (-1.30%)
Rank 48
Mineable Currency
Market Cap
$12,191,424
10,285 BTC
Volume (24h)
$124,627
105.14 BTC
Circulating Supply
14,736,400 NMC
[https://coinmarketcap.com/currencies/namecoin/ {2017-04-15}]
===
Namecoin (sign: N; code: NMC) is a cryptocurrency which also acts as an alternative, decentralized DNS, which would avoid domain name censorship by making a new top level domain outside of ICANN control, and in turn, make internet censorship much more difficult, as well as reduce downages.[3][4][5][1][2][6][7][8][9]
Namecoin currently uses the .bit domain, and as of July 2013, 78549 .bit domains have been registered.[1][2][7][10][11] bit domains are not currently awarded, hence to resolve domain names, one must have either a copy of the Namecoin "blockchain" (a decentralized ledger storing all transactions and domains), or access to a public DNS server that participates in the Namecoin system.[1][12]
There is a limit of 21 million Namecoins, and each Namecoin is divisible down to 8 decimal places.[1] As of July 2013, one Namecoin costs around 0.45 USD, making Namecoin roughly level with PPCoin as the third largest cryptocurrency, with a money supply valued at around 2.9 million USD.[13][14][15]
[http://en.wikipedia.org/wiki/Namecoin]
===
Namecoin - created in 2010, Namecoin is best described as a decentralized name registration database. In decentralized protocols like Tor, Bitcoin and BitMessage, there needs to be some way of identifying accounts so that other people can interact with them, but in all existing solutions the only kind of identifier available is a pseudorandom hash like 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. Ideally, one would like to be able to have an account with a name like "george". However, the problem is that if one person can create an account named "george" then someone else can use the same process to register "george" for themselves as well and impersonate them. The only solution is a first-to-file paradigm, where the first registerer succeeds and the second fails - a problem perfectly suited for the Bitcoin consensus protocol. Namecoin is the oldest, and most successful, implementation of a name registration system using such an idea.
[https://github.com/ethereum/wiki/wiki/White-Paper]
===
Namecoin:
An altcoin designed to provide an alternative to the traditional domain name system (DNS).
Users can register .bit domains, accessible via proxy servers, by paying with namecoins.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.bcnnet.time.Bitcoin (BTCnet {2009-01-03})@cptIt,
_GENERIC:
* money-transacting-system#cptItsoft98#
* distributed-sihMny#cptItsoft98.13#
name::
* McsEngl.btcnet'NAME@cptIt,
* McsEngl.conceptIt1010,
* McsEngl.bitcoin-ecosystem@cptIt,
* McsEngl.bitcoin-Electronic-Cash-System@cptIt, [Nakamoto 2008]
* McsEngl.bitcoin-financial-network@cptIt,
* McsEngl.bitcoin-network@cptIt,
* McsEngl.bitcoin-payment-system@cptIt,
* McsEngl.Bitcoin-Peer-to-Peer-Electronic-Cash-System@cptIt, [Nakamoto]
* McsEngl.bitcoin-peer-to-peer-network@cptIt,
* McsEngl.bitcoin-system@cptIt,
* McsEngl.bitcoinland@cptIt,
* McsEngl.btcn@cptIt,
* McsEngl.btcnet@cptIt,
* McsEngl.btcnetwork@cptIt,
* McsEngl.btcStm@cptIt, {2015-08-10}
* McsEngl.netBtc@cptIt, {2016-03-25}
* McsEngl.stmBtc@cptIt, {2015-08-10}
_DESCRIPTION:
* Bitcoin is the first financial network that exhibits the characteristics of neutrality.
[https://www.cryptocoinsnews.com/bitcoin-evangelist-antonopoulos-in-barcelona-thoughts-on-the-future-of-money/]
name::
* McsEngl.btcnet'DESCRIPTON@cptIt,
_DESCRIPTION:
Bitcoin
Refers to a protocol, network or a unit of currency.
As a protocol, Bitcoin is a set of rules that every client must follow to accept transactions and have its own transactions accepted by other clients. Also includes a message protocol that allows nodes to connect to each other and exchange transactions and blocks.
As a network, Bitcoin is all the computers that follow the same rules and exchange transactions and blocks between each other.
As a unit, one Bitcoin (BTC, XBT) is defined as 100 million satoshis, the smallest units available in the current transaction format. Bitcoin is not capitalized when speaking about the amount: "I received 0.4 bitcoins."
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md#bitcoin]
_DESCRIPTION:
Bitcoin represents the culmination of decades of research in cryptography and distributed systems and includes four key innovations brought together in a unique and powerful combination.
Bitcoin consists of:
A decentralized peer-to-peer network (the bitcoin protocol)
A public transaction ledger (the-blockchain#ql:bitcoin'blockchain#)
A decentralized mathematical and deterministic currency issuance (distributed mining)
A decentralized transaction verification system (transaction script)
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
_DESCRIPTION:
Bitcoin is two things which share a name: 1) a payment system and 2) a currency. You use the Bitcoin payment system to send bitcoins as currency from one account holder to another. The transfer is instantaneous, carries no necessary fee, works anywhere in the world, and is private.
[http://keepyourassets.net/2012/09/27/bitcoin-the-first-five-questions/]
Bitcoin is also the name of the open source software which enables the use of this currency.
[http://bitcoin.org/] {2012-05-27}
_DESCRIPTION:
Connect to the world’s first borderless payment network - Bitcoin.
[https://bitpay.com/tour]
_DESCRIPTION:
Bitcoin is a decentralized P2P electronic cash system without a central server or trusted parties. Users hold the crypto keys to their own money and transact directly with each other, with the help of the network to check for double-spending.
[http://sourceforge.net/projects/bitcoin/] 2013-03-18
_DESCRIPTION:
Just like the Internet, Bitcoin is not a corporation and does not have a CEO.
[http://www.givebtc.org/GiveBTC_-_Handbook_for_Non_Profits.pdf]
_DESCRIPTION:
Bitcoin uses a simple broadcast network to propagate transactions and blocks. All communications are done over TCP. Bitcoin is fully able to use ports other than 8333 via the -port parameter. IPv6 is suported with Bitcoind/Bitcoin-Qt v0.7.
[https://en.bitcoin.it/wiki/Network]
_DESCRIPTION:
A decentralized peer-to-peer network (the bitcoin protocol)
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
_DESCRIPTION:
Behind the scenes, bitcoin is also the name of the protocol, a network, and a distributed computing innovation.
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
name::
* McsEngl.btcnet'Attribute.INDEXED (btcatt)@cptIt,
* McsEngl.btcattribute.indexed@cptIt,
* McsEngl.btcglossary@cptIt,
* McsEngl.btcvocabulary@cptIt,
_SPECIFIC:
* https://en.bitcoin.it/wiki/Vocabulary,
* Oleg Andreev: https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md,
===
* btcBare_multisig
* btcChild_private_key
* btcChild_public_key
* btcCompressed_public_key
* btcConfirmation_score
* btcData_carrier_transaction
* btcData_pushing_op_code
* btcDNS_seed
* btcEscrow_contract
* btcExtended_key
* btcFree_transaction
* btcHardened_extended_key
* btcHeader
* btcHeader_chain
* btcHeaders_first_sync
* btcHigh_priority_transaction
* btcIBD
* btcInitial_block_download
* btcInternal_byte_order
* btcInventory
* btcMajority_attack
* btcMaster_chain_code
* btcMaster_private_key
* btcMerkle_block
* btcMerkle_root
* btcMessage_header
* btcMiners_fee
* btcMinimum_relay_fee
* btcMultisig
* btcNetwork_magic
* btcnLockTime
* btcNon_data_pushing_op_code
* btcNull_data_transaction
* btcOP_RETURN_transaction
* btcOrphan_block
* btcOutpoint
* btcP2P_protocol_messages
* btcP2PKH_address
* btcP2PKH_output
* btcP2SH_address
* btcP2SH_multisig
* btcP2SH_output
* btcParent_key
* btcParent_private_key
* btcParent_public_key
* btcPayment_protocol
* btcPayment_request
* btcPOWPrivate_extended_keyPrivate_key
* btcPublic_extended_key
* btcBitcoin_Core_RPCs
* btcRaw_transaction
* btcRedeem_script
* btcRedeemScript
* btcRegression_test_mode
* btcRegtest
* btcRelay_fee
* btcRPC_byte_order
* btcSatoshis
* btcScriptPubKey
* btcSig
* btcSequence_number
* btcSerialized_block
* btcSerialized_transaction
* btcSighash
* btcSIGHASH_ALL
* btcSIGHASH_ANYONECANPAY
* btcSIGHASH_NONE
* btcSIGHASH_SINGLE
* btcSignature
* btcSignature_hash
* btcStale_block
* btcStart_string
* btcTransaction_malleability
* btcTransaction_mutability
* btcTxid
* btcWallet_Import_Format
* btcWatch_only_address
* btcWIF
name::
* McsEngl.btcatt.Oleg-Adreev@cptIt,
* McsEngl.btcglossary.Oleg-Adreev@cptIt,
* McsEngl.btcOleg-Adreev-glossary@cptIt,
_DESCRIPTION:
Glossary is made by Oleg Andreev (oleganza@gmail.com).
Twitter: @oleganza#ql:http://twitter.com/oleganza#.
Send your thanks here: 1CBtcGivXmHQ8ZqdPgeMfcpQNJrqTrSAcG.
This glossary is released under WTFPL#ql:http://www.wtfpl.net#.
Do what you want with it, but I would appreciate if you give full credit in case you republish it.
Please report any mistakes or create pull requests on Github.
Contributors will be listed here. Thanks!
Some unusual terms are frequently used in Bitcoin documentation and discussions like *tx* or *coinbase*.
Or words like *scriptPubKey* were badly chosen and now deserve some extra explanation.
This glossary will help you understand exact meaning of all Bitcoin-related terms.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
#idBtcattOaASIC#btcASIC:
Stands for "application-specific integrated circuit".
In other words, a chip designed to perform a narrow set of tasks (compared to CPU or GPU that perform a wide range of functions).
ASIC typically refers to specialized *mining#ql:idBtc1Mining#* chips or the whole machines built on these chips.
Some ASIC manufacturers: Avalon, ASICMiner, Butterfly Labs (BFL) and Cointerra.
#idBtcattOaASICMiner#btcASICMiner:
A Chinese manufacturer that makes custom mining hardware, sells shares for bitcoins, pays dividends from on-site mining and also ships actual hardware to customers.
#idBtcattOaBitcoin_ruby#btcBitcoin_ruby:
A Bitcoin utilities library in Ruby by Julian Langschaedel.
Used in production on *Coinbase.com*.
#idBtcattOaCasascius_Coin#btcCasascious_Coins:
Physical collectible coins produced#ql:https://www.casascius.com# by Mike Caldwell. Each coin contains a *private key* under a tamper-evident hologram. The name "Casascius" is formed from a phrase "call a spade a spade", as a response to a name of Bitcoin itself.
#idBtcattOaCoin#btcCoin:
An informal term that means either 1 bitcoin, or an unspent *transaction output* that can be *spent*.
#idBtcattOaCoinbase.com#btcCoinbase.com:
US-based Bitcoin/USD exchange and web wallet service.
#idBtcattOaKey#btcKey:
Could mean an ECDSA public or private key, or AES symmetric encryption key.
AES is not used in the protocol itself (only to encrypt the ECDSA keys and other sensitive data), so usually the word *key* means an ECDSA key.
When talking about *keys*, people usually mean private keys as public key can always be derived from a private one.
See also Private Key#ql:idBtcprk# and *Public Key*.
#idBtcattOaMain_Chain#btcMain_Chain:
A part of the blockchain which a node considers the most difficult (see difficulty#ql:idBtcblkhdrnbtsdflt#).
All nodes store all valid blocks, including orphans#ql:idBtcblkOrfn# and recompute the total difficulty when receiving another block.
If the newly arrived block or blocks do not extend existing main chain, but create another one from some previous block, it is called *reorganization*.
#idBtcattOaMiner#btcMiner:
A person, a software or a hardware that performs mining#ql:idBtcmnng#.
#idBtcattOaSecret_key#btcSecret_key:
Either the *Private Key* or an encryption key used in encrypted *wallets*.
Bitcoin protocol does not use encryption anywhere, so *secret key* typically means a *private key* used for signing transactions.
#idBtcattOaSpam#
Incorrect peer-to-peer messages (like sending invalid transactions) may be considered a denial of service attack (see *DoS*).
Valid transactions sending very tiny amounts and/or having low *mining fees* are called Dust#ql:idBtctxDst# by some people.
The protocol itself does not define which transactions are not worth relaying or mining, it's a decision of every individual node.
Any valid transaction in the blockchain must be accepted by the node if it wishes to accept the remaining blocks, so transaction censorship only means increased confirmation delays.
Individual payees may also blacklist certain addresses (refuse to accept payments from some addresses), but that's too easy to work around using *mixing*.
#idBtcattOaVarInt#
VarInt:
This term may cause confusion as it means different formats in different Bitcoin implementations. See *CompactSize* for details.
name::
* McsEngl.btcatt.Coindesk@cptIt,
* McsEngl.btcglossary.Coindesk@cptIt,
* McsEngl.btcCoindesk-glossary@cptIt,
_DESCRIPTION:
CoinDesk is the world leader in news and information on digital currencies such as bitcoin, and its underlying technology – the blockchain.
We cover news and analysis on the trends, price movements, technologies, companies and people in the bitcoin and digital currency world.
[http://www.coindesk.com/about-us/]
_ADDRESS.WPG:
[http://www.coindesk.com/information/bitcoin-glossary//]
#idBtcattCdAML#btcAML:
Anti-Money Laundering techniques are used to stop people converting illegally obtained funds, to appear as though they have been earned legally.
AML mechanisms can be legal or technical in nature.
Regulators frequently apply AML techniques to bitcoin exchanges.
#idBtcattCdASIC#btcASIC:
An Application Specific Integrated Circuit is a silicon chip specifically designed to do a single task.
In the case of bitcoin, they are designed to process SHA-256 hashing problems to mine new bitcoins.
#idBtcattCdASIC_miner#btcASIC_miner:
A piece of equipment containing an ASIC chip, configured to mine for bitcoins.
They can come in the form of boards that plug into a backplane, devices with a USB connector, or standalone devices including all of the necessary software, that connect to a network via a wireless link or ethernet cable.
#idBtcattCdBitcoin_Investment_Trust#btcBitcoin_Investment_Trust:
This private, open-ended trust invests exclusively in bitcoins and uses a state-of-the-art protocol to store them safely on behalf of its shareholders.
It provides a way for people to invest in bitcoin without having to purchase and safely store the digital currency themselves.
#idBtcattCdBitcoin_Sentiment_Index#btcBitcoin_Sentiment_Index, btcBSI:
The Bitcoin Sentiment Index is a measure of whether individuals feel the digital currency's prospects are increasing or decreasing on any given day, and is powered by data collected by Qriously.
#idBtcattCdBitcoin_Market_Potential_Index#btcBitcoin_Market_Potential_Index, btcBMPI:
The Bitcoin Market Potential Index (BMPI) uses a data set to rank the potential utility of bitcoin across 177 countries.
It attempts to show which markets have the greatest potential for bitcoin adoption.
#idBtcattCdBitcoin_Price_Index#btcBitcoin_Price_Index, btcBPI:
The CoinDesk Bitcoin Price Index represents an average of bitcoin prices across leading global exchanges that meet criteria specified by the BPI.
There is also an API for developers to use.
#idBtcattCdBitPay#btcBitPay:
A payment processor for bitcoins, which works with merchants, enabling them to take bitcoins as payment.
#idBtcattCdButtonwood#btcButtonwood:
A project founded by bitcoin enthusiast Josh Rossi, to form a public outcry bitcoin exchange in New York's Union Square.
Named after the Buttonwood agreement, which formed the basis for the New York Stock Exchange in 1792.
#idBtcattCdCircle#btcCircle:
Circle is an exchange and wallet service, offering users worldwide the chance to store, send, receive and exchange bitcoins.
#idBtcattCdCoin_age#btcCoin_age:
The age of a coin, defined as the currency amount multiplied by the holding period.
#idBtcattCdDDoS#btcDDoS:
A distributed denial of service attack uses large numbers of computers under an attacker’s control to drain the resources of a central target.
They often send small amounts of network traffic across the Internet to tie up computing and bandwidth resources at the target, which prevents it from providing services to legitimate users.
Bitcoin exchanges have sometimes been hit with DDoS attacks.
#idBtcattCdDeflation#btcDeflation:
The reduction of prices in an economy over time.
It happens when the supply of a good or service increases faster than the supply of money, or when the supply of money is finite, and decreases.
This leads to more goods or services per unit of currency, meaning that less currency is needed to purchase them.
This carries some downsides.
When people expect prices to fall, it causes them to stop spending and hoard money, in the hope that their money will go further later.
This can depress an economy.
#idBtcattCdEscrow#btcEscrow:
The act of holding funds or assets in a third-party account to protect them during an asynchronous transaction.
If Bob wants to send money to Alice in exchange for a file, but they cannot conduct the exchange in person, then how can they trust each other to send the money and file to each other at the same time?
Instead, Bob sends the money to Eve, a trusted party who holds the funds until Bob confirms that he has received the file from Alice.
She then sends Alice the money.
#idBtcattCdFaucet#:btcFaucent:
A technique used when first launching an altcoin.
A set number of coins are pre-mined, and given away for free, to encourage people to take interest in the coin and begin mining it themselves.
#idBtcattCdFiat_currency#btcFiat_currency:
A currency, conjured out of thin air, which only has value because people say it does.
Constantly under close scrutiny by regulators due to its known application in money laundering and terrorist activities.
Not to be confused with bitcoin.
#idBtcattCdFinCEN#btcFinCEN:
The Financial Crimes Enforcement Network, an agency within the US Treasury Department.
FinCEN has thus far been the main organization to impose regulations on exchanges trading in bitcoin.
#idBtcattCdFPGA#btcFPGA:
A Field Programmable Gate Array is a processing chip that can be configured with custom functions after it has been fabricated.
Think of it as a blank silicon slate on which instructions can be written.
Because FPGAs can be produced en masse and configured after fabrication, manufacturers benefit from economies of scale, making them cheaper than ASIC chips.
However, they are usually far slower.
#idBtcattCdGPU#btcGPU:
Graphical Processing Unit.
A silicon chip specifically designed for the complex mathematical calculations needed to render millions of polygons in modern computer game graphics.
They are also well suited to the cryptographic calculations needed in cryptocurrency mining.
#idBtcattCdInflation#btcInflation:
When the value of money drops over time, causing prices for goods to increase.
The result is a drop in purchasing power.
Effects include less motivation to hoard money, and more motivation to spend it quickly while the prices of goods are still low.
#idBtcattCdKYC#btcKYC:
Know Your Client/Customer rules force financial institutions to vet the people they are doing business with, ensuring that they are legitimate.
#idBtcattCdLeverage#btcLeverage, btcMargin_requirement:
In foreign currency trading, leverage multiplies the real funds in your account by a given factor, enabling you to make trades that result in significant profit.
By giving leverage to a trader, the trading exchange is effectively lending them money, in the hope that it will earn back more than it loaned in commission.
Leverage is also known as a margin requirement.
#idBtcattCdLiberty_Reserve#btcLiberty_Reserve:
A centralized digital currency payment processor based in Costa Rica.
It was shut down by the US government, after it was found guilty of money laundering.
#idBtcattCdLiquidity#btcLiquidity:
The ability to buy and sell an asset easily, with pricing that stays roughly similar between trades.
A suitably large community of buyers and sellers is important for liquidity.
The result of an illiquid market is price volatility, and the inability to easily determine the value of an asset.
#idBtcattCdMargin_call#btcMargin_call:
The act of calling in a margin requirement.
An exchange will issue a margin call when it feels that a trader does not have sufficient funds to cover a leveraged trading position.
#idBtcattCdMarket_order#btcMarket_order:
An instruction given to an exchange, asking it to buy or sell an asset at the going market rate.
In a bitcoin exchange, you would place a market order if you simply wanted to buy or sell bitcoins immediately, rather than holding them until a set market condition is triggered to try and make a profit.
#idBtcattCdP2P#btcP2P:
Peer-to-peer.
Decentralized interactions that happen between at least two parties in a highly interconnected network.
An alternative system to a 'hub-and-spoke' arrangement, in which all participants in a transaction deal with each other through a single mediation point.
#idBtcattCdPrimecoin#btcPrimecoin
Developed by Sunny King, Primecoin uses a proof of work system to calculate prime numbers.
#idBtcattCdPSP#btcPSP:
Payment Service Provider.
The PSP offers payment processing services for merchants who wish to accept payments online.
#idBtcattCdPump_and_dump#btcPump_and_dump:
Inflating the value of a financial asset that has been produced or acquired cheaply, using aggressive publicity and often misleading statements.
The publicity causes others to acquire the asset, forcing up its value.
When the value is high enough, the perpetrator sells their assets, cashing in and flooding the market, which causes the value to crash.
#idBtcattCdSilk_Road#btcSilk_Road:
An underground online marketplace, generally used for illicit purchases, often with cryptocurrencies such as bitcoin.
Silk Road was shut down in early October 2013 by the FBI after owner Ross Ulbricht was arrested.
Ulbricht was later convicted on money laundering and drug distribution charges.
#idBtcattCdSEPA#btcSEPA:
The Single European Payments Area.
A payment integration agreement within the European Union, designed to make it easier to transfer funds between different banks and nations in euros.
#idBtcattCdTOR#btcTOR:
An anonymous routing protocol, used by people wanting to hide their identity online.
#idBtcattCdVolatility#btcVolatility:
The measurement of price movements over time for a traded financial asset (including bitcoin).
#idBtcattCdWire_transfer#btcWire_transfer:
Electronically transferring money from one person to another.
Commonly used to send and retrieve fiat currency from bitcoin exchanges.
#idBtcattCdZerocoin#btcZerocoin:
A protocol designed to make cryptocurrency transactions truly anonymous.
name::
* McsEngl.btcnet'Protocol (btcprl)@cptIt,
* McsEngl.bitcoin-protocol@cptIt,
* McsEngl.btcprotocol@cptIt,
* McsEngl.Bitcoin-message-protocol@cptIt,
* McsEngl.bitcoin-protocol@cptIt,
* McsEngl.btcprl@cptIt,
====== lagoGreek:
* McsElln.μπιτκόιν-πρωτόκολλο@cptIt,
* McsElln.πρωτόκολλο-μπιτκόιν@cptIt,
_GENERIC:
* blockchain-protocol,
name::
* McsEngl.btcprl'White-paper (btcwpr {2008})@cptIt,
* McsEngl.bitcoin-whitepaper@cptIt,
* McsEngl.btcwpr@cptIt,
====== lagoGreek:
* McsElln.λευκή-βίβλος-του-μπτικόιν@cptIt,
_DESCRIPTION:
Bitcoin_Whitepaper:
The bitcoin whitepaper was written by 'Satoshi Nakamoto#ql:idBtchmnSnt#’ and posted to a Cryptography Mailing list in 2008.
The paper describes the bitcoin protocol in detail, and is well worth a read.
Satoshi Nakamoto followed this by releasing the bitcoin code in 2009.
...
Bitcoin_white_paper:
In November 2008, a paper, authored (probably pseudonymously) by Satoshi Nakamoto#ql:idBtchmnSnt#, was posted on the newly created Bitcoin.org website with the title 'Bitcoin: A Peer-to-Peer Electronic Cash System’.
The eight-page document described methods of using a peer-to-peer network to generate "a system for electronic transactions without relying on trust" and laid down the working principles of the cryptocurrency.
[http://www.coindesk.com/information/bitcoin-glossary//]
Bitcoin: A Peer-to-Peer Electronic Cash System
Satoshi Nakamoto
www.bitcoin.org
{2008-10-31}
A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution.
Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending.
We propose a solution to the double-spending problem using a peer-to-peer network.
The network timestamps transactions by hashing them into an ongoing chain of hashbased proof-of-work, forming a record that cannot be changed without redoing the proof-of-work.
The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power.
As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers.
The network itself requires minimal structure.
Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.
Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments.
While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model.
Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes.
The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for nonreversible services.
With the possibility of reversal, the need for trust spreads.
Merchants must be wary of their customers, hassling them for more information than they would otherwise need.
A certain percentage of fraud is accepted as unavoidable.
These costs and payment uncertainties can be avoided in person by using physical currency, but no mechanism exists to make payments over a communications channel without a trusted party.
What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party.
Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms could easily be implemented to protect buyers.
In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions.
The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes.
We define an electronic coin as a chain of digital signatures.
Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin.
A payee can verify the signatures to verify the chain of ownership.
#idBtcwprfig1#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgBtcwprFig1.png!#
The problem of course is the payee can't verify that one of the owners did not double-spend the coin.
A common solution is to introduce a trusted central authority, or mint, that checks every transaction for double spending.
After each transaction, the coin must be returned to the mint to issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent.
The problem with this solution is that the fate of the entire money system depends on the company running the mint, with every transaction having to go through them, just like a bank.
We need a way for the payee to know that the previous owners did not sign any earlier transactions.
For our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend.
The only way to confirm the absence of a transaction is to be aware of all transactions.
In the mint based model, the mint was aware of all transactions and decided which arrived first.
To accomplish this without a trusted party, transactions must be publicly announced[01#ql:idBtcwprref1#], and we need a system for participants to agree on a single history of the order in which they were received.
The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received.
The solution we propose begins with 'defn.a-timestamp-server'.
A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post[2-5#ql:idBtcwprref2#].
The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash.
Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.
#idBtcwprfig2#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgBtcwprFig2.png!#
To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system similar to Adam Back's Hashcash[06#ql:idBtcwprref6#], rather than newspaper or Usenet posts.
The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits.
The average work required is exponential in the number of zero bits required and can be verified by executing a single hash.
For our timestamp network, we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits.
Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work.
As later blocks are chained after it, the work to change the block would include redoing all the blocks after it.
#idBtcwprfig3#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgBtcwprFig3.png!#
The proof-of-work also solves the problem of determining representation in majority decision making.
If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs.
Proof-of-work is essentially one-CPU-one-vote.
The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it.
If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains.
To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes.
We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added.
To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour.
If they're generated too fast, the difficulty increases.
The steps to run the network are as follows:
1. New transactions are broadcast to all nodes.
2. Each node collects new transactions into a block.
3. Each node works on finding a difficult proof-of-work for its block.
4. When a node finds a proof-of-work, it broadcasts the block to all nodes.
5. Nodes accept the block only if all transactions in it are valid and not already spent.
6. Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.
Nodes always consider the longest chain to be the correct one and will keep working on extending it.
If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first.
In that case, they work on the first one they received, but save the other branch in case it becomes longer.
The tie will be broken when the next proof-of-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.
New transaction broadcasts do not necessarily need to reach all nodes.
As long as they reach many nodes, they will get into a block before long.
Block broadcasts are also tolerant of dropped messages.
If a node does not receive a block, it will request it when it receives the next block and realizes it missed one.
By convention, the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block.
This adds an incentive for nodes to support the network, and provides a way to initially distribute coins into circulation, since there is no central authority to issue them.
The steady addition of a constant of amount of new coins is analogous to gold miners expending resources to add gold to circulation.
In our case, it is CPU time and electricity that is expended.
The incentive can also be funded with transaction fees.
If the output value of a transaction is less than its input value, the difference is a transaction fee that is added to the incentive value of the block containing the transaction. Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free.
The incentive may help encourage nodes to stay honest.
If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins.
He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth.
Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space.
To facilitate this without breaking the block's hash, transactions are hashed in a Merkle Tree [7#ql:idBtcwprref7#][2#ql:idBtcwprref2#][5#ql:idBtcwprref5#], with only the root included in the block's hash.
Old blocks can then be compacted by stubbing off branches of the tree.
The interior hashes do not need to be stored.
#idBtcwprfig4#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgBtcwprFig4.png!#
A block header with no transactions would be about 80 bytes.
If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year.
With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.
It is possible to verify payments without running a full network node.
A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in.
He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.
#idBtcwprfig5#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgBtcwprFig5.png!#
As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker.
While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network.
One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency.
Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification.
Although it would be possible to handle coins individually, it would be unwieldy to make a separate transaction for every cent in a transfer.
To allow value to be split and combined, transactions contain multiple inputs and outputs.
Normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender.
#idBtcwprfig6#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgBtcwprFig6.png!#
It should be noted that fan-out, where a transaction depends on several transactions, and those transactions depend on many more, is not a problem here.
There is never the need to extract a complete standalone copy of a transaction's history.
The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party.
The necessity to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous.
The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone.
This is similar to the level of information released by stock exchanges, where the time and size of individual trades, the "tape", is made public, but without telling who the parties were.
#idBtcwprfig7#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgBtcwprFig7.png!#
As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner.
Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner.
The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner.
We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain.
Even if this is accomplished, it does not throw the system open to arbitrary changes, such as creating value out of thin air or taking money that never belonged to the attacker.
Nodes are not going to accept an invalid transaction as payment, and honest nodes will never accept a block containing them.
An attacker can only try to change one of his own transactions to take back money he recently spent.
The race between the honest chain and an attacker chain can be characterized as a Binomial Random Walk.
The success event is the honest chain being extended by one block, increasing its lead by +1, and the failure event is the attacker's chain being extended by one block, reducing the gap by -1.
The probability of an attacker catching up from a given deficit is analogous to a Gambler's Ruin problem.
Suppose a gambler with unlimited credit starts at a deficit and plays potentially an infinite number of trials to try to reach breakeven.
We can calculate the probability he ever reaches breakeven, or that an attacker ever catches up with the honest chain, as follows[8#ql:idBtcwprref8#]:
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgBtcwprFig8.png!#
Given our assumption that p>q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases.
With the odds against him, if he doesn't make a lucky lunge forward early on, his chances become vanishingly small as he falls further behind.
We now consider how long the recipient of a new transaction needs to wait before being sufficiently certain the sender can't change the transaction.
We assume the sender is an attacker who wants to make the recipient believe he paid him for a while, then switch it to pay back to himself after some time has passed.
The receiver will be alerted when that happens, but the sender hopes it will be too late.
The receiver generates a new key pair and gives the public key to the sender shortly before signing.
This prevents the sender from preparing a chain of blocks ahead of time by working on it continuously until he is lucky enough to get far enough ahead, then executing the transaction at that moment.
Once the transaction is sent, the dishonest sender starts working in secret on a parallel chain containing an alternate version of his transaction.
The recipient waits until the transaction has been added to a block and z blocks have been linked after it.
He doesn't know the exact amount of progress the attacker has made, but assuming the honest blocks took the average expected time per block, the attacker's potential progress will be a Poisson distribution with expected value:
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgBtcwprFig9.png!#
To get the probability the attacker could still catch up now, we multiply the Poisson density for each amount of progress he could have made by the probability he could catch up from that point:
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgBtcwprFig10.png!#
Rearranging to avoid summing the infinite tail of the distribution...
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgBtcwprFig11.png!#
Converting to C code...
#include
double AttackerSuccessProbability(double q, int z)
{
double p = 1.0 - q;
double lambda = z * (q / p);
double sum = 1.0;
int i, k;
for (k = 0; k <= z; k++)
{
double poisson = exp(-lambda);
for (i = 1; i <= k; i++)
poisson *= lambda / i;
sum -= poisson * (1 - pow(q / p, z - k));
}
return sum;
}
Running some results, we can see the probability drop off exponentially with z.
q=0.1
z=0 P=1.0000000
z=1 P=0.2045873
z=2 P=0.0509779
z=3 P=0.0131722
z=4 P=0.0034552
z=5 P=0.0009137z=6 P=0.0002428
z=7 P=0.0000647
z=8 P=0.0000173
z=9 P=0.0000046
z=10 P=0.0000012
q=0.3
z=0 P=1.0000000
z=5 P=0.1773523
z=10 P=0.0416605
z=15 P=0.0101008
z=20 P=0.0024804
z=25 P=0.0006132
z=30 P=0.0001522
z=35 P=0.0000379
z=40 P=0.0000095
z=45 P=0.0000024
z=50 P=0.0000006
Solving for P less than 0.1%...
P < 0.001
q=0.10 z=5
q=0.15 z=8
q=0.20 z=11
q=0.25 z=15
q=0.30 z=24
q=0.35 z=41
q=0.40 z=89
q=0.45 z=340
We have proposed a system for electronic transactions without relying on trust.
We started with the usual framework of coins made from digital signatures, which provides strong control of ownership, but is incomplete without a way to prevent double-spending.
To solve this, we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power.
The network is robust in its unstructured simplicity.
Nodes work all at once with little coordination.
They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis.
Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone.
They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them.
Any needed rules and incentives can be enforced with this 'defn.consensus-mechanism'.
#idBtcwprref1#[1]. W. Dai, "b-money," http://www.weidai.com/bmoney.txt, 1998.
#idBtcwprref2#[2]. H. Massias, X.S. Avila, and J.-J. Quisquater, "Design of a secure timestamping service with minimal trust requirements," In 20th Symposium on Information Theory in the Benelux, May 1999.
#idBtcwprref3#[3]. S. Haber, W.S. Stornetta, "How to time-stamp a digital document," In Journal of Cryptology, vol 3, no 2, pages 99-111, 1991.
#idBtcwprref4#[4]. D. Bayer, S. Haber, W.S. Stornetta, "Improving the efficiency and reliability of digital timestamping," In Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993.
#idBtcwprref5#[5]. S. Haber, W.S. Stornetta, "Secure names for bit-strings," In Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, April 1997.
#idBtcwprref6#[6]. A. Back, "Hashcash - a denial of service countermeasure," http://www.hashcash.org/papers/hashcash.pdf, 2002.
#idBtcwprref7#[7]. R.C. Merkle, "Protocols for public key cryptosystems," In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, pages 122-133, April 1980.
#idBtcwprref8#[8]. W. Feller, "An introduction to probability theory and its applications," 1957.
_ADDRESS.WPG:
* https://bitcoin.org/bitcoin.pdf,
* http://www.cryptovest.co.uk/resources/Bitcoin%20paper%20Original.pdf,
name::
* McsEngl.btcprl'Implementation@cptIt,
name::
* McsEngl.btcprl'BIP (Bitcoin-Improvement-Proposals | btcbip)@cptIt,
* McsEngl.BIP@cptIt,
* McsEngl.Bitcoin-Improvement-Proposals@cptIt,
* McsEngl.btcBIP@cptIt,
* McsEngl.btcBitcoin-Improvement-Proposals@cptIt,
* McsEngl.btcprl'BIP@cptIt,
* McsEngl.btcnet'BIP@cptIt,
====== lagoGreek:
* McsElln.Προτάσεις-Βελτίωσης-Bitcoin@cptIt,
_DESCRIPTION:
People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Greg Maxwell <gmaxwell@gmail.com>. After copy-editing and acceptance, it will be published here.
We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.
Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community.
Those proposing changes should consider that ultimately consent may rest with the consensus of the Bitcoin users (see also: economic majority).
[https://github.com/bitcoin/bips#readme]
===
Bitcoin Improvement Proposals.
RFC-like documents modeled after PEPs (Python Enhancement Proposals) discussing different aspects of the protocol and software.
Most interesting BIPs describe *hard-fork#ql:btchard_fork#* changes in the core protocol that require supermajority of Bitcoin users (or, in some cases, only miners) to agree on the change and accept it in an organized manner.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
_ADDRESS.WPG:
* https://github.com/bitcoin/bips#readme,
name::
* McsEngl.ptcprl'SegWit@cptIt,
* McsEngl.btcnet'SegWit@cptIt,
* McsEngl.segwit@cptIt,
_DESCRIPTION:
Segwit is a proposal to allow transaction-producing software to separate (segregate) transaction signatures (witnesses) from the rest of the data in a transaction, and to allow miners to place those witnesses outside of the traditional block structure.
[https://bitcoincore.org/en/2016/06/24/segwit-next-steps/]
name::
* McsEngl.btcnet'Sidechain@cptIt,
* McsEngl.bitcoin-sidechain@cptIt,
* McsEngl.pegged-sidechain@cptIt,
* McsEngl.btcsidechain@cptIt,
_ADDRESS.WPG:
* https://www.blockstream.com//
* https://www.blockstream.com/sidechains.pdf,
name::
* McsEngl.btcprl'Lightning-network@cptIt,
* McsEngl.bitcoin-lightning-network@cptIt,
* McsEngl.bitcoin-thunder-network@cptIt,
* McsEngl.btcnet'Lightning-network@cptIt,
* McsEngl.lightning-network-of-bitcoin@cptIt,
_ADDRESS.WPG:
* {2017-03-26} https://medium.com/@btc_coach/lightning-network-in-action-b18a035c955d#.t0xv3e8mk,
* https://lightning.network//
* https://medium.com/@AudunGulbrands1/lightning-faq-67bd2b957d70#.gtx36kylc,
_DESCRIPTION:
A quick overview of what the Lightning network is
- A payment layer that makes use of the script language in Bitcoin
- A way to send and spend Bitcoin across nodes instantly and irreversibly
- A layer that builds on the security of the underlying protocol, Bitcoin
[https://medium.com/@btc_coach/lightning-network-in-action-b18a035c955d]
===
The lightning network is a highly anticipated second-layer protocol to be rolled out on top of Bitcoin’s blockchain. Cleverly utilizing Bitcoin’s programmable elements (like multisignature and time-locks), lightning users should be able to make a virtually unlimited number of off-chain transactions with instant confirmations and at low cost. This should boost Bitcoin’s micropayment-ability, overall scalability and even privacy.
[https://bitcoinmagazine.com/articles/lightning-network-one-step-closer-to-reality-as-lightning-labs-announces-alpha-release-1484333955]
===
Announcing the Thunder Network Alpha Release
Peter · May 16, 2016 · Leave a Reply
At Blockchain, we’re on a mission to create an open, accessible, and equitable financial future. Since our inception, we have focused on building products that make it easy for everyday people to use bitcoin to store and transfer value all over the world. We make Bitcoin usable and useful. We’ve been able to do that because we develop with a user-focused mandate.
A faster, cheaper, and more functional network would deliver real value to our users, so we were excited by the growth of research into payment channel technology on the bitcoin network and innovative uses of this technology. We were particularly interested in the idea of using smart contracts to build what are basically super-charged payments networks, as outlined in a white paper by the lightning.network team. Last year, we hired a talented engineer, Mats Jerratsch, who had been pioneering innovation in this vertical to work with our engineering team and lead research and development on a network based around these ideas.
Lightning networks have been purely conceptual, research based, and only in test nets and labs – until now. Today, we release the alpha version of our Thunder Network, the first usable implementation of the Lightning network for off chain bitcoin payments that settles back to the main bitcoin blockchain.
We used it internally a few days ago. Click here to learn all about Transaction 0 between Mats and me.
Thunder has the potential to facilitate secure, trustless, and instant payments. It has the ability to unleash the power of microtransactions, to allow the bitcoin network to handle heavy loads, and to increase user privacy. In this Alpha version, we prove that it can be done. From a feature perspective, there is both a node and a wallet (with GUI) present. Even more importantly:
Settlement to the bitcoin blockchain
Scale: According to our tests so far, we can achieve better-than-Visa scale (100,000 TPS) with only a few thousand nodes on the network
Extremely cheap payments: fees will develop naturally, due to the free market in an open and permissionless network and will fundamentally be lower than on-chain payments
Encryption and Authentication: All communications between all nodes and wallets are encrypted using AES-CTR and take place only after completing authentication.
Seed Peers and automatically provide them with network topology using a basic gossip protocol similar to the one used in the bitcoin network, which allows complex routes over multiple hops
Payment Channels can be opened and closed at will, with transactions settling onto the bitcoin blockchain
Payment Debate: Across the route each hop will renegotiate a new status with the next hop, as a payment makes its way through the network with cryptography in place to prevent fraud
Relaying Payments: TN will relay payments over multiple nodes in the network automatically, using encrypted routing. No one knows who made a payment, allowing for more privacy
Settle payments automatically, no manual intervention needed. The settlement will ripple back through the network to provide proof-of-payment
Instant Payments that are irrevocable the moment you see them
Until both CSV and SegWit are implemented on the bitcoin blockchain, transactions are not enforceable at the bitcoin protocol level. So, the current Thunder prototype is best suited for transactions among a trusted network of users. Try this amongst your dev team or amongst your trusted internet friends, but don’t use it for real payments. Remember: this is alpha testing software.
So why release this now? We believe it is critical to get something in the hands of users as soon as possible to gain feedback that will enable us to be ready when the network is. So review it, test it out, open an issue on GitHub, or send us an email. If you want to work on tech like this full time, head here and apply to join our team.
We encourage you to find out more at:
www.blockchain.com/thunder
https://github.com/blockchain/thunder
[https://blog.blockchain.com/2016/05/16/announcing-the-thunder-network-alpha-release/]
name::
* McsEngl.ptcprl'Resource@cptIt,
_ADDRESS.WPG:
* https://lightning.network/lightning-network-paper.pdf,
name::
* McsEngl.btcnet'Node (btcnod)@cptIt,
* McsEngl.btcnod@cptIt,
* McsEngl.btcnode@cptIt,
* McsEngl.bitcoin-node@cptIt,
* McsEngl.btcnet'node@cptIt,
* McsElln.κόμβος-μπιτκόιν@cptIt,
_DESCRIPTION:
Node:
A computer connected to the bitcoin network using a client#ql:idBtcpgmClnt# that relays transactions to others (see client).
If you'd like to run a bitcoin node, then bitcoin.org offers a comprehensive guide.
[http://www.coindesk.com/information/bitcoin-glossary//]
===
Node, or client, is a computer on the network that speaks Bitcoin message protocol (exchanging transactions and blocks).
There are *full nodes* that are capable of validating the entire blockchain and *lightweight nodes*, with reduced functionality.
Wallet-applications#ql:"btcwallet_program"# that speak to a server are not considered nodes.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
A computer connected to the bitcoin network using a client that relays transactions to others (see client). If you'd like to run a bitcoin node, then bitcoin.org offers a comprehensive guide.
[http://www.coindesk.com/information/bitcoin-glossary/#node]
===
A system running a Bitcoin client is called a Bitcoin node.
The Bitcoin network's function is to relay two types of messages: Transactions and blocks.
A transaction is a digitally signed instruction to transfer money between addresses, as described earlier.
A block is: A set of transactions.Apr 7, 2013
Bitcoin part 10: The network « self-evident
[https://self-evident.org/?p=999]
name::
* McsEngl.btcnod'Consensus@cptIt,
* McsEngl.btcconsensus@cptIt,
====== lagoGreek:
* McsElln.μπιτκόιν-συναίνεση@cptIt,
_DESCRIPTION:
When several nodes (usually most nodes on the network) all have the same blocks#ql:btcblock# in their locally-validated best block chain.
[https://bitcoin.org/en/glossary/consensus]
name::
* McsEngl.btcnod.AGGREGATE@cptIt,
{time.2017-04-05};
Reachable nodes as of Wed Apr 05 2017 15:37:06 GMT+0300 (Eastern Europe Daylight Time).
6981 NODES
[https://bitnodes.21.co//]
{2017}:
Each of the currently approx. 6,500 computing nodes in the Bitcoin network constantly works on forming blocks, a process referred to as mining.
[http://www.sciplore.org/wp-content/papercite-data/pdf/gipp15a.pdf, ~=2015]
name::
* McsEngl.btcnod.FULL@cptIt,
* McsEngl.bitcoin-full-node@cptIt,
* McsEngl.btcfull-node@cptIt,
* McsEngl.btcpeer@cptIt,
* McsEngl.btcfnd@cptIt,
_ADDRESS.WPG:
* https://bitcoin.org/en/full-node,
_DESCRIPTION:
A node#ql:idBtcnod# which implements all of Bitcoin protocol and does not require trusting any external service to validate transactions.
It is able to download and validate the entire *blockchain*.
All full nodes implement the same peer-to-peer messaging protocol to exchange transactions and blocks, but that is not a requirement.
A full node may receive and validate data using any protocol and from any source.
However, the highest security is achieved by being able to communicate as fast as possible with as many nodes as possible.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
A full node is defined as a network-attached bitcoin client application, such as the original bitcoin Core (QT) client or an implementation of the bitcoind framework. A full node has the entire, up-to-date set of blockchain files, and also has port 8333 open, so it is set to listen for incoming requests. This list is very specific, and all of these conditions must be met for it to be a useful full node.
[http://bravenewcoin.com/news/the-decline-in-bitcoins-full-nodes/]
===
A full node is a program that fully validates transactions and blocks. Almost all full nodes also help the network by accepting transactions and blocks from other full nodes, validating those transactions and blocks, and then relaying them to further full nodes.
Most full nodes also serve lightweight clients by allowing them to transmit their transactions to the network and by notifying them when a transaction affects their wallet. If not enough nodes perform this function, clients won’t be able to connect through the peer-to-peer network—they’ll have to use centralized services instead.
Many people and organizations volunteer to run full nodes using spare computing and bandwidth resources—but more volunteers are needed to allow Bitcoin to continue to grow. This document describes how you can help and what helping will cost you.
[https://bitcoin.org/en/full-node#what-is-a-full-node]
===
Each full node in the Bitcoin network independently stores a block chain containing only blocks validated by that node.
[https://bitcoin.org/en/developer-guide#block-chain]
===
The Bitcoin network protocol allows full nodes (peers) to collaboratively maintain a peer-to-peer network for block and transaction exchange.
[https://bitcoin.org/en/developer-guide#term-peer]
name::
* McsEngl.btcnodFul'requirements@cptIt,
_DESCRIPTION:
Minimum Requirements
Bitcoin Core full nodes have certain requirements. If you try running a node on weak hardware, it may work—but you’ll likely spend more time dealing with issues. If you can meet the following requirements, you’ll have an easy-to-use node.
Desktop or laptop hardware running recent versions of Windows, Mac OS X, or Linux.
50 gigabytes of free disk space
2 gigabytes of memory (RAM)
A broadband Internet connection with upload speeds of at least 400 kilobits (50 kilobytes) per second
An unmetered connection, a connection with high upload limits, or a connection you regularly monitor to ensure it doesn’t exceed its upload limits. It’s common for full nodes on high-speed connections to use 200 gigabytes upload or more a month. Download usage is around 20 gigabytes a month, plus around an additional 40 gigabytes the first time you start your node.
6 hours a day that your full node can be left running. (You can do other things with your computer while running a full node.) More hours would be better, and best of all would be if you can run your node continuously.
Note: many operating systems today (Windows, Mac, and Linux) enter a low-power mode after the screensaver activates, slowing or halting network traffic. This is often the default setting on laptops and on all Mac OS X laptops and desktops. Check your screensaver settings and disable automatic “sleep” or “suspend” options to ensure you support the network whenever your computer is running.
[https://bitcoin.org/en/full-node#minimum-requirements]
name::
* McsEngl.btcnod.FULL.NO (lightweight)@cptIt,
* McsEngl.bitcoin-light-node@cptIt,
* McsEngl.btcnod.light@cptIt,
* McsEngl.btclightweight-client-node@cptIt,
* McsEngl.btclightweight-node@cptIt,
_DESCRIPTION:
Lightweight client
Comparing to a full node, lightweight node does not store the whole blockchain and thus cannot fully verify any transaction.
There are two kinds of lightweight nodes: those fully trusting an external service to determine wallet balance and validity of transactions (e.g. blockchain.info) and the apps implementing Simplified Payment Verification (SPV).
SPV clients do not need to trust any particular service, but are more vulnerable to a 51% attack than full nodes. See Simplified Payment Verification for more info.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md#lightweight-client]
===
A protocol known as “simplified payment verification” (SPV) allows for another class of nodes to exist, called “light nodes”, which download the block headers, verify the proof of work on the block headers, and then download only the “branches” associated with transactions that are relevant to them.
This allows light nodes to determine with a strong guarantee of security what the status of any Bitcoin transaction, and their current balance, is while downloading only a very small portion of the entire blockchain.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
name::
* McsEngl.btcnod.HONEST@cptIt,
* McsEngl.btchonest-peer@cptIt,
name::
* McsEngl.btcnod.HONEST.NO@cptIt,
* McsEngl.btchonestNo-peer@cptIt,
* McsEngl.btcmalicious-node@cptIt,
* McsEngl.btcmisbehaving-node@cptIt,
* McsEngl.btcuntrustworthy-peer@cptIt,
_DESCRIPTION:
Take note that for both types of broadcasting, mechanisms are in place to punish misbehaving peers who take up bandwidth and computing resources by sending false information. If a peer gets a banscore above the -banscore=<n> threshold, he will be banned for the number of seconds defined by -bantime=<n>, which is 86,400 by default (24 hours).
[https://bitcoin.org/en/developer-guide#misbehaving-nodes]
name::
* McsEngl.btcnod.MINER@cptIt,
* McsEngl.btcminer-node@cptIt,
* McsEngl.btcnet'miner@cptIt,
_DESCRIPTION:
The bitcoin network is driven by what are called miners, specialized computers that run the bitcoin software. In exchange, the people who run these miners are automatically paid in bitcoin. That’s their immediate incentive. But they also have an interest in expanding the network and keeping it running smoothly. Otherwise, those payments will dry up.
...
As Hearn pointed out, two Chinese operations control about 50 percent of the network’s mining power, and they’re reluctant to adopt the larger block size. “[They] refuse to switch to any competing product, as they perceive doing so as ‘disloyalty’—and they’re terrified of doing anything that might make the news of a ‘split’ and cause investor panic,” he wrote. “They have chosen instead to ignore the problem and hope it goes away.”
[http://www.wired.com/2016/02/the-schism-over-bitcoin-is-how-bitcoin-is-supposed-to-work/]
===
The process of finding a valid block is called mining whereas nodes that participate in that process are called miners.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
name::
* McsEngl.btcnodMnr'Mining (btcmng)@cptIt,
* McsEngl.bitcoin-mining@cptIt,
* McsEngl.btccevt'creating@cptIt,
* McsEngl.btccevt'issuance@cptIt,
* McsEngl.btccevt'mining@cptIt,
* McsEngl.netBtc'currency-issuance@cptIt,
* McsEngl.btccevt'mining@cptIt,
* McsEngl.btcmining@cptIt,
* McsEngl.netBtc'mining@cptIt,
====== lagoGreek:
* McsElln.εξόρυξη-μπιτκόιν@cptIt,
_DESCRIPTION:
Mining infrastructure is the backbone of bitcoin. Anyone who contributes computing power to help process transactions on the network is rewarded with the chance to "mine" bitcoin.
In plain English, in return for helping keep the network up and running, they have the chance of being given a newly created piece of the digital currency.
[https://www.weforum.org/agenda/2016/06/these-photos-show-you-inside-an-icelandic-bitcoin-mine?]
===
Τα bitcoin δημιουργούνται μέσω μιας διαδικασίας που ονομάζεται «εξόρυξη» (mining), η οποία αφορά τον ανταγωνισμό για εύρεση λύσεων σε ένα μαθηματικό πρόβλημα κατά την επεξεργασία των συναλλαγών bitcoin.
Κάθε συμμετέχων στο δίκτυο bitcoin (ο καθένας δηλαδή με τη χρήση μιας συσκευής που τρέχει τη πλήρη στοίβα πρωτοκόλλου bitcoin) μπορεί να λειτουργήσει ως εξορύκτης (miner), χρησιμοποιώντας την επεξεργαστική ισχύ του υπολογιστή του για να επαληθεύει και να καταγράφει τις συναλλαγές.
Κάθε 10 λεπτά, κατά μέσο όρο, είναι σε θέση κάποιος να επικυρώσει τις συναλλαγές των τελευταίων 10 λεπτών και να ανταμειφθεί με ολοκαίνουργια bitcoin.
[Mastering Bitcoin, Adonopoulos, https://www.bitcoinbook.info/translations/el/book.pdf]
===
A decentralized mathematical and deterministic currency issuance (distributed mining)
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
name::
* McsEngl.btcnodMnr'Resource@cptIt,
_ADDRESS.WPG:
* https://cointelegraph.com/news/pros-and-cons-of-starting-bitcoin-mining-farm-no-more-childs-play,
name::
* McsEngl.btcnodMnr'CLOUD-MINING@cptIt,
* McsEngl.bitcoin-clound-mining@cptIt,
* McsEngl.btcclound-mining@cptIt,
_ADDRESS.WPG:
* {2016-07-02} https://cointelegraph.com/news/hashocean-scam-victims-sign-petitions-to-fbi-hackers-to-reveal-more-scams,
“The website HashOcean.com is off-line and took with them millions of dollars from approximately 700,000 users worldwide. Since there are neither regulating institutions nor reliable sources of information, we have decided to open this channel to all users and supporters of cloud mining - people who believe in a transparent mining process. We created this petition to be able to ask the FBI and other similar institutions to trace those in charge of www.HashOcean.com - Cloud Mining. 700,000 users want their money back and the supporters of Cloud Mining deserve a reliable mining process.
If you lost money with www.HashOcean.com - Cloud Mining or you are simply a cryptocurrency supporter, please help us to raise awareness and get specialist help to trace the people responsible for HashOcean.com. Please sign the petition and forward to as many people as possible in all social medias. Let΄s unite and raise awareness as soon as possible.”
name::
* McsEngl.btcnodMnr'COMPANY@cptIt,
* McsEngl.bitcoin-mining-company@cptIt,
* McsEngl.btcmining-company@cptIt,
_DESCRIPTION:
Bitcoin’s biggest mining farm, Bitmain/Antpool,
[http://cointelegraph.com/news/bitcoins-biggest-miner-invests-in-wings-development-to-make-dao-mainstream]
name::
* McsEngl.btcnod.SEED@cptIt,
* McsEngl.bitcoin-seed-node@cptIt,
* McsEngl.btcseed-node@cptIt,
_DESCRIPTION:
Seed Nodes
Nodes whose IP addresses are included in the Bitcoin client for use during a new installation when the normal bootstrapping process through IRC wasn't possible.
[https://en.bitcoin.it/wiki/Vocabulary#Seed_Nodes]
name::
* McsEngl.btcnet'Blockchain (btcbcn)@cptIt,
* McsEngl.btcbcn@cptIt,
* McsEngl.btcnet'blockchain@cptIt,
* McsEngl.bitcoin-global-database@cptIt,
* McsEngl.blockchain.bitcoin@cptIt,
* McsEngl.btcbcn@cptIt, {2015-09-13}
* McsEngl.btcbc@cptIt, {2015-09-03}
* McsEngl.btcblockchain@cptIt,
* McsEngl.bitcoin-block-chain@cptIt,
* McsElln.μπιτκόιν-μπλοκτσέιν@cptIt,
* McsElln.μπλοκτσέιν-του-μπικόιν@cptIt,
* McsElln.παγκόσμιο-μπιτκόιν-μπλοκτσέιν@cptIt,
* McsElln.παγκόσμιο-μπλοκτσέιν-του-μπικόιν@cptIt,
_DESCRIPTION:
The blockchain is a record of all transactions that have occured in the Bitcoin system and is shared by every node in it.
Its main purpose is to infer a list of all unspent transaction outputs and their spending conditions.
The novelty of Bitcoin lies, among other things, in how the blockchain is structured in order to guarantee chronological ordering of transactions and prevent double-spending in a distributed network.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
_GENERIC:
* Blockchain#ql:idBcnbcn#
_DESCRIPTION:
Blockchain:
The full list of blocks#ql:idBtcblk# that have been mined since the beginning of the bitcoin cryptocurrency.
The blockchain is designed so that each block contains a hash drawing on the blocks that came before it.
This is designed to make it more tamperproof.
To add further confusion, there is a company called Blockchain, which has a very popular blockchain explorer and bitcoin wallet.
[http://www.coindesk.com/information/bitcoin-glossary//]
_DESCRIPTION:
A block chain is a transaction database shared by all nodes participating in a system based on the Bitcoin protocol. A full copy of a currency's block chain contains every transaction ever executed in the currency. With this information, one can find out how much value belonged to each address at any point in history.
Every block contains a hash of the previous block. This has the effect of creating a chain of blocks from the genesis block to the current block. Each block is guaranteed to come after the previous block chronologically because the previous block's hash would otherwise not be known. Each block is also computationally impractical to modify once it has been in the chain for a while because every block after it would also have to be regenerated. These properties are what make double-spending of bitcoins very difficult. The block chain is the main innovation of Bitcoin.
Honest generators only build onto a block (by referencing it in blocks they create) if it is the latest block in the longest valid chain. "Length" is calculated as total combined difficulty of that chain, not number of blocks, though this distinction is only important in the context of a few potential attacks. A chain is valid if all of the blocks and transactions within it are valid, and only if it starts with the genesis block.
For any block on the chain, there is only one path to the genesis block. Coming from the genesis block, however, there can be forks. One-block forks are created from time to time when two blocks are created just a few seconds apart. When that happens, generating nodes build onto whichever one of the blocks they received first. Whichever block ends up being included in the next block becomes part of the main chain because that chain is longer. More serious forks have occurred after fixing bugs that required backward-incompatible changes.
Blocks in shorter chains (or invalid chains) are not used for anything. When the bitcoin client switches to another, longer chain, all valid transactions of the blocks inside the shorter chain are re-added to the pool of queued transactions and will be included in another block. The reward for the blocks on the shorter chain will not be present in the longest chain, so they will be practically lost, which is why a network-enforced 100-block maturation time for generations exists.
These blocks on the shorter chains are often called "orphan" blocks. This is because the generation transactions do not have a parent block in the longest chain, so these generation transactions show up as orphan in the listtransactions RPC call. Several pools have misinterpreted these messages and started calling their blocks "orphans". In reality, these blocks have a parent block, and might even have children.
Because a block can only reference one previous block, it is impossible for two forked chains to merge.
It's possible to use the block chain algorithm for non-financial purposes: see Alternative chain.
The block chain is broadcast to all nodes on the networking using a flood protocol: see Block chain download.
[https://en.bitcoin.it/wiki/Block_chain]
_DESCRIPTION:
6) The mined block is added to the "blockchain", a big, unbreakable ledger that lives on the bitcoin network and serves as a record of all transactions.
[http://www.economist.com/blogs/graphicdetail/2015/01/daily-chart-3]
_DESCRIPTION:
A public transaction ledger (the blockchain)
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
_DESCRIPTION:
Blockchain is the system that bitcoin inventors devised. To understand how blockchain works requires dedicated study, but non-specialists might think of it as a publicly viewable spreadsheet that records every bitcoin transaction — who sent how much to whom (it's possible to remain fairly anonymous). Every few minutes, a "block" of new rows is added. But old blocks on the chain can't be edited. They're locked tight by theoretically unbreakable computer code.
See the most-read stories this hour >>
At least thousands of specially set up computers store a copy of the blockchain, so messing with records would require the herculean feat of infecting them all. Anyone can set up one of these computers, which work together to find inconsistencies and prevent fraud like double-spending. The people and businesses around the world who have set up these computers collect fees in exchange for authorizing transactions.
Finding applications for blockchain is wide-open territory right now. Factom, an organization in Austin, Texas, proposes using it to verify and lock down the records on mortgage contracts, with the aim of preventing some of the abuses of the mortgage meltdown, where signatures were faked and mortgage contracts went missing.
[http://www.latimes.com/business/la-fi-cutting-edge-blockchain-20150809-story.html]
_DESCRIPTION:
Blockchain:
A public ledger of all confirmed transactions in a form of a tree of all valid *blocks* (including *orphans*).
Most of the time, "blockchain" means the *main chain*, a single most *difficult* chain of blocks.
Blockchain is updated by *mining* blocks with new transactions.
*Unconfirmed transactions* are not part of the blockchain.
If some clients disagree on which chain is main or which blocks are valid, a *fork* happens.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcbcn'Block (btcblk)@cptIt,
* McsEngl.btc'block@cptIt,
* McsEngl.btcblk@cptIt,
* McsEngl.btcblock@cptIt,
* McsEngl.btcBlock-Of-Transactions@cptIt,
* McsEngl.btcnet'block@cptIt,
* McsEngl.bitcoin-block@cptIt,
* McsEngl.btcnet'blockchain'Block-of-transactions@cptIt,
_WHOLE:
* btc-blockchain#ql:btcblockchain#
_DESCRIPTION:
A data structure that consists of a *block-header#ql:btcblock_header#* and a *merkle-tree#ql:btcmerkle_tree#* of transactions.
Each block (except for *genesis block*) references one previous block thus forming a tree called the *blockchain*.
Block can be though of as a group of transactions with a timestamp and a *proof-of-work* attached.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
One or more transactions prefaced by a block header and protected by proof of work.
Blocks are the data stored on the block chain.
[https://bitcoin.org/en/glossary/block]
===
Data is permanently recorded in the Bitcoin network through files called blocks.
A block is a record of some or all of the most recent Bitcoin transactions that have not yet been recorded in any prior blocks. They could be thought of like the individual pages of a city recorder's recordbook (where changes to title to real estate are recorded) or a stock transaction ledger. New blocks are added to the end of the record (known as the block chain), and can never be changed or removed once written (although some software will remove them if they are orphaned). Each block memorializes what took place in the minutes before it was created.
[https://en.bitcoin.it/wiki/Block]
name::
* McsEngl.btcblk'PART@cptIt,
_DESCRIPTION:
Each block is composed of a header and a payload.
The header stores the current block header version (nVersion), a reference to the previous block (HashPrevBlock), the root node of the Merkle tree (HashMerkleRoot), a timestamp (nTime), a target value (nBits) and a nonce (nNonce).
Finally, the payload stores the number of transactions (#vtx ) and the vector of transactions (vtx ) included in the block.
Field name Type(Size) Description
* nVersion int(4 bytes) Block format version (currently 2).
* HashPrevBlock uint256(32 bytes) Hash of previous block header SHA2562 (nV ersion|| . . . ||nNonce).
* HashMerkleRoot uint256 (32 bytes) Top hash of the Merkle tree built from all transactions.
* nTime unsigned int (4 bytes) Timestamp in UNIX-format of approximate block creation time.
* nBits unsigned int (4 bytes) Target T for the proof of work problem in compact format. Full target value is derived as: T = 0xh2h3h4h5h6h7 * 2 8*(0xh0h1-3)
* nNonce unsigned int (4 bytes) Nonce allowing variations for solving the proof of work problem.
*#vtx VarInt (1-9 bytes) Number of transaction entries in vtx.
* vtx[ ] Transaction (Variable) Vector of transactions.
Table 3.1. Block Structure
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
name::
* McsEngl.btcblk'part.HEADER (80B)@cptIt,
* McsEngl.btcblk'header@cptIt,
* McsEngl.btcblk-header@cptIt,
* McsEngl.btcblock-header@cptIt,
_DESCRIPTION:
Each block is composed of a header and a payload.
The header stores the current block header version (nVersion), a reference to the previous block (HashPrevBlock), the root node of the Merkle tree (HashMerkleRoot), a timestamp (nTime), a target value (nBits) and a nonce (nNonce).
Finally, the payload stores the number of transactions (#vtx ) and the vector of transactions (vtx ) included in the block.
Field name Type(Size) Description
1) nVersion int(4 bytes) Block format version (currently 2).
2) HashPrevBlock uint256(32 bytes) Hash of previous block header SHA256^2 (nV ersion|| . . . ||nNonce).
3) HashMerkleRoot uint256 (32 bytes) Top hash of the Merkle tree built from all transactions.
4) nTime unsigned int (4 bytes) Timestamp in UNIX-format of approximate block creation time.
5) nBits unsigned int (4 bytes) Target T for the proof of work problem in compact format. Full target value is derived as: T = 0xh2h3h4h5h6h7 * 2 8*(0xh0h1-3)
6) nNonce unsigned int (4 bytes) Nonce allowing variations for solving the proof of work problem.
*#vtx VarInt (1-9 bytes) Number of transaction entries in vtx.
* vtx[ ] Transaction (Variable) Vector of transactions.
Table 3.1. Block Structure
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
===
A data structure containing a previous block hash, a hash of a merkle tree of transactions, a timestamp, a *difficulty* and a *nonce*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
An 80-byte header belonging to a single block which is hashed repeatedly to create proof of work.
[https://bitcoin.org/en/glossary/block-header]
name::
* McsEngl.btcnVersion@cptIt,
_DESCRIPTION:
The version field stores the version number of the block format.
Ever since BIP0034 [5] is in place, the block format version is 2 and blocks of any other version are neither relayed nor mined.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
name::
* McsEngl.btcblk'HashPrevBlock@cptIt,
* McsEngl.btcHashPrevBlock@cptIt,
_DESCRIPTION:
This field stores the reference to the previous block, computed as a hash over the block
header as depicted in Fig. 3.1.
Figure 3.1. Block Reference Computation
A double-SHA256 hash is calculated over the concatenation of all elements in the previous
block header:
SHA2562 (nVersion||HashPrevBlock||HashMerkleRoot||nTime||nBits||nNonce) (4)
The reference functions as a chaining link in the blockchain. By including a reference
to the previous block, a chronological order on blocks, and thus transactions as well, is
imposed.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
name::
* McsEngl.btcblk'merkle-root@cptIt,
* McsEngl.btcHashMerkleRoot@cptIt,
* McsEngl.btcMerkle-root@cptIt,
_DESCRIPTION:
Merkle root:
Every transaction has a hash associated with it.
In a block, all of the transaction hashes in the block are themselves hashed (sometimes several times -- the exact process is complex), and the result is the Merkle root.
In other words, the Merkle root is the hash of all the hashes of all the transactions in the block.
The Merkle root is included in the block header.
With this scheme, it is possible to securely verify that a transaction has been accepted by the network (and get the number of confirmations) by downloading just the tiny block headers and Merkle tree -- downloading the entire block chain is unnecessary.
This feature is currently not used in Bitcoin, but it will be in the future.
[https://en.bitcoin.it/wiki/Vocabulary#Merkle_root]
===
Merkle Root
The root node of a merkle tree, a descendant of all the hashed pairs in the tree.
Block headers must include a valid merkle root descended from all transactions in that block.
[https://bitcoin.org/en/glossary/merkle-root]
===
This field stores the root of the Merkle hash tree.
It is used to provide integrity of all transactions included in the block and is computed according to the scheme described in Sect. 2.2.
The parameters used for computing the tree are double-SHA256#ql:sha_256d_cpt# as the hashing algorithm and raw transactions as the data blocks (see Table 3.2 and 3.4).
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
name::
* McsEngl.btcMerkle-tree@cptIt,
* McsEngl.Merkle-hash-tree-btcnet@cptIt,
* McsEngl.Merkle-tree-btcnet@cptIt,
_DESCRIPTION:
Merkle Tree
A tree constructed by hashing paired data (the leaves), then pairing and hashing the results until a single hash remains, the merkle root.
In Bitcoin, the leaves are almost always transactions from a single block.
[https://bitcoin.org/en/glossary/merkle-tree]
===
Merkle_Tree:
Merkle tree is an abstract data structure that organizes a list of data items in a tree of their hashes (like in Git, Mercurial or ZFS).
In Bitcoin the merkle tree is used only to organize transactions within a block (the block header contains only one hash of a tree) so that full nodes may prune fully spent transactions to save disk space.
*SPV#ql:btcSPV#* clients store only block headers and validate transactions if they are provided with a list of all intermediate hashes.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.bitcoin-timestamp@cptIt,
* McsEngl.btcnTime@cptIt,
* McsEngl.btcTimestamp@cptIt,
* McsElln.χρονοσφραγίδα@cptIt,
_DESCRIPTION:
The time field stores the timestamp in UNIX format denoting the approximate block creation time.
As the timestamp is a parameter included in block mining, it is fixed at the beginning of the process.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
===
UNIX timestamp is a standard representation of time as a number of seconds since January 1st 1970 GMT.
Usually stored in a 32-bit signed integer.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcnBits@cptIt,
* McsEngl.btctarget@cptIt,
* McsEngl.btctarget-threshold@cptIt,
==
====== lagoGreek:
* McsElln.στόχος-δυσκολίας-μπικόιν@cptIt,
_DESCRIPTION:
The target is the threshold below which a block header hash must be in order for the block to valid, and nBits is the encoded form of the target threshold as it appears in the block header.
[https://bitcoin.org/en/glossary/nbits]
_DESCRIPTION:
A 256-bit number that puts an upper limit for a block header hash to be valid.
The lower the target is, the higher the *difficulty* to find a valid hash.
The maximum (easiest) target is 0x00000000FFFF0000000000000000000000000000000000000000000000000000.
The difficulty and the target are adjusted every 2016 blocks (approx. 2 weeks) to keep interval between the blocks close to 10 minutes.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
The target is the threshold below which a block header hash must be in order for the block to valid, and nBits is the encoded form of the target threshold as it appears in the block header.
[https://bitcoin.org/en/glossary/nbits]
name::
* McsEngl.bitcoin-difficulty@cptIt,
* McsEngl.btcdifficulty@cptIt,
* McsEngl.btcNetwork-difficulty@cptIt,
====== lagoGreek:
* McsElln.δυσκολία-μπικόιν@cptIt,
_DESCRIPTION:
Difficulty is a measure of how difficult it is to find a new block compared to the easiest it can ever be.
By definition, it is a maximum *target#ql:btctarget#* divided by the current target.
Difficulty is used in two Bitcoin rules:
1) every block must be meet difficulty target to ensure 10 minute interval between blocks and
2) transactions are considered confirmed only when belonging to a *main chain* which is the one with the biggest cumulative difficulty of all blocks.
As of July 27, 2014 the difficulty is 18 736 441 558 and grows by 3-5% every two weeks.
See also *Target*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
The contents of the block are then hashed with an incrementing random number (called a “nonce”) until the resulting output contains a certain number of leading zeroes.
The network dynamically adjusts the requisite number of leading zeroes (or the “difficulty”) so that a block is mined every 10 minutes on average.
Because the results of hashing algorithms are unpredictable, finding a valid hash which the rest of the network will accept requires both luck and CPU power.
[https://media.consensys.net/time-sure-does-fly-ed4518792679#.rjkzhxgwo]
===
What is the formula for difficulty?
difficulty = difficulty_1_target / current_target
(target is a 256 bit number)
difficulty_1_target can be different for various ways to measure difficulty. Traditionally, it represents a hash where the leading 32 bits are zero and the rest are one (this is known as "pool difficulty" or "pdiff"). The Bitcoin protocol represents targets as a custom floating point type with limited precision; as a result, Bitcoin clients often approximate difficulty based on this (this is known as "bdiff").
[https://en.bitcoin.it/wiki/Difficulty#What_is_the_formula_for_difficulty.3F]
===
This number determines how difficult it is to hash a new block.
It is related to the maximum allowed number in a given numerical portion of a transaction block’s hash.
The lower the number, the more difficult it is to produce a hash value that fits it.
Difficulty varies based on the amount of computing power used by miners on the bitcoin network.
If large numbers of miners leave a network, the difficulty would decrease.
Thus far, however, bitcoin’s growing popularity has attracted more computing power to the network, meaning that the difficulty has increased.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.btcnNonce@cptIt,
* McsEngl.btcNonce@cptIt,
_DESCRIPTION:
Nonce:
Stands for "number used once".
A 32-bit number in a *block header* which is iterated during a search for proof-of-work.
Each time the nonce is changed, the *hash* of the block header is recalculated.
If nonce overflows before valid proof-of-work is found, an *extra nonce* is incremented and placed in the *coinbase* script.
Alternatively, one may change a merkle tree of transactions or a timestamp.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
Nonce:
A random string of data used as an input when hashing a transaction block.
A nonce is used to try and produce a digest that fits the numerical parameters set by the bitcoin difficulty.
A different nonce will be used with each hashing attempt, meaning that billions of nonces are generated when attempting to hash each transaction block.
[http://www.coindesk.com/information/bitcoin-glossary//]
===
The nonce field contains arbitrary data and is used as a source of randomness for solving the proof of work problem.
However, since it is fairly small in size with 4 bytes, it does not necessarily provide sufficient variation for finding a solution.
Therefore, other sources exist and will be addressed in more detail in Sect. 5.2.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
name::
* McsEngl.btcheader-chain@cptIt,
_DESCRIPTION:
A chain of block headers with each header linking to the header that preceded it; the most-difficult-to-recreate chain is the best header chain
[https://bitcoin.org/en/glossary/header-chain]
name::
* McsEngl.btcbest-header-chain@cptIt,
_DESCRIPTION:
A chain of block headers with each header linking to the header that preceded it; the most-difficult-to-recreate chain is the best header chain
[https://bitcoin.org/en/glossary/header-chain]
name::
* McsEngl.btcblk'part.PAYLOAD@cptIt,
* McsEngl.btcblk'payload@cptIt,
_DESCRIPTION:
Each block is composed of a header and a payload.
Finally, the payload stores
- the number of transactions (#vtx ) and
- the vector of transactions (vtx ) included in the block.
Field name Type(Size) Description
*#vtx VarInt (1-9 bytes) Number of transaction entries in vtx.
* vtx[ ] Transaction (Variable) Vector of transactions.
Table 3.1. Block Structure
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
name::
* McsEngl.btcblk'number-of-transaction-entries@cptIt,
name::
* McsEngl.btcblk'Height@cptIt,
* McsEngl.btcblk'height@cptIt,
* McsEngl.btcBlock-Chain-Height@cptIt,
* McsEngl.btcBlock-Height@cptIt,
* McsEngl.btcHeight@cptIt,
_DESCRIPTION:
The number of blocks preceding a particular block on a block chain.
For example, the genesis block has a height of zero because zero block preceded it.
[https://bitcoin.org/en/glossary/block-height]
===
Since multiple blocks can have the same height during a block chain fork, block height should not be used as a globally unique identifier.
Instead, blocks are usually referenced by the hash of their header (often with the byte order reversed, and in hexadecimal).
[https://bitcoin.org/en/developer-guide#block-height-and-forking]
===
Block-Height:
A sequence number of a block in the blockchain.
Height 0 refers to the-genesis-block#ql:idBtcblk0#.
Several blocks may share the same height (see *Orphan*), but only one of them belongs to the *main chain*.
Block height is used in Lock time#ql:idBtctxltm#.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcblk'Reward@cptIt,
* McsEngl.bitcoin-block-reward@cptIt,
* McsEngl.bitcoin-reward@cptIt,
* McsEngl.btcBlock-Reward@cptIt,
* McsEngl.btcBlock-Miner-Reward@cptIt,
* McsEngl.btcreward@cptIt,
_ADDRESS.WPG:
* http://www.bitcoinblockhalf.com//
_DESCRIPTION:
Together, the transaction fees#ql:idBtctxfee# and block subsidy#ql:idBtcblkrwdsbsd# are called 'defn.the-block-reward'.
A coinbase transaction is invalid if it tries to spend more value than is available from the block reward.
[https://bitcoin.org/en/developer-reference#serialized-blocks]
===
The amount that miners may claim as a reward for creating a block. Equal to the sum of the block subsidy (newly available satoshis) plus the transactions fees paid by transactions included in the block.
[https://bitcoin.org/en/glossary/block-reward]
===
Bitcoin Block Reward Halving Countdown
Reward-Drop ETA date: 11 Jul 2016 22:03:04
The Bitcoin block mining reward halves every 210,000 blocks, the coin reward will decrease from 25 to 12.5 coins.
Total Bitcoins in circulation: 15,443,050
Total Bitcoins to ever be produced: 21,000,000
Percentage of total Bitcoins mined: 73.54%
Total Bitcoins left to mine: 5,556,950
Total Bitcoins left to mine until next blockhalf: 306,950
Bitcoin price (USD): $431.25
Market capitilzation (USD): $6,659,815,312.50
Bitcoins generated per day: 3,600
Bitcoin inflation rate per annum: 8.88%
Bitcoin inflation rate per annum at next block halving event: 4.09%
Bitcoin inflation per day (USD): $1,552,500
Bitcoin inflation until next blockhalf event based on current price (USD): $132,372,188
Total blocks: 407,722
Blocks until mining reward is halved: 12,278
Approximate block generation time: 10.00 minutes
Approximate blocks generated per day: 144
Difficulty: 178,678,307,672
Hash rate: 1.39 Exahashes/s
[http://www.bitcoinblockhalf.com//] {2016-04-17}
===
The reward given to a miner which has successfully hashed a transaction block.
This can be a mixture of coins and transaction fees, depending on the policy used by the cryptocurrency in question, and whether all of the coins have already been successfully mined.
Bitcoin currently awards 25 bitcoins for each block.
The block reward halves when a certain number of blocks have been mined.
In bitcoin’s case, the threshold is every 210,000 blocks.
[http://www.coindesk.com/information/bitcoin-glossary//]
===
Reward:
Amount of newly generated bitcoins that a *miner* may claim in a new block.
The first transaction in the block allows miner to claim currently allowed reward as well as all *transaction fees* from all transactions in the block.
Reward is *halved* every 210 000 blocks, approximately every 4 years.
As of July 27, 2014 the reward is 25 BTC (the first halving occurred in December 2012).
For security reasons, rewards cannot be *spent* before 100 blocks built on top of the current block.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcblkrwd'Subsidy@cptIt,
* McsEngl.btcblk'subsidy@cptIt,
* McsEngl.btcBlock-subsidy@cptIt,
_DESCRIPTION:
All blocks with a block height less than 6,930,000 are entitled to receive a block subsidy of newly created bitcoin value, which also should be spent in the coinbase transaction. (The block subsidy started at 50 bitcoins and is being halved every 210,000 blocks—approximately once every four years. As of November 2014, it’s 25 bitcoins.)
Together, the transaction fees and block subsidy are called the block reward.
A coinbase transaction is invalid if it tries to spend more value than is available from the block reward.
[https://bitcoin.org/en/developer-reference#serialized-blocks]
name::
* McsEngl.btcblkrwd'Halving@cptIt,
* McsEngl.bitcoin-reward-halving@cptIt,
* McsEngl.btchalving@cptIt,
_DESCRIPTION:
Halving:
Refers to reducing *reward* every 210 000 blocks (approximately every 4 years).
Since the *genesis block* to a block 209999 in December 2012 the reward was 50 BTC.
Till 2016 it will be 25 BTC, then 12.5 BTC and so on till 1 *satoshi* around 2140 after which point no more bitcoins will ever be created.
Due to reward halving, the total supply of bitcoins is limited: only about 2100 trillion *satoshis* will ever be created.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcblkrwd.VIRGIN-BITCOIN@cptIt,
* McsEngl.btcvirgin-bitcoin@cptIt,
_DESCRIPTION:
Virgin bitcoin
The reward for generating a block that has not yet been spent, a state which might increase the ability to transact anonymously.
[https://en.bitcoin.it/wiki/Vocabulary#Virgin_bitcoin]
name::
* McsEngl.btcblk'Hash@cptIt,
* McsEngl.bitcoin-block-hash@cptIt,
* McsEngl.bitcoin-hash-of-block@cptIt,
* McsEngl.btchash-of-block@cptIt,
name::
* McsEngl.bitcoin-checkpoint@cptIt,
* McsEngl.btccheckpoin@cptIt,
_DESCRIPTION:
Checkpoint:
A hash of a block before which the *BitcoinQT* client downloads blocks without verifying digital signatures for performance reasons.
A checkpoint usually refers to a very deep block (at least several days old) when it's clear to everyone that that block is accepted by the overwhelming majority of users and *reorganization* will not happen past that point.
It also helps protecting most of the history from a *51% attack*.
Since checkpoints affect how the *main chain* is determined, they are part of the protocol and must be recognized by alternative clients (although, the risk of reorganization past the checkpoint would be incredibly low).
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcblk'Size@cptIt,
This isn’t the first time bitcoin community members attempted to change the block size limit. Originally, there was no block size limit. The current limit was introduced early on to protect the system against “spam transactions.” At the time, it wasn’t a big deal since few people were using bitcoin. The one megabyte limit was like a 500 MPH speed limit. It was completely non-binding. But the system has grown a lot since then. Although it’s not yet bumping up against the hard constraint—it averaged around 117,500 transactions per day over the last month—many believe the block size limit will become binding in the very near future.
...
There’s a related concern that bigger block sizes will require more bandwidth, which would preclude some smaller players from competing in the mining race. Opponents claim this, too, would result in a more centralized system.
[http://www.forbes.com/sites/realspin/2015/09/08/new-bitcoin-development-spurs-unnecessary-fear-of-centralization/]
BitPay Supports Increase in Bitcoin Block Size Limit
Posted on August 23, 2015Author Gautham
BitPay Supports Increase in Bitcoin Block Size Limit.
BitPay, the largest bitcoin payment processor has sided with Gavin Andresen’s court by showing its support towards incorporation of BIP 101. In other words, BitPay in one of their blog posts mentioned that the company supports the move to increase bitcoin block size from 1 MB to 8 MB (which is known as BIP 101).
Bitcoin XT has been a topic of serious debate among the bitcoin community for a while now. The debate has ranged ever since Gavin Andresen, the Chief Scientist at Bitcoin Foundation and Mike Hearn proposed Bitcoin XT a few months ago.
The Bitcoin XT proposal was later changed to incorporate a few changes after receiving inputs from members of the bitcoin community. While there are few who are in favor of a 7MB increase in the bitcoin block size, there are others who are opposed to this idea. The bitcoin block size limit is currently 1 MB, which Bitcoin XT proposed to change to 8 MB. Gavin Andresen and Mike Hearn finally launched a Bitcoin XT fork few days ago. The launch didn’t go will with many bitcoin based entities who are also part of the club.
The bitcoin network has experienced rapid growth since its inception in 2009. At the current rate of growth, the bitcoin network with 1 MB block size limit will be left obsolete by 2017.
BitPay has put forward a sensible argument as to why BIP 101 has to be incorporated while expressing its support towards its integration into bitcoin core client. Contrary to the opinions of a few people, BitPay believes that the integration of BIP 101 will not compromise the integrity of the Bitcoin network. BIP 101 will instead protect the decentralized nature of the bitcoin network. BitPay sees the current argument against integration of BIP 101 to be favoring a centralized group of developers, which if continued will compromise the decentralized nature of the bitcoin network. Increased block size limit will prevent big mining companies from running a full bitcoin node, thereby preserving the decentralized nature of bitcoin.
To summarize in the words of Stephen Pair, the CEO and co-founder of BitPay — BIP 101 will safeguard bitcoin’s decentralized nature while providing reliable, immediate path towards greater network throughput and BitPay supports merging BIP 101 into Bitcoin Core.
[http://www.newsbtc.com/2015/08/23/bitpay-supports-increase-in-bitcoin-block-size-limit/]
A spat between developers may split the digital currency
The project approaches a "fork" in the road
Aug 18th 2015 | Business and finance
"FEDERAL Reserve deeply split. Renegade group of board members to create separate American dollar.” Such a headline seems highly unlikely, but this in essence is happening in the land of bitcoin, the digital currency. On August 15th two of bitcoin’s five main developers released a competing version, or “fork”, of the software that powers the currency—a move, some fear, that may split bitcoin.
The dispute is predictably arcane. The bone of contention is the size of a “block”, a batch of bitcoin transactions into which these are assembled before they are processed. Satoshi Nakamoto, the elusive creator of bitcoin who went offline in 2011, limited their size to 1Mb. That is enough to handle about 300,000 transactions per day—suitable for a currency used mainly by crypto-geeks, as bitcoin once was, but nowhere near enough to rival conventional payment systems. The likes of Visa and MasterCard can process tens of thousands of payments per second if needed.
Related topics
Bitcoins
By how much and when to increase this limit has long been a matter of a heated debate within the bitcoin community. One camp wants to set the number much higher and do it soon. Otherwise, they argue, the system could crash as it runs out of capacity as early as next year. Transactions could take hours to confirm and fees could rocket, warns Mike Hearn, a leading bitcoin developer. “Bitcoin would survive,” he wrote in a blog post in May, “but it would have lost critical momentum.”
The other side, led by the other three main bitcoin developers, frets that increasing the block size hastily would lead to centralisation and turn bitcoin into more of a conventional payment system. This matters to bitcoin purists, who laud the currency’s decentralised approach of running a currency. The system currently relies on thousands of independent “nodes”, computers spread across the world that check whether blocks of transactions are valid and keep tabs on who owns which bitcoins. Increasing the size of these blocks would make the system so unwieldy as to dissuade nodes from participating, so hastening a worrying recent decline in participants.
How Bitcoin works
The dispute is as ideological as it is technical. The bitcoin community has a process to settle such controversies, but it is by design slow and produces decisions only when everybody is happy. Frustrated that the discussion has kept dragging on, Mr Hearn and Gavin Andresen, one of the dissenting developers, decided to press the issue by organising a referendum of sorts: they have called on “miners”, specialised nodes that assemble the blocks and mint new bitcoin, to install their new version, called “Bitcoin XT”.
Once at least 75% of the blocks are processed by Bitcoin XT, but no earlier than January, it will upgrade to a block size of a maximum of 8Mb (and double that limit every two years). The nodes that then still run the old “Bitcoin Core” software would find themselves excluded from the system.
Predictably, the move has increased the temperature of the debate. On discussion sites such as Reddit, moderators have censored mentions of Bitcoin XT because they see it as an effort to undermine the bitcoin community. Comments purportedly made by Mr Nakamoto warning that a fork would lead him to “declare bitcoin a failed project” have been widely dismissed as a hoax.
Despite all the sound and fury, such an outcome is still unlikely. Like spatting doves and hawks at an old-fashioned central bank, the two sides will probably agree on some compromise; two fun-sounding “Bitcoin Scalability Workshops” have been scheduled for later this year.
Even if miners get to make the decision, this would probably not lead to a bitcoin split. Once it becomes clear which version is likely to prevail, all miners will have an incentive to jump on the winning bandwagon. Already, 8% of them have joined the dissident XT faction, a rapid take-up. Whether such a majority rule is the best way to run the highly complex bitcoin system, however, is an entirely different question.
[http://www.economist.com/news/business-and-finance/21661404-spat-between-developers-may-split-digital-currency-forking-hell]
name::
* McsEngl.btcblk'Depth@cptIt,
* McsEngl.btcdepth-of-block@cptIt,
_DESCRIPTION:
Depth:
Depth refers to a place in the blockchain.
A transaction with 6 *confirmations* can also be called "6 blocks deep".
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcblk'Blocktime@cptIt,
* McsEngl.bitcoin-block-interval@cptIt,
_DESCRIPTION:
For reasons of stability and low latency in transactions, the network tries to produce one block every 10 minutes.
[https://en.bitcoin.it/wiki/Target]
name::
* McsEngl.btcblk'validation-rule@cptIt,
* McsEngl.btcconsensus-rule@cptIt,
* McsEngl.btcconsensus-rules@cptIt,
* McsEngl.btcvalidation-rule@cptIt,
_DESCRIPTION:
The block validation rules that full nodes follow to stay in consensus with other nodes.
[https://bitcoin.org/en/glossary/consensus-rules]
name::
* McsEngl.btcblk'Explorer@cptIt,
* McsEngl.bitcoin-block-explorer@cptIt,
* McsEngl.btcblk'explorer@cptIt,
* McsEngl.btcnet'explorer@cptIt,
* McsEngl.btcblkexr@cptIt,
* McsEngl.btcblock-explorer@cptIt,
_SPECIFIC:
* https://blockexplorer.com//
* https://blockchain.info/block-height/0,
* https://blockchain.info/address/3LpiaPt5To7876GRm3W4hGoZ6npr8cDwYG,
name::
* McsEngl.btcblk'Resource@cptIt,
_ADDRESS.WPG:
* https://blockexplorer.com/block/0000000000000000015d91f146e17f2bee451d90ecde7d3649b5b6678a1f715f,
name::
* McsEngl.btcblk'DOING@cptIt,
name::
* McsEngl.btcblk'Creating@cptIt,
* McsEngl.bitcoin-block-creation@cptIt,
* McsEngl.bitcoin-hashing-a-block@cptIt,
* McsEngl.bitcoin-to-hash-a-block@cptIt,
name::
* McsEngl.btcblk'Reorganization@cptIt,
* McsEngl.bitcoin-reorganization@cptIt,
* McsEngl.btcreorg@cptIt,
* McsEngl.btcreorganization@cptIt,
_DESCRIPTION:
Reorg, Reorganization:
An event in the *node* when one or more blocks in the *main chain* become *orphaned*.
Usually, newly received blocks are extending existing main chain.
Sometimes (4-6 times a week) a couple of blocks of the same *height* are produced almost simultaneously and for a short period of time some nodes may see one block as a tip of the main chain which will be eventually replaced by a more difficult block(s).
Each transaction in the orphaned blocks either becomes invalid (if already included in the main chain block) or becomes *unconfirmed* and moved to the *mempool#ql:btcmempool#*.
In case of a major bug or a *51% attack*, reorganization may involve reorganizing more than one block.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
Reorganize
A block chain reorganize (or reorg) happens when one chain becomes longer than the one you are currently working on.
All of the blocks in the old chain that are not in the new one become orphan blocks, and their generations are invalidated.
Transactions that use the newly-invalid generated coins also become invalid, though this is only possible in large chain splits because generations can't be spent for 100 blocks.
The number of confirmations for transactions may change after a reorg, and transactions that are not in the new chain will become "0/unconfirmed" again.
If a transaction in the old chain conflicts with one in the new chain (as a result of double-spending), the old one becomes invalid.
[https://en.bitcoin.it/wiki/Vocabulary#Reorganize]
name::
* McsEngl.btcblk'doing.CREATING@cptIt,
* McsEngl.btcblk'adding@cptIt,
* McsEngl.btcblk'creating@cptIt,
* McsEngl.btcblk'processing@cptIt,
* McsEngl.btcmining@cptIt,
_DESCRIPTION:
Mining:
The act of generating new bitcoins by solving cryptographic problems using computing hardware.
[http://www.coindesk.com/information/bitcoin-glossary//]
===
Mining adds new blocks to the block chain, making transaction history hard to modify.
[https://bitcoin.org/en/developer-guide#mining]
===
Central to Bitcoin’s architecture is a public ledger called the blockchain, which stores all processed transactions in chronological order.
Transactions are processed by a loosely organized network of miners in a process called mining (see Sect. 5.2).
In it the miner creates a block with a set of unprocessed transactions and attempts to solve a proof of work puzzle (see Sect. 2.1).
Once a valid solution has been found, the block including the solution is published throughout the network and accepted into the blockchain.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
===
Mining:
A process of finding valid *hashes* of a block header by iterating millions of variants of block headers (using *nonce* and *extra nonce*) in order to find a hash lower than the *target* (see also *difficulty*).
The process needs to determine a single global history of all transactions (grouped in blocks).
Mining consumes time and electricity and nowadays the difficulty is so big, that energy-wise it's not even profitable to mine using video graphics cards.
Mining is paid for by *transaction fees* and by block *rewards* (newly generated coins, hence the term "mining").
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
_DOING:
As described in [9], mining nodes perform the following
steps in an endless loop:
1) Collect all broadcasted transactions and validate whether they satisfy the miner’s
self-defined policy. Typically, a transaction includes a transaction fee that functions
as an incentive for the miner to include it in the block. However, if it does
not, then it is up to the miner to decide whether or not to include it.
2) Verify all transactions that are to be included in the block. Transactions are
verified as described in Sect. 4.2 and it is checked whether their inputs have been
previously spent.
3) Select the most recent block on the longest path in the blockchain, i.e. the path
that involves most accumulated computational effort, and insert the hash of the
block header into the new block.
4) Solve the proof of work problem as described below and broadcast the solution.
Should another node solve the proof of work problem before, then the block is
first validated, meaning the proof of work solution is checked and all transactions
included in the block are verified. If it passes these controls then the cycle is
repeated. Note that if there are transactions that have not been included in the
new block then they are saved and included in the next cycle.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
name::
* McsEngl.btcmining'Mining-pool@cptIt,
* McsEngl.bitcoin-mining-pool@cptIt,
* McsEngl.btcmining-pool@cptIt,
* McsElln.ομάδα-εξόρυξης-μπιτκόιν@cptIt,
_DESCRIPTION:
Mining_Pool:
A service that allows separate owners of mining hardware to split the reward proportionally to submitted work.
Since probability of finding a valid block hash is proportional to miner's *hashrate*, small individual miners may work for months before finding a big per-block reward.
Mining pools allow more steady stream of smaller income.
Pool owner determines the block contents and distributes ranges of *nonce* values between its workers.
Normally, mining pools are centralized.
P2Pool is a fully decentralized pool.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
Pool:
A collection of mining clients which collectively mine a block, and then split the reward between them.
Mining pools are a useful way to increase your probability of successfully mining a block as the difficulty rises.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.btcmining.POOLED@cptIt,
* McsEngl.btcpooled-mining@cptIt,
_DESCRIPTION:
Pooled mining, where the miner pools resources with other miners to find blocks more often, with the proceeds being shared among the pool miners in rough correlation to the amount of hashing power they each contributed, allowing the miner to receive small payments with a lower variance (shorter time between payments).
[https://bitcoin.org/en/developer-guide#mining]
name::
* McsEngl.btcmining.SOLO@cptIt,
* McsEngl.btcsolo-mining@cptIt,
_DESCRIPTION:
Solo mining, where the miner attempts to generate new blocks on his own, with the proceeds from the block reward and transaction fees going entirely to himself, allowing him to receive large payments with a higher variance (longer time between payments)
[https://bitcoin.org/en/developer-guide#mining]
name::
* McsEngl.btcblk.EXAMPLE@cptIt,
_EXAMPLE:
An example header in hex (2-hex-digits = 1 byte, (ff)16=(11111111)2=(255)10):
02000000 ............................................ Block version: 2
b6ff0b1b1680a2862a30ca44d346d9e8
910d334beb48ca0c0000000000000000 ... Hash of previous block's header
9d10aa52ee949386ca9385695f04ede2
70dda20810decd12bc9b048aaab31471 ... Merkle root
24d95a54 ............................................. Unix time: 1415239972
30c31b18 ............................................. Target: 0x1bc330 * 256**(0x18-3)
fe9f0864 ............................................... Nonce
name::
* McsEngl.btcblk.GENESIS (btcblk0)@cptIt,
* McsEngl.Bitcoin-genesis-block@cptIt,
* McsEngl.btcblk.genesis@cptIt,
* McsEngl.btcGenesis-Block@cptIt,
* McsEngl.btcBlock-0@cptIt,
_DESCRIPTION:
Genesis block
A genesis block is the first block of a block chain.
Modern versions of Bitcoin assign it block number 0, though older versions gave it number 1.
The genesis block is almost always hardcoded into the software.
It is a special case in that it does not reference a previous block, and for Bitcoin and almost all of its derivatives, it produces an unspendable subsidy#ql:btcblk'subsidy#.
[https://en.bitcoin.it/wiki/Genesis_block]
===
Genesis_Block:
A very first block in the blockchain with hard-coded contents and a all-zero reference to a previous block.
Genesis block was released on 3rd of January 2009 with a newspaper quote in its coinbase#ql:idBtctxinpcnbs#:
"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" as a proof that there are no secretly pre-mined blocks to overtake the blockchain in the future.
The message ironically refers to a reason for Bitcoin existence: a constant inflation of money supply by governments and banks.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
Block Height 0 Blocks at depth 0 in the bitcoin blockchain
Summary
Height 0 (Main chain)
Hash 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
Previous Block 0000000000000000000000000000000000000000000000000000000000000000
Next Blocks 00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048
Time 2009-01-03 18:15:05
Difficulty 1
Bits 486604799
Number Of Transactions 1
Output Total 50 BTC
Estimated Transaction Volume 0 BTC
Size 0.285 KB
Version 1
Merkle Root 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
Nonce 2083236893
Block Reward 50 BTC
Transaction Fees 0 BTC
[https://blockchain.info/block-height/0]
name::
* McsEngl.btcblk.BLOCK1 (btcblk1)@cptIt,
* McsEngl.btcblk1@cptIt,
* McsEngl.btcBlock-1@cptIt,
_DESCRIPTION:
Block Height 1 Blocks at depth 1 in the bitcoin blockchain
Summary
Height 1 (Main chain)
Hash 00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048
Previous Block 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
Next Blocks 000000006a625f06636b8bb6ac7b960a8d03705d1ace08b1a19da3fdcc99ddbd
Time 2009-01-09 02:54:25
Difficulty 1
Bits 486604799
Number Of Transactions 1
Output Total 50 BTC
Estimated Transaction Volume 0 BTC
Size 0.215 KB
Version 1
Merkle Root 0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098
Nonce 2573394689
Block Reward 50 BTC
Transaction Fees 0 BTC
[https://blockchain.info/block-height/1]
name::
* McsEngl.btcblk.ORPHAN@cptIt,
* McsEngl.btcorphan-Block@cptIt,
* McsEngl.btcOrphan@cptIt,
* McsEngl.btcOrphaned-block@cptIt,
_DESCRIPTION:
Orphan Block
An orphan block is a block which has no known parent in the currently-longest block chain.
Not to be confused with a Stale Block (which has a known parent, but is no longer part of the longest chain).
[https://en.bitcoin.it/wiki/Vocabulary#Orphan_Block]
===
Orphan_block:
A block which is not a part of the valid blockchain, but which was instead part of a fork that was discarded.
[http://www.coindesk.com/information/bitcoin-glossary//]
===
Orphan block (a block whose previous (parent) hash field points to an unknown block, meaning the orphan can’t be validated)
[https://bitcoin.org/en/glossary/stale-block]
===
A valid block that is no longer a part of a *main chain*.
Usually happens when two or more blocks of the same *height* are produced at the same time.
When one of them becomes a part of the main chain, others are considered "orphaned".
Orphans also may happen when the blockchain is *forked* due to an attack (see *51% attack*) or a bug.
Then a chain of several blocks may become abandoned.
Usually a transaction is included in all blocks of the same height, so its *confirmation* is not delayed and there is no *double spend*. See also *Fork*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcblk.RAW@cptIt,
* McsEngl.btcBinary-block@cptIt,
* McsEngl.btcRaw-block@cptIt,
* McsEngl.btcSerialized-block@cptIt,
_DESCRIPTION:
A complete block in its binary format—the same format used to calculate total block byte size; often represented using hexadecimal.
[https://bitcoin.org/en/glossary/serialized-block]
name::
* McsEngl.btcblk.STALE@cptIt,
* McsEngl.btcStale-block@cptIt,
_DESCRIPTION:
Blocks which were successfully mined but which aren’t included on the current best block chain, likely because some other block at the same height had its chain extended first.
Not To Be Confused With Orphan block (a block whose previous (parent) hash field points to an unknown block, meaning the orphan can’t be validated)
[https://bitcoin.org/en/glossary/stale-block]
===
Stale:
When a bitcoin block is successfully hashed, any others attempting to hash it may as well stop, because it is now ‘stale'.
They would simply be repeating work that someone else has already done, for no reward.
The term is also used in mining pools to describe a share of a hashing job that has already been completed.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.btcblk.VALID@cptIt,
* McsEngl.btcvalid-block@cptIt,
name::
* McsEngl.btcbcn'Block-explorer@cptIt,
_ADDRESS.WPG:
* https://blockchain.info//
* BlockH0 https://blockchain.info/block-height/0,
* https://blockexplorer.com//
name::
* McsEngl.bitcoin-block-explorer@cptIt,
* McsEngl.bitcoin-browser@cptIt,
* McsEngl.btcblock-explorer@cptIt,
* McsEngl.btcbrowser@cptIt,
_DESCRIPTION:
A block chain browser (also called "block explorer") is a program or web site that lets users search and navigate a block chain. Uses include:
checking address balances
tracking coin transfer histories
watching for transaction acceptance
monitoring the network hash rate and other statistics
Block chain browsers typically provide:
a list of a chain's recent blocks
transactions in a given block
links to the previous and next transaction involving each input and output
a list of all transactions involving a given address
current and historical address balances
a way to search for blocks, transactions, and addresses
[https://en.bitcoin.it/wiki/Block_chain_browser]
name::
* McsEngl.btcbcn'Consensus-algorithm@cptIt,
* McsEngl.bitcoin-consensus-algorithm@cptIt,
* McsEngl.btcconsensus-algorithm@cptIt,
_DESCRIPTION:
The algorithm for checking if a block is valid, expressed in this paradigm, is as follows:
Check if the previous block referenced by the block exists and is valid.
Check that the timestamp of the block is greater than that of the previous block[2] and less than 2 hours into the future
Check that the proof of work on the block is valid.
Let S[0] be the state at the end of the previous block.
Suppose TX is the block's transaction list with n transactions. For all i in 0...n-1, set S[i+1] = APPLY(S[i],TX[i]) If any application returns an error, exit and return false.
Return true, and register S[n] as the state at the end of this block.
Essentially, each transaction in the block must provide a valid state transition from what was the canonical state before the transaction was executed to some new state. Note that the state is not encoded in the block in any way; it is purely an abstraction to be remembered by the validating node and can only be (securely) computed for any block by starting from the genesis state and sequentially applying every transaction in every block. Additionally, note that the order in which the miner includes transactions into the block matters; if there are two transactions A and B in a block such that B spends a UTXO created by A, then the block will be valid if A comes before B but not otherwise.
The one validity condition present in the above list that is not found in other systems is the requirement for "proof of work". The precise condition is that the double-SHA256 hash of every block, treated as a 256-bit number, must be less than a dynamically adjusted target, which as of the time of this writing is approximately 2187. The purpose of this is to make block creation computationally "hard", thereby preventing sybil attackers from remaking the entire blockchain in their favor. Because SHA256 is designed to be a completely unpredictable pseudorandom function, the only way to create a valid block is simply trial and error, repeatedly incrementing the nonce and seeing if the new hash matches.
At the current target of ~2187, the network must make an average of ~269 tries before a valid block is found; in general, the target is recalibrated by the network every 2016 blocks so that on average a new block is produced by some node in the network every ten minutes. In order to compensate miners for this computational work, the miner of every block is entitled to include a transaction giving themselves 25 BTC out of nowhere. Additionally, if any transaction has a higher total denomination in its inputs than in its outputs, the difference also goes to the miner as a "transaction fee". Incidentally, this is also the only mechanism by which BTC are issued; the genesis state contained no coins at all.
In order to better understand the purpose of mining, let us examine what happens in the event of a malicious attacker. Since Bitcoin's underlying cryptography is known to be secure, the attacker will target the one part of the Bitcoin system that is not protected by cryptography directly: the order of transactions. The attacker's strategy is simple:
Send 100 BTC to a merchant in exchange for some product (preferably a rapid-delivery digital good)
Wait for the delivery of the product
Produce another transaction sending the same 100 BTC to himself
Try to convince the network that his transaction to himself was the one that came first.
Once step (1) has taken place, after a few minutes some miner will include the transaction in a block, say block number 270000. After about one hour, five more blocks will have been added to the chain after that block, with each of those blocks indirectly pointing to the transaction and thus "confirming" it. At this point, the merchant will accept the payment as finalized and deliver the product; since we are assuming this is a digital good, delivery is instant. Now, the attacker creates another transaction sending the 100 BTC to himself. If the attacker simply releases it into the wild, the transaction will not be processed; miners will attempt to run APPLY(S,TX) and notice that TX consumes a UTXO which is no longer in the state. So instead, the attacker creates a "fork" of the blockchain, starting by mining another version of block 270000 pointing to the same block 269999 as a parent but with the new transaction in place of the old one. Because the block data is different, this requires redoing the proof of work. Furthermore, the attacker's new version of block 270000 has a different hash, so the original blocks 270001 to 270005 do not "point" to it; thus, the original chain and the attacker's new chain are completely separate. The rule is that in a fork the longest blockchain is taken to be the truth, and so legitimate miners will work on the 270005 chain while the attacker alone is working on the 270000 chain. In order for the attacker to make his blockchain the longest, he would need to have more computational power than the rest of the network combined in order to catch up (hence, "51% attack").
[https://github.com/ethereum/wiki/wiki/White-Paper]
_DESCRIPTION:
A proof of work is a cryptographic puzzle used to ensure that a party has performed a certain amount of work.
In particular, the Bitcoin mining process (see Sect. 5.2) incorporates a proof of work system based on Adam Back’s Hashcash [3].
It has two basic properties - firstly, it ensures that the party providing the proof of work has invested a predefined amount of effort in order to create the proof and secondly, that the proof is efficiently verifiable.
Typically, finding a solution to a proof of work puzzle is a probabilistic process with a success probability depending on the predefined difficulty.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
name::
* McsEngl.btcbcn'consensus-rule@cptIt,
* McsEngl.btcconsensus-rule@cptIt,
* McsEngl.btcconsensus-rules@cptIt,
* McsEngl.btcvalidation-rule@cptIt,
_DESCRIPTION:
The block validation rules that full nodes follow to stay in consensus with other nodes.
[https://bitcoin.org/en/glossary/consensus-rules]
_SPECIFIC:
* current-consensus-rules,
* previous-consensus-rules,
name::
* McsEngl.btcbcncsa'Proof-of-work (PoW)@cptIt,
* McsEngl.btcPOW@cptIt,
* McsEngl.btcproof-of-work@cptIt,
* McsEngl.btcnet'proof-of-work@cptIt,
_DESCRIPTION:
A-hash#ql:idBtchsh256# below a-target-value#ql:btctarget_threshold# which can only be obtained, on average, by performing a certain amount of brute force work—therefore demonstrating proof of work.
[https://bitcoin.org/en/glossary/proof-of-work]
_DESCRIPTION:
Proof_of_Work_(PoW):
A number that is provably hard to compute.
That is, it takes measurable amount of time and/or computational power (energy) to produce.
In Bitcoin it is a-hash#ql:idBtchsh256# of a block header#ql:idBtcblkhdr#.
A block is considered valid only if its hash is lower than the current *target* (roughly, starts with a certain amount of zero bits). Each block refers to a previous block thus accumulating previous proof-of-work and forming a *blockchain*.
Proof-of-work is not the only requirement, but an important one to make sure that it is economically infeasible to produce an alternative history of transactions with the same accumulated work. Each client can independently consider the most difficult chain of valid blocks as the "true" history of transactions, without need to trust any source that provides the blocks.
Note that owning a very large amount of computational power does not override other rules enforced by every client. Ill-formed blocks or blocks containing invalid transactions are rejected no matter how difficult they were to produce.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
_DESCRIPTION:
A proof of work is a piece of data which was difficult (costly, time-consuming) to produce so as to satisfy certain requirements. It must be trivial to check whether data satisfies said requirements. Producing a proof of work can be a random process with low probability, so that a lot of trial and error is required on average before a valid proof of work is generated. Bitcoin uses the Hashcash proof of work.
One application of this idea is using hashcash as a method to preventing email spam, requiring a proof of work on the email's contents (including the To address), on every email. Legitimate emails will be able to do the work to generate the proof easily (not much work is required for a single email), but mass spam emailers will have difficulty generating the required proofs (which would require huge computational resources).
Hashcash proofs of work are used in Bitcoin for block generation. Proofs of work that are tied to the data of each block are required for the blocks to be accepted. The difficulty of this work is adjusted so as to limit the rate at which new blocks can be generated by the network to one every 10 minutes. Due to the very low probability of successful generation, this makes it unpredictable which worker computer in the network will be able to generate the next block.
For a block to be valid it must hash to a value less than the current target; this means that each block indicates that work has been done generating it. Each block contains the hash of the preceding block, thus each block has a chain of blocks that together contain a large amount of work. Changing a block (which can only be done by making a new block containing the same predecessor) requires regenerating all successors and redoing the work they contain. This protects the block chain from tampering.
The most widely used proof-of-work scheme is SHA-256, which was introduced by Bitcoin. Some other hashing algorithms that are used for proof-of-work include scrypt, Blake-256, CryptoNight,[1] HEFTY1, Quark, SHA-3, scrypt-jane, scrypt-n, and combinations.
[https://en.bitcoin.it/wiki/Proof_of_work]
name::
* McsEngl.btcbcn'Address (btcads)@cptIt,
* McsEngl.bitcoin-address@cptIt,
* McsEngl.btcaddress@cptIt,
* McsEngl.btcads@cptIt,
* McsEngl.btcnet'address@cptIt,
* McsEngl.btcpayment-address@cptIt,
* McsElln.διεύθυνση-Bitcoin@cptIt,
_DESCRIPTION:
Bitcoin-address is THE-PUBLIC-NAME of some-bitcoin-tokens#ql:idBtccet#[1].
Looks like 3EtZT5fEQ9Atf73UMnyRUXsbWqcNeQ6rXy.
The-owner of these[1] bitcoins has a-sectret-private-key#ql:idBtcprk# with which s|he can-spent these[1] bitcoin-tokens.
Wallets#ql:idBtcwlt# manage the-addresses and its corresponding private-keys.
Anyone who owns bitcoin-tokens can-send bitcoin-tokens to any address.
[hmnSngo.2017-04-09]
_DESCRIPTION:
A bitcoin address looks like 1DSrfJdB2AnWaFNgSbv3MZC2m74996JafV.
It consists of a string of letters and numbers.
It’s really an encoded base58check version of a public key 160-bit-hash#ql:idBtcadsh160#.
Just like you ask others to send an email to your email address, you would ask others to send you bitcoins to one of your bitcoin addresses.
[https://github.com/bitcoinbook/bitcoinbook/blob/develop/glossary.asciidoc]
_DESCRIPTION:
Bob provides the pubkey hash to Alice.
Pubkey hashes are almost always sent encoded as Bitcoin addresses, which are base58-encoded strings containing an address version number, the hash, and an error-detection checksum to catch typos.
The address can be transmitted through any medium, including one-way mediums which prevent the spender from communicating with the receiver, and it can be further encoded into another format, such as a QR code containing a bitcoin: URI.
[https://bitcoin.org/en/developer-guide#transactions]
_DESCRIPTION:
Bitcoin address is a-Base58Check#ql:idBtcb58c# representation of a-Hash160#ql:idBtcadsh160# of a *public key* with a version byte 0x00 which maps to a prefix "1".
Typically represented as text (ex. 1CBtcGivXmHQ8ZqdPgeMfcpQNJrqTrSAcG) or as a QR code.
A more recent variant of an address is a *P2SH* address: a hash of a spending script with a version byte 0x05 which maps to a prefix "3" (ex. 3NukJ6fYZJ5Kk8bPjycAnruZkE5Q7UW7i8).
Another variant of an address is not a hash, but a raw private key representation (e.g. 5KQntKuhYWSRXNqp2yhdXzjekYAR7US3MT1715Mbv5CyUKV6hVe). It is rarely used, only for importing/exporting private keys or printing them on *paper wallets*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
_DESCRIPTION:
A bitcoin address is used to receive and send transactions on the bitcoin network.
It contains a string of alphanumeric characters, but can also be represented as a scannable QR code.
A bitcoin address is also the public key in the pair of keys used by bitcoin holders to digitally sign transactions (see Public key).
[http://www.coindesk.com/information/bitcoin-glossary//]
_DESCRIPTION:
addresses (hashed public keys)
[https://bitcoin.org/en/developer-guide#transaction-fees-and-change]
_DESCRIPTION:
To each Bitcoin wallet is associated one or many matching pairs of a Bitcoin address and a private key (they consist of a string of numbers and letters).
The Bitcoin address is someone’s identification in the network, and each address is associated with a balance of funds denominated in Bitcoins.
The private key can be thought of as the password which allows users to have access to the funds associated
with the matching public address.
To put it simply: the Bitcoin address is like a person’s email address while the private key is like the password.
When we say that someone owns Bitcoins, what we mean is that he is in possession of a private key which corresponds to the public address to which those Bitcoins are associated.
[http://www.givebtc.org/GiveBTC_-_Handbook_for_Non_Profits.pdf]
_DESCRIPTION:
A Bitcoin address is a unique, 27-34 alphanumeric characters long identifier that can be used as a destination for Bitcoin payments.
There are currently two different types of Bitcoin addresses in existence, Pay-to-PubkeyHash and Pay-to-ScriptHash, which are used in conjunction with their corresponding transaction type.
In the following both will be described in detail.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
_DESCRIPTION:
A 20-byte hash formatted using base58check to produce either a P2PKH or P2SH Bitcoin address. Currently the most common way users exchange payment information.
[https://bitcoin.org/en/glossary/address]
_DESCRIPTION:
A Bitcoin address, or simply address, is an identifier of 26-35 alphanumeric characters, beginning with the number 1 or 3, that represents a possible destination for a Bitcoin payment.
Addresses can be generated at no cost by any user of Bitcoin.
An example of a Bitcoin address is 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy.
[https://en.bitcoin.it/wiki/Address]
_DESCRIPTION:
Address validation
A bitcoin address includes a four byte checksum, which means addresses can be validated without talking to any servers.
The bitcoin-address module (GitHub: shtylman / bitcoin-address, npm: bitcoin-address) by Roman Shtylman implements the algorithm: a double SHA-256 digest of the 21 bytes before the checksum is calculated to validate the address.
var btcAddr = require('bitcoin-address');
btcAddr.validate('1Gtov23WTQPbj4c6dMaXnXxbvFKc87Lutb');
// true
Addresses are encoded with base 58, so Roman’s module includes his own decoding library.
He also uses Node Buffer objects to work with the decoded data.
Node’s crypto core module is used to create SHA-256 hashes.
[http://dailyjs.com/2013/08/23/bitcoins/]
_DESCRIPTION:
A bitcoin address is an identifier (account number), starting with 1 or 3 and containing 27-34 alphanumeric Latin characters (except 0, O, I, l).
An address can be also represented as a QR-code, is anonymous, and does not contain information about the owner.
It can be obtained for free, using, for example, bitcoin software.
[https://en.wikipedia.org/wiki/Bitcoin_network]
_DESCRIPTION:
Address:
A bitcoin address is used to receive and send transactions on the bitcoin network.
It contains a string of alphanumeric characters, but can also be represented as a scannable QR code.
A bitcoin address is also the public key in the pair of keys used by bitcoin holders to digitally sign transactions (see Public key).
[http://www.coindesk.com/information/bitcoin-glossary//]
===
This is wrong.
A-bitcoin-address is-not a-public-key, it derives from a-public-key#ql:idBtcpbk#.
[hmnSngo.2017-04-08]
_ADDRESS.WPG:
* https://github.com/shtylman/bitcoin-address,
* https://npmjs.org/package/bitcoin-address,
name::
* McsEngl.btcads'QR-code@cptIt,
* McsEngl.bitcoin-QR-code@cptIt,
* McsEngl.btcQR-code@cptIt,
_DESCRIPTION:
QR_code:
A two-dimensional graphical block containing a monochromatic pattern representing a sequence of data.
QR codes are designed to be scanned by cameras, including those found in mobile phones, and are frequently used to encode bitcoin addresses.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.btcads'Private-key@cptIt,
* McsEngl.bitcoin-private-key@cptIt,
* McsEngl.btcaddress'private-key@cptIt,
* McsEngl.btcnet'private-key@cptIt,
* McsEngl.btcprivate-key@cptIt,
_DESCRIPTION:
The bitcoin private key is just a number.
You can pick your private keys randomly using just a coin, pencil, and paper: toss a coin 256 times and you have the binary digits of a random private key you can use in a bitcoin wallet.
The public key can then be generated from the private key.
[https://github.com/bitcoinbook/bitcoinbook/blob/first_edition/ch04.asciidoc#private-keys]
_DESCRIPTION:
The private portion of a keypair which can create signatures that other people can verify using the public key.
[https://bitcoin.org/en/glossary/private-key]
===
When we say that someone owns Bitcoins, what we mean is that he is in possession of a private key which corresponds to the public address#ql:idBtcads# to which those Bitcoins are associated.
[http://www.givebtc.org/GiveBTC_-_Handbook_for_Non_Profits.pdf]
===
A private key in the context of bitcoin is a secret number that allows bitcoins to be spent.
Every bitcoin address has a matching private key, which is usually saved in the wallet file of the person who owns the balance but can be also stored using other means and methods.
The private key is mathematically related to the bitcoin address, and is designed so that the bitcoin address can be calculated from the private key but, importantly, the reverse cannot be done.
[https://en.wikipedia.org/wiki/Bitcoin_network]
===
private keys should not be stored on web servers,
[https://bitcoin.org/en/developer-guide#requesting-payments]
===
Private_Key_(Privkey):
A 256-bit number used in *ECDSA* algorithm to create transaction *signatures* in order to prove ownership of certain amount of bitcoins.
Can also be used in arbitrary *elliptic curve arithmetic* operations.
Private keys are stored within *wallet* applications and are usually encrypted with a pass phrase.
Private keys may be completely random (see *Key Pool*) or generated from a single secret number ("seed").
See also *Deterministic Wallet*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcads'Public-key@cptIt,
* McsEngl.bitcoin-public-key@cptIt,
* McsEngl.btcpublic-key@cptIt,
* McsEngl.btcaddress'public-key@cptIt,
* McsEngl.btcnet'public-key@cptIt,
* McsEngl.btcwlt'public-key@cptIt,
_DESCRIPTON:
Bob must first generate a private/public key pair before Alice can create the first transaction.
Bitcoin uses the Elliptic Curve Digital Signature Algorithm (ECDSA) with the secp256k1 curve; secp256k1 private keys are 256 bits of random data.
A copy of that data is deterministically transformed into an secp256k1 public key.
Because the transformation can be reliably repeated later, the public key does not need to be stored.
[https://bitcoin.org/en/developer-guide#transactions]
===
Public_Key_(Pubkey):
A 2D point on an elliptic curve https://en.bitcoin.it/wiki/Secp256k1 that is produced by multiplying a predefined "generator" point by a *private key*.
Usually it is represented by a pair of 256-bit numbers ("uncompressed public key"), but can also be compressed to just one 256-bit number (at the slight expense of CPU time to decode an uncompressed number). A special hash of a public key is called *address*.
Typical Bitcoin transactions contain public keys or addresses in the output scripts and *signatures* in the input scripts.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcads'Version-number@cptIt,
_DESCRIPTION:
Pubkey hashes are almost always sent encoded as Bitcoin addresses, which are base58-encoded strings containing an address version number, the hash, and an error-detection checksum to catch typos.
[https://bitcoin.org/en/developer-guide#transactions]
name::
* McsEngl.btcads'Public-key-hash@cptIt,
* McsEngl.btcpubkey-hash@cptIt,
* McsEngl.btcpublic-key-hash@cptIt,
* McsEngl.public-key-hash-of-bitcoin@cptIt,
_DESCRIPTION:
The public key (pubkey) is then cryptographically hashed.
This pubkey hash can also be reliably repeated later, so it also does not need to be stored.
The hash shortens and obfuscates the public key, making manual transcription easier and providing security against unanticipated problems which might allow reconstruction of private keys from public key data at some later point.
[https://bitcoin.org/en/developer-guide#transactions]
name::
* McsEngl.btcads'Hash160@cptIt,
* McsEngl.btchash160@cptIt,
_DESCRIPTION:
Hash160:
SHA-256#ql:idBtccrptsha256# hashed with RIPEMD-160.
It is used to produce an *address* because it makes a smaller hash (20 bytes vs 32 bytes) than SHA-256, but still uses SHA-256 internally for security.
BTCHash160() in CoreBitcoin, Hash160() in BitcoinQT.
It is also available in scripts as OP_HASH160.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcads'Error-detection-checksum@cptIt,
_DESCRIPTION:
DESCRIPTION:
Address validation
A bitcoin address includes a four byte checksum, which means addresses can be validated without talking to any servers.
The bitcoin-address module (GitHub: shtylman / bitcoin-address, npm: bitcoin-address) by Roman Shtylman implements the algorithm: a double SHA-256 digest of the 21 bytes before the checksum is calculated to validate the address.
var btcAddr = require('bitcoin-address');
btcAddr.validate('1Gtov23WTQPbj4c6dMaXnXxbvFKc87Lutb');
// true
Addresses are encoded with base 58, so Roman’s module includes his own decoding library.
He also uses Node Buffer objects to work with the decoded data.
Node’s crypto core module is used to create SHA-256 hashes.
[http://dailyjs.com/2013/08/23/bitcoins/]
===
Pubkey hashes are almost always sent encoded as Bitcoin addresses, which are base58-encoded-strings#ql:idBtcb58# containing an address version number, the hash, and an error-detection checksum to catch typos.
[https://bitcoin.org/en/developer-guide#transactions]
name::
* McsEngl.btcads'Base58@cptIt,
* McsEngl.Base58-of-Bitcoin@cptIt,
* McsEngl.btcBase58@cptIt,
_DESCRIPTION:
A compact human-readable encoding for binary data invented by Satoshi Nakamoto#ql:idBtchmnSnt# to make more user-friendly addresses.
It consists of alphanumeric characters, but does not allow "0", "O", "I", "l" characters that look the same in some fonts and could be used to create visually identical looking addresses.
Lowercase "o" and "1" are allowed.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcads'Base58check@cptIt,
* McsEngl.Base58check-of-Bitcoin@cptIt,
* McsEngl.btcBase58check@cptIt,
* McsEngl.btcBitcoin-Address-Encoding@cptIt,
_DESCRIPTION:
The method used in Bitcoin for converting 160-bit hashes into P2PKH and P2SH addresses.
Also used in other parts of Bitcoin, such as encoding private keys for backup in WIP format.
Not the same as other base58 implementations.
[https://bitcoin.org/en/glossary/base58check]
===
Base58Check:
A variant of Base58 encoding that appends first 4 bytes of Hash256#ql:idBtchsh256# of the encoded data to that data before converting to Base58.
It is used in addresses to detect typing errors.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcads'Explorer@cptIt,
_ADDRESS.WPG:
* https://blockexplorer.com/address/38DdqhVuqb36jjmxTbvBkiFPXKA8EmW9Ly,
name::
* McsEngl.btcads'Taint-analysis@cptIt,
* McsEngl.bitcoin-taint-analysis@cptIt,
* McsEngl.btctaint-analysis@cptIt,
_DESCRIPTION:
Taint:
An analysis of how closely related two addresses are when they have both held a particular bitcoin.
'def.A-taint-analysis' could be used to determine how many steps it took for bitcoins to move from an address known for stolen coins, to the current address.
name::
* McsEngl.btcads'DOING@cptIt,
name::
* McsEngl.btcads'Creating@cptIt,
_DESCRIPTION:
Wallet-programs#ql:idBtcwltPgm# create bitcoin-addresses for free.
name::
* McsEngl.btcads'Changing@cptIt,
* McsEngl.bitcoin-key-reuse@cptIt,
* McsEngl.btcads'changing@cptIt,
* McsEngl.btcads'reusing@cptIt,
* McsEngl.btckey-reuse@cptIt,
_DESCRIPTION:
Using a separate address for each incoming payment makes it trivial to determine which customers have paid their payment requests.
Your applications need only track the association between a particular payment request and the address used in it, and then scan the block chain for transactions matching that address.
[https://bitcoin.org/en/developer-guide#requesting-payments]
_DESCRIPTION:
Avoiding Key Reuse
In a transaction, the spender and receiver each reveal to each other all public keys or addresses used in the transaction. This allows either person to use the public block chain to track past and future transactions involving the other person’s same public keys or addresses.
If the same public key is reused often, as happens when people use Bitcoin addresses (hashed public keys) as static payment addresses, other people can easily track the receiving and spending habits of that person, including how many satoshis they control in known addresses.
It doesn’t have to be that way.
If each public key is used exactly twice—once to receive a payment and once to spend that payment—the user can gain a significant amount of financial privacy.
Even better, using new public keys or unique addresses when accepting payments or creating change outputs can be combined with other techniques discussed later, such as CoinJoin or merge avoidance, to make it extremely difficult to use the block chain by itself to reliably track how users receive and spend their satoshis.
Avoiding key reuse can also provide security against attacks which might allow reconstruction of private keys from public keys (hypothesized) or from signature comparisons (possible today under certain circumstances described below, with more general attacks hypothesized).
Unique (non-reused) P2PKH and P2SH addresses protect against the first type of attack by keeping ECDSA public keys hidden (hashed) until the first time satoshis sent to those addresses are spent, so attacks are effectively useless unless they can reconstruct private keys in less than the hour or two it takes for a transaction to be well protected by the block chain.
Unique (non-reused) private keys protect against the second type of attack by only generating one signature per private key, so attackers never get a subsequent signature to use in comparison-based attacks. Existing comparison-based attacks are only practical today when insufficient entropy is used in signing or when the entropy used is exposed by some means, such as a side-channel attack.
So, for both privacy and security, we encourage you to build your applications to avoid public key reuse and, when possible, to discourage users from reusing addresses. If your application needs to provide a fixed URI to which payments should be sent, please see the bitcoin: URI section below.
[https://bitcoin.org/en/developer-guide#avoiding-key-reuse]
_ADDRESS.WPG:
* http://bitzuma.com/posts/five-ways-to-lose-money-with-bitcoin-change-addresses//
name::
* McsEngl.btcads.MULTISIG@cptIt,
* McsEngl.bitcoin-multisig-address@cptIt,
* McsEngl.btcmultisig-address@cptIt,
_DESCRIPTION:
Multisig:
Multi-signature addresses allow multiple parties to partially seed an address with a public key.
When someone wants to spend some of the bitcoins, they need some of these people to sign their transaction in addition to themselves.
The needed number of signatures is agreed at the start when people create the address.
Services using multi-signature addresses have a much greater resistance to theft.
Read more about Multisig here.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.btcads.P2PKH@cptIt,
* McsEngl.btcads.P2PKH@cptIt,
* McsEngl.btcP2PKH@cptIt,
* McsEngl.btcPay-To-PubKey-Hash@cptIt,
_DESCRIPTION:
A Bitcoin payment address comprising a hashed public key, allowing the spender to create a standard pubkey-script#ql:btcpubkey_script# that Pays To PubKey Hash (P2PKH).
[https://bitcoin.org/en/glossary/p2pkh-address]
===
P2PKH is the most common form of pubkey script used to send a transaction to one or multiple Bitcoin addresses.
Pubkey script: OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Signature script: <sig> <pubkey>
[https://bitcoin.org/en/developer-guide#pay-to-public-key-hash-p2pkh]
name::
* McsEngl.btcads.P2SH@cptIt,
* McsEngl.btcaddress.P2SH@cptIt,
* McsEngl.btcP2SH@cptIt,
* McsEngl.btcPay-To-Script-Hash@cptIt,
_DESCRIPTION:
A Bitcoin payment address comprising a hashed script, allowing the spender to create a standard pubkey script that Pays To Script Hash (P2SH).
The script can be almost any valid pubkey script.
[https://bitcoin.org/en/glossary/p2sh-address]
name::
* McsEngl.btcads.VANITY@cptIt,
* McsEngl.bitcoin-vanity-address@cptIt,
* McsEngl.btcvanity-address@cptIt,
_DESCRIPTION:
Vanity_address:
A bitcoin address with a desirable pattern, such as a name.
name::
* McsEngl.btcbcn'Transaction (btctx)@cptIt,
* McsEngl.btcnet'blockchain-transaction@cptIt,
* McsEngl.btcnet'transaction@cptIt,
* McsEngl.bitcoin-transaction@cptIt,
* McsEngl.btctransaction@cptIt,
* McsEngl.btctrn@cptIt,
* McsEngl.btctx@cptIt,
* McsEngl.btctransaction-record@cptIt,
====== lagoGreek:
* McsElln.συναλλαγή-μπιτκόιν@cptIt,
_WHOLE:
* btc-block#ql:btcblock@cptIt#
* btc-blockchain#ql:btcblockchain#
_DESCRIPTION:
A chunk of binary data that describes how bitcoins are moved from one owner to another.
Transactions are stored in the *blockchain*.
Every transaction (except for *coinbase* transactions) has a reference to one or more previous transactions (*inputs*) and one or more rules on how to spend these bitcoins further (*outputs*).
See *Transaction-Input#ql:btcTransaction_Input#* and *Transaction Output* for more info.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
Bitcoins are the equivalent of Internet cash. You can send bitcoins over the Internet directly to anyone with no middle man. Like cash, Bitcoin transactions are irreversible. Bitcoins are traded worldwide.
[https://www.bitstamp.net/help/what-is-bitcoin/]
===
How do bitcoin transactions work?
Jan 9th 2015, 15:03 BY THE DATA TEAM
Even Satoshi Nakamoto, the elusive creator of bitcoin, admitted that his invention is hard to explain–because there is nothing you can compare it to. Here is how a bitcoin transaction is processed:
1) Payers initiate a bitcoin payment using "wallet" software.
2) This and other pending transactions are broadcast on the global bitcoin network.
3) Once every ten minutes or so, "miners", specialised computers (or groups of computers) on this network, collect a few hundred transactions and combine them in a "block".
4) In order to mine a block and validate the transaction, miners compete to solve a difficult mathematical equation (a "hash function"). The miner that solves the equation first further processes the block and broadcasts this "proof-of-work" to the bitcoin network.
5) The other miners check the proof-of-work and the validity of the transactions. If they approve, the winning miner gets a reward of 25 newly minted bitcoin (about $6,900 at current prices), which is the incentive for miners to provide computing power. Adjusting the difficulty of the puzzle ensures that the supply of new bitcoins remains steady.
6) The mined block is added to the "blockchain", a big, unbreakable ledger that lives on the bitcoin network and serves as a record of all transactions.
7) The payee can use his wallet software to see whether the bitcoin have arrived.
[http://www.economist.com/blogs/graphicdetail/2015/01/daily-chart-3]
name::
* McsEngl.btctx'part.VERSION (4B)@cptIt,
* McsEngl.btctx'version@cptIt,
* McsEngl.btctx'version@cptIt,
* McsEngl.btcnVersion@cptIt,
* McsEngl.btctransaction-version-number@cptIt,
_DESCRIPTION:
Every transaction consists of
- a transaction version (nVersion),
- a vector of inputs (vin) and
- a vector of outputs (vout), both preceded by their count, and
- a transaction inclusion date (nLockTime).
nVersion / int (4 bytes) / Transaction format version (currently 1).
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
===
Each transaction is prefixed by a four-byte transaction version number which tells Bitcoin peers and miners which set of rules to use to validate it. This lets developers create new rules for future transactions without invalidating previous transactions.
===
Transaction version numbers will be a better way to specify exactly what rues should be used to validate a transaction; transactions with old version numbers will be validated under the old rules, transactions with new version numbers will always be validated under the new rules before being relayed or included in mined blocks. To avoid being in the minority fork of a block chain split, transactions with new version numbers appearing in blocks will only be validated using the new rules when a super-majority of the network (as expressed by block version numbers in the last N blocks) supports the new feature.
A transaction's version number is part of it's hash (transaction ID) and is part of the signature hash, so cannot be changed by an attacker. However, software using new transaction features will need to make sure that transactions have the correct version number before asking users to provide signatures or telling users that the transaction has been properly signed, etc.
[https://gist.github.com/gavinandresen/2355445]
name::
* McsEngl.btctx'part.INPUT@cptIt,
* McsEngl.bitcoin-transaction-input@cptIt,
* McsEngl.btcInput@cptIt,
* McsEngl.btctx'input@cptIt,
* McsEngl.btcTransaction-Input@cptIt,
* McsEngl.btcTxin@cptIt,
_DESCRIPTION:
An input
- references an output#ql:idBtctxoupt# in a previous transaction — a transaction ID (the hash of the transaction data) and output index — and
- provides a script, known as the scriptSig, that satifies the output script conditions.
[http://joncave.co.uk/2014/08/bitcoin-sighash-single/]
===
Every transaction consists of
- a transaction version (nVersion),
- a vector of inputs (vin) and
- a vector of outputs (vout), both preceded by their count, and
- a transaction inclusion date (nLockTime).
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
===
Transaction_Input:
A part of a transaction that contains
- a reference to a previous transaction's *output*
- and a *script* that can prove ownership of that output.
The script usually contains a *signature* and thus called *scriptSig*.
Inputs spend previous outputs completely.
So if one needs to pay only a portion of some previous output, the transaction should include extra *change* output that sends the remaining portion back to its owner (on the same or different address).
*Coinbase* transactions contain only one input with a zeroed reference to a previous transaction and an arbitrary data in place of script.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
Each transaction has at least one input and one output. Each input spends the satoshis paid to a previous output.
[https://bitcoin.org/en/developer-guide#transactions]
===
An input in a transaction which contains four fields:
- an outpoint,
- a signature script, and
- a sequence number.
The outpoint references a previous output and the signature script allows spending it.
[https://bitcoin.org/en/glossary/input]
===
Each transaction spends the satoshis previously received in one or more earlier transactions, so the input of one transaction is the output of a previous transaction.
[https://bitcoin.org/en/developer-guide#block-chain-overview]
===
Input:
The part of a bitcoin transaction denoting where the bitcoin payment has come from.
Typically, this will be a bitcoin address, unless the transaction is a generation transaction#ql:idBtctxCnbs#, meaning that the bitcoin has been freshly mined (see Coinbase).
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.btctxinpt'part.OUTPOINT (32B+4B)@cptIt,
* McsEngl.btctxinpt'outpoint@cptIt,
* McsEngl.btcoutpoint@cptIt,
* McsEngl.btctx'outpoint@cptIt,
_DESCRIPTION:
The data structure used to refer to a particular transaction output, consisting of a 32-byte TXID and a 4-byte output index number (vout).
[https://bitcoin.org/en/glossary/outpoint]
===
Outpoint (the combination of a txid with a vout used to identify a specific output)
[https://bitcoin.org/en/glossary/txid]
name::
* McsEngl.btctxinpt'id (32B)@cptIt,
* McsEngl.btctx'id@cptIt,
==
* McsEngl.btctxinpt'txid@cptIt,
* McsEngl.btcTransaction-Identifier@cptIt,
* McsEngl.btcTxid@cptIt,
* McsEngl.btctx'id@cptIt,
_DESCRIPTION:
An identifier used to uniquely identify a particular transaction; specifically, the sha256d hash of the transaction.
[https://bitcoin.org/en/glossary/txid]
===
The-rawtransaction-format#ql:btctx'code# is hashed to create the transaction identifier (txid).
From these txids, the merkle tree is constructed by pairing each txid with one other txid and then hashing them together.
[https://bitcoin.org/en/developer-guide#transaction-data]
name::
* McsEngl.btctxinpt'vout (4B)@cptIt,
* McsEngl.btcoutput-index-number@cptIt,
* McsEngl.btcoutput-vector@cptIt,
_DESCRIPTION:
An input uses a transaction identifier (txid) and an output index number (often called “vout” for output vector) to identify a particular output to be spent.
[https://bitcoin.org/en/developer-guide#transactions]
name::
* McsEngl.btctxinpt'part.SEQUENCE-NUMBER@cptIt,
* McsEngl.btctxinpt'sequence-number@cptIt,
* McsEngl.btcsequence-number@cptIt,
* McsEngl.btctx'sequence-number@cptIt,
_DESCRIPTION:
Part of all transactions.
A number intended to allow unconfirmed time-locked transactions to be updated before being finalized; not currently used except to disable locktime in a transaction
[https://bitcoin.org/en/glossary/sequence-number]
===
Sequence:
A 32-bit unsigned integer in a transaction input used to replace older version of a transaction by a newer one.
Only used when *locktime* is not zero.
Transaction is not considered valid until the sequence number is 0xFFFFFFFF.
By default, the sequence is 0xFFFFFFFF.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btctxinpt'Coinbase@cptIt,
* McsEngl.bitcoin-coinbase@cptIt,
* McsEngl.btccoinbase@cptIt,
_DESCRIPTION:
A special field used as the sole input for coinbase transactions.
The coinbase allows claiming the block reward and provides up to 100 bytes for arbitrary data.
[https://bitcoin.org/en/glossary/coinbase]
===
Coinbase:
An input script of a transaction that generates new bitcoins. Or a name of that transaction itself ("coinbase transaction"). Coinbase transaction does not spend any existing transactions, but contains exactly one input which may contain any data in its script. *Genesis block* transaction contains a reference to The Times article from January 3rd 2009 to prove that more blocks were not created before that date. Some *mining pools* put their names in the coinbase transactions (so everyone can estimate how much *hashrate* each pool produces).
Coinbase is also used to vote on a protocol change (e.g. *P2SH*). Miners vote by putting some agreed-upon marker in the coinbase to see how many support the change. If a majority of miners support it and expect non-mining users to accept it, then they simply start enforcing new rule. Minority then should either continue with a forked blockchain (thus producing an *altcoin*) or accept new rule.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btctxinpt'Hash-type@cptIt,
* McsEngl.btchash-type@cptIt,
* McsEngl.btchashtype@cptIt,
_DESCRIPTION:
Hash_Type_(hashtype):
A single byte appended to a transaction *signature* in the *transaction input* which describes how the transaction should be hashed in order to verify that signature.
There are three types affecting outputs:
ALL (default), SINGLE, NONE and one optional modifier ANYONECANPAY affecting the inputs (can be combined with either of the first three).
ALL requires all outputs to be hashed (thus, all outputs are signed).
SINGLE clears all output scripts but the one with the same index as the input in question.
NONE clears all outputs thus allowing changing them at will.
ANYONECANPAY removes all inputs except the current one (allows anyone to contribute independently).
The actual behavior is more subtle than this overview, you should check the actual source code for more comments.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btctx'part.OUTPUT (btctxout)@cptIt,
* McsEngl.bitcoin-transaction-output@cptIt,
* McsEngl.btcOutput@cptIt,
* McsEngl.btcTransaction-Output@cptIt,
* McsEngl.btctx'output@cptIt,
* McsEngl.btcTxOut@cptIt,
_DESCRIPTION:
An output in a transaction which contains two fields:
- a value field for transferring zero or more satoshis and
- a pubkey script for indicating what conditions must be fulfilled for those satoshis to be further spent.
[https://bitcoin.org/en/glossary/output]
_DESCRIPTION:
Each transaction has at least one input and one output.
Each input spends the satoshis paid to a previous output.
Each output then waits as an Unspent Transaction Output (UTXO) until a later input spends it.
When your Bitcoin wallet tells you that you have a 10,000 satoshi balance, it really means that you have 10,000 satoshis waiting in one or more UTXOs.
[https://bitcoin.org/en/developer-guide#transactions]
_DESCRIPTION:
A single transaction can create multiple outputs, as would be the case when sending to multiple addresses, but each output of a particular transaction can only be used as an input once in the block chain.
[https://bitcoin.org/en/developer-guide#block-chain-overview]
_DESCRIPTION:
The destination address for a bitcoin transaction.
There can be multiple outputs for a single transaction.
[http://www.coindesk.com/information/bitcoin-glossary//]
_DESCRIPTION:
Transaction_Output:
An output contains an amount to be sent and a *script* that allows further spending.
The script typically contains a *public key* (or an *address*, a hash of a public key) and a signature verification *opcode*.
Only an owner of a corresponding *private key* is able to create another transaction that sends that amount further to someone else.
In every transaction, the sum of output-amounts must be equal or less than a sum of all input amounts.
See also *Change*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btctxout'part.INDEX-implied@cptIt,
* McsEngl.btctxout'index@cptIt,
_DESCRIPTION:
An output has an implied index number based on its location in the transaction—the first output is output zero.
[https://bitcoin.org/en/developer-guide#transactions]
name::
* McsEngl.btctxout'part.AMOUNT@cptIt,
* McsEngl.btctxout'amount@cptIt,
_DESCRIPTION:
The output also has an amount in satoshis which it pays to a conditional pubkey script.
[https://bitcoin.org/en/developer-guide#transactions]
name::
* McsEngl.btctxout.CHANGE@cptIt,
* McsEngl.btcChange@cptIt,
* McsEngl.btcChange-Output@cptIt,
* McsElln.επιστροφή-μπιτκόιν@cptIt,
* McsElln.ρέστα-μπιτκόιν@cptIt,
_DESCRIPTION:
An output in a transaction which returns satoshis to the spender, thus preventing too much of the input value from going to transaction fees.
[https://bitcoin.org/en/glossary/change-address]
_DESCRIPTION:
Change outputs are regular outputs which spend the surplus satoshis from the UTXOs back to the spender. They can reuse the same P2PKH pubkey hash or P2SH script hash as was used in the UTXO, but for the reasons described in the next subsection, it is highly recommended that change outputs be sent to a new P2PKH or P2SH address.
[https://bitcoin.org/en/developer-guide#transaction-fees-and-change]
===
Change:
Informal name for a portion of a *transaction output* that is returned to a sender as a "change" after spending that output.
Since *transaction outputs* cannot be partially spent, one can spend 1 BTC out of 3 BTC output only be creating two new outputs: a "payment" output with 1 BTC sent to a payee address, and a "change" output with remaining 2 BTC (minus *transaction fees*) sent to the payer's addresses.
*BitcoinQT* always uses new address from a *key pool* for a better privacy.
*Blockchain.info* sends to a default address in the wallet.
A common mistake when working with a *paper wallet* or a *brain wallet* is to make a change transaction to a different address and then accidentally delete it.
E.g. when importing a private key in a temporary BitcoinQT wallet, making a transaction and then deleting the temporary wallet.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btctxout.DUST@cptIt,
* McsEngl.btcdust-transaction-output@cptIt,
_DESCRIPTION:
Dust:
A transaction output that is smaller than a typically fee required to spend it. This is not a strict part of the protocol, as any amount more than zero is valid. BitcoinQT refuses to mine or relay "dust" transactions to avoid uselessly increasing the size of unspent transaction outputs (UTXO) index. See also discussion about *UTXO*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btctxout.MULTISIG@cptIt,
* McsEngl.btcm-of-n-multisig@cptIt,
* McsEngl.btcmultisig-output@cptIt,
_DESCRIPTION:
M-of-N-Multisig, Multisig-Output:
A pubkey script that provides n number of pubkeys and requires the corresponding signature script provide m minimum number signatures corresponding to the provided pubkeys.
[https://bitcoin.org/en/glossary/multisig]
name::
* McsEngl.btctxout.SPENT@cptIt,
* McsEngl.btcSpent-Transaction-Output@cptIt,
_DESCRIPTION:
Used as input#ql:btctx'input# in another transaction.
[hmnSngo.2017-02-18]
===
Because each output of a particular transaction can only be spent once, the outputs of all transactions included in the block chain can be categorized as either Unspent Transaction Outputs (UTXOs) or spent transaction outputs.
[https://bitcoin.org/en/developer-guide#block-chain-overview]
===
#idBtc1Spent_Output#
A transaction *output* can be spent only once: when another valid transaction makes a reference to this output from its own input.
When another transaction attempts to spend the same output, it will be rejected by the nodes already seeing the first transaction.
Blockchain as a *proof-of-work* scheme allows every node to agree on which transaction was indeed the first one.
The whole transaction is considered spent when all its outputs are spent.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btctxout.SPENT.NO (unspent UTXO)@cptIt,
* McsEngl.bitcoin-Unspent-Transaction-Output@cptIt,
* McsEngl.btctx'UTXO@cptIt,
* McsEngl.btctxout.UTXO@cptIt,
* McsEngl.btcUnspent-Transaction-Output@cptIt,
* McsEngl.btcUTXO@cptIt,
_DESCRIPTION:
An Unspent Transaction Output (UTXO) that can be spent as an input in a new transaction.
[https://bitcoin.org/en/glossary/unspent-transaction-output]
name::
* McsEngl.bitcoin-Unspent-Transaction-Output-Set@cptIt,
* McsEngl.btctx'UTXO-set@cptIt,
* McsEngl.btctxout.UTXO-set@cptIt,
* McsEngl.btcUnspent-Transaction-Output-set@cptIt,
* McsEngl.btcUTXO-set@cptIt,
_DESCRIPTION:
UTXO_Set:
A collection of *Unspent Transaction Outputs*.
Typically used in discussions on optimizing an ever-growing index of *transaction outputs* that are not yet *spent*.
The index is important to efficiently validate newly created transactions.
Even if the rate of the new transactions remains constant, the time required to locate and verify unspent outputs grows.
Possible technical solutions include more efficient indexing algorithms and a more performant hardware.
*BitcoinQT*, for example, keeps only an index of outputs matching user's keys and scans the entire blockchain when validating other transactions.
A developer of one web wallet service mentioned that they maintain the entire index of UTXO and its size was around 100 Gb when the blockchain itself was only 8 Gb.
Some people seek social methods to solve the problem.
For instance, by refusing to *relay* or *mine* transactions that are considered *dust* (containing outputs smaller than a *transaction fee* required to mine/relay them).
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btctx'part.LOCKTIME (4Bytes)@cptIt,
* McsEngl.btctx'locktime@cptIt,
* McsEngl.btcLocktime@cptIt,
* McsEngl.btcnLockTime@cptIt,
_DESCRIPTION:
Part of a transaction which indicates the earliest time or earliest block when that transaction may be added to the block chain.
[https://bitcoin.org/en/glossary/locktime]
===
One thing all signature hash types sign is the transaction’s locktime. (Called nLockTime in the Bitcoin Core source code.) The locktime indicates the earliest time a transaction can be added to the block chain.
Locktime allows signers to create time-locked transactions which will only become valid in the future, giving the signers a chance to change their minds.
If any of the signers change their mind, they can create a new non-locktime transaction. The new transaction will use, as one of its inputs, one of the same outputs which was used as an input to the locktime transaction. This makes the locktime transaction invalid if the new transaction is added to the block chain before the time lock expires.
[https://bitcoin.org/en/developer-guide#locktime-and-sequence-number]
===
Every transaction consists of
- a transaction version (nVersion),
- a vector of inputs (vin) and
- a vector of outputs (vout), both preceded by their count, and
- a transaction inclusion date (nLockTime).
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
===
Lock_Time_(locktime):
A 32-bit field in a *transaction* that means either a block *height* at which the transaction becomes valid, or a UNIX timestamp.
Zero means transaction is valid in any block.
A number less than 500000000 is interpreted as a block number (the limit will be hit after year 11000), otherwise a timestamp.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btctx'Bytes@cptIt,
_DESCRIPTION:
the fee is relative to the number of bytes in the transaction
[https://bitcoin.org/en/faq#transactions]
name::
* McsEngl.btctx'Fee@cptIt,
* McsEngl.btctx'fee@cptIt,
* McsEngl.btcfee@cptIt,
* McsEngl.btcTransaction-Fee@cptIt,
* McsEngl.btcMiner-Fee@cptIt,
* McsEngl.btcMiners-Fee@cptIt,
* McsEngl.bitcoin-transaction-fee@cptIt,
====== lagoGreek:
* McsElln.τέλη-μπικόιν-συναλλαγής@cptIt,
* McsElln.χρέωση-μπικόιν-συναλλαγής@cptIt,
_ADDRESS.WPG:
* http://cointelegraph.com/news/bitcoins-transaction-fees-skyrocket-as-the-bitcoin-halving-looms,
Having almost tripled since last summer, Bitcoin transaction fees continue to grow. {2016-05-15}
* New Service Finds Optimum Bitcoin Transaction Fee,
_DESCRIPTION:
Fees are relatively unimportant at the moment since “miners” who successfully process a block of transactions are rewarded with newly created bitcoin. However, fees will become more important in the future because the amount of new bitcoin issued to a successful miner is cut in half roughly every four years. If increasing the block size lowers the transaction fees miners can expect to receive, one would expect fewer miners competing to process transactions as the block reward decreases over time. The bitcoin system would become more centralized as a result.
[http://www.forbes.com/sites/realspin/2015/09/08/new-bitcoin-development-spurs-unnecessary-fear-of-centralization/]
===
Transaction_Fee:
Also known as "miners' fee", an amount that an author of transaction pays to a miner who will include the transaction in a block.
The fee is expressed as difference between the sum of all *input* amounts and a sum of all *output* amounts.
Unlike traditional payment systems, miners do not explicitly require fees and most miners allow free transactions.
All miners are competing between each other for the fees and all transactions are competing for a place in a block.
There are soft rules encoded in most clients that define minimum fees per kilobyte to relay or mine a transaction (mostly to prevent *DoS* and *spam*).
Typically, the fee affects the priority of a transaction.
As of July 27, 2014 average fee per block is below 0.1 BTC.
See also *Reward*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
The amount remaining when the value of all outputs in a transaction are subtracted from all inputs in a transaction; the fee is paid to the miner who includes that transaction in a block.
[https://bitcoin.org/en/glossary/transaction-fee]
===
A small fee imposed on some transactions sent across the bitcoin network.
The transaction fee is awarded to the miner that successfully hashes the block containing the relevant transaction.
[http://www.coindesk.com/information/bitcoin-glossary//]
===
Transaction fees may be included with any transfer of bitcoins from one address to another. At the moment, many transactions are typically processed in a way where no fee is expected at all, but for transactions which draw coins from many bitcoin addresses and therefore have a large data size, a small transaction fee is usually expected.
The transaction fee is processed by and received by the bitcoin miner. When a new bitcoin block is generated with a successful hash, the information for all of the transactions is included with the block and all transaction fees are collected by that user creating the block, who is free to assign those fees to himself.
Transaction fees are voluntary on the part of the person making the bitcoin transaction, as the person attempting to make a transaction can include any fee or none at all in the transaction. On the other hand, nobody mining new bitcoins necessarily needs to accept the transactions and include them in the new block being created. The transaction fee is therefore an incentive on the part of the bitcoin user to make sure that a particular transaction will get included into the next block which is generated.
It is envisioned that over time the cumulative effect of collecting transaction fees will allow somebody creating new blocks to "earn" more bitcoins than will be mined from new bitcoins created by the new block itself. This is also an incentive to keep trying to create new blocks even if the value of the newly created block from the mining activity is zero in the far future.
[https://en.bitcoin.it/wiki/Transaction_fees]
{2017-02-18}
Now, the average fee to have a transaction included in the next six blocks or roughly one hour is $0.37, higher than many card processors’ fees.
[https://cointelegraph.com/news/bitcoin-fork-soon-bitcoin-unlimited-surges-past-segwit-core-blocks-drop-below-75]
name::
* McsEngl.btctx'Format.Binary@cptIt,
* McsEngl.btcxt'binary-format@cptIt,
* McsEngl.btcxt'raw-format@cptIt,
* McsEngl.btcTransaction-format@cptIt,
* McsEngl.btcrawtransaction-format@cptIt,
_DESCRIPTION:
All transactions, including the coinbase transaction, are encoded into blocks in binary rawtransaction format.
[https://bitcoin.org/en/developer-guide#transaction-data]
name::
* McsEngl.btctx'Script-language (btcstl)@cptIt,
* McsEngl.btcstl@cptIt,
* McsEngl.btctx'script-language@cptIt,
* McsEngl.bitcoin-scripting-system@cptIt,
* McsEngl.bitcoin-script-language@cptIt,
* McsEngl.btcscripting-language@cptIt,
* McsEngl.btctransaction-script@cptIt,
* McsEngl.btcnet'transaction-script@cptIt,
_DESCRIPTION:
Bitcoin uses a scripting system for transactions.
Forth-like, Script is simple, stack-based, and processed from left to right.
It is purposefully not Turing-complete, with no loops.
[https://en.bitcoin.it/wiki/Script]
===
The script language is a Forth-like stack-based language deliberately designed to be stateless and not Turing complete.
Statelessness ensures that once a transaction is added to the block chain, there is no condition which renders it permanently unspendable.
Turing-incompleteness (specifically, a lack of loops or gotos) makes the script language less flexible and more predictable, greatly simplifying the security model.
[https://bitcoin.org/en/developer-guide#p2pkh-script-validation]
===
A decentralized transaction verification system (transaction script)
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
===
The scripting language is stack-based, this means that each data, input or output is put on a stack of other data.
[https://docs.google.com/document/d/1D_gi_7Sf9sOyAHG25cMpOO4xtLq3iJUtjRwcZXFLv1E/edit]
===
Pubkey-scripts#ql:btcscriptpubkey# and signature-scripts#ql:btcscriptsig# combine secp256k1 pubkeys and signatures with conditional logic, creating a programmable authorization mechanism.
[https://bitcoin.org/en/developer-guide#transactions]
name::
* McsEngl.btcstl'Script@cptIt,
* McsEngl.bitcoin-script@cptIt,
* McsEngl.btcscript@cptIt,
* McsEngl.btcstl'script@cptIt,
* McsElln.σενάριο-μπιτκόιν@cptIt,
_DESCRIPTION:
Script is code written with the-bitcoin-script-language.
[hmnSngo.2017-04-06]
_DESCRIPTION:
Script:
A compact turing-incomplete programming language used in transaction *inputs* and *outputs*.
Scripts are interpreted by a Forth-like stack machine: each operation manipulates data on the stack.
Most scripts follow the standard pattern and verify the digital *signature* provided in the transaction *input* against a *public key* provided in the previous transaction's *output*.
Both signatures and public keys are provided using scripts.
Scripts may contain complex conditions, but can never change amounts being transferred.
Amount is stored in a separate field in a *transaction output*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcstl'script'Opcode@cptIt,
* McsEngl.bitcoin-opcode@cptIt,
* McsEngl.btctx'Op-Code@cptIt,
* McsEngl.btcopcode@cptIt,
* McsEngl.btcop-code@cptIt,
_DESCRIPTION:
Operation codes from the Bitcoin Script language which push data or perform functions within a pubkey script or signature script.
[https://bitcoin.org/en/glossary/op-code]
===
Opcode:
8-bit code of a *script* operation.
Codes from 0x01 to 0x4B (decimal 75) are interpreted as a length of data to be pushed on the stack of the interpreter (data bytes follow the opcode).
Other codes are either do something interesting, or disabled and cause transaction verification to fail, or do nothing (reserved for future use).
See also *Script*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcstl'script.Signature-Script (input)@cptIt,
* McsEngl.biticoin-input-script@cptIt,
* McsEngl.btcinput-script@cptIt,
* McsEngl.btcscriptInput@cptIt,
* McsEngl.btcscriptSig@cptIt,
* McsEngl.btcsequence-script@cptIt,
* McsEngl.btcsignature-script@cptIt,
* McsEngl.btctx'signature-script@cptIt,
* McsEngl.btctxinpt'signature-script@cptIt,
_DESCRIPTION:
It [an-input#ql:btctx'input#] also has a signature script which allows it to provide data parameters that satisfy the conditionals in the pubkey script.
[https://bitcoin.org/en/developer-guide#transactions]
===
Signature-script:
Data generated by a spender which is almost always used as variables to satisfy a-pubkey-script#ql:btcpubkey_script#.
Called a scriptSig in code.
[https://bitcoin.org/en/glossary/signature-script]
===
Anyone who can satisfy the conditions of that pubkey script can spend up to the amount of satoshis paid to it.
[https://bitcoin.org/en/developer-guide#transactions]
===
scriptSig:
Original name in *bitcoind* for a transaction *input* script.
Typically, input scripts contain *signatures#ql:btcsignature#* to prove ownership of bitcoins sent by a previous transaction.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcstl'script.Pubkey-script (output)@cptIt,
* McsEngl.bitcoin-output-script@cptIt,
* McsEngl.btcoutput-script@cptIt,
* McsEngl.btcpubkey-script@cptIt,
* McsEngl.btcscriptOutput@cptIt,
* McsEngl.btcScriptPubKey@cptIt,
* McsEngl.btctxotp'pubkey-script@cptIt,
_WHOLE:
* bitcoin-transaction's-output#ql:idBtctxoupt#
_DESCRIPTION:
The output also has an amount in satoshis which it pays to a conditional pubkey script.
Anyone who can satisfy the conditions of that pubkey script can spend up to the amount of satoshis paid to it.
[https://bitcoin.org/en/developer-guide#transactions]
===
A script included in outputs which sets the conditions that must be fulfilled for those satoshis to be spent.
Data for fulfilling the conditions can be provided in a-signature-script#ql:btcsignature_script#.
Called a scriptPubKey in code.
[https://bitcoin.org/en/glossary/pubkey-script]
===
scriptPubKey:
Original name in *bitcoind* for a transaction *output* script.
Typically, output scripts contain *public keys* (or their hashes; see *Address*) that allow only owner of a corresponding *private key* to redeem the bitcoins in the output.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
_DESCRIPTION:
Pubkey
Pubkey outputs are a simplified form of the P2PKH pubkey script, but they aren’t as secure as P2PKH, so they generally aren’t used in new transactions anymore.
Pubkey script: <pubkey> OP_CHECKSIG
Signature script: <sig>
[https://bitcoin.org/en/developer-guide#pubkey]
name::
* McsEngl.btcscriptPubKey.multisig@cptIt,
* McsEngl.btcM-of-N-Multisig@cptIt,
* McsEngl.btcmultisig@cptIt,
* McsEngl.btcMultisig-Output@cptIt,
_DESCRIPTION:
A pubkey script that provides n number of pubkeys and requires the corresponding signature script provide m minimum number signatures corresponding to the provided pubkeys.
[https://bitcoin.org/en/glossary/multisig]
name::
* McsEngl.btcscriptPubKey.P2PKH-address@cptIt,
* McsEngl.btcP2PKH-Output@cptIt,
_DESCRIPTION:
In a P2PKH output, the pubkey script is:
OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG
[https://bitcoin.org/en/developer-guide#p2pkh-script-validation]
name::
* McsEngl.btcscriptSig'secp256k1-signature@cptIt,
* McsEngl.btcscriptSig'sig@cptIt,
* McsEngl.btcscriptSig'signature@cptIt,
* McsEngl.btcsecp256k1-signature@cptIt,
* McsEngl.btcstl'sig@cptIt,
* McsEngl.btcECDSA-signature@cptIt,
* McsEngl.btcstl'secp256k1-signature@cptIt,
_DESCRIPTION:
Signature, ECDSA Signature
A value related to a public key which could only have reasonably been created by someone who has the private key that created that public key. Used in Bitcoin to authorize spending satoshis previously sent to a public key.
[https://bitcoin.org/en/glossary/signature]
name::
* McsEngl.btcscriptSig.P2PKH-address@cptIt,
* McsEngl.btcscriptSig.P2PKH@cptIt,
_DESCRIPTION:
In a P2PKH transaction, the signature script contains an secp256k1 signature (sig) and full public key (pubkey), creating the following concatenation:
<Sig> <PubKey> OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG
[https://bitcoin.org/en/developer-guide#p2pkh-script-validation]
name::
* McsEngl.btcstl'script.P2PKH@cptIt,
_DESCRIPTION:
Pay To Public Key Hash (P2PKH)
P2PKH is the most common form of pubkey script used to send a transaction to one or multiple Bitcoin addresses.
Pubkey script: OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Signature script: <sig> <pubkey>
[https://bitcoin.org/en/developer-guide#standard-transactions]
name::
* McsEngl.btcstl'script.P2SH@cptIt,
_DESCRIPTION:
Pay To Script Hash (P2SH)
P2SH is used to send a transaction to a script hash.
Each of the standard pubkey scripts can be used as a P2SH redeem script, but in practice only the multisig pubkey script makes sense until more transaction types are made standard.
Pubkey script: OP_HASH160 <Hash160(redeemScript)> OP_EQUAL
Signature script: <sig> [sig] [sig...] <redeemScript>
[https://bitcoin.org/en/developer-guide#pay-to-script-hash-p2sh]
===
Pay_to_Script_Hash:
A type of the *script* and *address* that allows sending bitcoins to arbitrary complex scripts using a compact hash of that script.
This allows payer to pay much smaller *transaction fees* and not wait very long for a *non-standard* transaction to get included in the blockchain.
Then the actual script matching the hash must be provided by the payee when redeeming the funds.
P2SH addresses are encoded in *Base58Check* just like regular public keys and start with number "3".
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcstl'script.Multisig@cptIt,
_DESCRIPTION:
Multisig
Although P2SH multisig is now generally used for multisig transactions, this base script can be used to require multiple signatures before a UTXO can be spent.
In multisig pubkey scripts, called m-of-n, m is the minimum number of signatures which must match a public key; n is the number of public keys being provided. Both m and n should be opcodes OP_1 through OP_16, corresponding to the number desired.
Because of an off-by-one error in the original Bitcoin implementation which must be preserved for compatibility, OP_CHECKMULTISIG consumes one more value from the stack than indicated by m, so the list of secp256k1 signatures in the signature script must be prefaced with an extra value (OP_0) which will be consumed but not used.
The signature script must provide signatures in the same order as the corresponding public keys appear in the pubkey script or redeem script. See the description in OP_CHECKMULTISIG for details.
Pubkey script: <m> <A pubkey> [B pubkey] [C pubkey...] <n> OP_CHECKMULTISIG
Signature script: OP_0 <A sig> [B sig] [C sig...]
Although it’s not a separate transaction type, this is a P2SH multisig with 2-of-3:
Pubkey script: OP_HASH160 <Hash160(redeemScript)> OP_EQUAL
Redeem script: <OP_2> <A pubkey> <B pubkey> <C pubkey> <OP_3> OP_CHECKMULTISIG
Signature script: OP_0 <A sig> <C sig> <redeemScript>
[https://bitcoin.org/en/developer-guide#multisig]
name::
* McsEngl.btcstl'script.Null-data@cptIt,
_DESCRIPTION:
Null Data
Null data transaction type relayed and mined by default in Bitcoin Core 0.9.0 and later that adds arbitrary data to a provably unspendable pubkey script that full nodes don’t have to store in their UTXO database. It is preferable to use null data transactions over transactions that bloat the UTXO database because they cannot be automatically pruned; however, it is usually even more preferable to store data outside transactions if possible.
Consensus rules allow null data outputs up to the maximum allowed pubkey script size of 10,000 bytes provided they follow all other consensus rules, such as not having any data pushes larger than 520 bytes.
Bitcoin Core 0.9.x to 0.10.x will, by default, relay and mine null data transactions with up to 40 bytes in a single data push and only one null data output that pays exactly 0 satoshis:
Pubkey Script: OP_RETURN <0 to 40 bytes of data>
(Null data scripts cannot be spent, so there's no signature script.)
Bitcoin Core 0.11.x increases this default to 80 bytes, with the other rules remaining the same.
Bitcoin Core 0.12.0 defaults to relaying and mining null data outputs with up to 83 bytes with any number of data pushes, provided the total byte limit is not exceeded. There must still only be a single null data output and it must still pay exactly 0 satoshis.
The -datacarriersize Bitcoin Core configuration option allows you to set the maximum number of bytes in null data outputs that you will relay or mine.
[https://bitcoin.org/en/developer-guide#null-data]
name::
* McsEngl.btcstl'Evaluation@cptIt,
_DESCRIPTION:
However, the scripting language as implemented in Bitcoin has several important limitations:
Lack of Turing-completeness - that is to say, while there is a large subset of computation that the Bitcoin scripting language supports, it does not nearly support everything. The main category that is missing is loops. This is done to avoid infinite loops during transaction verification; theoretically it is a surmountable obstacle for script programmers, since any loop can be simulated by simply repeating the underlying code many times with an if statement, but it does lead to scripts that are very space-inefficient. For example, implementing an alternative elliptic curve signature algorithm would likely require 256 repeated multiplication rounds all individually included in the code.
Value-blindness -
there is no way for a UTXO script to provide fine-grained control over the amount that can be withdrawn.
For example, one powerful use case of an oracle contract would be a hedging contract, where A and B put in $1000 worth of BTC and after 30 days the script sends $1000 worth of BTC to A and the rest to B.
This would require an oracle to determine the value of 1 BTC in USD, but even then it is a massive improvement in terms of trust and infrastructure requirement over the fully centralized solutions that are available now.
However, because UTXO are all-or-nothing, the only way to achieve this is through the very inefficient hack of having many UTXO of varying denominations (eg. one UTXO of 2k for every k up to 30) and having O pick which UTXO to send to A and which to B.
Lack of state -
UTXO can either be spent or unspent; there is no opportunity for multi-stage contracts or scripts which keep any other internal state beyond that.
This makes it hard to make multi-stage options contracts, decentralized exchange offers or two-stage cryptographic commitment protocols (necessary for secure computational bounties).
It also means that UTXO can only be used to build simple, one-off contracts and not more complex "stateful" contracts such as decentralized organizations, and makes meta-protocols difficult to implement.
Binary state combined with value-blindness also mean that another important application, withdrawal limits, is impossible.
Blockchain-blindness -
UTXO are blind to certain blockchain data such as the nonce and previous block hash.
This severely limits applications in gambling, and several other categories, by depriving the scripting language of a potentially valuable source of randomness.
[https://github.com/ethereum/wiki/wiki/White-Paper#scripting]
name::
* McsEngl.btcstl'Execution@cptIt,
* McsEngl.btcspt'execution@cptIt,
* McsEngl.btcspt'validation@cptIt,
* McsEngl.btcspt'verification@cptIt,
_DESCRIPTION:
To test whether the transaction is valid, signature script and pubkey script operations are executed one item at a time, starting with Bob’s signature script and continuing to the end of Alice’s pubkey script.
[https://bitcoin.org/en/developer-guide#p2pkh-script-validation]
===
scriptIpt: <Sig> <PubKey>
scriptOpt: OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG
<Sig> <PubKey> OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG
DOING:
1. CODE: <Sig> STACK: <Sig>
The signature (from Bob’s signature script) is added (pushed) to an empty stack. Because it’s just data, nothing is done except adding it to the stack.
2. CODE: <PubKey> STACK: <PubKey><Sig>
The public key (also from the signature script) is pushed on top of the signature.
3. CODE: OP_DUP STACK: <PubKey><PubKey><Sig>
From Alice’s pubkey script, the OP_DUP operation is executed. OP_DUP pushes onto the stack a copy of the data currently at the top of it—in this case creating a copy of the public key Bob provided.
4. CODE: OP_HASH160 STACK: <PubKeyHash><PubKey><Sig>
The operation executed next, OP_HASH160, pushes onto the stack a hash of the data currently on top of it—in this case, Bob’s public key. This creates a hash of Bob’s public key.
5. CODE: <PubKeyHash> STACK: <PubKeyHash><PubKeyHash><PubKey><Sig>
Alice’s pubkey script then pushes the pubkey hash that Bob gave her for the first transaction. At this point, there should be two copies of Bob’s pubkey hash at the top of the stack.
6. CODE: OP_EQUALVERIFY STACK: <PubKey><Sig>
Now it gets interesting: Alice’s pubkey script executes OP_EQUALVERIFY.
OP_EQUALVERIFY is equivalent to executing OP_EQUAL followed by OP_VERIFY (not shown).
OP_EQUAL (not shown) checks the two values at the top of the stack; in this case, it checks whether the pubkey hash generated from the full public key Bob provided equals the pubkey hash Alice provided when she created transaction#1.
OP_EQUAL pops (removes from the top of the stack) the two values it compared, and replaces them with the result of that comparison: zero (false) or one (true).
OP_VERIFY (not shown) checks the value at the top of the stack.
If the value is false it immediately terminates evaluation and the transaction validation fails.
Otherwise it pops the true value off the stack.
7. CODE: OP_CHECKSIG STACK: true
Finally, Alice’s pubkey script executes OP_CHECKSIG, which checks the signature Bob provided against the now-authenticated public key he also provided.
If the signature matches the public key and was generated using all of the data required to be signed, OP_CHECKSIG pushes the value true onto the top of the stack.
If false is not at the top of the stack after the pubkey script has been evaluated, the transaction is valid (provided there are no other problems with it).
[https://bitcoin.org/en/developer-guide#p2pkh-script-validation]
name::
* McsEngl.btctx'Priority@cptIt,
* McsEngl.btcpriority@cptIt,
_DESCRIPTION:
Priority
A scoring mechanism to help ensure that expensive data storage isn't consumed by lower quality and spam. Low priority transactions will not get included by a miner if the limited space is already filled by higher priority transactions. A transaction fee will affect priority.
[https://en.bitcoin.it/wiki/Vocabulary#Priority]
name::
* McsEngl.btctx'Time@cptIt,
_ADDRESS.WPG:
* https://cointelegraph.com/news/why-is-my-bitcoin-transaction-taking-so-long-heres-why,
name::
* McsEngl.btctx'Visibility@cptIt,
_DESCRIPTION:
Transactions are not encrypted, so it is possible to browse and view every transaction ever collected into a block.
All transactions are visible in the block chain, and can be viewed with a hex editor.
A block chain browser is a site where every transaction included within the block chain can be viewed in human-readable terms.
This is useful for seeing the technical details of transactions in action and for verifying payments.
[https://en.bitcoin.it/wiki/Transaction]
name::
* McsEngl.btctx'DOING@cptIt,
name::
* McsEngl.btctx'Confirmation@cptIt,
* McsEngl.bitcoin-transaction-confirmation@cptIt,
* McsEngl.btcconfirmation@cptIt,
* McsEngl.btctransaction-confirmation@cptIt,
====== lagoGreek:
* McsElln.επιβεβαίωση-συναλλαγής-μπιτκόιν@cptIt,
_DESCRIPTION:
Confirmation means that a transaction has been processed by the network and is highly unlikely to be reversed.
Transactions receive a confirmation when they are included in a block and for each subsequent block.
Even a single confirmation can be considered secure for low value transactions, although for larger amounts like 1000 US$, it makes sense to wait for 6 confirmations or more.
Each confirmation exponentially decreases the risk of a reversed transaction.
[https://bitcoin.org/en/vocabulary#confirmation]
===
Unconfirmed transactions aren't secure
Transactions don't start out as irreversible. Instead, they get a confirmation score that indicates how hard it is to reverse them (see table). Each confirmation takes between a few seconds and 90 minutes, with 10 minutes being the average. If the transaction pays too low a fee or is otherwise atypical, getting the first confirmation can take much longer.
Confirmations Lightweight wallets Bitcoin Core
0 Only safe if you trust the person paying you
1 Somewhat reliable Mostly reliable
3 Mostly reliable Highly reliable
6 Minimum recommendation for high-value bitcoin transfers
30 Recommendation during emergencies to allow human intervention
[https://bitcoin.org/en/you-need-to-know#instant]
===
Confirmation:
The act of hashing a bitcoin transaction successfully into a transaction block, and cementing its validity.
A single confirmation will take around 10 minutes, which is the average length of time for a transaction block to be hashed.
However, some more sensitive or larger transactions may require multiple confirmations, meaning that more blocks must be hashed and added to the blockchain after the transaction’s block has been hashed.
Each time another block is added to the blockchain after the transaction’s block, the transaction is confirmed again.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.btctx'Resource@cptIt,
_ADDRESS.WPG:
* https://www.blocktrail.com/BTC/tx/79ef1753f92c97e7f97eb01fa69d46838ab2924eb5655b10dac2b0cb479b66fd,
* https://en.bitcoin.it/wiki/Transaction,
name::
* McsEngl.btctx'blockchain.info-site@cptIt,
* McsEngl.blockchain.info-site@cptIt,
_DESCRIPTION:
We also have a website called https://blockchain.info/ where you can follow all the transactions that are happening in the Bitcoin network, you can get market and price information and even pull down data if you want to do some interesting statistical work.
For all the nerds out there we have developed a platform that allows enterprises and software programmers to build great things on top of the bitcoin protocol
[http://cointelegraph.com/news/our-goal-is-to-replace-your-need-for-a-bank-says-blockchain-co-founder-and-ceo-nicolas-cary]
===
Blockchain.info:
A web service running a Bitcoin *node* and displaying statistics and raw data of all the transactions and blocks.
It also provides a *web wallet* functionality with *lightweight clients* for Android, iOS and OS X.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btctx.specific@cptIt,
* McsEngl.btctx.specific@cptIt,
name::
* McsEngl.btctx.AGGREGATE@cptIt,
name::
* McsEngl.btctx.aggregate.DAY@cptIt,
_DESCRIPTION:
The bitcoin system can currently handle around 300,000 transactions per day
For comparison, Visa averages around 150 million transactions per day and reports the ability to handle more than 24,000 transactions per second.
[http://www.forbes.com/sites/realspin/2015/09/08/new-bitcoin-development-spurs-unnecessary-fear-of-centralization/]
name::
* McsEngl.btctx.aggregate.SECOND@cptIt,
With Thunder, a transaction is so fast that the network can process 100,000 transactions per second. On average, Visa handles 2,000 transactions per second and the Visa network is capable of processing 56,000 transactions per second.
To put this into perspective, Blockchain wallet users are on track to make 40 million transactions this year, or around 1.3 transaction per second. Quite impressive, but let’s be honest. While there are many other wallets out there, given that Blockchain is the most popular wallet maker, bitcoin transaction volume is very far behind Visa. Reason of this lies in the fact that bitcoin transactions have been too cumbersome. So I’m convinced projects like Thunder are part of the solution.
[http://techcrunch.com/2016/05/16/blockchain-open-sources-thunder-network-paving-the-way-for-instant-bitcoin-transactions/?ncid=rss]
name::
* McsEngl.btctx.BIGEST-in-money@cptIt,
_DESCRIPTION:
The largest transaction processed so far by the network was 150 million US dollars, transmitted instantly and processed without any fees.
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
name::
* McsEngl.btctx.BINARY (raw)@cptIt,
* McsEngl.btctx.binary@cptIt,
* McsEngl.btctx.hexadecimal@cptIt,
* McsEngl.btctx.raw@cptIt,
* McsEngl.btcbinary-transaction-format@cptIt,
* McsEngl.btcSerialized-Transaction@cptIt,
* McsEngl.btcRaw-Transaction@cptIt,
* McsEngl.btcRaw-Transaction-format@cptIt,
_DESCRIPTION:
Serialized Transaction, Raw Transaction
Complete transactions in their binary format; often represented using hexadecimal.
Sometimes called raw format because of the various Bitcoin Core commands with “raw” in their names.
[https://bitcoin.org/en/glossary/serialized-transaction]
===
All transactions, including the coinbase transaction, are encoded into blocks in binary rawtransaction format.
The rawtransaction format is hashed to create the transaction identifier (txid).
[https://bitcoin.org/en/developer-guide#transaction-data]
name::
* McsEngl.btctx.COINBASE (new bitcoin)@cptIt,
* McsEngl.bitcoin-coinbase-transaction@cptIt,
* McsEngl.btctx.coinbase@cptIt,
* McsEngl.btccoinbase-transaction@cptIt,
* McsEngl.btcgeneration-transaction@cptIt,
* McsEngl.btctx.generation@cptIt,
_DESCRIPTION:
In principle, there are two types of transactions, coinbase transactions and regular transactions.
Coinbase transactions are special transactions in which new Bitcoins are introduced into the system.
They are included in every block as the very first transaction and are meant as a reward for solving a proof of work puzzle.
Regular transactions, on the other hand, are used to transfer existing Bitcoins amongst different users.
From an architectural point of view, a coinbase transaction can be seen as a special case of a regular transaction.
For this reason, the structure of a regular transaction will be discussed first, followed by the differences between coinbase and regular transactions.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
===
The first transaction in a block.
Always created by a miner, it includes a single coinbase.
[https://bitcoin.org/en/glossary/coinbase-transaction]
===
Coinbase transactions can only be created by Bitcoin miners#ql:btcminer# and they’re an exception to many of the rules listed below.
[https://bitcoin.org/en/developer-guide#transactions]
===
Coinbase:
Another name for the input used in a bitcoin’s generation transaction.
When a bitcoin is mined, it doesn't come from another bitcoin user, but is generated as a reward for the miner.
That reward is recorded as a transaction, but instead of another user's bitcoin address, some arbitrary data is used as the input.
Coinbase is also the name of a bitcoin wallet service that also offers payment processing services for merchants and acts as an intermediary for purchasing bitcoins from exchanges.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.btctxCnbs'Extra-nonce@cptIt,
* McsEngl.bitcoin-extra-nonce@cptIt,
* McsEngl.btcextra-nonce@cptIt,
_DESCRIPTION:
Extra_nonce:
A number placed in *coinbase* script and incremented by a miner each time the *nonce* 32-bit integer overflows.
This is not the required way to continue mining when nonce overflows, one can also change the *merkle tree* of transactions or change a public key used for collecting a block *reward*.
See also *nonce*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btctxCnbs'UTXO@cptIt,
* McsEngl.bitcoin-extra-nonce@cptIt,
* McsEngl.btcextra-nonce@cptIt,
_DESCRIPTION:
UTXO:
The UTXO#ql:idBtctxoutSpntNo# of a coinbase transaction has the special condition that it cannot be spent (used as an input) for at least 100 blocks.
This temporarily prevents a miner from spending the transaction fees and block reward from a block that may later be determined to be stale (and therefore the coinbase transaction destroyed) after a block chain fork.
[https://bitcoin.org/en/developer-guide#transaction-data]
name::
* McsEngl.btctx.COINBASE.NO (regular)@cptIt,
* McsEngl.btcregular-transaction@cptIt,
* McsEngl.btctx.regular@cptIt,
_DESCRIPTION:
In principle, there are two types of transactions, coinbase transactions and regular transactions.
Coinbase transactions are special transactions in which new Bitcoins are introduced into the system.
They are included in every block as the very first transaction and are meant as a reward for solving a proof of work puzzle.
Regular transactions, on the other hand, are used to transfer existing Bitcoins amongst different users.
From an architectural point of view, a coinbase transaction can be seen as a special case of a regular transaction.
For this reason, the structure of a regular transaction will be discussed first, followed by the differences between coinbase and regular transactions.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
_PART:
Every transaction consists of
- a transaction version (nVersion),
- a vector of inputs (vin) and
- a vector of outputs (vout), both preceded by their count, and
- a transaction inclusion date (nLockTime).
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
name::
* McsEngl.btctx.CONFIRMED@cptIt,
* McsEngl.btcConfirmed-transaction@cptIt,
_DESCRIPTION:
Confirmed_Transaction:
Transaction that has been included in the blockchain.
Probability of transaction being rejected is measured in a number of confirmations.
See *Confirmation Number*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
Confirmation Score: A score indicating the number of blocks on the best block chain that would need to be modified to remove or modify a particular transaction.
A confirmed transaction has a confirmation score of one or higher.
[https://bitcoin.org/en/glossary/confirmation-score]
name::
* McsEngl.btcconfirmation-number@cptIt,
* McsEngl.btctx'confirmation-number@cptIt,
_DESCRIPTION:
Confirmation_Number:
Confirmation number is a measure of probability that transaction could be rejected from the *main chain*.
"Zero confirmations" means that transaction is *unconfirmed* (not in any block yet).
One confirmation means that the transaction is included in the latest block in the main chain.
Two confirmations means the transaction is included in the block right before the latest one.
And so on.
Probability of transaction being reversed (*"double spent"*) is diminishing exponentially with more blocks added "on top" of it.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.bitcoin-Zero-confirmation-transaction@cptIt,
* McsEngl.btcZero-confirmation-transaction@cptIt,
_DESCRIPTION:
Zero_confirmation_transaction:
A transaction in which the merchant is happy to provide a product or service before the bitcoin’s transmission has been confirmed by a miner and added to the blockchain.
It can carry a risk of double spending.
name::
* McsEngl.btctx.CONFIRMED.NO@cptIt,
* McsEngl.btc0-confirmation-transaction@cptIt,
* McsEngl.btcUnconfirmed-transaction@cptIt,
* McsEngl.btczero-confirmation-transaction@cptIt,
_DESCRIPTION:
Unconfirmed_Transaction:
Transaction that is not included in any block.
Also known as "0-confirmation" transaction.
Unconfirmed transactions are *relayed* by the nodes and stay in their *mempools*.
Unconfirmed transaction stays in the pool until the node decides to throw it away, finds it in the blockchain, or includes it in the blockchain itself (if it's a miner).
See also *Confirmation Number*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.bitcoin-mempool@cptIt,
* McsEngl.btcmempool@cptIt,
_DESCRIPTION:
Mempool:
A technical term for a collection of unconfirmed transactions stored by a node until they either expire or get included in the main chain.
When *reorganization* happens, transactions from orphaned blocks either become invalid (if already included in the *main chain*) or moved to a pool of unconfirmed transactions.
By default, bitcoind#ql:idBtcbitcoind# nodes throw away unconfirmed transactions after 24 hours.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btctx.CONTRACT@cptIt,
* McsEngl.btccontract@cptIt,
* McsEngl.bitcoin-contract@cptIt,
_DESCRIPTION:
Contracts are transactions which use the decentralized Bitcoin system to enforce financial agreements.
Bitcoin contracts can often be crafted to minimize dependency on outside agents, such as the court system, which significantly decreases the risk of dealing with unknown entities in financial transactions.
[https://bitcoin.org/en/developer-guide#contracts]
name::
* McsEngl.btctx.DUST@cptIt,
* McsEngl.btcDust-Transaction@cptIt,
_DESCRIPTION:
Dust transaction
A transaction for an extremely small amount of bitcoins, which offers little financial value, but takes up space in the blockchain.
The bitcoin developer team has taken efforts to eliminate dust transactions by increasing the minimum transaction amount that will be relayed by the network.
[http://www.coindesk.com/information/bitcoin-glossary/#dusttransaction]
name::
* McsEngl.btctx.HIGH-PRIORITY@cptIt,
* McsEngl.btcHigh-Priority-Transaction@cptIt,
* McsEngl.btcFree-Tx@cptIt,
_DESCRIPTION:
Transactions that don’t have to pay a transaction fee because their inputs have been idle long enough to accumulated large amounts of priority.
Note: miners choose whether to accept free transactions.
[https://bitcoin.org/en/glossary/high-priority-transaction]
name::
* McsEngl.btctx.MULTISIG@cptIt,
* McsEngl.btctx.multisig@cptIt,
* McsEngl.btcM-of-N-Multi-signature-Transaction@cptIt,
* McsEngl.btcMultisig-transaction@cptIt,
_DESCRIPTION:
M-of-N Multisig, Multisig Output
A pubkey script that provides n number of pubkeys and requires the corresponding signature script provide m minimum number signatures corresponding to the provided pubkeys.
[https://bitcoin.org/en/glossary/multisig]
===
M_of_N_Multi_signature_Transaction:
A transaction that can be spent using M signatures when N public keys are required (M is less or equal to N).
Multi-signature transactions that only contain one *OP_CHECKMULTISIG* opcode and N is 3, 2 or 1 are considered standard#ql:idBtctxStdrd#.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btctx.P2PKH@cptIt,
* McsEngl.btcPay-To-Public-Key-Hash-transaction@cptIt,
* McsEngl.btcP2PKH-transaction@cptIt,
name::
* McsEngl.btctx.P2SH@cptIt,
* McsEngl.btctx.P2SH@cptIt,
* McsEngl.btcPay-To-Script-Hash-transaction@cptIt,
_DESCRIPTION:
Pubkey scripts are created by spenders who have little interest what that script does. Receivers do care about the script conditions and, if they want, they can ask spenders to use a particular pubkey script. Unfortunately, custom pubkey scripts are less convenient than short Bitcoin addresses and there was no standard way to communicate them between programs prior to widespread implementation of the BIP70 Payment Protocol discussed later.
To solve these problems, pay-to-script-hash (P2SH) transactions were created in 2012 to let a spender create a pubkey script containing a hash of a second script, the redeem script.
[https://bitcoin.org/en/developer-guide#p2sh-scripts]
name::
* McsEngl.btctx.RELAYING@cptIt,
* McsEngl.btcSigned-transaction@cptIt,
_DESCRIPTION:
Relaying_Transactions:
Connected Bitcoin *nodes* relay new transactions between each other on best effort basis in order to send them to the *mining* nodes.
Some transactions may not be relayed by all nodes.
E.g. *non-standard* transactions, or transactions without a minimum *fee*.
Bitcoin message protocol is not the only way to send the transaction.
One may also send it directly to a miner, or mine it yourself, or send it directly to the payee and make them to relay or mine it.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btctx.SIGNED@cptIt,
* McsEngl.btcSigned-transaction@cptIt,
name::
* McsEngl.btctx.SIGNED.NO@cptIt,
* McsEngl.btcSignedNo-transaction@cptIt,
* McsEngl.btcUnsigned-transaction@cptIt,
name::
* McsEngl.btctx.STANDARD@cptIt,
* McsEngl.btcStandard-transaction@cptIt,
_DESCRIPTION:
After the discovery of several dangerous bugs in early versions of Bitcoin, a test was added which only accepted transactions from the network if their pubkey scripts and signature scripts matched a small set of believed-to-be-safe templates, and if the rest of the transaction didn’t violate another small set of rules enforcing good network behavior.
This is the IsStandard() test, and transactions which pass it are called 'defn.standard-transactions'.
[https://bitcoin.org/en/developer-guide#standard-transactions]
===
As of Bitcoin Core 0.9.3, standard transactions must also meet the following conditions:
The transaction must be finalized: either its locktime must be in the past (or less than or equal to the current block height), or all of its sequence numbers must be 0xffffffff.
The transaction must be smaller than 100,000 bytes. That’s around 200 times larger than a typical single-input, single-output P2PKH transaction.
Each of the transaction’s signature scripts must be smaller than 1,650 bytes. That’s large enough to allow 15-of-15 multisig transactions in P2SH using compressed public keys.
Bare (non-P2SH) multisig transactions which require more than 3 public keys are currently non-standard.
The transaction’s signature script must only push data to the script evaluation stack. It cannot push new opcodes, with the exception of opcodes which solely push data to the stack.
The transaction must not include any outputs which receive fewer than 1/3 as many satoshis as it would take to spend it in a typical input. That’s currently 546 satoshis for a P2PKH or P2SH output on a Bitcoin Core node with the default relay fee. Exception: standard null data outputs must receive zero satoshis.
[https://bitcoin.org/en/developer-guide#non-standard-transactions]
===
Some transactions are considered *standard*, meaning they are relayed and mined by most *nodes*.
More complex transactions could be buggy or cause DoS attacks on the network, so they are considered *non-standard* and not relayed or mined by most nodes.
Both standard and non-standard transactions are valid and once included in the blockchain, will be recognized by all nodes.
Standard transactions are:
1) sending to a *public key*,
2) sending to an *address*,
3) sending to a-P2SH-address#ql:idBtcadsP2sh#,
4) sending to *M-of-N multi-signature transaction* where N is 3 or less.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btctx.STANDARD.NO@cptIt,
* McsEngl.bitcoin-non-standard-transaction@cptIt,
* McsEngl.btcnon-standard-transaction@cptIt,
* McsEngl.btcStandardNo-transaction@cptIt,
_DESCRIPTION:
Non_standard_Transaction:
Any valid transaction that is not *standard*.
Non-standard transactions are not relayed or mined by default *BitcoinQT* nodes (but are relayed and mined on *testnet*).
However, if anyone puts such transaction in a block, it will be accepted by all nodes.
In practice it means that unusual transactions will take more time to get included in the blockchain.
If some kind of non-standard transaction becomes useful and popular, it may get named standard and adopted by users (like it ).
See also Standard Transaction#ql:idBtctxStdrd#.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btctx.VALID@cptIt,
* McsEngl.btcvalid-transaction@cptIt,
name::
* McsEngl.btctx.VALID.NO@cptIt,
* McsEngl.btcvalidNo-transaction@cptIt,
_DESCRIPTION:
Ignoring coinbase transactions (described later), if the value of a transaction’s outputs exceed its inputs, the transaction will be rejected.
[https://bitcoin.org/en/developer-guide#block-chain-overview]
name::
* McsEngl.btcbcn'Hashrate (btchhrt )@cptIt,
* McsEngl.btcmny'hashing-power@cptIt,
* McsEngl.btcnet'Hashing-power@cptIt,
* McsEngl.hash-rate-btcnet@cptIt,
_TIME:
3.39-Exahash#ql:exa# {2017-01-24}
_DESCRIPTION:
The hash rate is the measuring unit of the processing power of the Bitcoin network.
The Bitcoin network must make intensive mathematical operations for security purposes.
When the network reached a hash rate of 10 Th/s, it meant it could make 10 trillion calculations per second.
[https://bitcoin.org/en/vocabulary#hash-rate]
===
Hashrate:
A measure of mining hardware performance expressed in hashes per second (GH/s).
As of July 27, 2014 the hash rate of all Bitcoin mining nodes combined is around 135 799 000 GH/s.
For comparison, AMD Radeon graphics cards produce from 0.2 to 0.8 GH/s depending on model.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
Hash (Rate) ~ A hash is the output of a hash function and, as it relates to Bitcoin, the Hash Rate is the speed at which a compute is completing an operation in the Bitcoin code.
A higher hash rate is better when mining as it increases your opportunity of finding the next block and receiving the reward.
[http://bitcoinsimplified.org/definitions/]
name::
* McsEngl.btchhrt'Resource@cptIt,
Bitcoin’s Network Hash Rate Has Doubled Since October
Jan 23, 20174:20 PM EST by Kyle Torpey
Bitcoin’s mining difficulty increased by 16.6 percent over the weekend, signaling that the network’s overall hash rate has also increased by a similar amount over the past two weeks. The network’s total estimated hash rate has essentially doubled since the middle of October. A large chunk of this increase has taken place over the past month, where the hash rate has increased by more than 50 percent.
The network hash rate is the total amount of computing power pointed at the Bitcoin network.
Pools That Saw Their Share of Total Hashing Power Increase
It’s difficult to know where exactly this new hashing power is being deployed, but it is possible to see the differences in mining pools’ shares of the overall hash rate.
When comparing the most recently completed difficulty period with a run of 2016 blocks from the middle of October, GBMiners is the pool that saw the largest amount of growth. GBMiners enjoyed an increase of 62 blocks compared to the total set of 2016 blocks from October. Recently, it was found that GBMiners is connected to a Ponzi scheme disguised as a bitcoin cloud mining operation in India.
Since October, BTC.TOP has grown from nothing to roughly 3 percent of the network hash rate. Batpool also emerged during this period of time to grab a little over 1 percent of the network. Not much is known about either of these China-based pools, other than the fact that ltc1btc.com Founder and CEO Jiang Zhuo’er is behind BTC.TOP and does not much care for Bitcoin Core’s Segregated Witness improvement.
Both GBMiners and BTC.TOP signal support for Bitcoin Unlimited as opposed to Bitcoin Core. Bitcoin Unlimited is software that intends to replace Bitcoin’s 1 MB block size limit with the concept of emergent consensus. At this time, it is unclear if this new digital currency network would be a new version of Bitcoin or an altcoin.
In terms of pools signaling for Bitcoin Core’s Segregated Witness improvement, Bitfury saw the largest amount of growth. The mining pool saw an increase of just under 3 percent between the middle of October and the most recently completed difficulty period.
Pools That Saw Their Share of Total Hashing Power Decrease
If the above mining pools are mining more blocks, then that means someone else must be mining fewer blocks.
No miner saw a bigger drop in their share of the network since October than BTCC. BTCC now mines about 35 percent less blocks than they did in October.
No other pool came close to BTCC in terms of a loss in their share of the network hash rate, but ViaBTC and Slush Pool also saw notable declines. These two pools are mining about 25 percent less than the number of blocks they were mining in October.
The two largest mining pools on the network, Antpool and F2Pool, mined roughly 5 percent fewer blocks when their numbers were combined.
Although never the largest pools on the network, Bitcoin.com, GoGreenLight and Kano CKPool all saw sizable declines.
Hash Rate Continuing to Increase
Although the last difficulty period saw a rather massive increase of 16.6 percent, it appears that hash rate is continuing to be added to the network. At 118 blocks into the current difficulty period, there has already been another estimated 15.25 percent increase in the network hash rate.
Judging from the rapidly increasing hash rate, it appears multiple mining pools are receiving shipments of new hardware. While some predicted Bitcoin could crash and burn as a result of the halving event over the summer, the mining pools were correct in predicting a more positive outcome.
As Bitcoin’s total hash rate increases, it becomes more difficult for a motivated adversary to pull off an effective attack on the network.
Kyle Torpey by Kyle Torpey
Kyle Torpey is a freelance writer and researcher who has been following Bitcoin since 2011. His work has been featured on VICE Motherboard, Business Insider, NASDAQ, RT’s Keiser Report, and many other media outlets. You can follow @kyletorpey on Twitter.
[https://bitcoinmagazine.com/articles/bitcoins-network-hash-rate-has-doubled-october/]
name::
* McsEngl.btchhrt.KILOHASH/SEC (1000^1)@cptIt,
* McsEngl.btckilohash@cptIt,
_DESCRIPTION:
Kilohashes/sec:
The number of hashing#ql:idBcncrptchfhhng# attempts possible in a given second, measured in thousands of hashes.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.btchhrt.MEGGAHASH/SEC (1000^2)@cptIt,
* McsEngl.btcmegahash@cptIt,
_DESCRIPTION:
Megahashes/sec:
The number of hashing#ql:idBcncrptchfhhng# attempts possible in a given second, measured in millions of hashes (thousands of Kilohashes).
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.btchhrt.GIGAHASH/SEC (1000^3)@cptIt,
* McsEngl.btcgigahash@cptIt,
_DESCRIPTION:
Gigahashes/sec:
The number of hashing#ql:idBcncrptchfhhng# attempts possible in a given second, measured in billions of hashes (thousands of Megahashes).
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.btchhrt.TERAHASH/SEC (1000^4)@cptIt,
* McsEngl.btcterahash@cptIt,
_DESCRIPTION:
Terahashes/sec:
The number of hashing#ql:idBcncrptchfhhng# attempts possible in a given second, measured in trillions of hashes (thousands of Gigahashes).
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.btchhrt.PETAHASH/SEC (1000^5)@cptIt,
* McsEngl.btcpetahash@cptIt,
name::
* McsEngl.btchhrt.EXAHASH/SEC (1000^6)@cptIt,
* McsEngl.btcexahash@cptIt,
name::
* McsEngl.btcbcn'Crypto (btccrpt)@cptIt,
* McsEngl.bitcoin-crypto@cptIt,
* McsEngl.btccrypto@cptIt,
name::
* McsEngl.btccrpt'Hash-function@cptIt,
* McsEngl.bitcoin-hash-function@cptIt,
* McsEngl.btchash-function@cptIt,
_DESCRIPTION:
Hash-Function:
Bitcoin protocol mostly uses two cryptographic hash functions: SHA-256 and RIPEMD-160.
First one is almost exclusively used in the two round hashing (*Hash256*), while the latter one is only used in computing an *address* (see also *Hash160*).
*Scripts* may use not only Hash256 and Hash160, but also SHA-1, SHA-256 and RIPEMD-160.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
_GENERIC:
* cryptographic-hash-function#ql:idBcncrptchf#
name::
* McsEngl.btccrpt'To-hash@cptIt,
* McsEngl.bitcoin-hashing@cptIt,
* McsEngl.bitcoin-to-hash@cptIt,
* McsEngl.btchashing@cptIt,
* McsEngl.btcto-hash@cptIt,
_DESCRIPTION:
To_hash:
To compute a hash function of some data.
If hash function is not mentioned explicitly, it is the one defined by the context.
For instance, "to hash a transaction" means to compute Hash256#ql:idBtchsh256# of binary representation of a transaction.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btccrpt'Hash256@cptIt,
* McsEngl.btchash@cptIt,
* McsEngl.btchash256@cptIt,
_DESCRIPTION:
The-output of two executions of the-hash-function#ql:idBtccrpthf# SHA-256.
[hmnSngo.2017-04-08]
===
Hash, Hash256:
When not speaking about arbitrary hash functions, Hash refers to two rounds of SHA-256#ql:idBtccrptsha256#.
That is, you should compute a SHA-256 hash of your data and then another SHA-256 hash of that hash.
It is used in *block header* hashing, *transaction* hashing, making a *merkle tree* of transactions, or computing a checksum of an *address*.
Known as BTCHash256() in CoreBitcoin, Hash() in BitcoinQT.
It is also available in scripts as OP_HASH256.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
'def.SHA-256d' is also known as Double SHA-256 hash algorithm.
It is a cryptographic hash, first proposed by Ferguson and Schneier in the book “Practical Cryptography”.
Bitcoin is one such cryptocurrency that utilizes the SHA-256d hashing algorithm.
The SHA-256d hash is achieved by applying the regular SHA-256 hash twice, by first applying SHA-256 hash to the data and then once again to the resulting hash.
Many of the early released cryptocurrencies uses the SHA-256d algorithm such as: Bitcoin, Freicoin, Namecoin and Peercoin.
[https://cryptojunction.com/questions/question/what-is-the-difference-between-the-sha256d-and-sha256-hashing-algorithm]
name::
* McsEngl.bitcoin-SHA-256@cptIt,
* McsEngl.btcSHA-256@cptIt,
_DESCRIPTION:
SHA-2 includes significant changes from its predecessor, SHA-1.
The SHA-2 family consists of six hash functions#ql:idBtccrpthf# with digests (hash values) that are 224, 256, 384 or 512 bits: SHA-224, 'defn.SHA-256', SHA-384, SHA-512, SHA-512/224, SHA-512/256.
[https://en.wikipedia.org/wiki/SHA-2]
===
SHA-256:
The cryptographic function used as the basis for bitcoin’s proof of work system.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.btccrpt'Signature@cptIt,
* McsEngl.bitcoin-signature@cptIt,
* McsEngl.btcsignature@cptIt,
_DESCRIPTION:
Signature:
A sequence of bytes that proves that a piece of data is acknowledged by a person holding a certain *public key*.
Bitcoin uses ECDSA#ql:idBtccrptecdsa# for signing transactions.
Amounts of bitcoins are sent through a chain of transactions: from one to another.
Every transaction must provide a signature matching a public key defined in the previous transaction.
This way only a proper owner a secret *private key* associated with a given public key can spend bitcoins further.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
Signature:
A digital digest produced by hashing#ql:idBcncrptchfhhng# private and public keys together to prove that a bitcoin transaction came from a particular address.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.btccrpt'Elliptic-Curve-Arithmetic@cptIt,
* McsEngl.btcElliptic-Curve-Arithmetic@cptIt,
_DESCRIPTION:
Elliptic_Curve_Arithmetic:
A set of mathematical operations defined on a group of points on a 2D elliptic curve.
Bitcoin protocol uses predefined curve https://en.bitcoin.it/wiki/Secp256k1.
Here's the simplest possible explanation of the operations: you can add and subtract points and multiply them by an integer.
Dividing by an integer is computationally infeasible (otherwise cryptographic signatures won't work).
The private key is a 256-bit integer and the public key is a product of a predefined point G ("generator") by that integer: A = G * a.
Associativity law allows implementing interesting cryptographic schemes like Diffie-Hellman key exchange (ECDH): two parties with private keys *a* and *b* may exchange their public keys *A* and *B* to compute a shared secret point C: C = A * b = B * a because (G * a) * b == (G * b) * a.
Then this point C can be used as an AES encryption key to protect their communication channel.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btccrpt'ECDSA@cptIt,
* McsEngl.btcECDSA@cptIt,
* McsEngl.btcElliptic-Curve-Digital-Signature-Algorithm@cptIt,
_DESCRIPTION:
ECDSA:
Stands for Elliptic Curve Digital Signature Algorithm.
Used to verify transaction ownership when making a transfer of bitcoins.
See *Signature*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
ECDSA:
The Elliptic Curve Digital Signature Algorithm is the lightweight cryptographic algorithm used to sign transactions in the Bitcoin protocol.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.btccrpt'CompactSize@cptIt,
* McsEngl.btccompactSize@cptIt,
* McsEngl.btcSatshi's-encoding@cptIt,
_DESCRIPTION:
CompactSize:
Original name of a variable-length integer format used in transaction and block serialization.
Also known as "Satoshi's encoding".
It uses 1, 3, 5 or 9 bytes to represent any 64-bit unsigned integer.
Values lower than 253 are represented with 1 byte.
Bytes 253, 254 and 255 indicate 16-, 32- or 64-bit integer that follows.
Smaller numbers can be presented differently.
In *bitcoin-ruby* it is called "var_int", in *Bitcoinj* it is VarInt.
*BitcoinQT* also has even more compact representation called VarInt which is not compatible with CompactSize and used in block storage.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcbcn'Evaluation@cptIt,
* McsEngl.bitcoin-blockchain-evaluation@cptIt,
_DESCRIPTION:
However, another, arguably more important, part of the Bitcoin experiment is the underlying blockchain technology as a tool of distributed consensus, and attention is rapidly starting to shift to this other aspect of Bitcoin.
[https://github.com/ethereum/wiki/wiki/White-Paper]
name::
* McsEngl.btcbcn'Size@cptIt,
{time.2015}:
=== the full 35 gigabyte Blockchain
[http://bravenewcoin.com/news/the-decline-in-bitcoins-full-nodes/]
{time.2014.04}:
A “full node” in the Bitcoin network, one that stores and processes the entirety of every block, takes up about 15 GB of disk space in the Bitcoin network as of April 2014, and is growing by over a gigabyte per month.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
name::
* McsEngl.btcbcn'Resource@cptIt,
_ADDRESS.WPG:
* http://www.weforum.org/agenda/2015/12/what-is-the-future-of-blockchain//
* http://recode.net/2015/07/05/forget-bitcoin-what-is-the-blockchain-and-why-should-you-care//
name::
* McsEngl.btcbcn'Doing@cptIt,
_MAINTAINANCE:
The block chain is collaboratively maintained by anonymous peers on the network, so Bitcoin requires that each block prove a significant amount of work was invested in its creation to ensure that untrustworthy peers who want to modify past blocks have to work harder than honest peers who only want to add new blocks to the block chain.
[https://bitcoin.org/en/developer-guide#proof-of-work]
name::
* McsEngl.btcbcn'Changing@cptIt,
_ADDRESS.WPG:
* Blockchain Rule Update Process: https://gist.github.com/gavinandresen/2355445,
name::
* McsEngl.btcbcn'Synchronizing@cptIt,
* McsEngl.bitcoin-locks-first-sync@cptIt,
* McsEngl.btcBlocks-First-Sync@cptIt,
_DESCRIPTION:
Synchronizing the block chain by downloading each block from a peer and then validating it.
[https://bitcoin.org/en/glossary/blocks-first-sync]
name::
* McsEngl.btcbcn'Split@cptIt,
* McsEngl.bitcoin-blockchain-split@cptIt,
* McsEngl.bitcoin-split@cptIt,
* McsEngl.btcblockchain-split@cptIt,
_DESCRIPTION:
Blockchain-split is the-process at which a-blockchain-network is-split into two networks.
The-blockchain of the-new-networks is the-same until the-timepoint of split, but different after that timepoint.
[hmnSngo.2017-04-07]
===
Andreas@aantonop
Needs repeating...
Users: If you hold bitcoin and there is a HF, you will now own bitcoin on both forks. You don't need to do anything.
[https://twitter.com/aantonop/status/841347865972740097 {2017-03-13}]
_ADDRESS.WPG:
* {2017-03-20} https://news.bitcoin.com/this-happens-to-your-coins-during-a-bitcoin-hard-fork-and-possible-blockchain-split//
name::
* McsEngl.btcbcn'doing.FORK@cptIt,
* McsEngl.btcfork@cptIt,
_DESCRIPTION:
The creation of an alternative ongoing version of the blockchain, typically because one set of miners begins hashing a different set of transaction blocks from another.
It can be caused maliciously, by a group of miners gaining too much control over the network (see 51% attack), accidentally, thanks to a bug in the system, or intentionally, when a core development team decides to introduce substantial new features into a new version of a client.
A fork is successful if it becomes the longest version of the blockchain, as defined by difficulty.
[http://www.coindesk.com/information/bitcoin-glossary//]
===
Fork:
Refers either to
- a fork of a source code (see *Altcoin*) or,
- more often, to a split of the blockchain when two different parts of the network see different *main chains*.
In a sense, fork occurs every time two blocks of the same *height* are created at the same time.
Both blocks always have the different hashes (and therefore different *difficulty*), so when a node sees both of them, it will always choose the most difficult one.
However, before both blocks arrive to a majority of nodes, two parts of the network will see different blocks as tips of the main chain.
Term *fork* or *hard fork* also refers to a change of the protocol that may lead to a split of the network (by design or because of a bug).
On March 11 2013 a smaller half of the network running version 0.7 of *bitcoind* could not include a large (>900 Kb) block at height 225430 created by a miner running newer version 0.8.
The block could not be included because of the bug in v0.7 which was fixed in v0.8.
Since the majority of computing power did not have a problem, it continued to build a chain on top of a problematic block.
When the issue was noticed, majority of 0.8 miners agreed to abandon 24 blocks incompatible with 0.7 miners and mine on top of 0.7 chain.
Except for one double spend experiment against OKPay, all transactions during the fork were properly included in both sides of the blockchain.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcbcn'fork.HARD@cptIt,
* McsEngl.btchard-fork@cptIt,
* McsEngl.btcHard-Forking-Change@cptIt,
_DESCRIPTION:
A permanent divergence in the the block chain, commonly occurs when non-upgraded nodes can’t validate blocks created by upgraded nodes that follow newer consensus rules.
[https://bitcoin.org/en/glossary/hard-fork]
===
Hard fork:
Some people use the term hard fork to stress that changing Bitcoin protocol requires overwhelming majority to agree with it, or some noticeable part of the economy will continue with original blockchain following the old rules.
See *Fork* and *Soft Fork* for further discussion.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcbcn'fork.SOFT@cptIt,
* McsEngl.btcsoft-fork@cptIt,
* McsEngl.btcSoft-Forking-Change@cptIt,
_DESCRIPTION:
A temporary fork in the block chain which commonly occurs when miners using non-upgraded nodes violate a new consensus rule their nodes don’t know about.
[https://bitcoin.org/en/glossary/soft-fork]
===
Soft_Fork:
Sometimes the *soft fork* refers to an important change of software behavior that is not a *hard fork* (e.g. changing *mining fee* policy).
See also *Hard Fork* and *Fork#ql:btcfork#*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcbcn.BEST@cptIt,
* McsEngl.bitcoin-best-blockchain@cptIt,
* McsEngl.btcBest-block-chain@cptIt,
* McsEngl.btcbest-blockchain@cptIt,
_DESCRIPTION:
block-chain: A chain of blocks with each block referencing the block that preceded it.
The most-difficult-to-recreate chain is the best block chain.
[https://bitcoin.org/en/glossary/block-chain]
===
Main Chain
The longest Block Chain.
[https://en.bitcoin.it/wiki/Vocabulary#Main_Chain]
name::
* McsEngl.btcnet'Consensus-Exchange-Value-Token (BTCcevt)@cptIt,
* McsEngl.conceptIt98.23,
* McsEngl.bitcoin-consensus-exval-token@cptIt, {2017-03-31}
* McsEngl.btccevt@cptIt, {2017-03-31}
* McsEngl.bitcoin-currency@cptIt,
* McsEngl.bitcoin-token@cptIt,
* McsEngl.bitcoin-value@cptIt, {2017-04-11}
* McsEngl.btc@cptIt,
* McsEngl.btcc@cptIt,
* McsEngl.btcevtkn@cptIt,
* McsEngl.mnyBtc@cptIt,
* McsEngl.bitcoin@cptIt,
* McsEngl.btcc@cptIt,
* McsEngl.BTC@cptIt, {2012-07-12}
* McsEngl.btcMny@cptIt,
* McsEngl.currency.bitcoin@cptIt, {2012-07-12}
* McsEngl.mnyBtc@cptIt,
* McsEngl.netBtc'currency@cptIt,
* McsEngl.XBT@cptIt,
* McsElln.μπικόιν-αξία@cptIt,
* McsElln.μπικόιν-νόμισμα@cptIt,
=== _NOTES: BTC:
The most popular informal currency code for 1 Bitcoin (defined as 100 000 000 *Satoshis*).
See also *XBT* and *Bit*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
XBT:
Informal currency code for 1 Bitcoin (defined as 100 000 000 *Satoshis*).
Some people proposed using it for 0.01 Bitcoin to avoid confusion with *BTC*.
There were rumors that Bloomberg tests XBT as a ticker for 1 Bitcoin, but currently there is only ticker XBTFUND for SecondMarket's Bitcoin Investment Trust.
See also *BTC*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
_DESCRIPTION:
Bitcoin-BTC is the-consensus-exval-token#ql:idBcncet# of the-bitcoin-network.
[hmnSgm-2017-04-04]
_GENERIC:
* consensus-exval-token#ql:idBcncet#,
* global-digital-currency,
_DESCRIPTION:
2) The currency units used on this payment system have a market price, based purely on supply and demand.
Currently one bitcoin is worth about $12 USD, and there are a couple dozen exchanges around the world which enable conversion between normal government currencies and bitcoins.
The currency unit can be divided to eight decimal places (so you can send someone 0.00000001 bitcoins).
There are about 10 million bitcoins currently in existence (as of Sept. 2012) and there will never be more than 21 million in existence.
They are released in blocks of 50 bitcoins at a time every ten minutes and this amount gets cut in half every four years (thus creating the limit of 21 million coins).
[http://keepyourassets.net/2012/09/27/bitcoin-the-first-five-questions/]
_DESCRIPTION:
Bitcoin is an experimental new digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Bitcoin is also the name of the open source software which enables the use of this currency.
[http://bitcoin.org/] {2012-05-27}
_DESCRIPTION:
Bitcoin is one of the first implementations of a concept called crypto-currency, which was first described in 1998 by Wei Dai on the cypherpunks mailing list. Building upon the notion that money is any object, or any sort of record, accepted as payment for goods and services and repayment of debts in a given country or socio-economic context, Bitcoin is designed around the idea of using cryptography to control the creation and transfer of money, rather than relying on central authorities.
[http://bitcoin.org/about.html]
name::
* McsEngl.btccevt'adoption@cptIt,
* McsEngl.btccevt'acceptance@cptIt,
* McsEngl.btccevt'usage@cptIt,
* McsEngl.btcacceptance@cptIt,
* McsEngl.btcadoption@cptIt,
* McsEngl.btcusage@cptIt,
_ADDRESS.WPG:
* https://cointelegraph.com/news/around-the-world-in-18-months-using-only-bitcoins-felix-weiss-big-adventure,
* http://cointelegraph.com/news/bitcoin-gambling-is-exploding,
* https://weacceptbitcoin.gr//
* http://cointelegraph.com/news/venezuela-economy-bitcoin,
* http://techcrunch.com/2016/03/16/why-latin-american-economies-are-turning-to-bitcoin//
_DESCRIPTION:
How extensively is Bitcoin used? Well, around the world there are somewhere between 100,000 and 1,000,000 users, some of whom use it frequently and some who use it only on occasion. Several million dollars worth are transferred per day, but it is impossible to know for what purpose. In the last 24 hours, about 30,000 transactions occurred, or over one thousand transactions per hour. Since Bitcoins are exchanged back and forth with standard government currencies, the volume of this trading is about $100,000-$500,000 worth per day. Usage is increasing rapidly around the world, a chart of transactions can be found here: http://blockchain.info/charts/n-transactions?showDataPoints=false×pan=all&show_header=true&daysAverageString=7&scale=0&address= and more basic economic stats can be found here: http://bitcoinwatch.com/
[http://keepyourassets.net/2012/09/27/bitcoin-the-first-five-questions/]
_ADDRESS.WPG:
* accounting: https://cointelegraph.com/news/ey-switzerland-world-top-four-accounting-firm-to-accept-bitcoin,
* traveling: http://www.bookwithbit.com//
name::
* McsEngl.btccevt'Distribution@cptIt,
_DESCRIPTION:
So, as of Dec. 3., using a price of $1,000 (which is basically where we are now), and assuming 12 million Bitcoins in circulation, here's the breakdown: 47 individuals own 28.9% of the approximately 12 million Bitcoins in existence so far. Another 880 own 21.5%, meaning 927 people control half of the entire market cap of the digital currency. Another 10,000 individuals control about a quarter. And the rest of us (around a million of us) get the crumbs (500,000 are out of circulation, whether through government seizure or people losing their passwords).
[http://www.businessinsider.com/927-people-own-half-of-the-bitcoins-2013-12]
name::
* McsEngl.btccevt'Exchange-rate@cptIt,
* McsEngl.bitcoin-exchange-rate@cptIt,
* McsEngl.bitcoin-price@cptIt,
* McsEngl.bitcoin-rate@cptIt,
* McsEngl.btc'price@cptIt,
* McsEngl.btccevt'value@cptIt,
* McsEngl.btcprice@cptIt,
* McsEngl.btcrate@cptIt,
* McsEngl.btcvalue@cptIt,
_DESCRIPTION:
Bitcoin is attractive because, unlike the fiat system, its value as an independent currency solely depends on its market demand.
[https://cointelegraph.com/news/cloud-miner-on-trends-making-bitcoin-attractive-now-japan-litecoin-dwindling-fiat]
_GENERIC:
* exchange-rate-of-bcncevt#ql:idBcncetegrt#
_ADDRESS.WPG:
* BitPay: https://bitpay.com/bitcoin-exchange-rates,
* https://bitcoinaverage.com/en/bitcoin-price/btc-to-usd,
name::
* McsEngl.btcrate'API@cptIt,
_ADDRESS.WPG:
* https://openexchangerates.org//
* https://github.com/currencybot/open-exchange-rates/
name::
* McsEngl.btcrate.PAST@cptIt,
* McsEngl.btcrate.histroical@cptIt,
name::
* McsEngl.btcrate.PRESENT@cptIt,
* McsEngl.btcrate.live@cptIt,
* McsEngl.btcrate.real-time@cptIt,
name::
* McsEngl.btcrate.FUTURE@cptIt,
* McsEngl.btcrate.future@cptIt,
name::
* McsEngl.btcrate.EVOLUTING@cptIt,
{time.2017-01-01}:
=== 997.75$
[https://www.bitstamp.net//]
{time.2016-01-04}:
=== 443.36$
[https://www.bitstamp.net//]
{time.2015-01-05}:
=== 277.59$
[https://www.bitstamp.net//]
{time.2014-08-19}:
=== 451$
Επεσε κατά 120 δολάρια η τιμή του Bitcoin μέσα σε μια εβδομάδα
Οι αναλυτές αναμένουν περαιτέρω μείωση για το ψηφιακό νόμισμα
ΔΗΜΟΣΙΕΥΣΗ: 08:55
Επεσε κατά 120 δολάρια η τιμή του Bitcoin μέσα σε μια εβδομάδα
Πτώση 120 δολαρίων κατέγραψε η τιμή του Bitcoin μέσα σε μια εβδομάδα με τους αναλυτές να αναμένουν πως η τιμή του ψηφιακού νομίσματος θα μειωθεί περαιτέρω, καθώς γίνεται διαρκώς όλο και λιγότερο ευαίσθητο στα «καλά νέα».
Συγκεκριμένα, σύμφωνα με την πλατφόρμα CoinDesk η αξία διαπραγμάτευσης του Bitcoin υποχώρησε σήμερα Τρίτη στα 451 δολάρια από 571 δολάρια πριν από μία εβδομάδα, ενώ χθες βρέθηκε να διαπραγματεύεται ακόμη και στα 309 δολάρια στη βουλγαρική πλατφόρμα συναλλαγών Bitcoin BTC-e.
Οι ειδικοί αποδίδουν τις απώλειες του Bitcoin στις προσπάθειες κάποιων traders να καλύψουν τις θέσεις τους, πιέζοντας περαιτέρω τις τιμές. Σε κάθε περίπτωση η πτώση της τιμής του ψηφιακού νομίσματος συνδέεται και με την μεγαλύτερη εποπτεία που έχει υπάρξει στις πλατφόρμες διαπραγμάτευσης του.
Με δεδομένο ότι τα εικονικά νομίσματα βρέθηκαν στο προσκήνιο της δημοσιότητας τον προηγούμενο Φεβρουάριο λόγω της κατάρρευσης κάποιων πλατφόρμων διαπραγμάτευσης οι κεντρικές τράπεζες διεθνώς απεύθυναν συστάσεις στους επενδυτές – καταναλωτές για τους πιθανούς κινδύνους. Το ίδιο έπραξε και η Τράπεζα της Ελλάδος υιοθετώντας σχετικές επισημάνσεις της Ευρωπαϊκής Αρχής Τραπεζών.
[http://www.tovima.gr/finance/article/?aid=623940]
{time.2014-01-06}:
=== 849.39$
[https://www.bitstamp.net//]
{time.2013-01-07}:
=== 13.69$
[https://www.bitstamp.net//]
{time.2013}:
The price of Bitcoins – based on little more than the hope the system will become a substantial means of exchange – has been yo-yoing.
It was below $7 a year ago and reached $266 in April before dropping below $80.
It has been called “a modern tulip mania but without the pretty flowers”.
[http://www.ft.com/intl/cms/s/0/51b78cb6-e40e-11e2-91a3-00144feabdc0.html, 2013-07-05]
===
Bitcoins have been in the headlines recently due to the massive volatility of their exchange rate.
When they were first introduced in 2009, they were essentially worthless, trading for just five cents per bitcoin in July 2010.
This year, however, they rocketed up in value to a high of $230 per bitcoin in April before plunging back to their current rate of exchange.
Some have attributed the rise to concerns about the ongoing euro crisis in Europe.
[http://www.spiegel.de/international/business/germany-declares-bitcoins-to-be-a-unit-of-account-a-917525.html, 2013-08-20]
{time.2012.05}:
=== 5$
In May 2012, 1 BTC traded at around $5.00 USD.
Taking into account the total number of Bitcoins in circulation, the market capitalization of the Bitcoin network stands at over 45 million USD.[51]
{time.2010.07}:
=== 0.05$
Bitcoins have been in the headlines recently due to the massive volatility of their exchange rate.
When they were first introduced in 2009, they were essentially worthless, trading for just five cents per bitcoin in July 2010.
This year, however, they rocketed up in value to a high of $230 per bitcoin in April before plunging back to their current rate of exchange.
Some have attributed the rise to concerns about the ongoing euro crisis in Europe.
[http://www.spiegel.de/international/business/germany-declares-bitcoins-to-be-a-unit-of-account-a-917525.html, 2013-08-20]
name::
* McsEngl.btccevt'Evaluation@cptIt,
Απόρροια του περιορισμένου αριθμού των ψηφιακών νομισμάτων που βγαίνουν στην κυκλοφορία είναι ότι για όσο διάστημα αυξάνεται η αξία τους οι κάτοχοί τους έχουν συμφέρον να τα «αποταμιεύουν» στα ηλεκτρονικά «πορτοφόλια» τους και όχι να πραγματοποιούν συναλλαγές με αυτά, όπως είναι ο πρωταρχικός ρόλος κάθε νομίσματος.
[http://info-war.gr/bitcoin-h-φούσκα-του-λιγότερου-κράτους/]
Lifthrasir thinks that the 400,000-times greater hashing power of Bitcoin and its 23-time bigger market cap make it a better choice for the real estate database instead of Ethereum.
[https://cointelegraph.com/news/vitalik-buterin-bitcoin-more-likely-than-ethereum-to-split-in-2017]
name::
* McsEngl.btccevt'ATM@cptIt,
* McsEngl.bitcoin-ATM@cptIt,
* McsEngl.bitcoin-AVMS@cptIt,
* McsEngl.btcATM@cptIt,
* McsEngl.BTM@cptIt,
_DESCRIPTION:
Bitcoin_ATM
A bitcoin ATM is a physical machine that allows a customer to buy bitcoin with cash.
There are many manufacturers, some of which enable users to sell bitcoin for cash.
They are also sometimes called 'BTMs' or 'Bitcoin AVMS'.
CoinDesk maintains a worldwide map of operational bitcoin atm machines and a list of manufacturers.
[http://www.coindesk.com/information/bitcoin-glossary//]
H Ελλάδα αποκτάει το πρώτο της Bitcoin ATM
Είναι πλέον και επίσημο! Η Ελλάδα έχει από σήμερα το πρώτο της Bitcoin ATM σε λειτουργία!
Το Bitcoin ATM βρίσκεται στην Αθήνα και συγκεκριμένα στην ΙΩΑΝΝΟΥ ΘΗΒΑΙΟΥ 20 , ΑΧΑΡΝΑΙ, ΤΚ: 13673 στο βιβλιοπωλείο ΟΡΙΖΟΝΤΕΣ.
Το ΑΤΜ είναι το Satoshi 1 της εταιρίας Genesis (https://bitcoinatm.com ) και λειτουργεί σε συνεργασία με το Ελληνικό Bitcoin ανταλλακτήριο bitcoinsgreece. Όπως αναφέρουν στο forum του BitcoinNews.gr έχουν δημιουργήσει ένα ημερολόγιο λειτουργίας του ΑΤΜ με φωτογραφίες ενώ και στο Bitcointalk έχει δημιουργηθεί νήμα συζήτησης Το Bitcoin ATM είναι one way Fiat>Bitcoin δηλαδή μπορείς μόνο να αγοράσεις και όχι να πουλήσεις Bitcoin.
To μηχάνημα ήδη έχει μπει στην λίστα του Bitcoin ATM radar coinatmradar
[http://www.insomnia.gr/_/articles/διάφορα/internet/h-ελλάδα-αποκτάει-το-πρώτο-της-bitcoin-atm-r9602, 2015-06-25]
Get your Bitcoin in cash: World's second Bitcoin ATM to open in Hong Kong
By Naomi Ng for CNN
January 7, 2014 -- Updated 0305 GMT (1105 HKT)
This file photo shows users waiting in line to use the world's first real Bitcoin ATM in Vancouver, Canada on October 29, 2013.
Hong Kong (CNN) -- The world's second Bitcoin ATM is due to land in Hong Kong by the end of this month, according to U.S. based software company Robocoin.
The machine, available for sale to individual operators such as banks and private entrepreneurs, allows users to buy or sell Bitcoin in just a few minutes.
The process should be much faster than setting up an account on an exchange or via mobile apps and computers which could take a few days for account verification.
The advent of Bitcoin ATMs is seen as a step towards bringing the digital currency into the real world.
"It removes all the pain and barriers of entry to buying Bitcoin on an online exchange," said Robocoin chief executive Jordan Kelley.
"Our goal as a company is to make the acquisition truly grandma friendly," he added.
READ: What is Bitcoin?
Indian government warns against Bitcion Bitcoin: Money of the future? Pay for a trip to space with Bitcoin
The virtual currency has generated lots of media attention in China where investors have helped drive the price up to dramatic highs above $1,000.
"I think we're going to unleash the power of Bitcoin. It opens a virtual money portal where people can send money to and from," said Kelley.
This is how it works:
Customers must choose to either buy or sell Bitcoin.
Let's say you want to make a withdrawal from your Bitcoin wallet. After choosing an amount of cash you'd like to withdraw, the software installed in the ATM generates a code which you have to scan with your smartphone.
Simultaneously, the machine also produces a receipt.
Following a confirmation from the Bitcoin network to your phone, you can then scan the code on the receipt at the kiosk, which then prompts the ATM to spit out the allotted amount of cash.
The machine is also equipped with a hand scanner that creates a biometric authenticated identity as an anti-money laundering measure.
Casper Cheng Tsz Chun, a Hong Kong Bitcoin enthusiast, said the ATM would work a bit like a vending machine "for buying and selling virtual goods (Bitcoin) instead of physical goods like a can of soda."
READ: 8 things you can buy with bitcoins right now
Robocoin's first Bitcoin ATM launched in Vancouver in October, and after a month of operation, transactions have totaled 1 million Canadian Dollars ($942,000) in total transactions, according to the company.
Kelley said the company has already sold 50 ATMs to other operators worldwide but they are not yet in operation.
The company said it chose Hong Kong as the next place to launch its cash machine for the virtual currency because it "responds well to technological innovation."
Kelley declined to disclose where the ATM would be located.
I think we're going to unleash the power of Bitcoin
Jordan Kelley, Robocoin CEO
Not every government in Asia is ready for a Bitcoin ATM.
Taiwan's Financial Supervisory Commission (FSC) and Central Bank released a joint statement on their website on Monday stating it does not recognize Bitcoin as an accepted form of currency.
The installation of Robocoin Bitcoin ATMs will be prohibited said Tseng Ming-chung, FSC chairman in an interview with Taiwan's Central News Agency.
"Bitcoin is not real currency and banks cannot receive or provide it. Installing ATMs require the authorization of the FSC, but it will not be approved, thus it is 'impossible' for Bitcoin ATMs to enter or appear in Taiwan," Central News Agency reported.
The statement also warned institutions against the risk of investing in Bitcoin because of the extremely volatile price.
China's central bank issued new rules in December that prohibited financial institutions from dealing in the digital currency. While it did not outlaw individuals from owning Bitcoin, it specifies that it is not to be considered a currency.
Despite the setback, Robocoin's chief executive said he still firmly believes China will come to accept Bitcoin.
"Citizens around the world love Bitcoin. The Chinese are very pragmatic in their approach, they just want to make sure they have a very good understanding of the market and the usage," he said.
Kelley revealed that Robocoin has begun talks with several operators in China that are reaching out to the government and local regulators to "educate" them about the value and potential of the Bitcoin market.
[http://edition.cnn.com/2014/01/06/business/bitcoin-atm-hong-kong/index.html]
name::
* McsEngl.btccevt'DOING@cptIt,
name::
* McsEngl.btccevt'Double-spending@cptIt,
_DESCRIPTION:
Double_spending:
The act of spending bitcoins twice.
It happens when someone makes a transaction using bitcoins, and then makes a second purchase from someone else, using the same bitcoins.
They then convince the rest of the network to confirm only one of the transactions by hashing it in a block.
Double spending is not easy to do, thanks to the way that the bitcoin network operates, but it is nevertheless a risk run by those accepting zero-confirmation transactions.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.btccevt'Mixing@cptIt,
* McsEngl.bitcoin-mixing@cptIt,
* McsEngl.btcmixing@cptIt,
_DESCRIPTION:
Mixing:
A process of exchanging coins with other persons in order to increase privacy of one's history.
Sometimes it is associated with money laundering, but strictly speaking it is orthogonal to laundering.
In traditional banking, a bank protects customer's privacy by hiding transactions from all 3rd parties.
In Bitcoin any merchant may do a statistical analysis of one's entire payment history and determine, for instance, how many bitcoins one owns.
While it's still possible to implement KYC (Know You Customer) rules on a level of every merchant, mixing allows to to separate information about one's history between the merchants.
Most important use cases for mixing are:
1) receiving a salary as a single big monthly payment and then spending it in small transactions ("cafe sees thousands of dollars when you pay just $4");
2) making a single payment and revealing connection of many small private spendings ("car dealer sees how much you are addicted to coffee").
In both cases your employer, a cafe and a car dealer may comply with KYC/AML laws and report your identity and transferred amounts, but neither of them need to know about each other.
Mixing bitcoins after receiving a salary and mixing them before making a big payment solves this privacy problem.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
_DESCRIPTION:
Mixing_service:
A service that mixes your bitcoins with someone else's, sending you back bitcoins with different inputs and outputs from the ones that you sent to it.
A mixing service (also known as a tumbler) preserves your privacy because it stops people tracing a particular bitcoin to you.
It also has the potential to be used for money laundering.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.btccevt.AGGREGATE@cptIt,
{2017-04-15}
Circulating Supply
16,274,987 BTC
Max Supply
21,000,000 BTC
[https://coinmarketcap.com/currencies/bitcoin/]
_DESCRIPTION:
The protocol also halves the rate at which new bitcoins are created every four years, and limits the total number of bitcoins that will be created to a fixed total of 21 million coins. The result is that the number of bitcoins in circulation closely follows an easily predictable curve that reaches 21 million by the year 2140. Due to bitcoin’s diminishing rate of issuance, over the long term, the bitcoin currency is deflationary. Furthermore, bitcoin cannot be inflated by "printing" new money above and beyond the expected issuance rate.
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
===
Το πρωτόκολλο επίσης μειώνει στο μισό, κάθε τέσσερα χρόνια, το ρυθμό με τον οποίο τα νέα bitcoin δημιουργούνται, ενώ ταυτόχρονα περιορίζει τον συνολικό αριθμό των bitcoin που θα δημιουργηθούν σε συνολικά 21 εκατομμύρια νομίσματα.
Το αποτέλεσμα είναι ότι ο αριθμός των bitcoin σε κυκλοφορία ακολουθεί πιστά μια εύκολα προβλέψιμη καμπύλη που φτάνει τα 21 εκατομμύρια μέχρι το έτος 2140.
Λόγω του φθίνοντος ποσοστού έκδοσης bitcoin, μακροπρόθεσμα, το bitcoin νόμισμα είναι αποπληθωριστικό.
Επιπλέον, το bitcoin δεν μπορεί να πληθωριστεί από «εκτύπωση» νέου χρήματος πάνω από τον αναμενόμενο ρυθμό έκδοσης.
[Mastering Bitcoin, Adonopoulos, https://www.bitcoinbook.info/translations/el/book.pdf]
===
Καθώς το bitcoin είναι δομημένο με τις φαντασιώσεις περί χρυσού, το αυτό ισχύει και για την ποσότητά του. O χρυσός πέρα από γυαλιστερός είναι και σχετικά σπάνιος και αυτή η σπανιότητά του, τον κάνει πολύτιμο και άρα επιθυμητό μέσο συναλλαγής και συσσώρευσης της αξίας. Έτσι και το bitcoin λοιπόν έπρεπε να γίνει σπάνιο. Από τον τρόπο που είναι δομημένο το bitcoin, υπάρχει δυνατότητα να παραχθούν μόλις 21 εκ bitcoins. Είναι αυτή η παραγωγή μια first come first serve περίπτωση? Όχι φυσικά. Τα αστέρια που σχεδίασαν τα bitcoins έφτιαξαν μια παραβολική καμπύλη σύμφωνα με την οποία, όσο περισσότερα bitcoins παράγονται, τόσο πιο δύσκολο θα γίνεται να παραχθούν τα επόμενα. Αυτό το κόλπο στην ουσία εγγυάται τη σπανιότητα του νομίσματος.
[http://www.techiechan.com/?p=1954]
name::
* McsEngl.btccevt.SUBUNIT@cptIt,
* McsEngl.bitcoin-denomination@cptIt,
* McsEngl.btccevt.subunit@cptIt,
* McsEngl.btcdenomination@cptIt,
_DESCRIPTION:
Denominations of Bitcoin value, usually measured in fractions of a bitcoin but sometimes measured in multiples of a satoshi.
One bitcoin equals 100,000,000 satoshis.
[https://bitcoin.org/en/glossary/denominations]
===
As the value of the unit of 1 BTC grew too large to be useful for day to day transactions, people started dealing in smaller units, such as milli-bitcoins#ql:milli@cptCore776.6# (mBTC) or micro-bitcoins#ql:micro@cptCore776.5# (μBTC).
[https://en.bitcoin.it/wiki/Myths]
name::
* McsEngl.btccevt.unit.cBTC 1/100@cptIt,
* McsEngl.btccBTC@cptIt,
* McsEngl.bitcenti@cptIt,
* McsEngl.centibitcoin@cptIt,
name::
* McsEngl.btccevt.unit.mBTC 1/1'000@cptIt,
* McsEngl.btcmBTC@cptIt,
* McsEngl.mBTC@cptIt,
* McsEngl.millibitcoin@cptIt,
name::
* McsEngl.btccevt.unit.μBTC 1/1'000'000@cptIt,
* McsEngl.bitbitcoin@cptIt,
* McsEngl.btcμBTC@cptIt,
* McsEngl.btcuBTC@cptIt,
* McsEngl.microbitcoin@cptIt,
* McsEngl.btcbit@cptIt,
* McsEngl.1-millionth-of-a-bitcoin@cptIt,
* McsEngl.one-Mike@nickname,
_DESCRIPTION:
Bit:
Name of a Bitcoin denomination equal to 100 *satoshis* (1 millionth of 1 *BTC*).
In 2014 several companies including Bitpay and Coinbase, and various wallet apps adopted *bit* to display bitcoin amounts.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btccevt.unit.SATOSHI 1/100'000'000@cptIt,
* McsEngl.btcsatoshi@cptIt,
* McsEngl.mnySatoshi@cptIt,
* McsEngl.satoshi@cptIt,
_DESCRIPTION:
There are a maximum of 2,099,999,997,690,000 Bitcoin elements (called satoshis), which are currently most commonly measured in units of 100,000,000 known as BTC.
Stated another way, no more than 21 million BTC can ever be created.
[https://en.bitcoin.it/wiki/Bitcoin]
===
A Satoshi is the smallest fraction of a Bitcoin that can currently be sent: 0.00000001 BTC, that is, a hundredth of a millionth BTC. In the future, however, the protocol may be updated to allow further subdivisions, should they be needed.Aug 30, 2011
terminology - What is a 'Satoshi'? - Bitcoin Stack Exchange
bitcoin.stackexchange.com/questions/114/what-is-a-satoshi
===
Satoshi:
The first name of the Bitcoin's creator Satoshi Nakamoto#ql:idBtchmnSnt# and also the name of the smallest unit used in transactions.
1 bitcoin (BTC) is equal to 100 million satoshis.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcnet'Statistics (btcstat)@cptIt,
_ADDRESS.WPG:
* https://webbtc.com/stats,
* http://organofcorti.blogspot.gr/2016/04/april-10th-2016-bitcoin-network.html,
name::
* McsEngl.btcnet'Security (btcscrt)@cptIt,
* McsEngl.btcsecurity@cptIt,
_DESCRIPTION:
Two basic questions for anyone accepting digital money are:
Can I trust the money is authentic and not counterfeit?
Can I be sure that no one else can claim that this money belongs to them and not me? (Aka the “double-spend” problem.)
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
===
8 November 2013 Last updated at 16:22 GMT Share this pageEmailPrint
ShareFacebookTwitter
Major Bitcoin theft from website, claims owner
Bitcoins
Bitcoins are becoming more popular as a method of payment online
Continue reading the main story
Related Stories
What is Bitcoin? Watch
Bitcoin 'at risk' of network attack
Man cashes in on $22 Bitcoin stash
A man who ran an online "wallet service" for storing Bitcoins has claimed hackers stole virtual currency from his site worth more than one million Australian dollars.
The Australian man said 4,100 Bitcoins (US$1.04m, £650,000) were taken in two separate attacks.
He said he would not report the theft to police as Bitcoin transactions are virtually impossible to trace.
This has led some users to speculate whether it was an "inside job".
In a radio interview with ABC News the man, who only used his online name TradeFortress, denied being involved.
The Bitcoin virtual currency is increasingly used to pay for things online.
According to the Sydney Morning Herald, the theft occurred on 26 October but users were only alerted this week via a message he posted on the wallet service's website.
"I know this doesn't mean much, but I'm sorry, and saying that I'm very sad that this has happened is an understatement.
"Please don't store Bitcoins on an internet-connected device, regardless if it is your own or a service's."
Bitcoin is the most well known of a handful of virtual currencies. The currencies are developed through a computer process called "mining" and can be traded on exchanges or privately between users.
[http://www.bbc.co.uk/news/technology-24871444]
{time.2015}
=== Former Mt Gox chief arrested in Japan
Japanese police have arrested Mark Karpelθs, the head of the bankrupt Japan-based bitcoin exchange Mt Gox, who is alleged to have manipulated the computer system to inflate his account.
[FINANCIAL TIMES, Saturday August 01 2015, BREAKING NEWS]
name::
* McsEngl.btcnet'anonymity@cptIt,
* McsEngl.btcanonymity@cptIt,
_ADDRESS.WPG:
* https://www.expressvpn.com/internet-privacy/bitcoin-anonymity//
name::
* McsEngl.btcnet'fraud@cptIt,
* McsEngl.btcnet'fail@cptIt,
* McsEngl.btcnet'problem@cptIt,
_ADDRESS.WPG:
* http://cointelegraph.com/news/top-10-bitcoin-fails-from-gambling-ponzi-to-mother-of-all-frauds,
name::
* McsEngl.btcnet'LBC@cptIt,
_DESCRIPTION:
What is LBC?
The "Large Bitcoin Collider" (LBC - a homage to LHC) is a distributed effort to find at least one collision of private Bitcoin keys by creating addresses to private keys in the 2160 range. These are checked against the list of known BTC addresses with funds on them. In the rare event of a collision, the funds on the address in question would become accessible to the collision finder.
[https://lbc.cryptoguru.org/about]
name::
* McsEngl.btcnet'privacy@cptIt,
* McsEngl.btcprivacy@cptIt,
_DESCRIPTION:
The concept of privacy is best defined as the amount of control you have over your information. This control not only includes the power to hide or conceal your personal information, but also the power to reveal it to the public.
[https://www.expressvpn.com/internet-privacy/bitcoin-anonymity/]
name::
* McsEngl.btcnet'protection@cptIt,
* McsEngl.btcprotection@cptIt,
_DESCRIPTION:
Transparency Requires Protection
Bitcoin is by default a transparent system, in which every piece of information is available to the public. As such, every Bitcoin user requires some level of protection. Anyone with substantial wealth in Bitcoin would not want to advertise their funds to every person they transact with, for obvious reasons. But every time you spend just a tiny portion of your Bitcoin wallet, you reveal your wealth to the other party. Doing that on the Internet is like flashing large stacks of cash in a dark back alley. It is not advisable! A criminal might see how much you have, and decide to come after it. Distributing your wealth between several wallets and using a different address for each transaction is a common practice that prevents others from knowing how much Bitcoin you have.
[https://www.expressvpn.com/internet-privacy/bitcoin-anonymity/]
name::
* McsEngl.btcnet'resource@cptIt,
_ADDRESS.WPG:
* https://www.bitgo.com/about,
* http://cointelegraph.com/news/bitcoin-will-it-survive-2016,
name::
* McsEngl.btcnet'transparency@cptIt,
* McsEngl.btctransparency@cptIt,
_DESCRIPTION:
Transparency Requires Protection
Bitcoin is by default a transparent system, in which every piece of information is available to the public. As such, every Bitcoin user requires some level of protection. Anyone with substantial wealth in Bitcoin would not want to advertise their funds to every person they transact with, for obvious reasons. But every time you spend just a tiny portion of your Bitcoin wallet, you reveal your wealth to the other party. Doing that on the Internet is like flashing large stacks of cash in a dark back alley. It is not advisable! A criminal might see how much you have, and decide to come after it. Distributing your wealth between several wallets and using a different address for each transaction is a common practice that prevents others from knowing how much Bitcoin you have.
[https://www.expressvpn.com/internet-privacy/bitcoin-anonymity/]
name::
* McsEngl.btcscrt'Double-spend@cptIt,
* McsEngl.bitcoin-double-spend@cptIt,
_DESCRIPTION:
A fraudulent attempt to spend the same *transaction output* twice.
There are two major ways to perform a double spend:
reverting an unconfirmed transaction#ql:idBtctxCfrmdNo# by making another one which has a higher chance of being included in a block (only works with merchants accepting zero-confirmation transactions) or
by mining#ql:idBtcmnng# a parallel blockchain with a second transaction to overtake the chain where the first transaction was included.
Bitcoin proof-of-work scheme#ql:idBtcpow# makes a probabilistic guarantee of difficulty to double spend transactions included in the *blockchain*.
The deeper transaction is recorded in the blockchain, the more expensive it is to "reverse" it.
See also 51%-attack#ql:idBtcscrt51ptak#.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.bitcoin-51-percent-attack@cptIt,
* McsEngl.btc51-percent-attack@cptIt,
_DESCRIPTION:
A condition in which more than half the computing power on a cryptocurrency network is controlled by a single miner or group of miners.
That amount of power theoretically makes them the authority on the network.
This means that every client on the network believes the attacker’s hashed transaction block.
This gives them control over the network, including the power to:
Issue a transaction that conflicts with someone else's.
Stop someone else's transaction from being confirmed.
Spend the same coins multiple times.
Prevent other miners from mining valid blocks.
[http://www.coindesk.com/information/bitcoin-glossary//]
===
51percent_Attack:
Also known as >50% attack or a *double spend* attack.
An attacker can make a payment, wait till the merchant accepts some number of *confirmations* and provides the service, then starts mining a parallel chain of blocks starting with a block before the transaction.
This parallel blockchain then includes another transaction that spends the same *outputs* on some other address.
When the parallel chain becomes more *difficult*, it is considered a *main chain* by all nodes and the original transaction becomes invalid.
Having more than a half of total *hashrate* guarantees possibility to overtake chain of any length, hence the name of an attack (strictly speaking, it is "more than 50%", not 51%).
Also, even 40% of hashrate allows making a double spend, but the chances are less than 100% and are diminishing exponentially with the number of confirmations that the merchant requires.
This attack is considered theoretical as owning more than 50% of hashrate might be much more expensive than any gain from a *double spend*.
Another variant of an attack is to disrupt the network by mining empty blocks, censoring all transactions.
An attack can be mitigated by blacklisting blocks that most of "honest" miners consider abnormal.
Under normal conditions, miners and mining pools do not censor blocks and transactions as it may diminish trust in Bitcoin and thus their own investments.
51% attack is also mitigated by using *checkpoints#ql:btccheckpoint#* that prevent *reorganization* past the certain block.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcscrt'Denial-of-service@cptIt,
* McsEngl.bitcoin-denial-of-service@cptIt,
* McsEngl.btndenial-of-service@cptIt,
* McsEngl.btnDoS@cptIt,
_DESCRIPTION:
Denial_of_Service:
Is a form of attack on the network.
Bitcoin *nodes* punish certain behavior of other nodes by banning their IP addresses for 24 hours to avoid DoS.
Also, some theoretical attacks like *51% attack* may be used for network-wide DoS.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcnet'Program (btcpgm)@cptIt,
* McsEngl.bitcoin-software@cptIt,
* McsEngl.btcprogram@cptIt,
* McsEngl.btcsoftware@cptIt,
* McsEngl.btcs@cptIt,
_DESCRIPTION:
Bitcoin is also the name of the open source software which enables the use of this currency.
[http://bitcoin.org/] {2012-05-27}
name::
* McsEngl.btcpgm.specific@cptIt,
* McsEngl.btcpgm.specific@cptIt,
_SPECIFIC:
* Wallet_file#ql:btcwf#
* https://npmjs.org/package/bitcoin,
* http://coinwidget.com//
name::
* McsEngl.btcpgm.bitcoinj@cptIt,
* McsEngl.bitcoinj@cptIt,
_ADDRESS.WPG:
* http://bitcoinj.github.io//
_DESCRIPTION:
Bitcoinj:
A Java implementation of a full Bitcoin node by Mike Hearn.
Also includes *SPV* implementation among other features.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
What is bitcoinj?
bitcoinj is a library for working with the Bitcoin protocol.
It can maintain a wallet, send/receive transactions without needing a local copy of Bitcoin Core and has many other advanced features. It's implemented in Java but can be used from any JVM compatible language: examples in Python and JavaScript are included.
It comes with full documentation and many large, well known Bitcoin apps and services are built on it.
Features
Highly optimised lightweight simplified payment verification (SPV) mode. In this mode, only a small part of the block chain is downloaded, making bitcoinj suitable for usage on constrained devices like smartphones or cheap virtual private servers.
Experimental full verification mode, which does the same verification work as Bitcoin Core. In this mode, the unspent transaction output set (UTXO set) is calculated and, thanks to a PostgreSQL store, can be indexed into a database allowing for fast lookup of balance by address.
A wallet class with encryption, fee calculation, multi-signing, deterministic key derivation, pluggable coin selection/coin control, extensions support and event listeners that let you stay up to date with changes in your balance.
Support for micropayment channels that let you set up a multi-signature contract between client and server, and then negotiate on the channel, allowing fast micropayments that avoid miner fees.
Provides both async and thread-per-connection for network IO, allowing you to choose between scalability and blocking-only features like SOCKS/Tor proxying.
Easily implement apps that use Bitcoin's contracts features.
A simple GUI wallet app that you can use as the basis for your own apps. Watch or read a tutorial on how to customise it and build a native installer that does not require Java.
Command line tools for working with wallet and chain files, the payment protocol, the network and more.
Strong Bitcoin standards support.
A friendly and helpful community!
[http://bitcoinj.github.io/]
name::
* McsEngl.btcpgm.Bitcore@cptIt,
_DESCRIPTION:
An open-source platform to build bitcoin and blockchain-based applications.
[http://bitcore.io/]
===
Bitcore:
A Bitcoin toolkit by Bitpay written in JavaScript.
More complete than *Bitcoinjs*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcpgm.CLIENT@cptIt,
* McsEngl.bitcoin-client-program@cptIt,
* McsEngl.btcclient@cptIt,
====== lagoGreek:
* McsElln.μπιτκόιν-λογισμικό-πελάτη@cptIt,
* McsElln.μπιτκόιν-πρόγραμα-πελάτη@cptIt,
* McsElln.μπιτκόιν-πελάτης@cptIt,
_DESCRIPTION:
Client
A software program running on a desktop or laptop computer, or mobile device.
It connects to the bitcoin network and forwards transactions.
It may also include a bitcoin wallet (see node).
[http://www.coindesk.com/information/bitcoin-glossary//]
_SPECIFIC:
* full-client#ql:idBtcpgmClntFul#,
* lightweight-client#ql:idBtcpgmClntFulNo#,
* web-client#ql:idBtcpgmClntWeb#
name::
* McsEngl.btcpgm.Full-client@cptIt,
* McsEngl.btcFull-client-program@cptIt,
* McsEngl.bitcoin-full-client@cptIt,
* McsElln.μπιτκόιν-πλήρης-πελάτης@cptIt,
_DESCRIPTION:
A full client, or "full node," is a client that stores the entire history of bitcoin transactions (every transaction by every user, ever), manages the users' wallets, and can initiate transactions directly on the bitcoin network.
This is similar to a standalone email server, in that it handles all aspects of the protocol without relying on any other servers or third-party services.
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
name::
* McsEngl.btcpgm.Lightweight-client@cptIt,
* McsEngl.bitcoin-light-client@cptIt,
* McsEngl.bitcoin-SPV-client@cptIt,
* McsEngl.btclight-client@cptIt,
* McsEngl.btclightweight-client@cptIt,
* McsEngl.btcThin-client@cptIt,
* McsElln.μπιτκόιν-ελαφρύς-πελάτης@cptIt,
_DESCRIPTION:
A lightweight client stores the user’s wallet but relies on third-party–owned servers for access to the bitcoin transactions and network.
The light client does not store a full copy of all transactions and therefore must trust the third-party servers for transaction validation.
This is similar to a standalone email client that connects to a mail server for access to a mailbox, in that it relies on a third party for interactions with the network.
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
name::
* McsEngl.bitcoin-bloom-filter@cptIt,
* McsEngl.btcBloom-filter@cptIt,
_DESCRIPTION:
A filter used primarily by SPV clients to request only matching transactions and merkle blocks from full nodes.
[https://bitcoin.org/en/glossary/bloom-filter]
_DESCRIPTION:
This gets us pretty far, but Bitcoin-style light clients do have their limitations. One particular limitation is that, while they can prove the inclusion of transactions, they cannot prove anything about the current state (eg. digital asset holdings, name registrations, the status of financial contracts, etc). How many bitcoins do you have right now? A Bitcoin light client can use a protocol involving querying multiple nodes and trusting that at least one of them will notify you of any particular transaction spending from your addresses, and this will get you quite far for that use case, but for other more complex applications it isn’t nearly enough; the precise nature of the effect of a transaction can depend on the effect of several previous transactions, which themselves depend on previous transactions, and so ultimately you would have to authenticate every single transaction in the entire chain.
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum// Buterin.Vitalik]
name::
* McsEngl.btcSPV@cptIt,
* McsEngl.btcSimplified-Payment-Verification@cptIt,
_DESCRIPTION:
A method for verifying particular transactions were included in a block without downloading the entire block.
The method is used by some lightweight Bitcoin clients.
[https://bitcoin.org/en/glossary/simplified-payment-verification]
===
SPV:
Simplified Payment Verification.
A feature of the Bitcoin protocol that enables nodes to verify payments without downloading the full blockchain.
Instead, they need only download block headers.
[http://www.coindesk.com/information/bitcoin-glossary//]
===
Simplified_Payment_Verification_(SPV):
A scheme to validate transactions without storing the whole blockchain (only block headers) and without trusting any external service.
Every transaction must be present with all its parent and sibling hashes in a *merkle tree* up to the root.
SPV client trusts the most *difficult* chain of block headers and can validate if the transaction indeed belongs to a certain block header.
Since SPV does not validate all transactions, a *51% attack* may not only cause a *double spend* (like with *full nodes*), but also make a completely invalid payment with bitcoins created from nowhere.
However, this kind of attack is very costly and probably more expensive than a product in question.
*Bitcoinj* library implements SPV functionality.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcpgm.Web-client@cptIt,
* McsEngl.bitcoin-web-client-program@cptIt,
* McsEngl.btcweb-client-program@cptIt,
_DESCRIPTION:
Web clients are accessed through a web browser and store the user’s wallet on a server owned by a third party. This is similar to webmail in that it relies entirely on a third-party server.
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
name::
* McsEngl.btcpgm.Mobile-client@cptIt,
* McsEngl.bitcoin-mobile-client-program@cptIt,
* McsEngl.btcmobile-client-program@cptIt,
_DESCRIPTION:
Mobile clients for smartphones, such as those based on the Android system, can either operate as full clients, lightweight clients, or web clients. Some mobile clients are synchronized with a web or desktop client, providing a multiplatform wallet across multiple devices but with a common source of funds.
[https://github.com/bitcoinbook/bitcoinbook/blob/first_edition/ch01.asciidoc]
name::
* McsEngl.btcpgm.BITCOIN-XT@cptIt,
* McsEngl.bitcoinXT@cptIt,
_DESCRIPTION:
Bitcoin XT is a fork of Bitcoin Core, the reference client for the bitcoin network. In mid-2015, the concept achieved significant attention within the bitcoin community amid a contentious debate among core developers over increasing the blockchain size cap.[1] The current reference implementation for bitcoin contains a computational bottleneck.[2][3] This averages to a daily maximum of around 300,000 transactions.[4]
It was proposed that the block chain size increase to eight megabyte, i.e. and from then onwards to automatically increase it exponentially, doubling every two years. The proposal did not gain the necessary support to go into effect on the Bitcoin network by early 2016, the earliest possible switchover date. Its use has been in steady decline from March 2016 onwards.
[https://en.wikipedia.org/wiki/Bitcoin_XT]
===
The approach taken by Hearn and Andresen clearly indicates their commitment to a decentralized system
Fears over excessive centralization are warranted. After all, decentralization is a big part of bitcoin’s value proposition. But the amount of centralization being considered at the moment still seems vastly more decentralized than traditional payment systems.
Indeed, the approach taken by Hearn and Andresen clearly indicates their commitment to a decentralized system. BitcoinXT will continue to enforce the existing blocksize limit until the protocol is so widely adopted that it is used to process at least 75% of all blocks added to the blockchain. If (and only if) that occurs—but no earlier than January—BitcoinXT will increase the limit to eight megabytes and double that limit every two years thereafter.
The commitment to gradual change based on consensus observed with the issuance of BitcoinXT is incredible, but perhaps not surprising. It reflects the core values held by bitcoin supporters. And it is also a hallmark of well-functioning self-governing systems. It bodes well for bitcoin’s future.
[http://www.forbes.com/sites/realspin/2015/09/08/new-bitcoin-development-spurs-unnecessary-fear-of-centralization/]
name::
* McsEngl.btcpgm.Bitcoin-Core (btcbcr|btcbqt)@cptIt,
* McsEngl.conceptIt1010.1,
* McsEngl.Bitcoin-core@cptIt,
* McsEngl.bitcoin-reference-implementation@cptIt,
* McsEngl.BitcoinQT@cptIt,
* McsEngl.btcbcr@cptIt,
* McsEngl.btcBitcoin-Core@cptIt,
* McsEngl.btcBitcoinQT@cptIt,
* McsEngl.btcbqt@cptIt,
* McsEngl.btcpgm.Bitcoin-Core@cptIt, {2014-03-19 v0.9}
* McsEngl.btcreference-implementation@cptIt,
* McsEngl.btcSatoshi-client@cptIt,
====== lagoGreek:
* McsElln.μπιτκόιν-πυρήνας@cptIt,
* McsElln.υλοποίηση-αναφοράς-μπιτκόιν@cptIt,
_DESCRIPTION:
BitcoinQT:
Bitcoin implementation based on original code by *Satoshi Nakamoto*.
Includes a graphical interface for Windows, OS X and Linux (using QT) and a command-line executable *bitcoind* that is typically used on servers.
It is considered a *reference implementation* as it's the most used *full node* implementation, especially among *miners*.
Other implementations must be bug-for-bug compatible with it to avoid being *forked*. BitcoinQT uses OpenSSL for its ECDSA operations which has its own quirks that became a part of the standard (e.g. non-canonically encoded public keys are accepted by OpenSSL without an error, so other implementations must do the same).
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md#bitcoinqt]
===
Once installed, you’ll have access to three programs: bitcoind, bitcoin-qt, and bitcoin-cli.
[https://bitcoin.org/en/developer-examples]
===
Bitcoin_Core:
New name of *BitcoinQT* since release of version 0.9 on March 19, 2014.
Not to confuse with *CoreBitcoin*, an Objective-C implementation published in August 2013.
See also *Bitcore#ql:idBtc1Bitcore#*, a JavaScript implementation for Node.js by Bitpay.
_DESCRIPTION:
Reference_Implementation:
BitcoinQT#ql:idBtcbcr# (or *bitcoind*) is the most used *full node* implementation, so it is considered a reference for other implementations.
If an alternative implementation is not compatible with BitcoinQT it may be *forked*, that is it will not see the same *main chain* as the rest of the network running *BitcoinQT*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
_ADDRESS.WPG:
* https://github.com/bitcoin/bitcoin,
* https://bitcoin.org/en/download,
name::
* McsEngl.btcbcr'application-directory@cptIt,
* McsEngl.btcdirectory@cptIt,
_DESCRIPTION:
All three programs get settings from bitcoin.conf in the Bitcoin application directory:
Windows: %APPDATA%\Bitcoin\
OSX: $HOME/Library/Application Support/Bitcoin/
Linux: $HOME/.bitcoin/
[https://bitcoin.org/en/developer-examples]
name::
* McsEngl.btcbcr'bitcoin.conf@cptIt,
* McsEngl.btcbitcoin.conf@cptIt,
You should also make the bitcoin.conf file only readable to its owner. On Linux, Mac OSX, and other Unix-like systems, this can be accomplished by running the following command in the Bitcoin application directory:
chmod 0600 bitcoin.conf
[https://bitcoin.org/en/developer-examples]
btcrpcpassword:
To use bitcoind and bitcoin-cli, you will need to add a RPC password to your bitcoin.conf file. Both programs will read from the same file if both run on the same system as the same user, so any long random password will work:
rpcpassword=change_this_to_a_long_random_password
[https://bitcoin.org/en/developer-examples]
name::
* McsEngl.btcbcr'bitcoind@cptIt,
* McsEngl.bitcoind@cptIt,
* McsEngl.btcBitcoind@cptIt,
_DESCRIPTION:
Bitcoind
Original implementation of Bitcoin with a command line interface.
Currently a part of *BitcoinQT* project.
"D" stands for "daemon" per UNIX tradition to name processes running in background.
See also *BitcoinQT*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md#bitcoind]
===
bitcoind is more useful for programming: it provides a full peer which you can interact with through RPCs to port 8332 (or 18332 for testnet).
[https://bitcoin.org/en/developer-examples]
name::
* McsEngl.btcbcr'Bitcoin-cli@cptIt,
* McsEngl.btcbitcoincli@cptIt,
* McsEngl.btcbitcoin-cli@cptIt,
_DESCRIPTION:
bitcoin-cli allows you to send RPC commands to bitcoind from the command line. For example, bitcoin-cli help
[https://bitcoin.org/en/developer-examples]
name::
* McsEngl.btcbcr'Bitcoin-qt@cptIt,
* McsEngl.btcbitcoin-qt@cptIt,
_DESCRIPTION:
bitcoin-qt provides a combination full Bitcoin peer and wallet frontend. From the Help menu, you can access a console where you can enter the RPC commands used throughout this document.
[https://bitcoin.org/en/developer-examples]
name::
* McsEngl.btcbcr'Internal-byte-order@cptIt,
* McsEngl.Internal-Byte-Order@cptIt,
_DESCRIPTION:
The standard order in which hash digests are displayed as strings—the same format used in serialized blocks and transactions.
Not To Be Confused With
RPC byte order (where the byte order is reversed)
[https://bitcoin.org/en/glossary/internal-byte-order]
name::
* McsEngl.btcbcr'RPC@cptIt,
* McsEngl.btcRpc@cptIt,
* McsEngl.btcRPC@cptIt,
* McsEngl.btcRemoteProcedureCall@cptIt,
_DESCRIPTION:
Bitcoin Core provides a remote procedure call (RPC) interface for various administrative tasks, wallet operations, and queries about network and block chain data.
[https://bitcoin.org/en/developer-reference#remote-procedure-calls-rpcs]
name::
* McsEngl.btcbcrrpc'Byte-order@cptIt,
* McsEngl.btcRPC-Byte-Order@cptIt,
_DESCRIPTION:
* A hash digest displayed with the byte order reversed; used in Bitcoin Core RPCs, many block explorers, and other software.
[https://bitcoin.org/en/glossary/rpc-byte-order]
_EXAMPLE:
internal-byte-order: 5472ac8b1187bfcf91d6d218bbda1eb2405d7c55f1f8cc820000000000000000
rpc-byte-order: 000000000000000082ccf8f1557c5d40b21edabb18d2d691cfbf87118bac7254
Note: hex representation uses two characters to display each byte of data, which is why the reversed string looks somewhat mangled.
The rational for the reversal is unknown, but it likely stems from Bitcoin’s use of hash digests (which are byte arrays in C++) as integers for the purpose of determining whether the hash is below the network target. Whatever the reason for reversing header hashes, the reversal also extends to other hashes used in RPCs, such as TXIDs and merkle roots.
Off-site documentation such as the Bitcoin Wiki tends to use the terms big endian and little endian as shown in the table below, but they aren’t always consistent. Worse, these two different ways of representing a hash digest can confuse anyone who looks at the Bitcoin Core source code and finds a so-called “big endian” value being stored in a little-endian data type.
[https://bitcoin.org/en/developer-reference#hash-byte-order]
name::
* McsEngl.btcbcr'Resource@cptIt,
_ADDRESS.WPG:
* https://bitcoin.org/en/bitcoin-core#ql:https://bitcoin.org/en/bitcoin-core/#/
* https://bitcoincore.org//
* https://github.com/bitcoin-core,
* https://bitcoincore.org/en/releases//
* https://bitcoincore.org/en/faq/contributing-code//
* how to cotribute: https://github.com/bitcoin-core/bitcoincore.org/issues/50#ql:https://github.com/bitcoin-core/bitcoincore.org/issues/50#
name::
* McsEngl.btcbcr.EVOLUTING@cptIt,
btcbcr.0-14-0.2017-03-07
Today marks the official release of Bitcoin Core 0.14.0, the fourteenth generation of Bitcoin’s original software client launched by Satoshi Nakamoto eight years ago.
Overseen by Bitcoin Core lead maintainer Wladimir van der Laan, this latest major release was developed by nearly 100 contributors over a six-month period.
[https://bitcoinmagazine.com/articles/bitcoin-core-0140-released-whats-new/]
btcbcr.0-13-2.2017-01-03 - Bitcoin Core version 0.13.2 released
btcbcr.0-13-1.2016-10-27 - Bitcoin Core version 0.13.1 released
btcbcr.0-13-0.2016-08-23:
Bitcoin Core version 0.13.0 released
btcbcr.0-12-0.2016-02-23:
Bitcoin Core version 0.12.0 released
23 February 2016
Bitcoin Core version 0.12.0 is now available from:
https://bitcoin.org/bin/bitcoin-core-0.12.0/
This is a new major version release, bringing new features and other improvements.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues
[https://bitcoin.org/en/release/v0.12.0]
btcbcr.0-11-0.2015-07-12:
Bitcoin Core version 0.11.0 released
- https://bitcoin.org/en/release/v0.11.0
- 2015.Jul.12
Bitcoin Core version 0.10.2 released
- https://bitcoin.org/en/release/v0.10.2
- 2015.May.19
Bitcoin Core version 0.10.1 released
- https://bitcoin.org/en/release/v0.10.1
- 2015.Apr.27
btcbcr.0-10-0.2015-02-16:
Bitcoin Core version 0.10.0 released
- https://bitcoin.org/en/release/v0.10.0
- 2015.Feb.16
Bitcoin Core version 0.9.3 released
- https://bitcoin.org/en/release/v0.9.3
- 2014.Sep.27
Bitcoin Core version 0.9.2.1 released
- https://bitcoin.org/en/release/v0.9.2.1
- 2014.Jun.19
Bitcoin Core version 0.9.2 released
- https://bitcoin.org/en/release/v0.9.2
- 2014.Jun.16
Bitcoin Core version 0.9.1 released
- https://bitcoin.org/en/release/v0.9.1
- 2014.Apr.08
btcbcr.0-9-0.2014-03-19:
Bitcoin Core version 0.9.0 released
- https://bitcoin.org/en/release/v0.9.0
- 2014.Mar.19
Bitcoin-Qt version 0.8.6 released
- https://bitcoin.org/en/release/v0.8.6
- 2013.Dec.09
Bitcoin-Qt version 0.8.5 released
- https://bitcoin.org/en/release/v0.8.5
- 2013.Sep.13
Bitcoin-Qt version 0.8.4 released
- https://bitcoin.org/en/release/v0.8.4
- 2013.Sep.03
Bitcoin-Qt version 0.8.3 released
- https://bitcoin.org/en/release/v0.8.3
- 2013.Jun.25
Bitcoin-Qt version 0.8.2 released
- https://bitcoin.org/en/release/v0.8.2
- 2013.May.29
Bitcoin-Qt version 0.8.1 released
- https://bitcoin.org/en/release/v0.8.1
- 2013.Mar.18
Bitcoin-Qt version 0.8.0 released
- https://bitcoin.org/en/release/v0.8.0
- 2013.Feb.19
Bitcoin-Qt version 0.7.2 released
- https://bitcoin.org/en/release/v0.7.2
- 2012.Dec.14
Bitcoin-Qt version 0.7.1 released
- https://bitcoin.org/en/release/v0.7.1
- 2012.Oct.19
Bitcoin-Qt version 0.7.0 released
- https://bitcoin.org/en/release/v0.7.0
- 2012.Sep.17
Bitcoin-Qt version 0.6.3 released
- https://bitcoin.org/en/release/v0.6.3
- 2012.Jun.25
Bitcoin-Qt version 0.6.2 released
- https://bitcoin.org/en/release/v0.6.2
- 2012.May.08
Bitcoin-Qt version 0.6.1 released
- https://bitcoin.org/en/release/v0.6.1
- 2012.May.04
Bitcoin-Qt version 0.6.0 released
- https://bitcoin.org/en/release/v0.6.0
- 2012.Mar.30
Bitcoin-Qt version 0.5.3.1 released
- https://bitcoin.org/en/release/v0.5.3.1
- 2012.Mar.16
Bitcoin-Qt version 0.5.3 released
- https://bitcoin.org/en/release/v0.5.3
- 2012.Mar.14
Bitcoin-Qt version 0.5.2 released
- https://bitcoin.org/en/release/v0.5.2
- 2012.Jan.09
Bitcoin-Qt version 0.5.1 released
- https://bitcoin.org/en/release/v0.5.1
- 2011.Dec.15
Bitcoin-Qt version 0.5.0 released
- https://bitcoin.org/en/release/v0.5.0
- 2011.Nov.21
Bitcoin version 0.4.0 released
- https://bitcoin.org/en/release/v0.4.0
- 2011.Sep.23
Bitcoin version 0.3.24 released
- https://bitcoin.org/en/release/v0.3.24
- 2011.Jul.08
Bitcoin version 0.3.23 released
- https://bitcoin.org/en/release/v0.3.23
- 2011.Jun.14
Bitcoin version 0.3.22 released
- https://bitcoin.org/en/release/v0.3.22
- 2011.Jun.05
Bitcoin version 0.3.21 released
- https://bitcoin.org/en/release/v0.3.21
- 2011.Apr.27
name::
* McsEngl.btcpgm.TRADING-BOT@cptIt,
* McsEngl.bitcoin-trading-bot@cptIt,
_ADDRESS.WPG:
* http://www.givebtc.org/everything-know-trading-cryptocurrency-using-bitcoin-bots//
name::
* McsEngl.btcnet'Wallet (btcwlt)@cptIt,
* McsEngl.bitcoin-wallet@cptIt,
* McsEngl.btcwallet@cptIt,
* McsEngl.btcwlt@cptIt,
====== lagoGreek:
* McsElln.πορτοφόλι-μπικόιν@cptIt,
_DESCRIPTION:
Bitcoin-wallet is ANY ENTITY used to manage ownership of bitcoins#ql:idBtccet#.
BTCs#ql:idBtccet# are-not-stored in the-wallets, they are-stored in the-blochain.
A-bitcoin-wallet STORES the-cryptographic-keys that define the-ownership of bitcoins.
[hmnSngo.2017-04-04]
===
'wallet' could be a file, a program, a web-service.
[hmnSngo.2015-09-07]
_GENERIC:
* blockchain-wallet#ql:idBcnwlt#
_DESCRIPTION:
Bitcoin wallets at their core are a collection of private keys. These collections are stored digitally in a file, or can even be physically stored on pieces of paper.
[https://bitcoin.org/en/developer-guide#wallet-files]
_DESCRIPTION:
The so-called wallet is a simple data file that contains a set of Bitcoin (or insert your preferred currency here) addresses. That's all you need to keep your Ecoins with you. The block chain is copied to every single client has a list of every single transaction and balance for your given currency, e.g. Bitcoin. The security of the wallet depends on the security of your computer or smartphone.
[http://www.coindesk.com/how-to-create-a-brain-wallet/]
_DESCRIPTION:
A Bitcoin wallet can refer to either a wallet program or a wallet file.
Wallet programs create public keys to receive satoshis and use the corresponding private keys to spend those satoshis.
Wallet files store private keys and (optionally) other information related to transactions for the wallet program.
[https://bitcoin.org/en/developer-guide#wallets]
_DESCRIPTION:
When a person joins the Bitcoin network, we typically mean that he has procured himself a Bitcoin wallet.
A Bitcoin wallet is the interface through which users will access the Bitcoin network and, more importantly, be able to utilize the Bitcoins that they own.
It can be procured for free as
- a software on a computer,
- a browser extension,
- an application on a mobile device or
- a simple web page which would look much like an online banking portal.
[http://www.givebtc.org/GiveBTC_-_Handbook_for_Non_Profits.pdf]
_DESCRIPTION:
Wallet:
An application or a service that helps keeping private keys for signing transactions.
Wallet does not keep bitcoins themselves (they are recorded in *blockchain*).
"Storing bitcoins" usually means storing the keys.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
_DESCRIPTION:
Users send bitcoins, the units of currency, by broadcasting digitally signed messages to the network using bitcoin wallet software
[https://en.wikipedia.org/wiki/Bitcoin_network]
_DESCRIPTION:
Bitcoin users manage their bitcoin addresses by using a digital wallet. Wallets let users send bitcoins, request payment, calculate the total balance of addresses in use, generate new addresses as needed. Many wallets include precautions to keep the private keys secret, for example by encrypting the wallet data with a password or by requiring two-factor authenticated logins.
Bitcoin wallets provide the following functionality:[10]
Storage of bitcoin addresses and corresponding public/private keys on user's computer in a wallet.dat file
Conducting transactions of obtaining and transferring bitcoins (BTC), also without connection to the Internet
Provide information about the balance in BTC at all available addresses, prior transactions, spare keys
Bitcoin wallets have been implemented as stand-alone software applications, web applications, and even printed documents or memorized passphrases.
[https://en.wikipedia.org/wiki/Bitcoin_network]
===
Since Bitcoin is open-source, any computer programmer with the right skills can create a bitcoin wallet. A Bitcoin wallet is like an email account, they are typically free to install, and you can send and receive money.
Some wallets have more features than others, and some wallets are more designed for advanced users. Some wallets store your bitcoins locally on the computer or mobile phone, and some wallets store your bitcoins in the cloud, where they can be accessed from anywhere.
A wallet that holds bitcoins only is considered an Advanced wallet, or Expert wallet, regardless of the complexity of the interface. Because Bitcoin is new, the volatility risk of holding only bitcoins is more significant than the technical risk of using the software.
Wallets in the Intermediate category allow you to store your local currency in the wallet, as well as bitcoins. This reduces the volatility risk to the user.
[http://lovebitcoins.org/getStarted.html]
_DESCRIPTION:
Wallet:
A method of storing bitcoins for later use.
A wallet holds the private keys associated with bitcoin addresses.
The blockchain is the record of the bitcoin amounts associated with those addresses.
[http://www.coindesk.com/information/bitcoin-glossary//]
_DESCRIPTION:
1) The payment system itself is revolutionary – nothing like it has ever been done. The system is decentralized, so there is no “server farm” or corporate office which controls payments. Transactions occur “peer to peer” just like file-sharing. To use the system, you can either download the client software (which runs on your computer and stores money locally) or you can use an “ewallet” which is a website run by a 3rd party which holds the funds for you (simpler, but introduces counter-party risk if the 3rd party is not trustworthy).
[http://keepyourassets.net/2012/09/27/bitcoin-the-first-five-questions/]
name::
* McsEngl.btcwlt'Security@cptIt,
_ADDRESS.WPG:
* https://bitcoin.org/en/secure-your-wallet,
* https://en.bitcoin.it/wiki/Securing_your_wallet,
* http://cointelegraph.com/news/10-steps-to-a-better-bitcoin-wallet,
_DESCRIPTION:
Bitcoin's most common vulnerability is in user error. Bitcoin wallet files that store the necessary private keys can be accidentally deleted, lost or stolen.
[https://bitcoin.org/en/faq#is-bitcoin-secure]
===
To help protect against theft, many wallet programs offer users the option of encrypting the wallet files which contain the private keys. This protects the private keys when they aren’t being used, but it cannot protect against an attack designed to capture the encryption key or to read the decrypted keys from memory.
[https://bitcoin.org/en/developer-guide#full-service-wallets]
===
Tips for preventing loss of Bitcoin
You should adopt these best practices and the chance that Apple or anyone else for that matter would not be able to get to your Bitcoin and other cryptocurrencies.
- Invest in a good hardware wallet.
- Do not keep all your Bitcoin in just one wallet
- Make a will or write down instructions about what should be done with your digital assets.
- Make backups of your wallets or at least ensure that you have keys kept somewhere securely.
- If you are using mobile wallets, make sure they are platform independent.
[http://cointelegraph.com/news/can-apple-microsoft-amazon-or-google-delete-bitcoin-from-your-computer]
name::
* McsEngl.btcwlt'Storage-medium@cptIt,
* McsEngl.bitcoin-wallet-storage@cptIt,
* McsEngl.btcnet'storage@cptIt,
* McsEngl.btcwlt'storage@cptIt,
_DESCRIPTION:
Το πρώτο «χρηματοκιβώτιο» για bitcoins
Δευτέρα, 13 Ιανουαρίου 2014 12:13 UPD:12:13
REUTERS/JIM URQUHART
Τα online «πορτοφόλια» που χρησιμοποιούνται για την αποθήκευση bitcoins θεωρούνται όλο και λιγότερο ασφαλή, καθώς είναι τρωτά σε κυβερνοεπιθέσεις.
Μία υπηρεσία για αποθήκευση καταθέσεων στο ψηφιακό νόμισμα, bitcoin, ξεκίνησε τη λειτουργία της στο Λονδίνο.
Σύμφωνα με δημοσίευμα του BBC, το Elliptic Vault χρησιμοποιεί τεχνικές «deep cold storage», όπου κωδικοποιημένα «κλειδιά» για bitcoins αποθηκεύονται σε servers οι οποίοι βρίσκονται σε ασφαλές σημείο και είναι αποκομμένοι από το Διαδίκτυο. Υπάρχουν πολλαπλά αντίγραφα των «κλειδιών», που προστατεύονται τόσο από ψηφιακά, όσο και από «φυσικά» συστήματα προστασίας. Στα εν λόγω αντίγραφα έχουν πρόσβαση μόνο ανώτερα στελέχη της εταιρείας. Οι δημιουργοί του ισχυρίζονται πως πρόκειται για μια παγκόσμια πρωτιά, με στόχο την παροχή ασφαλείας στους κατόχους bitcoins.
Σημειώνεται ότι τα online «πορτοφόλια» που χρησιμοποιούνται για την αποθήκευση bitcoins θεωρούνται όλο και λιγότερο ασφαλή, καθώς είναι τρωτά σε κυβερνοεπιθέσεις ενώ πολλοί χρήστες έχουν αναφέρει περιστατικά όπου χάθηκαν κατά λάθος τεράστια ποσά Χαρακτηριστικό παράδειγμα είναι η περίπτωση του Τζέιμς Χάουελς, ο οποίος πέταξε έναν σκληρό δίσκο στον οποίο είχε ξεχάσει ότι υπήρχαν από παλιά αποθηκευμένα bitcoins αξίας (σήμερα) εκατομμυρίων δολαρίων.
Δεν υπάρχει τρόπος ανάκτησης κλεμμένων bitcoins, ενώ οι συναλλαγές είναι μη αναστρέψιμες. Επίσης δεν υπάρχει κάποιος τρόπος ασφάλισής τους, όπως θα συνέβαινε σε μία «συμβατική» τράπεζα με κανονικά λεφτά.
«Ένας από τους κύριους προβληματισμούς που έχουν οι άνθρωποι με τα bitcoins είναι ότι είναι δύσκολο να τα αποθηκεύσουν με ασφάλεια» είπε στο BBC ο Τομ Ρόμπινσον, συνιδρυτής του Elliptic Vault. «Το να τους παρέχουμε αυτή την ασφάλεια φαινόταν το προφανές βήμα» πρόσθεσε.
Κατά τον Ρόμπινσον, ήταν δύσκολο να βρεθεί κάποια ασφαλιστική εταιρεία η οποία να υποστηρίξει το εγχείρημα, καθώς η σχετική βιομηχανία παρουσιάζεται πολύ συντηρητική και δεν «κατανοεί» ακόμα το bitcoin, ενώ επηρεάζεται και από την αρνητική δημοσιότητα πάνω στο ζήτημα. Ωστόσο, όπως επισημαίνει, η κατάσταση έχει βελτιωθεί από τότε που έκλεισε η online αγορά ναρκωτικών και άλλων παράνομων εμπορευμάτων, Silk Road.
[http://www.naftemporiki.gr/story/752249]
name::
* McsEngl.btcwlt'Key-pool@cptIt,
* McsEngl.btckey-pool@cptIt,
_DESCRIPTION:
Key_Pool:
Some wallet applications that create new private keys#ql:idBtcprk# randomly keep a pool of unused pre-generated keys (BitcoinQT keeps 100 keys by default).
When a new key is needed for *change* address or a new payment request, the application provides the oldest key from the pool and replaces it with a fresh one.
The purpose of the pool is to ensure that recently used keys are always already backed up on external storage.
Without a key pool you could create a new key, receive a payment on its address and then have your hard disk died before backing up this key.
A key pool guarantees that this key was already backed up several days before being used.
*Deterministic wallets* do not use a key pool because they need to back up a single secret key.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcwlt'Resource@cptIt,
_ADDRESS.WPG:
* http://bitcoinsimplified.org/get-started/how-to-set-up-a-wallet//
name::
* McsEngl.btcwlt'Doing@cptIt,
name::
* McsEngl.btcwltdng.SERVICE@cptIt,
* McsEngl.btcnet'wallet-service@cptIt,
* McsEngl.btcwallet-service@cptIt,
name::
* McsEngl.btcwlt.specific@cptIt,
* McsEngl.btcwlt.specific@cptIt,
_SPECIFIC:
* hardware-wallet
* paper-wallet,
* prgram-wallet,
_ADDRESS.WPG:
* https://bitcoin.org/en/choose-your-wallet,
SPECIFIC:
Within these two categories [hot|cold] of Bitcoin wallets there are other subcategories.
These include web wallets, desktop wallets installed on
your computer, hierarchical deterministic (“HD”) wallets, multiplesignature
(“multi-sig”) wallets, light wallets, paper wallets, and
wallets that require two-factor authentication (“2FA”).
These wallet characteristics are not mutually exclusive. For example,
you can have a web wallet that uses the multi-sig system or twofactor
authentication. You’ll find that some of the recommended
wallets appear in more than one category below.
[http://www.givebtc.org/GiveBTC_-_Handbook_for_Non_Profits.pdf]
name::
* McsEngl.btcwlt.AGGREGATE@cptIt,
_SPECIFIC:
An unlimited number of wallets can be generated, by anyone, anywhere, without any licenses or permissions required.
[http://www.givebtc.org/GiveBTC_-_Handbook_for_Non_Profits.pdf]
name::
* McsEngl.btcwlt.BRAIN@cptIt,
* McsEngl.bitcoin-brain-wallet@cptIt,
* McsEngl.btcwlt.brain@cptIt,
_DESCRIPTION:
Brain_wallet:
Brain wallet is a concept of storing *private keys* as a memorable phrase without any digital or paper trace.
Either a single key is used for a single address, or a *deterministic wallet* derived from a single key.
If done properly, a brain wallet greatly reduces the risk of theft because it is completely deniable: no one could say which or how much bitcoins you own as there are no actual wallet files to be found anywhere.
However, it is the most error-prone method as one can simply forget the secret phrase, or make it too simple for anyone to brute force and steal all the funds.
Additional risks are added by a complex wallet software.
E.g. BitcoinQT always sends *change* amount to a new address.
If a private key is imported temporarily to spend 1% of the funds and then the wallet is deleted, the remaining 99% will be lost forever as they are moved as a change to a completely new address.
This already happened to a number of people.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
_ADDRESS.WPG:
* https://brainwallet.io//
Brainwallet.org:
Utility based on bitcoinjs to craft transactions by hand, convert *private keys* to addresses and work with a *brain wallet*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcwlt.PAPER@cptIt,
* McsEngl.bitcoin-paper-wallet@cptIt,
* McsEngl.btcPaper-wallet@cptIt,
* McsEngl.btcwlt.paper@cptIt,
_DESCRIPTION:
Store the-keys on paper.
_DESCRIPTION:
Paper_wallet:
A printed sheet containing one or more public bitcoin addresses and their corresponding private keys.
Often used to store bitcoins securely, instead of using software wallets, which can be corrupted, or web wallets, which can be hacked or simply disappear.
A useful form of cold bitcoin storage.
[http://www.coindesk.com/information/bitcoin-glossary//]
===
Paper_Wallet:
A form of *cold storage* where a *private key* for Bitcoin *address* is printed on a piece of paper (with or without encryption) and then all traces of the key are removed from the computer where it was generated.
To redeem bitcoins, a key must be imported in the wallet application so it can sign a transaction.
See also *Casascius Coins*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
_ADDRESS.WPG:
* https://blog.bitaccess.co/how-to-send-bitcoin-from-paper-wallet//
name::
* McsEngl.btcwlt.PROGRAM (btcwtp)@cptIt,
* McsEngl.bitcoin-wallet-program@cptIt,
* McsEngl.btcnet'wallet-program@cptIt,
* McsEngl.btcwallet-application@cptIt,
* McsEngl.btcwallet-program@cptIt,
* McsEngl.btcwallet-software@cptIt,
* McsEngl.btcwtp@cptIt,
_DESCRIPTION:
Wallet programs create public keys to receive satoshis and use the corresponding private keys to spend those satoshis.
[https://bitcoin.org/en/developer-guide#wallets]
name::
* McsEngl.btcwtp'doing@cptIt,
_DESCRIPTION:
This leaves us with three necessary, but separable, parts of a wallet system: a public key distribution program, a signing program, and a networked program.
In the subsections below, we will describe common combinations of these parts.
[https://bitcoin.org/en/developer-guide#wallet-programs]
===
What if I receive a bitcoin when my computer is powered off?
This works fine. The bitcoins will appear next time you start your wallet application. Bitcoins are not actually received by the software on your computer, they are appended to a public ledger that is shared between all the devices on the network. If you are sent bitcoins when your wallet client program is not running and you later launch it, it will download blocks and catch up with any transactions it did not already know about, and the bitcoins will eventually appear as if they were just received in real time. Your wallet is only needed when you wish to spend bitcoins.
[https://bitcoin.org/en/faq#what-if-i-receive-a-bitcoin-when-my-computer-is-powered-off]
name::
* McsEngl.btcwtp'Evaluation@cptIt,
Wallet Privacy Rankings
1. ledger 50
2. Breadwallet 49
3. Airbitz 47
4. Darkwallet 45
5. ArcBit 45
6. Samourai 43
7. Bitcoin-QT 43
8. Trezor 42
9. LUXSTACK 42
10. Bitcoin Wallet 42
11. MultiBit HD 40
12. GreenAddress 39
13. Armory 38
14. Copay 37
15. Mycelium 37
16. Electrum 33
17. Blockchain 30
18. BitGo 27
19. Hive 19
20. Coinbase 18
[http://www.openbitcoinprivacyproject.org/2016/02/announcing-the-2nd-edition-of-our-bitcoin-wallet-privacy-rating-report/]
_SPECIFIC:
* full-service-wallet-program#ql:btcwp.full_service#
name::
* McsEngl.btcwtp.computer.DESKTOP@cptIt,
* McsEngl.bitcoin-mobile-wallet@cptIt,
* McsEngl.btcdesktop-wallet@cptIt,
name::
* McsEngl.btcwtp.computer.MOBILE@cptIt,
* McsEngl.bitcoin-mobile-wallet@cptIt,
* McsEngl.btcmobile-wallet@cptIt,
_DESCRIPTION:
Most mobile wallets support scanning bitcoin: URIs encoded in a QR code, and almost all wallets can display them for accepting payment.
While also handy for online orders, QR Codes are especially useful for in-person purchases.
[https://bitcoin.org/en/developer-guide#requesting-payments]
name::
* McsEngl.btcwtp.ELECTRUM@cptIt,
* McsEngl.electrum@cptIt,
* McsEngl.electrum-btc-wallet-program@cptIt,
_DESCRIPTION:
Electrum is a lightweight Bitcoin wallet.
[http://docs.electrum.org/en/latest/index.html]
name::
* McsEngl.btcwtp.FULL-SERVICE@cptIt,
_DESCRIPTION:
The simplest wallet is a program which performs all three functions: it generates private keys, derives the corresponding public keys, helps distribute those public keys as necessary, monitors for outputs spent to those public keys, creates and signs transactions spending those outputs, and broadcasts the signed transactions.
As of this writing, almost all popular wallets can be used as full-service wallets.
The main advantage of full-service wallets is that they are easy to use. A single program does everything the user needs to receive and spend satoshis.
The main disadvantage of full-service wallets is that they store the private keys on a device connected to the Internet. The compromise of such devices is a common occurrence, and an Internet connection makes it easy to transmit private keys from a compromised device to an attacker.
To help protect against theft, many wallet programs offer users the option of encrypting the wallet files which contain the private keys. This protects the private keys when they aren’t being used, but it cannot protect against an attack designed to capture the encryption key or to read the decrypted keys from memory.
[https://bitcoin.org/en/developer-guide#full-service-wallets]
_PART:
Several full-service wallets programs will also operate as two separate wallets:
one program instance acting as a signing-only wallet (often called an “offline wallet”) and the other program instance acting as the networked wallet (often called an “online wallet” or “watching-only wallet”).
[https://bitcoin.org/en/developer-guide#offline-wallets]
name::
* McsEngl.btcwtp.MYCELIUM@cptIt,
* McsEngl.Mycelium@cptIt,
_DESCRIPTION:
Mycelium Bitcoin Wallet
2,413
Mycelium Developers Finance
PEGI 3 PEGI 3
You don't have any devices
With the Mycelium Bitcoin Wallet you can send and receive Bitcoins using your mobile phone.
The unparalleled cold storage functionality allows you to 100% secure your funds until you are ready to spend them: http://youtu.be/jV-29RFU6xA
see also our promotional video "Mycelia in Wonderland" at https://www.youtube.com/watch?v=2_h9ZZwhwBg
- 100% control over your private keys, they never leave your device unless you export them
- No block chain download, install and run in seconds
- HD enabled - manage multiple accounts and never reuse addresses (Bip32, Bip44)
- Ultra fast connection to the Bitcoin network through our super nodes
- Watch-only addresses & private key import for secure cold-storage integration
- Secure your wallet with a PIN
- Compatible with other bitcoin services through bitcoin: uri handling
- Support for Bip38 Keys
- Find other people to trade Bitcoins with
Please always make sure you have backups of your private keys!
This application's source is published at https://github.com/mycelium-com/wallet
We need your feedback. If you have a suggestion or a bug to report open an issue at https://github.com/mycelium-com/wallet/issues
More features:
- Master seed based - make one backup and be safe for ever. (Bip39)
- 100% control over your private keys, they never leave your device unless you export them
- No block-chain download - install and run in seconds
- For enhanced privacy and availability you can connect to our super nodes via a tor hidden-service ( .onion address)
- Watch-only addresses (single key or HD) for a secure cold-storage integration
- Private key (single or xPriv) import
- Directly spend from paper wallets (single key, xPriv or master seed)
- Trezor enabled - directly spend from trezor-secured accounts.
- Mycelium Entropy compatible Shamir-Secret-Shared 2-out-of-3 keys spending
- Secure your wallet with a PIN
- Compatible with other bitcoin services through bitcoin: uri handling
- Encrypted PDF backup and restore of single key accounts
- Send and receive by specifying an amount in Fiat and switch between fiat and BTC while entering the amount
- Address book for commonly used addresses
- Transaction history with full transaction details.
- Share your bitcoin address using NFC, Twitter, Facebook, email and more.
- BIP70 payment request compatible
- Integration with service cashila.com to send money via SEPA
- Support for BitID Authentication
- Deterministic signatures for Bitcoin transactions (RFC6979)
Explanation for permission requests:
- Location - used to update LocalTrader location - only when user manually updates it.
- Camera/Microphone - Scan QR codes.
[https://play.google.com/store/apps/details?id=com.mycelium.wallet]
name::
* McsEngl.mycelium.EVOLUTING@cptIt,
{time.2016-07-23}
Mycelium, one of the world’s first and top rated software wallets, will integrate with Dash which will come into effect in October to allow Mycelium users to buy, sell and hold Dash, whose unique characteristics include extremely low fees, advanced encryption, instant transactions, and optional payment privacy through pool mixing technology.
Dash is like digital cash managed by a self funded, self governed organization comprised of over 15,000 users who move half a million dollars across the network every 24 hours. It can be spent instantly online and at merchants and service providers worldwide with transactions verified by miners and its system protected by 4,000 master nodes across the world. Its in-built governance and funding system allows projects to be proposed and voted on by the community, and if approved, paid for directly from the Blockchain.
The partnership is a testimony to the Dash system’s ability to make agreements with traditional corporations and keep its commitments while being a DAO.
[https://cointelegraph.com/news/dash-considered-alternative-to-bitcoin-integrates-into-mycelium]
name::
* McsEngl.btcwtp.OFFLINE@cptIt,
* McsEngl.btcOffline-wallet-program@cptIt,
* McsEngl.btcsigning-only-wallet@cptIt,
_DESCRIPTION:
Several full-service wallets programs will also operate as two separate wallets: one program instance acting as a signing-only wallet (often called an “offline wallet”) and the other program instance acting as the networked wallet (often called an “online wallet” or “watching-only wallet”).
The offline wallet is so named because it is intended to be run on a device which does not connect to any network, greatly reducing the number of attack vectors. If this is the case, it is usually up to the user to handle all data transfer using removable media such as USB drives. The user’s workflow is something like:
(Offline) Disable all network connections on a device and install the wallet software. Start the wallet software in offline mode to create the parent private and public keys. Copy the parent public key to removable media.
(Online) Install the wallet software on another device, this one connected to the Internet, and import the parent public key from the removable media. As you would with a full-service wallet, distribute public keys to receive payment. When ready to spend satoshis, fill in the output details and save the unsigned transaction generated by the wallet to removable media.
(Offline) Open the unsigned transaction in the offline instance, review the output details to make sure they spend the correct amount to the correct address. This prevents malware on the online wallet from tricking the user into signing a transaction which pays an attacker. After review, sign the transaction and save it to removable media.
(Online) Open the signed transaction in the online instance so it can broadcast it to the peer-to-peer network.
The primary advantage of offline wallets is their possibility for greatly improved security over full-service wallets. As long as the offline wallet is not compromised (or flawed) and the user reviews all outgoing transactions before signing, the user’s satoshis are safe even if the online wallet is compromised.
The primary disadvantage of offline wallets is hassle. For maximum security, they require the user dedicate a device to only offline tasks. The offline device must be booted up whenever funds are to be spent, and the user must physically copy data from the online device to the offline device and back.
[https://bitcoin.org/en/developer-guide#signing-only-wallets]
_DESCRIPTION:
To increase security, private keys can be generated and stored by a separate wallet program operating in a more secure environment. These signing-only wallets work in conjunction with a networked wallet which interacts with the peer-to-peer network.
... The following subsections describe the two most common variants of signing-only wallets: offline wallets and hardware wallets.
[https://bitcoin.org/en/developer-guide#signing-only-wallets]
name::
* McsEngl.btcwtp.os.ANDROID@cptIt,
* McsEngl.btcandroid-wallet@cptIt,
name::
* McsEngl.btcwtp.os.iOS@cptIt,
* McsEngl.btcios-wallet@cptIt,
name::
* McsEngl.btcwtp.os.LINUX@cptIt,
* McsEngl.btclinux-wallet@cptIt,
name::
* McsEngl.btcwtp.os.WINDOWS@cptIt,
* McsEngl.btcwindows-wallet@cptIt,
name::
* McsEngl.btcwtp.WEB@cptIt,
* McsEngl.bitcoin-web-wallet@cptIt,
* McsEngl.btcwlt.web@cptIt,
* McsEngl.btcwtp.web@cptIt,
_DESCRIPTION:
A-bitcoin-web-wallet is a-wallet-program that utilizes the-browser-program.
It could store the-keys online or locally.
[hmnSngo.2017-04-04]
_DESCRIPTION:
web-wallet:
A web service providing wallet functionality: ability to store, send and receive bitcoins.
User has to trust counter-party to keep their bitcoins securely and ready to redeem at any time.
It is very easy to build your own web wallet, so most of them were prone to hacks or outright fraud.
The most secure and respected web wallet is *Blockchain.info*.
Online exchanges also provide wallet functionality, so they can also be considered web wallets.
It is not recommended to store large amounts of bitcoins in a web wallet.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcwlt.HARDWARE@cptIt,
* McsEngl.bitcoin-hardware-wallet@cptIt,
* McsEngl.btcHardware-wallet@cptIt,
_GENERIC:
* bitcoin-signing-only-wallet-program#ql:btcwp.signing_only#
_DESCRIPTION:
A hardware wallet is a special type of bitcoin wallet which stores the user's private keys in a secure hardware device.
They have major advantages over standard software wallets:
private keys are often stored in a protected area of a microcontroller, and cannot be transferred out of the device in plaintext
immune to computer viruses that steal from software wallets
can be used securely and interactively, as opposed to a paper wallet which must be imported to software at some point
much of the time, the software is open source, allowing a user to validate the entire operation of the device
This page is an attempt to summarize all the known developments of hardware wallets that can use Bitcoin as part of their operation.
[https://en.bitcoin.it/wiki/Hardware_wallet]
===
Hardware wallets are devices dedicated to running a signing-only wallet. Their dedication lets them eliminate many of the vulnerabilities present in operating systems designed for general use, allowing them to safely communicate directly with other devices so users don’t need to transfer data manually. The user’s workflow is something like:
(Hardware) Create parent private and public keys. Connect hardware wallet to a networked device so it can get the parent public key.
(Networked) As you would with a full-service wallet, distribute public keys to receive payment. When ready to spend satoshis, fill in the transaction details, connect the hardware wallet, and click Spend. The networked wallet will automatically send the transaction details to the hardware wallet.
(Hardware) Review the transaction details on the hardware wallet’s screen. Some hardware wallets may prompt for a passphrase or PIN number. The hardware wallet signs the transaction and uploads it to the networked wallet.
(Networked) The networked wallet receives the signed transaction from the hardware wallet and broadcasts it to the network.
The primary advantage of hardware wallets is their possibility for greatly improved security over full-service wallets with much less hassle than offline wallets.
The primary disadvantage of hardware wallets is their hassle. Even though the hassle is less than that of offline wallets, the user must still purchase a hardware wallet device and carry it with them whenever they need to make a transaction using the signing-only wallet.
An additional (hopefully temporary) disadvantage is that, as of this writing, very few popular wallet programs support hardware wallets—although almost all popular wallet programs have announced their intention to support at least one model of hardware wallet.
[https://bitcoin.org/en/developer-guide#hardware-wallets]
name::
* McsEngl.btcwlt.hardware.LEDGER@cptIt,
* McsEngl.btcw.ledger@cptIt,
* McsEngl.ledger-btcw@cptIt,
* McsEngl.ledgerwallet@cptIt,
* McsEngl.btcw.ledger@cptIt,
_ADDRESS.WPG:
* https://www.ledgerwallet.com//
* http://support.ledgerwallet.com/knowledge_base/topics/general-ledger-nano-s-faq/
name::
* McsEngl.btcw.Ledger-nano-s (bhwlns)@cptIt,
* McsEngl.bhwlns@cptIt,
* McsEngl.bitcoin-hardware-wallet-ledger-nano-s@cptIt,
* McsEngl.Ledger-nano-s@cptIt,
_DESCRIPTION:
Ledger Nano S is a secure Bitcoin and Ethereum hardware wallet. It connects to any computer through USB and embeds a built-in OLED display to double-check and confirm each transaction with a single tap on its side buttons.
[http://support.ledgerwallet.com/knowledge_base/topics/general-ledger-nano-s-faq]
name::
* McsEngl.bwlns'Resource@cptIt,
_ADDRESS.WPG:
* config: https://www.ledgerwallet.com/start/
* https://medium.com/@Ledger/a-short-guide-to-nano-s-firmware-1-3-features-b92c939e7c9f#.pvihwc4h1,
* https://ledger.groovehq.com/knowledge_base/topics/firmware-upgrade-and-application-manager,
name::
* McsEngl.btcwlt.hardware.TREZOR ($99)@cptIt,
* McsEngl.trezor-btcw@cptIt,
* McsEngl.btcw.trezor@cptIt,
* McsEngl.trezor-btcw@cptIt,
_DESCRIPTION:
TREZOR is a secure bitcoin storage and a transaction signing tool. The private keys are generated by the device and never leave it thus they cannot be accessed by a malware.
It uses a deterministic wallet structure which means it can hold an unlimited number of keys (BIP 0032/BIP 0044). A recovery seed is generated when the device is initialized. In case TREZOR gets lost or stolen, all its contents can be recovered using this seed (private keys, bitcoin balance and transaction history) into a new device or another BIP 0039/BIP 0044 compatible wallet.
TREZOR also introduced a unique way of PIN entering preventing keyloggers from recording it even when entered on a compromised computer. An encryption passphrase can be set on top of the PIN protection. More passphrases can be used for plausible deniability.
[https://en.bitcoin.it/wiki/Hardware_wallet#TREZOR_The_Bitcoin_Safe]
_ADDRESS.WPG:
* https://www.buytrezor.com//
* http://themerkle.com/hardware-wallet-comparison-keepkey-vs-trezor-vs-ledger-nano//
* https://www.amazon.com/TREZOR-The-Bitcoin-Safe-Grey/dp/B00R6MRI50/ref=pd_sim_147_4?_encoding=UTF8&psc=1&refRID=3P0WRM4792AFXVT9HSZ4,
name::
* McsEngl.btcwlt.HD (Hierarchical-Deterministic)@cptIt,
* McsEngl.bitcoin-HD-wallet@cptIt,
* McsEngl.btcHD-wallet@cptIt,
* McsEngl.deterministic-wallet-of-btcnet@cptIt,
_DESCRIPTION:
The Hierarchical Deterministic (HD) key creation and transfer protocol (BIP32), which allows creating child keys from parent keys in a hierarchy.
Wallets using the HD protocol are called HD wallets.
[https://bitcoin.org/en/glossary/hd-protocol]
===
Deterministic_Wallet:
A collective term for different ways to generate a sequence of *private keys* and/or *public keys*. Deterministic wallet does not need a *Key Pool*.
The simplest form of a deterministic wallet is based on hashing a secret string concatenated with a key number.
For each number the resulting hash is used as a private key (public key is derived from it).
More complex scheme uses *elliptic curve arithmetic* to derive sequences of public and private keys separately which allows generating new *addresses* for every payment request without storing private keys on a web server.
More information on Bitcoin-Wiki#ql:https://en.bitcoin.it/wiki/Deterministic_wallet#.
See also *Wallet*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcwltHd'HD-protocoll@cptIt,
* McsEngl.btcHD-protocol@cptIt,
* McsEngl.btcBIP32@cptIt,
_ADDRESS.WPG:
* https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki,
_DESCRIPTION:
The hierarchical deterministic key creation and transfer protocol (HD protocol) greatly simplifies wallet backups, eliminates the need for repeated communication between multiple programs using the same wallet, permits creation of child accounts which can operate independently, gives each parent account the ability to monitor or control its children even if the child account is compromised, and divides each account into full-access and restricted-access parts so untrusted users or programs can be allowed to receive or monitor payments without being able to spend them.
[https://bitcoin.org/en/developer-guide#hierarchical-deterministic-key-creation]
===
The Hierarchical Deterministic (HD) key creation and transfer protocol (BIP32), which allows creating child keys from parent keys in a hierarchy. Wallets using the HD protocol are called HD wallets.
[https://bitcoin.org/en/glossary/hd-protocol]
name::
* McsEngl.btcwltHd'chain-code@cptIt,
* McsEngl.btcChain-Code@cptIt,
* McsEngl.btcHD-Wallet-Chain-Code@cptIt,
_DESCRIPTION:
In HD wallets, 256 bits of entropy added to the public and private keys to help them generate secure child keys; the master chain code is usually derived from a-seed#ql:btcroot_seed# along with the master private key
[https://bitcoin.org/en/glossary/chain-code]
name::
* McsEngl.btcMaster-chain-code@cptIt,
* McsEngl.Master-Chain-Code-And-Private-Key@cptIt,
_DESCRIPTION:
In HD wallets, the master chain code and master private key are the two pieces of data derived from the root seed.
[https://bitcoin.org/en/glossary/master-chain-code-and-private-key]
name::
* McsEngl.btcwltHd'child-key@cptIt,
* McsEngl.btcChild-Key@cptIt,
* McsEngl.btcHD-Wallet-Child-Key@cptIt,
_DESCRIPTION:
In HD wallets, a key derived from a parent key.
The key can be either a private key or a public key, and the key derivation may also require a-chain-code#ql:btcchain_code#.
[https://bitcoin.org/en/glossary/child-key]
name::
* McsEngl.btcwltHd'parent-key@cptIt,
* McsEngl.btcParent-Key@cptIt,
* McsEngl.btcHD-Wallet-Parent-Key@cptIt,
_DESCRIPTION:
In HD wallets, a key used to derive child keys. The key can be either a private key or a public key, and the key derivation may also require a chain code.
[https://bitcoin.org/en/glossary/parent-key]
name::
* McsEngl.btcwltHd'Root-seed@cptIt,
* McsEngl.btcHD-Wallet-Seed@cptIt,
* McsEngl.btcRoot-Seed@cptIt,
_DESCRIPTION:
A potentially-short value used as a seed to generate the master private key and master chain code for an HD wallet.
[https://bitcoin.org/en/glossary/hd-wallet-seed]
name::
* McsEngl.btcwlt.ONLINE (hot)@cptIt,
* McsEngl.btchot-wallet@cptIt,
* McsEngl.btcnetworked-wallet@cptIt,
* McsEngl.btcwallet.hot@cptIt,
_DESCRIPTION:
Wallets can be divided into two categories: hot and cold.
The difference between these is the location where the private keys are stored.
If the keys are stored on a computer connected to a network (like a laptop, desktop, or mobile device) the wallet is considered “hot” since the funds are within reach for you to use, but also for malware and cyber-criminals to steal.
If the private keys are stored on an offline device (like a laptop with disabled networking components, or a piece of paper) then it is considered “cold” since there is no way to gain access to the keys without having them physically in your hands.
[http://www.givebtc.org/GiveBTC_-_Handbook_for_Non_Profits.pdf]
name::
* McsEngl.btcwlt.ONLINE.NO (cold | offline)@cptIt,
* McsEngl.btccold-storage@cptIt,
* McsEngl.btccold-wallet@cptIt,
* McsEngl.btcwallet.cold@cptIt,
_DESCRIPTION:
Due to the risk of computers and USB drives being infected with bitcoin-stealing malware, most Bitcoin experts recommend storing your bitcoins offline. This is often referred to as “cold storage.”
[http://bitcoinconsultant.net/coinpro/]
===
btcCold_Storage:
A collective term for various security measures to reduce the risk of remote access to the private keys. It could be a normal computer disconnected from the internet, or a dedicated hardware wallet, or a USB stick with a wallet file, or a *paper wallet*.
name::
* McsEngl.btcnet'Human (btchmn)@cptIt,
* McsEngl.btchmn@cptIt,
* McsEngl.btchuman@cptIt,
* McsEngl.btccommunity@cptIt,
_ADDRESS.WPG:
* http://themonetaryfuture.blogspot.gr/2016/05/how-i-met-satoshi.html,
* http://www.drcraigwright.net//
* https://bitcointalk.org//
* https://bitcoin.org/en/community,
* http://motherboard.vice.com/blog/who-is-satoshi-nakamoto-the-creator-of-bitcoin,
_SPECIFIC:
* Nakamoto.Satoshi,
* Gavin Andresen
* Hal Finney
* Mark Karpeles
* Nick Szabo
* Amir Taaki
* Winklevoss twins
* Antonopoulos.Andreas,
name::
* McsEngl.btchmn'mailing-list@cptIt,
_ADDRESS.WPG:
* https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev,
name::
* McsEngl.btchmn.MINER@cptIt,
* McsEngl.bitcoin-miner@cptIt,
* McsEngl.btcminer@cptIt,
====== lagoGreek:
* McsElln.εξορύκτης-μπικόιν@cptIt,
_DESCRIPTION:
blocks are created by users known as "miners" who use specialized software or equipment designed specifically to create blocks.
[https://en.wikipedia.org/wiki/Block_chain_%28database%29]
name::
* McsEngl.btchmn.RECEIVER@cptIt,
* McsEngl.btcreceiver@cptIt,
name::
* McsEngl.btchmn.SPENDER@cptIt,
* McsEngl.btcspender@cptIt,
name::
* McsEngl.btchmn.USER@cptIt,
* McsEngl.btcuser@cptIt,
* McsEngl.btcnet'user@cptIt,
_DESCRIPTION:
Users of the system create transactions which are loosely passed around from node to node on a best-effort basis.
[https://en.wikipedia.org/wiki/Block_chain_%28database%29]
name::
* McsEngl.btchmn.Antonopoulos.Andreas@cptIt,
* McsEngl.human.Antonopoulos.Andreas@cptIt,
* McsEngl.Andreas-Antonopoulos@cptIt,
* McsEngl.Antonopoulos.Andreas@cptIt,
_ADDRESS.WPG:
* Internet of money: https://github.com/merklebloom/IoMv1/blob/master/chapters/en/master.asciidoc,
_DESCRIPTION:
Andreas M. Antonopoulos
Public Speaker | Author | Coder | Entrepreneur | Commentator
Author of “Mastering Bitcoin” by O’Reilly Media
MasteringBitcoin
Follow @aantonop on Twitter
Andreas M. Antonopoulos is a technologist and serial entrepreneur who has become one of the most well-known and well-respected figures in bitcoin. As an engaging public speaker, teacher and writer, Andreas makes complex subjects accessible and easy to understand. As an advisor, he helps startups recognize, evaluate, and navigate security and business risks.
Andreas literally grew up with the Internet, starting his first company, an early BBS and proto-ISP, as a teenager in his home in Greece. He earned degrees in Computer Science, Data Communications and Distributed Systems from University College London (UCL), recently ranked in the world’s top 10 universities. After moving to the US Andreas co-founded and managed a successful technology research company, and in that role advised dozens of Fortune 500 company executives on networking, security, data centers and cloud computing. More than 200 of his articles on security, cloud computing and data centers have been published in print and syndicated worldwide. He holds 2 patents in networking and security.
In 1990, Andreas started teaching on various IT topics in private, professional and academic environments. Andreas honed his speaking skills in front of audiences ranging in size from five executives in a boardroom to thousands of people in large conferences. With more than four hundred speaking engagements under his belt he is considered a world-class and charismatic public speaker and teacher. In 2014, he was appointed as a teaching fellow with the University of Nicosia, the first university in the world to offer a Masters Degree in Digital Currency. In this role, he helped to developed the curriculum and co-taught the Introduction to Digital Currencies course, offered as a MOOC (massively open online course), through the University.
As a bitcoin entrepreneur, Andreas has founded a number of bitcoin businesses and launched several community open-source projects. He serves as an advisor to several bitcoin and crypto-currency companies. He is a widely published author of articles and blog posts on bitcoin, is a permanent host on the popular Let’s Talk Bitcoin Podcast, and a frequent speaker at technology and security conferences worldwide.
[http://antonopoulos.com/]
_ADDRESS.WPG:
* https://antonopoulos.com//
* https://github.com/aantonop/bitcoinbook/blob/develop/book.asciidoc,
name::
* McsEngl.btchmn.Back.Adam@cptIt,
* McsEngl.human.Back.Adam@cptIt,
* McsEngl.Adam-Back@cptIt,
* McsEngl.Back.Adam@cptIt,
_DESCRIPTION:
Adam Back, Ph.D.
President
Having worked on e-cash protocols since 1995, Adam is an applied cryptographer and inventor of the hashcash proof-of-work and decentralized mining used in Bitcoin. In addition to implementing credlib, he was an e-cash consultant to Nokia and later to Credentica (acquired by Microsoft). Adam was an architect and cryptographer at Zero-Knowledge Systems working on its Freedom network, a precursor to Tor. He has also consulted for leading security companies, including oneID, Vmware and QWcap. Most recently, Adam co-founded Picorp, which was acquired by EMC and where he was CSO of the company’s consumer division, Decho. Adam holds a Ph.D. in distributed systems and computer science from the University of Exeter.
[https://www.blockstream.com/team/]
name::
* McsEngl.btchmn.Nakamoto.Satoshi (btchmnSnt)@cptIt,
* McsEngl.bcnhmn.Nakamoto.Satoshi@cptIt,
* McsEngl.btchmn.Nakamoto.Satoshi@cptIt,
* McsEngl.btchmnSnt@cptIt,
* McsEngl.btchmn.Satoshi-Nakamoto@cptIt,
* McsEngl.human.Nakamoto.Satoshi@cptIt,
* McsEngl.Satoshi-Nakamoto@cptIt,
* McsEngl.Nakamoto.Satoshi@cptIt,
_DESCRIPTION:
Satoshi Nakamoto (???? Nakamoto Satoshi?) is the name used by the person or group who invented bitcoin and created its original reference implementation, Bitcoin Core (formerly known as Bitcoin-Qt).
[https://en.wikipedia.org/wiki/Satoshi_Nakamoto]
===
Blockchain technology is the technological basis of Bitcoin, first described by its mysterious author Satoshi Nakamoto in his white paper “Bitcoin: A Peer-to-Peer Electronic Cash System”, published in 2008.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#a-next-generation-blockchain]
===
In November 2008, a paper, authored (probably pseudonymously) by Satoshi Nakamoto, was posted on the newly created Bitcoin.org website with the title 'Bitcoin: A Peer-to-Peer Electronic Cash System’.
The eight-page document described methods of using a peer-to-peer network to generate "a system for electronic transactions without relying on trust" and laid down the working principles of the cryptocurrency.
[http://www.coindesk.com/information/bitcoin-glossary//]
===
Satoshi left the project in late 2010 without revealing much about himself.
[https://bitcoin.org/en/faq#who-created-bitcoin]
===
A pseudonym of an author of initial Bitcoin implementation.
There are multitude of speculations on who and how many people worked on Bitcoin, of which nationality or age, but no one has any evidence to say anything definitive on that matter.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
Satoshi_Nakamoto:
The name used by the original inventor of the Bitcoin protocol, who withdrew from the project at the end of 2010.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.btcnet'Organization (btcogn)@cptIt,
* McsEngl.btcogn@cptIt,
* McsEngl.bitcoin-system-organization@cptIt,
* McsEngl.btcogn@cptIt,
name::
* McsEngl.btcogn.BITCOIN-FOUNDATION@cptIt,
* McsEngl.bitcoin-foundation@cptIt,
Σύλληψη ενός εκ των «πρωτοπόρων» του Bitcoin
Τετάρτη, 29 Ιανουαρίου 2014 16:06 UPD:16:11
REUTERS/LUCAS JACKSON
Ο αντιπρόεδρος του Ιδρύματος Bitcoin Τσάρλι Σρεμ κατά την έξοδό του από το Ομοσπονδιακό δικαστήριο του Μανχάταν στη Νέα Υόρκη.
Για ξέπλυμα χρημάτων συνελήφθη την Κυριακή στο αεροδρόμιο Κένεντι της Νέας Υόρκης ο 24χρονος Τσάρλι Σρεμ, ένας εκ των πλέον επιφανών υποστηρικτών της καθιέρωσης του διαδικτυακού νομίσματος, Bitcoin.
Ο Σρεμ συνελήφθη κατόπιν έρευνας της αμερικανικής υπηρεσίας Δίωξης Ναρκωτικών (DEA), καθώς κατηγορείται ότι, μαζί με συνεργό του, χρησιμοποίησαν bitcoins για να «ξεπλύνουν» χρήματα από πωλήσεις ναρκωτικών που σχετίζονταν με τη διαβόητη online αγορά Silk Road (η λειτουργία του τερματίστηκε κατόπιν επέμβασης των αρχών τον Οκτώβριο).
Σημειώνεται ότι ο Σρεμ ήταν αντιπρόεδρος του Ιδρύματος Bitcoin (Bitcoin Foundation), που έχει ως στόχο την καθιέρωση/ ευρεία αποδοχή του διαδικτυακού νομίσματος, και διευθύνων σύμβουλος, συνιδρυτής και επιβλέπων του ανταλλακτηρίου BitInstant.com.
Όπως έγινε γνωστό την Τρίτη, ο Σρεμ παραιτήθηκε από τη θέση του ως αντιπροέδρου του ιδρύματος μετά τη σύλληψή του.
Επίσης, συνελήφθη και ο 52χρονος Ρόμπερτ Φαϊέλα, (BTCKing) στη Φλόριντα.
Ειδικότερα, ο Σρεμ κατηγορείται ότι επέτρεψε στον Φαϊέλα να χρησιμοποιήσει το BitInstant για να αγοράσει μεγάλα ποσά bitcoins (αξίας ενός εκατ. δολαρίων), για να τα πουλήσει σε χρήστες του Silk Road που επιθυμούσαν να αγοράσουν ναρκωτικά. Σύμφωνα με τις αρχές, ο Σρεμ ήξερε ότι τα bitcoins προορίζονταν για αυτή τη χρήση.
EURONEWS
Η.Π.Α: Συνελήφθησαν δύο άτομα που ξέπλεναν χρήματα χρησιμοποιώντας bitcoin
Εκπρόσωπος του Bitcoin Foundation εξέφρασε την έκπληξη του ιδρύματος από την εξέλιξη της υπόθεσης, διαχωρίζοντας τη θέση του από τις συγκεκριμένες δραστηριότητες.
Το BitInstant ήταν ένα από τα μεγαλύτερα ανταλλακτήρια bitcoins στο Ίντερνετ, ωστόσο η πρόσβαση σε αυτό δεν ήταν δυνατή για κάποιο χρονικό διάστημα, όπως δήλωσε στο BBC ο Μάικ Χιρν, στέλεχος του συμβουλίου του Bitcoin Foundation.
[http://www.naftemporiki.gr/story/758439]
name::
* McsEngl.btcogn.SERVICE@cptIt,
* McsEngl.btcnet'service@cptIt,
* McsEngl.bitcoin-service@cptIt,
* McsEngl.btcService-organization@cptIt,
* McsEngl.ognBtcsvc@cptIt,
name::
* McsEngl.btcogn.EXCHANGE (btcognX)@cptIt,
* McsEngl.bitcoin-exchange@cptIt,
* McsEngl.btcexchange@cptIt,
_DESCRIPTION:
Exchange:
A central resource for exchanging different forms of money and other assets.
Bitcoin exchanges are typically used to exchange the cryptocurrency for other, typically fiat, currencies.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.btcognX'Resource@cptIt,
_ADDRESS.WPG:
* https://twitter.com/TuurDemeester/status/820332549469835264,
_SPECIFIC:
* https://bitcoinsgreece.com//
* https://www.mtgox.com//
Popular Bitcoin Currency Exchanges
(New York) BitInstant
- Cash Deposit (USA, Russia, Brazil)
(New York) BitFloor.com
- Cash Deposits (Chase, Wells Fargo)
- ING person2person
- Wire Transfer
(London) Intersango.com
- ACH
- Dwolla
- Wire Transfer
(Tokyo) MtGox.com
- Cash Deposit (BitInstant)
- Dwolla
- Wire Transfer
(Slovenia) BitStamp.net
- Cash Deposit (BitInstant)
- SEPA Transfer
- Wire Transfer
(Atlanta) CampBX.com
- Check, Money Order
- Dwolla
- Wire Transfer
(NSW, Australia) CryptoXChange.com
- Cash Deposit (BitInstant)
- Dwolla
- Bank Transfer
(Moscow) BTC-e.com
- Cash Deposit (BitInstant)
- SEPA Transfer
- Wire Transfer
(Hadera, Israel) Bitcoil.co.il
- Bank Transfer
(Fujian, China) BTCChina.com
[http://lovebitcoins.org/exchange.html]
name::
* McsEngl.btcognX.Cashila@cptIt,
* McsEngl.Cashila-ogn@cptIt,
_DESCRIPTION:
The bridge between bitcoin and euro.
Pay bills, send and receive money. Fast.
[https://www.cashila.com/]
name::
* McsEngl.btcognX.Mt.Gox@cptIt,
* McsEngl.btcMt.Gox@cptIt,
_DESCRIPTION:
Mt.Gox:
One of the first bitcoin exchanges, and at one time the most popular.
Mt.Gox has since gone into administration.
Based in Japan, the exchange was started by Jed McCaleb in 2010.
Read the latest Mt.Gox news.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.btcognX.OTC@cptIt,
* McsEngl.btcOTC-exchange@cptIt,
_DESCRIPTION:
OTC_exchange:
An exchange in which traders make deals with each other directly, rather than relying on a central exchange to mediate between them.
[http://www.coindesk.com/information/bitcoin-glossary//]
name::
* McsEngl.btcogn.CLOUD-MINING@cptIt,
* McsEngl.bitcoin-cloud-mining@cptIt,
* McsEngl.btccloud-mining@cptIt,
_DESCRIPTION:
Most Bitcoin Cloud Mining Companies are Scams
Like the heading says, most cloud mining contracts are scams. Why? Because it’s easy for companies to take peoples’ money, and then not pay out. A company can claim to be a cloud mining company without any proof of actually owning any hardware.
So remember: 99% of cloud mining companies are scams.
Which Companies Are Not Scams?
There is only one cloud mining company we are willing to recommend on this site: Genesis Mining.
Just because it is not a scam, however, does not mean that you will make a profit by using it.
[https://www.hobbymining.com/bitcoin-cloud-mining/]
name::
* McsEngl.btcogn.MINING-POOL@cptIt,
* McsEngl.bitcoin-mining-pool@cptIt,
* McsEngl.btcmining-pool@cptIt,
_DESCRIPTION:
What is a Mining Pool?
Mining, once done on the average home computer, is now mostly done in large, specialized warehouses. These warehouses usually direct their hashing power towards mining pools. What is a mining pool? Here’s the definition from Buy Bitcoin Worldwide:
Mining pools are groups of cooperating miners who agree to share block rewards in proportion to their contributed mining hashing power. While mining pools are desirable to the average miner as they smooth out rewards and make them more predictable, they unfortunately concentrate power to the mining pool’s owner. Miners can, however, choose to redirect their hashing power to a different mining pool at anytime.
While we can see which mining pools are the largest, it’s important to understand that the hash power pointed towards a mining pool isn’t necessarily owned by the mining pool itself. There are a few cases, like with BitFury and KnCMiner, where the company itself runs the mining operation but doesn’t run a mining pool.
Bitcoin miners can switch mining pools easily by routing their hash power to a different pool. The market share of pools is constantly changing. To make the list of top 10 miners, we looked at blocks found over the past 6 months using data from BlockTrail. The size of mining pools is constantly changing. We will do our best to keep this posted up-to-date. Note that if you cloud mine then you don’t need to select a pool; the cloud mining company does this automatically.
[https://www.hobbymining.com/bitcoin-mining-pools/]
name::
* McsEngl.btcogn.WALLET@cptIt,
name::
* McsEngl.ognBtc.Blocktrail@cptIt,
_DESCRIPTION:
A Powerful Bitcoin Wallet
Blocktrail is a Bitcoin wallet that puts you in full control of your Bitcoin
[https://www.blocktrail.com/]
name::
* McsEngl.btcogn.BitNation@cptIt,
* McsEngl.bitnation@cptIt,
_ADDRESS.WPG:
* https://bitnation.co// (Colombia)
* https://github.com/Bit-Nation,
CONSTITUTION:
* https://github.com/Bit-Nation/BITNATION-Constitution,
name::
* McsEngl.btcogn.Stashcrypto@cptIt,
* McsEngl.stashcrypto@cptIt,
name::
* McsEngl.btcogn.MERCHANT@cptIt,
* McsEngl.bitcoin-merchant@cptIt,
* McsEngl.bitcoin-shopping-organization@cptIt,
* McsEngl.btcmerchant@cptIt,
_SPECIFIC:
* bitit https://bitit.gift//
name::
* McsEngl.btcpurse@cptIt,
_DESCRIPTION:
Purse is a marketplace that connects shoppers with unused gift cards.
Shoppers pay with bitcoins at a huge discount, and Earners liquidate gift cards.
[https://purse.io/]
name::
* McsEngl.btcogn.EXCHANGE@cptIt,
* McsEngl.bitcoin-exchange-ogn@cptIt,
* McsEngl.btcmny'exchanger@cptIt,
* McsEngl.btcnet'exchange@cptIt,
* McsEngl.bitcoin-exchange@cptIt,
* McsEngl.bitcoin-marketplace@cptIt,
* McsEngl.bitcoin-exchange@cptIt,
====== lagoGreek:
* McsElln.ανταλλακτήριο-μπιτκόιν@cptIt,
_DESCRIPTION:
Digital currency exchangers (DCEs) or Bitcoin exchanges are businesses that allow customers to trade digital currencies for other assets, such as conventional fiat money, or different digital currencies.[1] They can be market makers that typically take the bid/ask spreads as transaction commissions for their services or simply charge fees as a matching platform.[1]
DCEs may be brick-and-mortar businesses, exchanging traditional payment methods and digital currencies, or strictly online businesses, exchanging electronically transferred money and digital currencies.[2] Most digital currency exchanges operate outside of Western countries, avoiding regulatory oversight and complicating prosecutions, but DCEs often handle Western fiat currencies, sometimes maintaining bank accounts in several countries to facilitate deposits in various national currencies.[3][4] They may accept credit card payments, wire transfers, postal money orders, or other forms of payment in exchange for digital currencies, and many can convert digital currency balances into anonymous prepaid cards which can be used to withdraw funds from ATMs worldwide.[3][4]
Some digital currencies are backed by real-world commodities such as gold.[5]
Creators of digital currencies are often independent of the DCEs that trade the currency.[4] In one type of system, digital currency providers, or DCPs, are businesses that keep and administer accounts for their customers, but generally do not issue digital currency to those customers directly.[2][6] Customers buy or sell digital currency from DCEs, who transfer the digital currency into or out of the customer's DCP account.[6] Some DCEs are subsidiaries of DCP, but many are legally independent businesses.[2] The denomination of funds kept in DCP accounts may be of a real or fictitious currency.[6]
https://en.wikipedia.org/wiki/Digital_currency_exchanger
===
The easiest way to obtain bitcoins is to receive them from another person. This can be done as an in-person trade, or you can accept bitcoins for your business using some business tools.
It is also easy to buy bitcoins at a currency exchange. There are many online currency exchanges that let you buy and sell bitcoins for US Dollars, Euros, Pounds, and many other currencies.
You can fund your exchange account with a cash deposit or electronic funds transfer. To learn more about cash deposits, visit BitInstant.com.
[http://lovebitcoins.org/exchange.html]
name::
* McsEngl.btcogn.PAYMENT-PROCESSOR@cptIt,
* McsEngl.bitcoin-internet-payment-system@cptIt,
* McsEngl.bitcoin-payment-processor@cptIt,
* McsEngl.bitcoin-transaction-service@cptIt,
name::
* McsEngl.btcogn.PAYROLL@cptIt,
* McsEngl.bitcoin-salary-payment-system@cptIt,
_ADDRESS.WPG:
* http://cointelegraph.com/news/bitcoin-payroll-hits-germany-bitpay-partnering-with-pey, {2016-03-29}
name::
* McsEngl.btcnet'Evaluation (btceln)@cptIt,
* McsEngl.btceln@cptIt,
* McsEngl.btcevaluation@cptIt,
* McsEngl.btcnet'evaluation@cptIt,
EVALUATION:
The current debate centers on a perceived tradeoff between the ability to process a growing number of transactions, on the one hand, and maintaining a highly decentralized mechanism for processing transactions on the other.
[http://www.forbes.com/sites/realspin/2015/09/08/new-bitcoin-development-spurs-unnecessary-fear-of-centralization/]
EVALUATION:
5. Could you speculate on what the future may hold for bitcoin specifically and digital currencies generally?
First it’s important to recognize that most “digital currencies” are not really digital currencies at all, because they are pegged to standard currencies. Credits in your Paypal account are really just USD-backed; they are not a unique currency themselves. Other “digital currencies” such as Facebook Credits, can be created out of nothing and without limit, so they are not serious money (ironically, the USD is more like Facebook Credits than Bitcoin, because both USD and Facebook Credits can be created out of thin air, whereas Bitcoin cannot be).
So Bitcoin is the first, what should be called “true” digital currency. It is a scarce, digital commodity with properties that make it perfect for use as money, and so it is used for this purpose.
As the world starts to realize the benefits of a real digital currency, it will become used in countless ways. It will become as ubiquitous as email (and for the very same reason – email made the cost of written communication near-zero and Bitcoin makes the cost of monetary communication near-zero). Really, there is no reason it should cost $45 to send a “wire transfer” of money between two people. The bank is just changing digital numbers in a digital database – why does it cost $45 and take 3 days? It’s absurd, and Bitcoin finally offers a real alternative.
Bitcoin is an invention which people will look back upon and say, “wow, that was obviously needed,” just as we look back on the internet today. And, like the internet, Bitcoin will change the way people interact and do business around the world. But, it’s a process that takes years, and it’s only just getting started.
[http://keepyourassets.net/2012/09/27/bitcoin-the-first-five-questions/]
name::
* McsEngl.btcnet'Advantage (pro)@cptIt,
* McsEngl.btcnet'benefit@cptIt,
* McsEngl.btcadvantage@cptIt,
* McsEngl.btcpro@cptIt,
* McsEngl.bitcoin-favorable-factor@cptIt,
* McsEngl.bitcoin-pro@cptIt,
_SPECIFIC:
* cheap micropayments,
* fast transactions,
* global interoperability, international currency,
* trustless (you don’t have to trust anyone)
* Bitcoins cannot be counterfeited,
the benefits of Bitcoin - fast transactions, global interoperability, cheap micropayments
[http://cointelegraph.com/news/bitcoin-in-africa-could-leapfrog-just-like-cellular-phones-replaced-landline]
2. What are the major advantages of bitcoin? How does bitcoin differ from other international payment systems like PayPal?
Advantages include:
1. Zero fee to transfer money
2. Transfers are instant. No holiday or weekend delays.
3. Works globally, no territory restrictions
4. Enables the storage and transfer of wealth with zero counter-party risk (ie – you don’t have to trust anyone)
5. Excellent hedge against monetary debasement (inflation)
6. Any amount can be sent (perfect for microtransactions under a penny, for example)
7. Zero chargeback risk (this means, once a merchant receives Bitcoin, there is no risk of a payment reversal or fraud. The funds are immediately “good”)
8. Ability to move around capital controls (for example, to get money out of China or Argentina)
9. Anyone can accept and use Bitcoin.
10. Open-source, continually upgradable. Anyone can adapt and improve the software and build with it.
How does this differ from PayPal? PayPal doesn’t share any of the above advantages, except perhaps for number 2. It’s important to realize that PayPal is just a payment system for US dollars using the traditional banking infrastructure, while Bitcoin is a payment system for its own currency unit: bitcoins, and is entirely separate from the traditional banking infrastructure.
[http://keepyourassets.net/2012/09/27/bitcoin-the-first-five-questions/]
BITCOIN IS BETTER THAN REGULAR CURRENCIESSome of the reasons Bitcoin is better than regular currencies:
Bitcoin is an international currency.
Bitcoin can be spent all over the world.
Bitcoins cannot be counterfeited.
There is no printing technology that will ever be able to fool the bitcoin network.
Bitcoin cannot be devalued.
Only 21 million bitcoins will ever be issued. Unlike regular currencies, since Bitcoin is not controlled by any government or bank, the raising of a debt ceiling and quantitative easing can not devalue bitcoins.
[https://www.bitstamp.net/help/what-is-bitcoin/]
Use Bitcoins instead of PayPal
Not linked to your bank account
No central authority telling you what you can and cannot do with your money
Available in any country
Your account can never be seized or closed
Use Bitcoins for Remittance
Eliminate the high fees
No minimum or maximum amount
Available in any country
Use Bitcoins instead of Debit or Credit Cards
Not linked to your bank account
No risk of identity theft
No chance of overdraft fees or overlimit fees
No monthly fees or annual fees
Use Bitcoins instead of Online Banking
Deposits are available within minutes
No International Boundaries: send and receive anywhere in the world for no additional fees
Unlimited Access: have full control of your money, 24 hours/day, 7 days/week, from anywhere in the world
[http://lovebitcoins.org/introduction1.html]
name::
* McsEngl.btcnet'Disadvantage (con)@cptIt,
* McsEngl.bitcoin-cons@cptIt,
* McsEngl.bitcoin-problem@cptIt,
* McsEngl.bitcoin-issue@cptIt,
3. What are the major liabilities of bitcoin? Is it associated with any major security problems?
Disadvantages include:
1. Steep learning curve
2. Requires personal responsibility (if you delete your wallet without making backups, your money is gone).
3. Value fluctuates and is relatively volatile (no guarantee that the price tomorrow will be the same as today).
Regarding security problems – this is an important point. All of the “bitcoin hacks” and security breaches to date have not been against Bitcoin itself, but rather against various companies and individuals who did not secure things properly. Consider a bank that leaves its doors and vault unlocked at night… it will find a theft has occurred in the morning. This doesn’t mean the US dollar was hacked, or that banking as an institution is necessarily at fault, but simply that one specific bank screwed up. The same is true with Bitcoin.
Frankly, it is very easy to lose your bitcoins if you are foolish, and it is very easy to never lose them if you are smart. The system requires some personal responsibility and due diligence. Because there is no company behind Bitcoin itself, there is no tech support you can call (this is the same with cash or bars of gold – if you lose them, they are gone, and nobody can get them back for you).
4. Is bitcoin commonly used to facilitate illegal transactions? Is it, as it has been characterized, a currency of crime?
Bitcoin, like any money, can be used for illegal transactions. Because of its private, secure nature, it is impossible to know the extent to which it is used for such purposes (just like we don’t know how much cash is used for illicit activity, but we all know that it happens).
Certainly the media has characterized Bitcoin as a “currency of crime”, because A) they don’t understand it and B) crime makes a good news story. Bitcoin is a highly powerful technology (like fire, or automobiles, or the internet itself) and thus it carries risk and danger. It can be used for good or evil – Bitcoin is morally agnostic, it’s just a tool. Now, to be sure, it’s a very good tool , and this means criminals will love to use it, just as good people will love to use it.
Likely for the foreseeable future, US dollar cash will remain the preferred currency of crime.
[http://keepyourassets.net/2012/09/27/bitcoin-the-first-five-questions/]
BITCOIN RISKS Do not invest anything in Bitcoin you can not afford to lose. Investing in Bitcoin or any other currency is not without risk. For example, any of the following could happen to Bitcoin:
Another crypto-currency might surpass Bitcoin
Several have already tried and failed.
A weakness in the encryption might be discovered
This is the same encryption used in online banking. Like banking systems, if a flaw is found in a particular algorithm, the Bitcoin client can be upgraded to use different encryption algorithms.
Governments might try to ban or regulate Bitcoin
This would be similar to the government banning the Internet because of illegal uses. Banning the Internet is unlikely because it would place the government and its people at a strategic communications disadvantage. Banning bitcoins, is similarly unlikely as it would place the government and its people at a strategic economic disadvantage.
An unfixable flaw might be discovered in the Bitcoin protocol
People have been trying to find a flaw for over two years.
[https://www.bitstamp.net/help/what-is-bitcoin/]
The Economic Problem is entirely separate. Whereas the Security Problem may wreck BTC, if BTC is not wrecked and takes over a large macro-economy (as people abandon government issued money for BTC), it is BTC that will wreck the economy. Why? Because it is designed to mimic the Gold Standard – the monetary system that caused one depression after the other, from the 19th Century until 1929, and which was replaced because capitalism cannot breathe under a fixed quantity of money.
Mr Nakamoto, BTC’s creator (whoever he, she or they may be) used ‘built-in scarcity’ in order to ensure that BTC would grow in value relative to the dollar, the euro, the yen etc. and thus attract ‘disciples’ to the BTC community. Unwittingly, however, Nakamoto was reinventing a deflationary currency by simulating a Gold Standard through the BTC algorithm. So, if the Security Problem does not shoot down BTC first, and BTC or something similar ‘takes over the world of money’, we are on our way to re-engineering the crashes of 1884,1890,1896,1901,1907 and 1929…
[http://yanisvaroufakis.eu/2014/03/13/on-bitcoins-potential-qa-on-what-bitcoin-can-and-cannot-offer-a-troubled-world/]
name::
* McsEngl.btcnet'performance@cptIt,
_DESCRIPTION:
Today the Bitcoin network is restricted to a sustained rate of 7 tps due to the bitcoin protocol restricting block sizes to 1MB.
VISA handles on average around 2,000 transactions per second (tps), so call it a daily peak rate of 4,000 tps. It has a peak capacity of around 56,000 transactions per second, [1] however they never actually use more than about a third of this even during peak shopping periods. [2]
PayPal, in contrast, handles around 10 million transactions per day for an average of 115 tps. [3]
Let's take 4,000 tps as starting goal. Obviously if we want Bitcoin to scale to all economic transactions worldwide, including cash, it'd be a lot higher than that, perhaps more in the region of a few hundred thousand tps. And the need to be able to withstand DoS attacks (which VISA does not have to deal with) implies we would want to scale far beyond the standard peak rates. Still, picking a target let us do some basic calculations even if it's a little arbitrary.
[https://en.bitcoin.it/wiki/Scalability], {2015-09-04}
name::
* McsEngl.btcnet'Relation-to-gold@cptIt,
_DESCRIPTION:
BITCOIN IS BETTER THAN GOLDFor thousands of years, gold has been one of the safest stores of value. Many people hold gold to reduce their fiat risk. Bitcoin has many advantages over gold:
Gold is not divisible
You can not easily cut up gold to give people small amounts. Bitcoin is easily divisible to 8 decimal places.
Gold is not instantly assayable
You can’t instantly tell if gold is pure. You can instantly prove you have real bitcoins.
Gold is not instantly weighable
You need a scale to weigh gold. You can instantly prove how many bitcoins you have.
Gold is not transmittable over the Internet
Sending gold notes has counterparty risk. Bitcoins are easily sent on the Internet.
Gold can be outlawed and confiscated
The US government can and has in the past made it illegal to own gold. You can memorize your Bitcoin private key.
[https://www.bitstamp.net/help/what-is-bitcoin/]
name::
* McsEngl.btcnet'Law (btclaw)@cptIt,
* McsEngl.btclaw@cptIt,
* McsEngl.bitcoin-law@cptIt,
* McsEngl.bitcoin-legal-status@cptIt,
_ADDRESS.WPG:
* https://en.wikipedia.org/wiki/Legality_of_bitcoin_by_country,
_DESCRIPTION:
The legal status of bitcoin varies substantially from country to country and is still undefined or changing in many of them.
While some countries have explicitly allowed its use and trade, others have banned or severely restricted it.
Likewise, various government agencies, departments, and courts have classified bitcoins differently.
While this article provides the legal status of bitcoin, regulations and bans that apply to this cryptocurrency likely extend to similar systems as well.
Steven Strauss, a Harvard public policy professor, suggested that governments could outlaw bitcoin in April 2013,[1] and this possibility was mentioned again in a July 2013 regulatory filing made by a bitcoin investment vehicle.[2]
However, the vast majority of nations have not done so as of 2014.
Bitcoin is illegal in Bangladesh,[3] Bolivia,[4] Ecuador,[5] Kyrgyzstan,[6] Russia,[7] and Vietnam.[8]
It has also been reported illegal in Indonesia.[9]
[https://en.wikipedia.org/wiki/Legality_of_bitcoin_by_country]
_DESCRIPTION:
Bitcoins are illegal because they're not legal tender
In March 2013, the U.S. Financial Crimes Enforcement Network issues a new set of guidelines on "de-centralized virtual currency", clearly targeting Bitcoin. Under the new guidelines, "a user of virtual currency is not a Money Services Businesses (MSB) under FinCEN's regulations and therefore is not subject to MSB registration, reporting, and record keeping regulations." [2] Miners, when mining bitcoins for their own personal use, aren't required to register as a MSB or Money Transmitter. [3]
In general, there are a number of currencies in existence that are not official government-backed currencies. A currency is, after all, nothing more than a convenient unit of account. While national laws may vary from country to country, and you should certainly check the laws of your jurisdiction, in general trading in any commodity, including digital currency like Bitcoin, BerkShares, game currencies like WoW gold, or Linden dollars, is not illegal.
[https://en.bitcoin.it/wiki/Myths]
_DESCRIPTION:
Bitcoins will be shut down by the government just like Liberty Dollars were
Liberty Dollars started as a commercial venture to establish an alternative US currency, including physical banknotes and coins, backed by precious metals. This, in and of itself, is not illegal. They were prosecuted under counterfeiting laws because the silver coins allegedly resembled US currency.
Bitcoins do not resemble the currency of the US or of any other nation in any way, shape, or form. The word "dollar" is not attached to them in any way. The "$" symbol is not used in any way.
Bitcoins have no representational similarity whatsoever to US dollars.
Of course, actually 'shutting down' Liberty Dollars was as easy as arresting the head of the company and seizing the offices and the precious metals used as backing. The decentralized Bitcoin, with no leader, no servers, no office, and no tangible asset backing, does not have the same vulnerability.
[https://en.bitcoin.it/wiki/Myths]
name::
* McsEngl.btclaw'LEGAL@cptIt,
_SPECIFIC:
* Australia Yes[10]
* Belgium Yes[12]
* Brazil Yes[14] Bitcoin is regulated under a 2013 law that discusses both mobile payment systems and electronic currencies.[14]
* Canada Yes[15] Bitcoin is regulated under anti-money laundering and counter-terrorist financing laws in Canada.[16]
* Colombia Yes[18]
* Croatia Yes[19]
* Czech Republic Yes[20]
* Cyprus Yes[21]
* Denmark Yes[22]
* France Yes[23]
* Germany Yes[24]
* Hong Kong Yes[25]
* Israel Yes[31]
* Italy Yes[32]
* Japan Yes[33]
* Jordan Yes The government of Jordan has issued a warning discouraging the use of bitcoin and other similar systems.[34]
* Lebanon Yes The government of Lebanon has issued a warning discouraging the use of bitcoin and other similar systems.[34]
* New Zealand Yes[35]
* Norway Yes[36]
* Poland Yes[37]
* Singapore Yes[41]
* Slovenia Yes[42]
* South Korea Yes[43] While not illegal in the country, Korean authorities will prosecute illegal activity involving bitcoin[44] and have indicted at least one individual for purchasing drugs with bitcoin.[45]
* Spain Yes[46]
* Switzerland Yes[47] Bitcoin businesses in Switzerland are subject to anti-money laundering regulations and in some instances may need to obtain a banking license.[47]
Sweden Yes[48]
* Turkey Yes[52]
* United Kingdom Yes[53]
* United States Yes
name::
* McsEngl.btclaw'RESTRICTED@cptIt,
_SPECIFIC:
* China (PRC) Restricted[17] Financial institutions cannot use or involve themselves with bitcoins.[17]
* Iceland Restricted[26] According to a 2014 opinion from the Central Bank of Iceland "there is no authorization to purchase foreign currency from financial institutions in Iceland or to transfer foreign currency across borders on the basis of transactions with virtual currency. For this reason alone, transactions with virtual currency are subject to restrictions in Iceland."[26] This does not stop[27] businesses in Iceland from mining bitcoins.[28]
* Taiwan Restricted[7] Bitcoin ATMs are banned here[7] although through a convoluted process, bitcoins can be purchased at some convenience stores kiosks that also sell train tickets and allow paying bills.[49]
name::
* McsEngl.btclaw'ILLEGAL@cptIt,
_SPECIFIC:
* Argentina,
* Bangladesh,
* Bolivia,
* Ecuador,
* Indonesia,
* Kyrgyzstan,
* Russia,
* Thailand,
* Vietnam,
_DESCRIPTION:
Bitcoin is illegal in
* Bangladesh,[3]
* Bolivia,[4]
* Ecuador,[5]
* Indonesia
* Kyrgyzstan,[6]
* Russia,[7] and
* Vietnam.[8] It has also been reported illegal in Indonesia.[9]
[https://en.wikipedia.org/wiki/Legality_of_bitcoin_by_country]
name::
* McsEngl.btcnet'Relation-to-PayPal@cptIt,
Difference between PayPal and Bitcoin international money transfer. (self.Bitcoin)
2016-02-23 19 hours ago ap? mouwe
I sent 100 euro via PayPal to a friend in Mexico today, and he received 1827.09 pesos (91.98 euro, 8% costs). It will take him 3-4 days to withdraw from PayPal to his Mexican bank account.
I also sent him 100 euro worth of bitcoin. I bought the bitcoin at www.bitonic.nl (Dutch exchange), sent it to him, and he withdrew with www.bitso.com (Mexican exchange). He received 1957.87 pesos (98.56 euro, 1.4% costs) and it took 45 minutes (waiting for 4 confirmations).
Adios PayPal !
[https://www.reddit.com/r/Bitcoin/comments/472ppl/difference_between_paypal_and_bitcoin/]
name::
* McsEngl.btcnet'Resource (btcrsc)@cptIt,
* McsEngl.bitcoin-resource@cptIt,
* McsEngl.btcresource@cptIt,
* McsEngl.btcrsc@cptIt,
_GENERIC:
* resource#cptResource843#
_ADDRESS.WPG:
* http://bitcoin.org//
* Resource#cptResource843#,
* http://sourceforge.net/projects/bitcoin//
* https://github.com/bitcoin-dot-org/bitcoin.org,
* https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf,
===
* http://davidederosa.com/basic-blockchain-programming//
===
* Top 10 Moments in Bitcoin History - Bitcoin.com https://www.youtube.com/watch?v=KplwstaZ_4M,
* https://www.weusecoins.com//
* Bitcoin Is Officially a Commodity, According to U.S. Regulator
The Commodity Futures Trading Commission makes its mark.
http://www.bloomberg.com/news/articles/2015-09-17/bitcoin-is-officially-a-commodity-according-to-u-s-regulator,
* http://www.michaelnielsen.org/ddi/how-the-bitcoin-protocol-actually-works/
* Nik Custodio Dec 12, 2013, Explain Bitcoin Like I’m Five:
https://medium.com/@nik5ter/explain-bitcoin-like-im-five-73b4257ac833,
* https://twitter.com/topnewsbitcoin,
* http://www.techiechan.com/?p=1954,
* http://www.spiegel.de/international/business/germany-declares-bitcoins-to-be-a-unit-of-account-a-917525.html,
* http://bitcoinmagazine.com//
* http://lovebitcoins.org//
* http://bitcoin.stackexchange.com//
* https://www.weusecoins.com/en//
* http://bitcoincharts.com/
* https://localbitcoins.com/
* https://bitcointalk.org/
* http://dailyjs.com/2013/08/23/bitcoins//
* https://npmjs.org/package/bitcoin,
* http://www.coindesk.com/information/bitcoin-glossary//
* http://greece.greekreporter.com/2015/04/01/yanis-varoufakis-greece-will-adopt-the-bitcoin-if-eurogroup-doesnt-give-us-a-deal//
===
* china: http://money.cnn.com/2013/11/18/investing/bitcoin-china/index.html,
_BOOK:
* Adonopoulos: mastering bitcoin https://github.com/aantonop/bitcoinbook,
- https://github.com/bitcoinbook/bitcoinbook/tree/develop,
- http://files.brendafernandez.com/Mastering%20Bitcoin/Mastering%20Bitcoin.pdf,
_TUTORIAL:
* https://bitcoin.org/en/developer-guide,
* https://bitcoin.org/en/developer-reference,
* https://bitcoin.org/en/developer-glossary,
* http://www.givebtc.org/GiveBTC_-_Handbook_for_Non_Profits.pdf,
name::
* McsEngl.btcnet'resource.MASTERING-BITCOIN in Greek (Αυθεντία-στο-Μπιτκόιν) {2016}@cptIt,
* McsEngl.btcmbc@cptIt,
* McsEngl.mastering-bitcoin@cptIt,
* McsElln.Αυθεντία-στο-Μπτικόιν@cptIt,
* McsElln.Γίνε-Αυθεντία-στο-Μπτικόιν@cptIt,
* McsElln.Δαμάζοντας-το-Μπτικόιν@cptIt,
_DESCRIPTION:
<a class="clsPreview" href="../dirMcs/dirTchInf/dirHitp/HitpTchInf002.last.html#idDescription">text in Mcsh-site</a>,
“Mastering Bitcoin by Andreas M. Antonopoulos (O’Reilly).
Copyright 2015 Andreas M. Antonopoulos, 978-1-449-37404-4.”
Mετάφραση στα Ελληνικά: Dimosthenis Chatzinikolaou - Δημοσθένης Χατζηνικολάου (@chdimosthenis)
_ADDRESS.WPG:
* https://www.bitcoinbook.info//
* https://www.bitcoinbook.info/translations-of-mastering-bitcoin//
* https://github.com/bitcoinbook/bitcoinbook,
* https://www.bitcoinbook.info/translations/el/book.pdf,
Έπαινος για το «Mastering Bitcoin»
«Όταν μιλάω για το bitcoin στο ευρύ κοινό, μερικές φορές με ρωτάνε: Πως πραγματικά λειτουργεί; Τώρα έχω μία εξαιρετική απάντηση για αυτήν την ερώτηση, επειδή οποιοσδήποτε διαβάζει το Mastering Bitcoin μπορεί να αποκτήσει μια βαθειά κατανόηση του πως λειτουργεί και θα έχει πραγματικά όλα τα εφόδια για να γράψει ο ίδιος την επόμενη γενιά των καταπληκτικών εφαρμογών κρυπτονομισμάτων».
— Gavin Andresen, Chief Scientist Bitcoin Foundation
«Οι τεχνολογίες bitcoin και blockchain γίνονται σταδιακά οι θεμέλιοι λίθοι για την επόμενη γενιά του Διαδικτύου. Οι καλύτεροι και λαμπρότεροι της Silicon Valley εργάζονται πάνω σε αυτές. Το βιβλίο του Αντρέα θα σας βοηθήσει να πάρετε μέρος στην επανάσταση του λογισμικού στον κόσμο των χρηματοοικονομικών».
— Naval Ravikant, Co-founder AngelList
«Το Mastering Bitcoin αποτελεί την καλύτερη διαθέσιμη αναφορά που υπάρχει για το bitcoin σήμερα. Το bitcoin ακολούθως μπορεί να ιδωθεί ως η πιο σημαντική τεχνολογία της δεκαετίας. Το βιβλίο αυτό, δηλαδή, είναι ένα απολύτως απαραίτητο εφόδιο για κάθε προγραμματιστή, ειδικά για εκείνους που χτίζουν εφαρμογές με το bitcoin πρωτόκολλο. Το συνιστώ ανεπιφύλακτα».
— Balaji S. Srinivasan (@balajis), General Partner, Andreessen Horowitz
«Η εφεύρεση του Bitcoin Blockchain αντιπροσωπεύει μια εντελώς καινούρια πλατφόρμα να χτίσουμε επάνω του, μία που θα επιτρέπει ένα οικοσύστημα τόσο ευρύ και τόσο ποικιλόμορφο όσο το Διαδίκτυο. Ως μία από τις διαπρεπείς ηγετικές μορφές σκέψης, ο Ανδρέας Αντωνόπουλος είναι η τέλεια επιλογή για τη συγγραφή αυτού του βιβλίου».
— Roger Ver, Bitcoin Entrepreneur and Investor
name::
* McsEngl.btcnet'DOING@cptIt,
name::
* McsEngl.btcnet'Service (btcsvc)@cptIt,
* McsEngl.btcnet'usage@cptIt,
* McsEngl.btcstm'service@cptIt,
* McsEngl.btcsvc@cptIt,
* McsEngl.btcusage@cptIt,
* McsEngl.btcnet'service@cptIt,
_DESCRIPTION:
Bitcoin is the first fully autonomous system to utilize distributed consensus technology to create a more efficient and reliable global payment network.
[http://docs.bitshares.eu/bitshares/whatis.html]
_ADDRESS.WPG:
* http://cointelegraph.com/news/bitcoin-adoption-could-save-india-7-billion,
* http://usebitcoins.info//
* http://www.wired.com/2015/09/wall-street-officially-opens-arms-bitcoin-invaders//
name::
* McsEngl.btcnet'market@cptIt,
_ADDRESS.WPG:
* {2016-05-13} Having overtaken the US, Japan has become the world’s second Bitcoin market, after China.
http://cointelegraph.com/news/what-makes-japan-second-largest-bitcoin-market-potentially-first,
_SPECIFIC:
* ID-service#ql:idBtcsvcIdn#,
* notary-service#ql:idBtcsvcNtzn#,
* payment-processing#ql:idBtcsvcPmnt#,
* shopping#ql:idBtcsvcShpg#,
* trading#ql:idBtcsvcTrd#,
* voting#ql:idBtcsvcVot#,
===
* https://proofofexistence.com/about, you can later certify that the data existed at that time.
name::
* McsEngl.btcsvc.ID@cptIt,
* McsEngl.btcsvc.ID@cptIt,
* McsEngl.btcsvc.identification@cptIt,
name::
* McsEngl.btcsvc.NOTARIZATION@cptIt,
* McsEngl.bitcoin-notarization@cptIt,
* McsEngl.btcnotarization@cptIt,
_DESCRIPTION:
Blockchain notarization is an effective way to record marriage contracts, wills, birth certificates, child care contracts, land titles and business deals, among many other records. The security of the blockchain protects the document permanently, ensures its easy access, and proves its authenticity and ownership anytime you need it.
[https://bitnation.co/notary/]
name::
* McsEngl.btcsvc.PAYMENT@cptIt,
name::
* McsEngl.btcsvc.payment.city@cptIt,
Αυτή είναι η ελβετική πόλη που πληρώνεις με bitcoin
Δημοσιεύθηκε: 14 Μαϊου 2016, 18:15 , Τελευταία Ενημέρωση: 14/05/2016, 16:18
Με το ψηφιακό νόμισμα, bitcoin, θα μπορούν να πληρώνουν τους λογαριασμούς του κάτοικοι στην πόλη Zug της Ελβετίας καθώς ξεκινά η εφαρμογή του εν λόγω πιλτικού προγράμματος από την 1η Ιουλίου. ο δήμαρχος της πόλης Dolfi M?ller ελπίζει πως με αυτό τον τρόπο θα προσελκύσει περισσότερες οικονομικές επιχειρήσεις και τεχνολογικές εταιρείες ώστε να εγκατασταθούν στην περιοχή. Για την ιστορία, έχουν γίνει και παρόμοιες προσπάθειες και σε άλλες χώρες χωρίς όμως άκρως ικανοποιητικά αποτελέσματα.
«Το πιλοτικό πρόγραμμα της κυβέρνησης της πόλης αρχικά βάζει 200 φράγκα όριο για τις δημόσιες συναλλαγές. Στα τέλη του 2016 θα γίνει και η αξιολόγηση του προγράμματος. Τότε ... το δημοτικό συμβούλιο θα αποφασίσει εάν το bitcoin και τα περισσότερα άλλα ψηφιακά νομίσματα μπορούν να γίνουν αποδεκτά ως τρόπος πληρωμής και σε άλλες υπηρεσίες στο μέλλον» αναφέρει χαρακτηριστικά η ανακοίνωση.
[http://www.sofokleousin.gr/archives/297034.html?utm_source=dlvr.it&utm_medium=twitter]
name::
* McsEngl.btcsvc.payment.tuition@cptIt,
* McsEngl.tuition-payment-with-bitcoin@cptIt,
_DESCRIPTION:
Πληρωμές διδάκτρων με Bitcoins στο Πανεπιστήμιο της Λευκωσίας
Παρασκευή, 22 Νοεμβρίου 2013 14:41 UPD:14:45
Η είδηση κάνει το γύρο του κόσμου, καθώς το κυπριακό πανεπιστήμιο παράλληλα παρέχει και τη δυνατότητα για σπουδές διαδικτυακού συναλλάγματος, με σκοπό την καλύτερη κατανόηση του νέου φαινομένου.
Το πρώτο πανεπιστήμιο στον κόσμο το οποίο θα δέχεται πληρωμές διδάκτρων και άλλων τελών με bitcoins θα αποτελέσει το Πανεπιστήμιο της Λευκωσίας, όπως ανακοινώθηκε.
Η είδηση κάνει το γύρο του κόσμου, καθώς το κυπριακό πανεπιστήμιο παράλληλα παρέχει και τη δυνατότητα για σπουδές διαδικτυακού συναλλάγματος, με σκοπό την καλύτερη κατανόηση του νέου φαινομένου.
Το Πανεπιστήμιο της Λευκωσίας (UNic) αποτελεί το μεγαλύτερο ιδιωτικό πανεπιστήμιο στην Κύπρο και ένα από τα μεγαλύτερα αγγλόφωνα πανεπιστήμια στη Μεσόγειο. Πέρα από τις πληρωμές, οι φοιτητές του θα έχουν τη δυνατότητα σπουδών και πάνω στο ίδιο το αντικείμενο, στο πλαίσιο του MSc Degree in Digital Currency, το οποίο είναι σχεδιασμένο για να βοηθήσει τον κάθε ενδιαφερόμενο, από τον χώρο των επιχειρήσεων ή της δημόσιας διοίκησης να καταλάβει καλύτερα τα τεχνικά χαρακτηριστικά του διαδικτυακού νομίσματος, το οποίο «πιθανότατα θα αλληλεπιδράσει με τα υπάρχοντα χρηματοοικονομικά συστήματα», καθώς και θα εξετάζει τις ευκαιρίες για καινοτομία που συνεπάγονται τα συστήματα ψηφιακών συναλλαγμάτων.
«Γνωρίζουμε ότι το ψηφιακό συνάλλαγμα αποτελεί μία αναπόφευκτη τεχνική εξέλιξη η οποία θα οδηγήσει σε σημαντικές καινοτομίες στο online εμπόριο, τα οικονομικά συστήματα, τις διεθνείς πληρωμές και εμβάσματα και την παγκόσμια οικονομική ανάπτυξη. Το ψηφιακό συνάλλαγμα θα δημιουργήσει πιο αποτελεσματικές υπηρεσίες και θα λειτουργήσει ως μηχανισμός για την εξάπλωση των οικονομικών υπηρεσιών σε τομείς του κόσμου που δεν έχουν μεγάλη τραπεζική υποστήριξη» δήλωσε ο Δρ. Χρήστος Βλάχος, μέλος του συμβουλίου του Πανεπιστημίου.
«Θεωρούμε πρέπον να υιοθετήσουμε ψηφιακό συνάλλαγμα ως μία μέθοδο πληρωμών σε όλα τα ιδρύματά μας, σε όλες τις πόλεις και χώρες όπου λειτουργούμε» πρόσθεσε.
Το εν λόγω Master θα διδάσκεται στην αγγλική γλώσσα, τόσο στο campus όσο και online, με τα μαθήματα να ξεκινούν την άνοιξη του 2014. Επίσης, αξίζει να σημειωθεί ότι το UNic προτείνει στην κυπριακή κυβέρνηση την δημιουργία ενός εκτενούς πλαισίου λειτουργίας με σκοπό την εξέλιξη της Κύπρου σε ένα «κέντρο» για εμπόριο, διαχείριση και τραπεζικές συναλλαγές που αφορούν σε Bitcoins.
[http://www.naftemporiki.gr/story/733285]
name::
* McsEngl.btcsvc.SHOPPING@cptIt,
* McsEngl.btcsvc.shopping@cptIt,
_ADDRESS.WPG:
* {2017-03-03} https://btcmanager.com/the-first-bitcoin-store-of-the-world-opens-in-vienna//
name::
* McsEngl.btcogn.Store@cptIt,
* McsEngl.btcogn.store@cptIt,
name::
* McsEngl.btcnet'Overstock.com@cptIt,
_DESCRIPTION:
Overstock.com, the largest online retailer to adopt bitcoin, says it accounts for less than 0.1 percent of sales.
[http://www.wired.com/2016/02/the-schism-over-bitcoin-is-how-bitcoin-is-supposed-to-work/]
name::
* McsEngl.btcsvc.TRADING@cptIt,
* McsEngl.btcsvc.trading@cptIt,
_DESCRIPTION:
In December, the Ukrainian Stock Exchange also announced it would offer Bitcoin futures trading on the back of what it described as “quite high interest” from investors.
In so doing, Ukraine became the first regulated market in the world to offer the Bitcoin trading option.
[https://cointelegraph.com/news/second-ukraine-bank-launches-blockchain-partnership- {2017-03-24}]
name::
* McsEngl.btcsvc.VOTING@cptIt,
* McsEngl.btcsvc.voting@cptIt,
name::
* McsEngl.btcsvc.SecureVote@cptIt,
_ADDRESS.WPG:
* http://demo.xo1.io/index.html,
XO.1
Aussie start-up to delay bitcoin transactions through anchoring 1.5bn votes to the Bitcoin blockchain over 24 hours starting 16:00, March 6 (GMT)
Stress-test of SecureVote will use 4% of bitcoin network capacity over 24 hours and delay some transactions by over 30 minutes – transaction backlog will take a maximum of 24 hours to clear
Sydney (March 5, 2017):
Australian secure voting start-up XO.1 announced a planned stress-test of their SecureVote application on March 6 GMT, which is planned to use more than 4% of the Bitcoin transaction network verification capacity.
This stress-test will process the equivalent of 1.5 billion electronic votes, verified on the Bitcoin blockchain network, over 24 hours, and during peak periods will delay some transactions by up to 30 minutes.
Co-founder and Chief Technology Officer of XO.1, Max Kaye, explained that the intent of the stresstest was to ensure the scalability and reliability of XO.1’s proprietary verification layer, and apologised for any inconvenience caused to bitcoin users.
“We’re building the world’s most secure voting technology, and while there aren’t currently any elections which would require 1.5bn votes, to prove the reliability and scalability of this technology we made the decision to conduct a stress-test a multitude of times larger than our expected first use cases,” said Mr Kaye.
“Unfortunately, this will cause disruption to some bitcoin users as we will be paying a fee to prioritise
the processing of our transactions. At the network’s anticipated peak processing times, we’ll delay
some transactions by up to 30 minutes, and create a backlog of transactions that will take a maximum of 24 hours to clear.”
SecureVote is the world’s first high-throughput commercially viable secure, verifiable, auditable, and scalable internet voting system, with voting delivered via smart-phone app and local electronic voting machines.
XO.1’s proprietary Copperfield algorithm enables verification of the vote and the vote count without compromising the privacy of the vote itself.
The start-up, which has received $500,000 of early-stage funding to date, is expecting to reach market with a product by the end of 2017.
“A number of technological advances in the past ten years have made this product possible – primarily the development of the blockchain, which ensures we have an immutable record of votes cast, once they’ve been verified,” said Mr Kaye.
“We’ll shortly be commencing another funding round which will allow us to quickly scale and capitalise on our early lead in the space,” concluded Mr Kaye.
Track the progress of the XO.1 SecureVote stress test on the demo at http://demo.xo1.io/index.html
- - Ends - -
Media contact:
Shane Allison | shane@xo1.io |+61 402 219 963
[https://xo1.io/stress-test-pr.pdf]
name::
* McsEngl.btcnet'GENERIC@cptIt,
_GENERIC:
* Exchange-value-token-blockchain-network#ql:idBcnnetEvtkn#
name::
* McsEngl.btcnet.MAINET@cptIt,
* McsEngl.bitcoin-mainnet@cptIt,
* McsEngl.btcMainnet@cptIt,
* McsEngl.btcBitcoin-Main-Network@cptIt,
_DESCRIPTION:
The original and main network for Bitcoin transactions, where satoshis have real economic value.
[https://bitcoin.org/en/glossary/mainnet]
===
Main Bitcoin network and its blockchain.
The term is mostly used in comparison to testnet#ql:idBtcnetTst#.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btcnet.REGTEST@cptIt,
* McsEngl.btcRegtest@cptIt,
* McsEngl.btcRegression-Test-Mode@cptIt,
_DESCRIPTION:
A local testing environment in which developers can almost instantly generate blocks on demand for testing events, and can create private satoshis with no real-world value.
[https://bitcoin.org/en/glossary/regression-test-mode]
name::
* McsEngl.btcnet.TESTNET@cptIt,
* McsEngl.bitcoin-testnet@cptIt,
* McsEngl.btcTestnet@cptIt,
* McsEngl.btcTesting-Network@cptIt,
_DESCRIPTION:
A global testing environment in which developers can obtain and spend satoshis that have no real-world value on a network that is very similar to the Bitcoin mainnet.
[https://bitcoin.org/en/glossary/testnet]
===
Testnet:
A set of parameters used for testing a Bitcoin network.
Testnet is like *mainnet*, but has a different genesis block (it was reset several times, the latest testnet is *testnet3*).
Testnet uses slightly different *address* format to avoid confusion with main Bitcoin addresses and all nodes are relaying and mining non-standard transactions.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
name::
* McsEngl.btctestnet'use@cptIt,
_DESCRIPTION:
To use testnet, use the argument -testnet with bitcoin-cli, bitcoind or bitcoin-qt or add testnet=1 to your bitcoin.conf file as described earlier. To get free satoshis for testing, use Piotr Piasecki’s testnet faucet. Testnet is a public resource provided for free by members of the community, so please don’t abuse it.
[https://bitcoin.org/en/developer-examples#testnet]
name::
* McsEngl.btcnet.TESTNET3@cptIt,
* McsEngl.bitcoin-testnet3@cptIt,
* McsEngl.btcTestnet3@cptIt,
_DESCRIPTION:
Testnet3:
The latest version of *testnet* with another genesis block.
name::
* McsEngl.btcnet.EVOLUTING@cptIt,
* McsEngl.bitcoin.evolution@cptIt,
* McsEngl.btcevolution@cptIt,
{time.2016.bitcoin, bitcoin2016}:
=== halfing: 11 Jul 2016 22:03:04
The Bitcoin block mining reward halves every 210,000 blocks, the coin reward will decrease from 25 to 12.5 coins.
[http://www.bitcoinblockhalf.com/]
{time.2015, bitcoin2015}:
=== {2015}
The major story from 2015 is undoubtedly the increasing focus on bitcoin's underlying technology, commonly referred to as blockchain or distributed ledger technology (DLT). Many parties, from government authorities to financial institutions, began to examine potential applications of DLT for securities transaction settlement and other use cases.
[http://www.coindesk.com/state-of-bitcoin-blockchain-2016/]
=== {2015-03-31} fraud:
On March 31, 2015, two now-former agents from the Drug Enforcement Administration and the U.S. Secret Service were charged with wire fraud, money laundering and other offenses for allegedly stealing bitcoin during the federal investigation of Silk Road, an underground illicit black market federal prosecutors shut down in 2013.[41]
[https://en.wikipedia.org/wiki/Cryptocurrency]
{time.2014, bitcoin2014}:
=== {2014.02}: Mt.Gox:
In February 2014, cryptocurrency made national headlines due to the world's largest bitcoin exchange, Mt. Gox, declaring bankruptcy. The company stated that it had lost nearly $473 million of their customer's bitcoins likely due to theft. This was equivalent to approximately 750,000 bitcoins, or about 7% of all the bitcoins in existence. Due to this crisis, among other news, the price of a bitcoin fell from a high of about $1,160 in December to under $400 in February.[40]
[https://en.wikipedia.org/wiki/Cryptocurrency]
{time.2013, bitcoin2013}:
=== VALUE:
At the end of August 2013, the value of all bitcoins in circulation exceeded US$ 1.5 billion with millions of dollars worth of bitcoins exchanged daily.
[https://bitcoin.org/en/faq#is-bitcoin-really-used-by-people]
=== {2013-12-05} CHINA
FINANCIAL TIMES
Thursday December 05 2013
BREAKING NEWS
Beijing bans banks from Bitcoin deals
China has taken a tough line against Bitcoin, ruling that it is a virtual product, not a currency, and barring the country’s financial institutions from doing any kind of business in it.
Surging Chinese demand has been one of the main drivers of Bitcoin’s 5000 per cent appreciation this year. The notice from Chinese financial regulators, published on Thursday, is the first official policy ruling from Beijing about the virtual currency.
=== {2013-11-22} University-of-Nicosia
Πληρωμές διδάκτρων με Bitcoins στο Πανεπιστήμιο της Λευκωσίας
Παρασκευή, 22 Νοεμβρίου 2013 14:41 UPD:14:45
Η είδηση κάνει το γύρο του κόσμου, καθώς το κυπριακό πανεπιστήμιο παράλληλα παρέχει και τη δυνατότητα για σπουδές διαδικτυακού συναλλάγματος, με σκοπό την καλύτερη κατανόηση του νέου φαινομένου.
Το πρώτο πανεπιστήμιο στον κόσμο το οποίο θα δέχεται πληρωμές διδάκτρων και άλλων τελών με bitcoins θα αποτελέσει το Πανεπιστήμιο της Λευκωσίας, όπως ανακοινώθηκε.
[http://www.naftemporiki.gr/story/733285]
=== {2013-10-26}: CHINA GBL:
GBL, a Chinese bitcoin trading platform, suddenly shut down on October 26, 2013. Subscribers, unable to login, lost up to $5 million worth of bitcoin.[37][38][39]
{time.2011}:
Satoshi Nakamoto withdrew from the public in April of 2011, leaving the responsibility of developing the code and network to a thriving group of volunteers. The identity of the person or people behind bitcoin is still unknown. However, neither Satoshi Nakamoto nor anyone else exerts control over the bitcoin system, which operates based on fully transparent mathematical principles. The invention itself is groundbreaking and has already spawned new science in the fields of distributed computing, economics, and econometrics.
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
{time.2009}:
=== Started on Januar 3, 2009, the Bitcoin peer-to-peer network has grown very quickly.
[http://subs.emis.de/LNI/Proceedings/Proceedings208/51.pdf]
{time.2008}:
Bitcoin was invented in 2008 with the publication of a paper titled "Bitcoin: A Peer-to-Peer Electronic Cash System," written under the alias of Satoshi Nakamoto. Nakamoto combined several prior inventions such as b-money and HashCash to create a completely decentralized electronic cash system that does not rely on a central authority for currency issuance or settlement and validation of transactions. The key innovation was to use a distributed computation system (called a "proof-of-work" algorithm) to conduct a global "election" every 10 minutes, allowing the decentralized network to arrive at consensus about the state of transactions. This elegantly solves the issue of double-spend where a single currency unit can be spent twice. Previously, the double-spend problem was a weakness of digital currency and was addressed by clearing all transactions through a central clearinghouse.
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
===
εμφάνισή του το 2008 (δημιουργός του είναι ένας ανώνυμος προγραμματιστής, συλλογικά γνωστός πλέον με το ψευδώνυμο Σατόσι Νακαμότο)
[http://www.naftemporiki.gr/story/731436]
name::
* McsEngl.btcnet.HARDFORK@cptIt,
* McsEngl.btcnet.hardfork@cptIt,
_DESCRIPTION:
A hardfork is a change to the bitcoin protocol that makes previously invalid blocks/transactions valid, and therefore requires all users to upgrade.
Any alteration to bitcoin which changes the block structure (including block hash), difficulty rules, or increases the set of valid transactions is a hardfork. However, some of these changes can be implemented by having the new transaction appear to older clients as a pay-to-anybody transaction (of a special form), and getting the miners to agree to reject blocks including the pay-to-anybody transaction unless the transaction validates under the new rules. This is known as a softfork, and how P2SH was added to Bitcoin.
[https://en.bitcoin.it/wiki/Hardfork]
name::
* McsEngl.btcnet.SOFTFORK@cptIt,
* McsEngl.btcnet.softfork@cptIt,
_DESCRIPTION:
A softfork is a change to the bitcoin protocol wherein only previously valid blocks/transactions are made invalid. Since old nodes will recognise the new blocks as valid, a softfork is backward-compatible. This kind of fork requires only a majority of the miners upgrading to enforce the new rules.
New transaction types can often be added as softforks, requiring only that the participants (sender and receiver) and miners understand the new transaction type. This is done by having the new transaction appear to older clients as a "pay-to-anybody" transaction (of a special form), and getting the miners to agree to reject blocks including these transaction unless the transaction validates under the new rules. This is how P2SH was added to Bitcoin.
[https://en.bitcoin.it/wiki/Softfork]
name::
* McsEngl.bcnnet.Aeternity@cptIt,
* McsEngl.aeternity-network@cptIt,
_DESCRIPTION:
According to Malahov, Aeternity’s competitors include Gnosis, Synereo and Ethereum, the largest cryptocurrency platform after Bitcoin.
Aeternity tokens are planned to sell in the first quarter of 2017.
Development of Aeternity’s Blockchain includes an emphasis on a unified consensus mechanism, a system for smart contract storage and execution, with planned improvements in system governance. The coding is also on Erlang, an industry-proven programming language.
“Malahov's approach to decentralized processing elegantly addresses issues of scale, by taking the state channel approach to the nth degree,’’ Trent McConaghy, co-founder and chief technology officer at BigchainDB, said in an interview. “That makes it easier to connect emerging decentralized networks.”
Aeternity “could end up being the TCP/IP of decentralized processing," McConaghy said, referring to the protocols that govern communication between networks on the Internet.
[https://cointelegraph.com/news/man-who-claims-to-be-ethereums-godfather-aims-at-recasting-smart-contracts]
name::
* McsEngl.bcnnet.Akasha@cptIt,
* McsEngl.akasha-network@cptIt,
_DESCRIPTION:
A Next-Generation Social Media Network
Powered by the Ethereum world computer
Embedded into the Inter-Planetary File System
[http://akasha.world/]
===
What can I do with AKASHA?
You can publish, share and vote for entries, similar to Medium and other modern publishing platforms, with the difference that your content is actually published over a decentralized network rather than on our servers.
Moreover, the votes are bundled with ETH micro transactions so if your content is good you’ll make ETH from it – in a way, mining with your mind.
[http://akasha.world//]
name::
* McsEngl.bcnnet.BOScoin (BOSnet)@cptIt,
* McsEngl.BOScoin-network@cptIt,
* McsEngl.bosnet@cptIt,
_DESCRIPTION:
BOScoin is a congressional decentralized cryptocurrency platform for “Trust Contracts”.
BOScoin is a cryptocurrency that utilizes the blockchain and numerous new technologies to solve persistent issues in decentralized systems.
1. Trust Contracts are securely executable contracts based on a decidable programming framework called Owlchain, which consists of the Web Ontology Language and the Timed Automata Language. Trust Contracts aim to overcome the issues regarding non-decidable smart contracts by using a more contained and comprehensible programming framework which provides secure and decidable transactions of contracts.
2. The Congress Network is the decision making body in the BOScoin network which improves governance issues arising in decentralized organizations and helps the system continuously evolve into a more robust ecosystem.
[https://www.boscoin.io/]
_GENERIC:
* Blockchain-network-with-builtin-decentralized-governance#ql:idBcnnetBig#,
* program-blockchain-network#ql:idBcnnetPgm#
name::
* McsEngl.bosnet'Protocol (bosprl)@cptIt,
name::
* McsEngl.bosprl'White-paper.2017-02-02@cptIt,
* McsEngl.bosnet'white-paper@cptIt,
* McsEngl.bosprl'white-paper@cptIt,
* McsEngl.boswpr@cptIt,
_ADDRESS.WPG:
* https://www.boscoin.io/wordpress/wp-content/themes/boscoin/src/pdf/boscoinwhitepaperv20170202.pdf,
The BOScoin White Paper
Initial Version: 20161101 / Current Version: 20170202
Han-Kyul Park, Changki Park, Yezune Choi, Jake Hyunduk Choi
BOScoin is a congressional decentralized cryptocurrency platform for Trust Contracts
BOScoin is a cryptocurrency that utilizes the blockchain and numerous new technologies to solve persistent issues in decentralized systems.
(1) Trust Contracts are securely executable contracts based on a decidable programming framework called Owlchain, which consists of the Web Ontology Language and the Timed Automata Language.
Trust Contracts aim to overcome the issues regarding non-decidable smart contracts by using a more contained and comprehensible programming framework which provides secure and decidable transactions of contracts.
(2) The Congress Network is the decision making body in the BOScoin network which improves governance issues arising in decentralized organizations and helps the system continuously evolve into a more robust ecosystem.
The blockchain was first conceptualized in Satoshi Nakamoto’s white paper “Bitcoin: A Peer-to-Peer Electronic Cash System“ in 2008(-1-#ql:idBoswprnot1#).
The technology was implemented the following year as the central technology behind Bitcoin.
Bitcoin uses blockchain technology as a financial transaction ledger where individuals publicly record transfers of currency.
Bitcoin was the first of its kind to use the blockchain to successfully solve the double spending problem.
Despite the absence of a centralized administrator, Bitcoin has successfully supported over 180 million peer-to-peer transactions and now has a market capitalization of more than 10 billion dollars.
Following the success of Bitcoin, there have been numerous systems leveraging blockchain technology.
There are hundreds of competing cryptocurrencies and according to a recent IBM report, more than 90% of banks are investing in blockchain technology(-2-#ql:idBoswprnot2#).
Although currency transactions are the most common applications of the blockchain technology, some groups are also attempting to transfer other digital assets, such as financial products and services, logistics information, property ownership, identity etc.
The cryptocurrency Ethereum gained a lot of traction in 2016 and aims to provide smart contracts on the blockchain: “a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create ‘contracts’ that can be used to encode arbitrary state transition functions." (3)
The goal is to allow users to write any kind of program (or contract) onto the blockchain.
Similar to Bitcoin, Ethereum uses the blockchain and a consensus mechanism to ensure that if a malicious node attempts to forge the content of the contract, the forged contract will eventually be removed from the blockchain.
Bitcoin ensures the integrity of the amount of Bitcoin being transferred between accounts, Ethereum must similarly ensure the integrity of the contract being executed.
Smart contracts have the potential to be a paradigm shift in the development of decentralized applications.
Programs that are not held on a centralized server, yet can run the same logic anywhere.
Smart contracts can be used to develop: decentralized marketplaces, currency exchange platforms, and projects like Golem( 4 ) which aim to create a decentralized worldwide super-computer.
However the freedom and flexibility provided by the turing-complete language which Ethereum is based on is the cause for several serious problems.
We believe that using a turing-complete language may be inappropriate for writing smart contracts as they are inherently undecidable( 5 ).
Due to this undecidability issue, a smart contract based on a Turing-complete language will make it difficult to know what a smart contract will do before running it.
Ethereum attempts to overcome this issue by applying a price for computational work (gas), however the inherent issue of the language used to program and execute smart contracts has inevitably led to a series of security vulnerabilities( 6 ) and outright failed projects such as The DAO( 7 ).
Trust Contracts.
BOScoin’s approach to the problem is to apply a domain-specific language which can be read easily by the average user and can demonstrate mathematically that the smart contract’s implementation is computationally decidable.
Thus, with BOScoin we aim to develop a platform for Trust Contracts: securely executable contracts based on Owlchain technology.
Additionally, through BOScoin we attempt to solve a number of commonly recurring issues related to cryptocurrencies.
Governance Issues.
Decentralized systems lack a systematic decision making process.
There have been several cases in the cryptocurrency space, where the decision making process has been persistently inefficient.
BOScoin constitutes a governance system whereby node operators referred to as the Congress Network can participate in creating and voting on proposals in order to continuously improve the software and ecosystem.
BOScoin sets aside a large public budget called the Commons Budget which is distributed to proposals that pass a vote in Congress improving the autonomy as well as fairness of the overall system.
Anti-centralizing Consensus Algorithm.
Cryptocurrencies like Bitcoin, that only use a proof-of-work(PoW) type consensus protocol, are affected by issues arising from the non-separation of economic and political incentives.
By buying up more mining hardware, a user can attain more control of the blockchain(political) and also increase their mining income(economic).
BOScoin overcomes this issue by using a consensus
mechanism(explained in more detail below) that separates economic incentives from political ones.
Attaining either political power or economical wealth requires an investment into the system.
A user can either acquire more votes by increasing the number of nodes(one operational node equals one congressional vote) or a user can invest in freezing and confirmation rewards(rewards relative to the amount of coins locked away in a node) to maximize mining income.
Additionally, the consensus protocol used is also more energy efficient and faster.
Application Ecosystem.
Decentralized currencies in many cases tend to become speculative islands with limited real applications.
As we believe the value of a currency is intrinsically tied to how useful it is, the BOScoin team will release the coin with two ready-made apps that use BOScoin.
The applications Stardaq and Delicracy have already been built and will not only increase the transactional value of the coin, but will also help acquire new users.
#idBoswprfig1#Features Bitcoin Ethereum BOScoin
Coins Bitcoin Ether BOScoin
Core Features Financial
Transactions
(Bitcoin script)
Smart Contracts
(Solidity, Serpent, etc)
Trust Contracts
(OWL 2 profiles, SDLang,
TAL)
Decision Making
Process
Non-systematic Non-systematic Democratic Congress
(One node = One vote)
Consensus
Algorithm
Proof of work Current: Proof of work.
Future: Casper(?)
Modified FBA(Federated
Byzantine Agreement)
Transaction Speed 7 tx/sec 25 tx/sec 1,000 tx/sec (target)
Block Interval 10 minutes 13 seconds 5 seconds
Block Size 1 MB Dynamic Dynamic
Fig 1. Comparison of Cryptocurrencies
BOScoin aims to use the Owlchain technology which consists of the Web Ontology
Language(OWL) and Timed Automata Language(TAL). This architecture is designed to
8
expand expressive power while retaining decidability to support secure and precise execution
of contracts. These Owlchain based contracts on the BOScoin blockchain are called Trust
Contracts.
Features Smart Contracts
(Ethereum)
Ricardian Contracts
(R3CEV Corda)
Trust Contracts
(BOScoin)
Programming
Language
LLL, Serpent, Solidity Ricardian Contract +
pure functions
Owlchain
(OWL* + TAL*)
Decidability Undecidable with
gas(fee)
Undecidable
(3rd party evaluation)
Decidable(TAL)
Blockchain type Permission-less Permission Permission-less
Consensus PoW* various mFBA*
Contract Inference None None OWL Reasoning
OWL*: Web Ontology Language
TAL*: Timed Automata Language
PoW*: Proof of Work
mFBA*: modified Federated Byzantine Agreement
Fig 2. Comparison of Blockchain-based Contracts
There are two primary approaches to developing contracts on the blockchain.
One is through using a flexible programming language on a virtual machine, the other is to use a slightly less flexible but decidable domain-specific language.
Unlike cryptocurrencies based on virtual machines, as the inference engine is based on the semantic web technology, it is possible to infer information from the code before the contract is run.
The contract is decidable and the outcome of the contract clearly known.
This is a key concept in building a secure and sustainable currency with contract features.
Although Ethereum attempted to solve this issue by using market mechanisms and applying a price to complexity, we believe that the more restrictive OWL and TAL approach will provide a more secure environment for contracts on the blockchain.
Building upon standard Web technologies such HTML, HTTP, RDF and OWL which were used to serve web pages, these technologies can be extended to share information in a way that can be predictably read by computers.
Both OWL and RDF can be used to create unambiguous structured data taxonomies.
Using these characteristics Ian Grigg proposed the concept of the Ricardian Contracts; contracts which are linked to every aspect of a payment system.(-9-#ql:idBoswprnot9#)
Despite, both OWL and RDF displaying similar characteristics, no RDF standards currently supports P-time completeness.
Using reasoners, tools that infer logical consequences from a set of previously asserted facts or axioms, certain versions of the OWL standard promise P-time complexity.
This means the amount of time it takes to run a contract can be pre-determined.
This feature is a key reason why OWL was selected as the language to build Trust Contracts.
OWL DL(description logic) is a sublanguage of OWL, “designed to provide the maximum expressiveness possible while retaining computational completeness.”(10)
OWL DL operates on a large dictionary of predefined vocabularies and taxonomies like the ISO20022 specification.
As transactions take place on the blockchain and other BOScoin specific features will not be provided by the OWL dictionaries.
These vocabularies and taxonomies need to be called from outside the contract.
To solve this technical issue, we propose to create a designated namespace domain on the blockchain which can call non-standard primitive types(taxonomies) from the contract.
Non-standard primitive types will be added conservatively in order to sustain the OWL’s decidability and taxonomic complexity features.
Fig 3. BOScoin Transfer Example
Another issue with regards to Turing-complete contracts on blockchains is that Turing-complete languages are difficult to read by non-technical people.
If code were law’, the code should be comprehensible to all the parties involved.
Currently, currencies using Turing-complete languages for contracts can only be audited by those that can read code.
By using the OWL standard and mapping the syntax to languages like SDLang(‘11#ql:idBoswprnot11#), we aim to allow anyone to read and precisely comprehend what a contract is meant to do.
The Timed Automata Language concept is based on Andrychowicz’s paper, Modeling Bitcoin Contracts by Timed Automata’(‘12#ql:idBoswprnot12#).
TAL will be used to model the programming logic used in a Trust Contract.
The HTML and Javascript pairing is similar to OWL and TAL.
OWL provides the structure of the data and TAL acts as an operator.
Operators in programming languages are constructs that do a certain function, such as adding, subtracting and comparisons.
OWL provides the information, and TAL tells the computer what to do with the data.
TAL is slightly different to other programming languages as there is a global time factor.
This means contracts can be tested for how long they take beforehand.
By running automated tests on all the different possible outcomes beforehand, we can promise a platform with bug-free contracts on the blockchain.
The details of the above concepts are further explored in the technical paper.
The consensus algorithm is core to any blockchain based currency or system.
The algorithm attempts to answer the question, ‘how can we prove with confidence that all distributed databases hold the same set of information?’
In response to this question, BOScoin uses a Modified Federated Byzantine Agreement(mFBA) consensus algorithm based on Stellar’s Consensus Protocol(FBA).(13)
Consensus
Algorithm
Proof of Work Tendermint Byzantine
Agreement
FBA[1] mFBA[2]
(BOScoin protocol)
Decentralized
Control
O O O O
Low Latency O O O O
Flexible Trust O O O
Asymptotic
Security
O O O O
Governance
Features
O
[1] Federated Byzantine Agreement
[2] Modified Federated Byzantine Agreement
Fig 5. Comparison of Consensus Algorithms
Mazieres defines key features of the federated Byzantine Agreement Protocol: (14#ql:idBoswprnot14#)
* Decentralized control.
Anyone is able to participate and no central authority dictates whose approval is required for consensus.
* Low latency.
In practice, nodes can reach consensus at timescales humans expect for web or payment transactions—i.e., a few seconds at most.
* Flexible trust.
Users have the freedom to trust any combination of parties they see fit.
For example, a small non-profit may play a key role in keeping much larger institutions honest.
* Asymptotic security.
Safety rests on digital signatures and hash families whose parameters can realistically be tuned to protect against adversaries with unimaginably vast computing power.
* Governance Features.
Voting and features that are related to operating the congress are additional features embedded into the protocol.
Bitcoin’s consensus mechanism and the traditional Byzantine agreement based protocols require a unanimous agreement by all participants of the network.
However, the federated Byzantine agreement(FBA) does not require an unanimous agreement by all participants and additionally each node can chooe which nodes to trust.
This results in faster transactions without losing integrity of the financial network and allowing for organic growth of the network.
FBA implemented this type of non-unanimous consensus mechanism by grouping nodes into teams (also known as a Quorums).
When a transaction is made, the information is sent to all those in the group.
Rather than waiting for the whole network to agree on the state of the data, if a node hears the same message from a sufficient number of trusted nodes, the node assumes the information is correct.
The overlapping of nodes, or loose federation of nodes, results in different nodes that have different sets of teams to agree on the same transactions.
This leads to a system-wide consensus, without requiring unanimous agreement for each transaction block.
In situations where nodes are in disagreement over a fraudulent transaction, there is a ballot system embedded into the system to overcome such issues.
Further technical details regarding FBA can be found in Stellar’s consensus protocol paper.
In addition to FBA, the BOScoin consensus protocol also applies a Proof of Stake feature for the maintenance of the governance system.
Users can freeze coins in units of 10,000 BOS within a node and forgo liquidity in return for newly issued BOScoin(similar to interest on savings) based on the total number of frozen coin in the node.
The frozen coins in the node then act as both an economic incentive to operate a node as well as collateral for the security and integrity of the information held in the node’s blockchain.
According to the pre-set rules, if the node is discovered to have forged the blockchain on the node, the frozen coins are forfeited to the Commons Budget.
The Congress Network is the decision-making body for BOScoin consisting of individual fully-synchronized node operators.
Although people refer to cryptocurrencies as decentralized and autonomous, in many cases, this is not true.
Both the code and the information on the blockchain are vulnerable to influence.
In order to overcome these issues, BOScoin proposes a decision-making body called the Congress Network to fully decentralize and automate the system.
Development of the source-code, forks, and even marketing resources can be allocated from within the system.
You will be regarded as a Congress member if you meet the following criteria:
* Run a fully-synchronized node at stable network speeds
* Freeze at least one unit (one frozen unit is 10,000 BOS)
* Participate in voting
Anyone can become a Congress member.
A node could be a server or a personal computer that a Congress member runs.
The node can be located at home or a remote location, as long as network speeds are stable.
Congress Members have the choice to either invest in increasing their political influence through running more nodes or increasing their economic return through increasing the BOScoin frozen.
Users are the beneficiaries of the BOScoin system.
They will interact with the BOScoin Network in three ways: by initiating transactions, submitting proposals and earning interest on BOScoins (coin freezing).
These interactions are displayed in the figure below.
#idBoswprfig6#
Fig 6. Interactions Between the Congress Network and User Network
When a transaction of digital assets is requested by a user, the request is sent to the Congress Network.
For a simple transfer of BOScoin, when a node confirms the block –roughly every 5 seconds– the user’s transactions will be confirmed, and the BOScoin will be transferred to another wallet.
For more complex Trust Contracts, the pre-defined logic/procedures will also be carried out.
In the initial stage of BOScoin, transaction fees will be fixed at 0.01 BOS.
The fixed transaction rate can later be adjusted by the Congress Network through the voting process.
Transaction fees act as an economic incentive for node operators and also as a defence mechanism against DoS attacks.
Proposals are Commons Budget spending plans that are submitted to the Congress Network.
When a proposal is made, the ‘net percentage point difference’ between the positive and negative votes must exceed 10% for the proposal to be passed.
When the proposal is passed, the requested coins will be sent to the proposer.
Under some conditions, such as when the size of the proposal is large, the system can define a contract that requires a report on how the coins were spent.
Coin Freezing is a Proof of Stake concept where if a user locks-in their coins and in return they will receive interest based on the number of coins frozen and the length of time the coins are stored.
This interest is called the Freezing Reward.
Users can freeze coins in units, which are sets of 10,000 BOS.
Frozen coins are used as collateral in case of attempted forgery of the blockchain.
If a node attempts to forge the blockchain, a portion of the frozen coins are confiscated and sent to the Commons Budget.
Additionally the system requires two weeks prior notice to unfreeze coins, as a mechanism to promote price stability.
Within the Congress Network, there is a unique incentive mechanism. Congress members can either choose to maximize financial rewards, by freezing BOScoin in one node or increase their voting power by running multiple nodes (one node equals one vote).
This deliberate division incentivises the separation of economic motives from decision-making motives similar to the separation of economic and political power concept.
Bitcoin suffers from the hash power centralization issue, due to its reliance on a Proof of Work consensus protocol.
A small number of major miners can easily buy up large amounts of mining hardware, which allows them to influence changes in code and even threaten the integrity of the blockchain.
By separating the incentives of those that wish to optimize financial gain, the barriers to entry to participate in the governance process is comparatively lower than a system that equates decision making power with financial rewards.
There are three ways for Congress Members to receive BOScoin rewards: the freezing reward, confirmation rewards, and transaction fees.
* Freezing Reward:
Congress Members receive the same amount of interest as normal wallet users when coins are frozen.
Starting from the first year, a total of 27,400 BOS is distributed equally to each unit of frozen BOScoins.
This freezing reward is issued every 720 blocks(roughly one hour).
The total amount that is distributed decreases by 10% year on year over 69 years.
* Confirmation Reward:
Confirmation rewards are given to a node when a block is confirmed.
This reward is crucial in providing a financial incentive to operate a node and the reward is directly linked to the number of Frozen Units in a node.
Similar to the block reward in Bitcoin, as the number of participating nodes increases, the probability of winning the confirmation reward decreases.
The reward is issued relative to the proportion of frozen units held while initially sustaining a system average of 24.5 BOScoins.
confirmation reward = 24.5 x (Number of Frozen Units / Average of Total System Frozen Units)
Initially the block confirmation reward starts at 24.5 BOScoins per block, and it will decreased by 5% year on year over roughly 141 years.
* Transaction Fee:
The transaction fee is a fixed 0.01 BOScoins.
Congress Nodes receive 70% of the collected transactions fee in a block, and 30% is sent to the Commons Budget.
Transaction fees can be adjusted through the Congress.
name::
* McsEngl.e. Decision Making Process@cptIt,
The idea of an integrated decision-making process within the currency was inspired by Dash(16) coin where the masternodes(17) vote to make decisions.
In BOScoin decisions are made by submitting proposals and voting on proposals, and then financing the proposals through the transfer of funds from the Commons Budget.
Anyone can make a proposal, which is then reviewed every third Monday of the month by 24:00 GMT.
These proposals are then voted on by the Congress members by the fourth Monday of the month by 24:00 GMT.
If the ‘net percentage point difference’ between the positive and negative votes exceed 10%, the proposal is passed.
There is the option for a neutral vote to signal that the Congress member participated in the decision-making process and votes can also be changed any time before the final due date.
In order to increase the chances of a proposal being passed, it is possible to provide collateral with the proposal.
Proposals that provide more than 1,000,000 BOS become Elevated Proposals.
If a Congress member does not vote on an Elevated Proposal, they are penalized by having the freezing feature disabled for their node for two weeks.
Disabling the coin freezing feature means the node will forgo all the benefits from freezing coins and will not be able to freeze any coins for two weeks.
name::
* McsEngl.f. Commons Budget@cptIt,
The Commons Budget is an account where BOScoins are held and can only be transferred by proposals that are passed through the Congress.
The main role of Commons Budget is to expedite the growth of the coin users during the early stages.
Coins in the Commons Budget are mainly accumulated through two channels; the first is the direct issuance of 100 BOS coins per block for 35 million(roughly 5.5 years) blocks and secondly from 30% of the transaction fee.
Out of all issued coins, Commons Budget make up the largest proportion of coins.
This will ensure funds are available to growth hack the adoption of BOScoin.
Any proposal which passes through the congress can access coins from the Commons Budget.
An example of a proposal is an Airdrop proposal; geo-socially distribute free coins to users in order to increase the number of BOScoin users.
Other examples can include funding the development of the BOScoin eco-system, marketing campaigns and organizing BOScoin related meetings.
Many cryptocurrencies offer examples of how to use and build applications on their platform.
However, few have delivered working applications utilizing currency.
Although it is difficult to fully understand how much of a cryptocurrency’s value is made up of transactional value and how much is made up by speculative value, BOScoin’s goal is to increase the transactional value of the currency relative to its competitors.
In the long-run the core-value of a currency is it’s usefulness.
Through ready-built applications such as Stardaq and Delicracy released with the currency, users will have sophisticated services available immediately within the BOScoin ecosystem.
name::
* McsEngl.a. Stardaq@cptIt,
Stardaq is an international celebrity popularity prediction market.
A celebrity's popularity is represented as an index and users can place bets on whether the popularity of the celebrity will rise or fall.
The bets can only be placed with BOScoins.
name::
* McsEngl.b. Delicracy@cptIt,
Delicracy is a collective decision making tool that can be implemented in any organization.
All users can participate in the decision-making process by placing bets on a set of proposals, similar to the Augur prediction market(18).
The proposal with the most bets is passed.
This type of system can help promote transparency and participation for decision-making processes in organizations large and small.
These applications serve as outlets to spend BOScoins and also serve as channels for Airdropping free coins.
Appropriately using these tools can help grow the ecosystem by introducing new users.
The following is a technical roadmap defining the key milestones.
Milestone ?
? Module
M1
A
L
P
H
A
M2
G
E
N
E
S
I
S
M3
N
E
B
U
L
A
M4
P2P Protocol
specification &
Implementation
Unit & Acceptance
Test
mFBA Consensus Key design
Implementation
Test App
Remittance Address design
UTXO Pattern
Send & Receive
coin
Multisig Tx Specs Multisig Tx
Implementation
Data Store Store specs &
SQLite Store
implementation
MessagePack
History
Blockchain
backup &
restore using
ISP(AWS,
Azure and
google)
CLI & Web
Interface
Web design &
implementation
Web UX design
Trust Contract
Proposal & Vote
Trust Contract
design
Proposal & Vote
implementation
Simple payment
verification wallets
(Mobile)
Wallet Formal
specification
UX design
Application PoC
Test
Android & iOS
Wallet
Inference Engine Formal spec. and
key design
elements available
Reasoner
integration with
Blockchain
Constructing
Basic Ontology
Trust Contract
Modeler
Formal spec. and
key design
elements
available
App
Deployment &
Demo Site
RPC & REST API Blockchain
Explorer
Fig 7. Implementation roadmap
New coins are issued in four ways; initial development budget (1.0bil, 10%), confirmation rewards(3.0bil, 30%), freezing rewards(2.4bil, 24%) and the Commons Budget(3.5bil, 36%).
We aim to issue a total of 9.99 billion coins over the next 141 years.
These values are subject to change.
#idBoswprfig8#
Initial Development
Budget
Confirmation
Rewards
Freezing Rewards Commons Budget
BOScoins 1,000,000,000 3,090,000,000 2,400,000,000 3,500,000,000
Share 10% 30% 24% 36%
Decrease Rate
-
5% per 6,310,080
blocks
10% per 6,310,080
blocks
-
End of
Issuance Genesis Block
block#
886,781,451
(~141 years)
block#
435,396,204
(~69 years)
Block# 35,000,001
(~5.5 years)
Fig 8. Issuance Summary
* Initial Development Budget:
Initial development coins are coins distributed prior to the Genesis block are intended to support the final development of the software.
These coins are made up of ICO sales and bounties.
1.0 billion BOScoins are issued with the Genesis block.
* Confirmation Rewards:
Confirmation rewards are financial rewards issued randomly to a node for every confirmed block(every 5 seconds).
As the reward is distributed randomly, if the number of nodes increase the probability that a node will receive a reward decreases.
This reward is relative to the number of units frozen in a node(refer to section 4d).
3.0 billion BOScoin are issued through Confirmation rewards.
Initially 24.5 BOScoins are issued per block.
The reward decreases every 6.31 million blocks–roughly one year– by 5% over 141 years.
* Freezing Rewards:
Freezing rewards are distributed relative to the number of BOScoin units frozen in a node and are issued every 720 blocks(roughly one hour).
Initially the total amount is 27,400.
The reward decreases by 10% over every 6.31 million blocks–roughly 1 year – over 69 years.
The freezing reward acts as an important incentive for congress members to increase the number of coins frozen in one node and disincentivize the centralization of decision making.
* Commons Budget:
The Commons Budget holds BOScoins that can only be used by proposals that have passed the Congress Network.
In order to create a sufficient budget for proposals, 100 Commons Coins are issued per block for the first 35 million blocks–roughly five and a half years.
After the first five and a half years the Commons Budget is maintained through the 30% commons fee on transactions fees.
The BOScoin team aims to overcome the technical and operational issues inherent in many cryptocurrencies.
The incentive scheme and issuance plan is aimed towards creating value for the coin while deterring the centralization of power.
The Modified Federated Byzantine Agreement algorithm will allow for low latency transactions while being more energy efficient.
The Congressional System is aimed towards creating a more democratic and productive decision making process.
Trust contracts will provide a decidable and approachable framework for creating and executing contracts on the blockchain.
The BOScoin team will aim to achieve these goals while leveraging the security and integrity that can be gained through blockchain technology.
Andrychowicz, Dziembowski, Malinowski and Mazurek, Modeling Bitcoin Contracts by Timed Automata, Lecture Notes in Computer Science Formal Modeling and Analysis of Timed Systems, 7-22, 2014, https://arxiv.org/pdf/1405.1861v2.pdf
David Mazieres, Stellar Consensus Protocol, https://www.stellar.org/papers/stellar-consensus-protocol.pdf
Decentralized Prediction Market, https://www.augur.net/
Evan Duffield, Daniel Diaz, Dash: A PrivacyCentric CryptoCurrency, https://www.dash.org/wp-content/uploads/2015/04/Dash-WhitepaperV1.pdf
Hodges, Andrew, Alan Turing: the enigma, London: Burnett Books
Ian Grigg, The Ricardian Contract, First IEEE International Workshop on Electronic Contracting (WEC) 6th July 2004, http://iang.org/papers/ricardian_contract.html
Leading the Pack in Blockchain Banking: Trailblazers Set the Pace, https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?htmlfid=GBP03467USEN&
N. Atzei, M. Bartoletti, T. Cimoli, A survey of attacks on Ethereum smart contracts, https://eprint.iacr.org/2016/1007.pdf
Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, https://bitcoin.org/bitcoin.pdf
Simple Declarative Language, https://sdlang.org/
The DAO, https://slock.it/dao.html
Using Decentralized Governance: Proposals, Voting, and Budgets, https://dashpay.atlassian.net/wiki/display/DOC/Using+Decentralized+Governance%3A+Proposals% 2C+Voting%2C+and+Budgets
OWL Web Ontology Language, https://www.w3.org/TR/owl-features/
OWL Web Ontology Language Reference, https://www.w3.org/TR/owl-ref
Vitalik Buterin, Ethereum Whitepaper, https://github.com/ethereum/wiki/wiki/White-Paper
#idBoswprnot1#(1) Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, https://bitcoin.org/bitcoin.pdf
#idBoswprnot2#(2) Leading the Pack in Blockchain Banking: Trailblazers Set the Pace, https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?htmlfid=GBP03467USEN&
#idBoswprnot3#(3) Vitalik Buterin, Ethereum Whitepaper, https://github.com/ethereum/wiki/wiki/White-Paper
#idBoswprnot4#(4) Golem, https://golem.network
#idBoswprnot5#(5) Hodges, Andrew, Alan Turing: the enigma, London: Burnett Books, p. 111
#idBoswprnot6#(6) N. Atzei, M. Bartoletti, T. Cimoli, A survey of attacks on Ethereum smart contracts, https://eprint.iacr.org/2016/1007.pdf
#idBoswprnot7#(7) The DAO, https://slock.it/dao.html
#idBoswprnot8#(8) Web Ontology Language Reference, https://www.w3.org/TR/owl-ref
#idBoswprnot9#(9) Ian Grigg, The Ricardian Contract, First IEEE International Workshop on Electronic Contracting (WEC) 6th July 2004
#idBoswprnot10#(10) OWL Web Ontology Language, https://www.w3.org/TR/owl-features/
#idBoswprnot11#(11) Simple Declarative Language, https://sdlang.org/
#idBoswprnot12#(12) Andrychowicz, Dziembowski, Malinowski and Mazurek, Modeling Bitcoin Contracts by Timed Automata, Lecture Notes in Computer Science Formal Modeling and Analysis of Timed Systems, 7-22, 2014, https://arxiv.org/pdf/1405.1861v2.pdf
#idBoswprnot13#(13) David Mazieres, Stellar Consensus Protocol, https://www.stellar.org/papers/stellar-consensus-protocol.pdf
#idBoswprnot16#(16) Evan Duffield, Daniel Diaz, Dash: A PrivacyCentric CryptoCurrency, https://www.dash.org/wp-content/uploads/2015/04/Dash-WhitepaperV1.pdf
#idBoswprnot17#(17) Using Decentralized Governance: Proposals, Voting, and Budgets, https://dashpay.atlassian.net/wiki/display/DOC/Using+Decentralized+Governance%3A+Proposals%2C+Voting%2C+and+Budgets
#idBoswprnot18#(18) Decentralized Prediction Market, https://www.augur.net//
name::
* McsEngl.bosprl'Techical-paper.2017-01-31 (bostpr)@cptIt,
Owlchain(BOScoin) Technical Specification
(This is a draft version. More details to be added)
Draft version: 20170131
Yezune Choi, Jake Hyunduk Choi
Alfred North Whitehead, known as the last metaphysician, asserted that "without adventure civilization is in full decay."
Imaginations and practices of the blockchain is enriching our world.
We put our thoughts into the world to join in this adventure of thought.
Every thought has its roots in thought.
The blockchain is not a random floatage on the Internet, but an outcome that is rooted in existing ideas.
In order for owlchain to have a solid roots in the Internet world, it is necessary to know its roots correctly.
The thoughts on which the Internet and the Web could grow can be summarized by several principles.
TCP/IP represents the Internet protocol, but TCP is only one of the typical application protocols of IP. For applications such as games or streaming that do not require a session connection, UDP is being used as an attractive alternative to TCP. In the Internet world, protocols define a clear function(specification) in their domain and perform only that function. The advantage of layer structure is that it does not hinder the emergence of new protocols by maximizing the possibility of substitution. IPv4 can be replaced with IPv6 because of the layer structure. When we consider this idea in the blockchain technology, the current blockchain technology is still in its infancy and is not approaching the layer structure design. In order for the blockchain to obtain the status of the protocol, it is essential to have a layer structure approach in which various technologies can be combined and compete.
Although TCP/IP has the advantage of speed and performance, the core quality to become a standard for the Internet is the openness of the protocol.
The TCP/IP protocol is open to the public without restrictions on use such as patents, and has served as a soil where many researches and developments can be achieved.
In standardizing protocols, patents are a sensitive issue for companies or individuals seeking to contribute.
But, ownership of ideas(patents) limits the emergence of new ideas.
From the perspective of innovation, ownership of ideas is more damaging than profit in the cyber world where thoughts can be copied without marginal cost.
You can also see how narrow the view is in claiming ownership of ideas in the Internet world, when the programming codes that actually implement the protocol are the most innovative in any licensing policy.
In order for Internet protocol features to be completed, there is a need for end-to-end principles that do not interfere with high-level applications.
A principle of a protocol is that a protocol does not discriminate against content that passes through it.
It is similar to collecting the same fare regardless of the type of vehicle on the highway.
It is known to the public as "the principle of net neutrality".
Based on these three principles, we intend to develop owlchain to acquire protocol status.
'def.Owlchain' is the underlying technology powering BOScoin and Trust Contracts.
Owlchain is developed in D language and Trust Contracts are written in the Web Ontology Language(OWL) and Timed Automata Language(TAL).
The purpose of OWL is to provide “trust” on the internet through the abstract combination of standard web technologies.
OWL 2.0 version solved the data handling time delay problem, which was the existing problem in 1.0 version, by creating profiles.
BOScoin provides OWL 2 Profiles that use "Linked Data" to create Trust Contract.
Linked data is a declaration of the data required to issue a particular contract, and the semantic of contracts can be automatically validated by these defined data in the OWL 2 Profile.
In addition, like using javascript, static elements as HTML and CSS to show the screen on the web browser, Timed Automata Language(TAL) can provide dynamic processing on Trust Contracts.
TAL is a programming environment with two constraints, which are the timed automata modeling and pure functions.
Timed automata modeling can detect undefined area(reachability problem) in program code that developer can not find and can eliminate side effects that can occur during development by using pure function.
Due to these limitations, operating environment of Trust Contract satisfies the memory safety and the decidability.
- Timed Automata - assure decidability
- Pure Function - remove side effect
#idBostprfig1#
[Figure 1] Trust Contract Blockchain
For programmers, OWL language can be viewed as a user-defined linked data because defined data, constraints and links of data in the OWL language can be used to program.
TAL is the data processing language of the blockchain(owlchain).
TAL can be abstracted as an operator to register a new transaction on a blockchain.
In order to explain a simple formula in the language of c++, when "c = a + b" formula is given for "+" operators, two variables ‘a’ and ‘b’ are added and then ‘c’ is returned.
The operator itself is implemented as pure function that does not produce any changes to the two variables used in computing.
A pure function prevents a program from being transmitted by providing the memory safety.
Thereafter, the operator written in TAL returns new transactions by referring to the Linked Data and the data in the Blockchain.
TAL shall satisfy both the conditions of the pure function and the characteristics of the Timed Automata.
These restrictions are set because the TAL environment is open to all users, and it is a permissionless blockchain for all users.
In the case of Trust Contract(Linked Data + TAL Operator) written in an open environment by an anonymous user, not having a rigid security model can create an unpredictable network state.
The table below compares the characteristics of OWL to the Bitcoin and Ethereum
Feature
Bitcoin
Ethereum
Owlchain(BOScoin)
Consensus
Proof of work
Current: Proof of work.
Future: Casper(?)
Modified FBA(Federated Byzantine Agreement)
- History revision mechanism
Soft and hard forks
Current: Soft and hard forks.
Future: Block revisions in case of temporary network isolation.
Block revisions in case of temporary network isolation.
- Membership
Open
Open
Open with constraint
(min 10,000 BOS)
Block Confirmation Time
10 minutes
Current: 15 seconds
5 seconds (target)
Block Size
1 MB
Dynamic
Dynamic
Maximum Transaction
100 KB
Dynamic based on gas limit
Dynamic
Transaction Throughput
7 tx/sec
25 tx/sec
1,000 tx/sec (target)
Coins
Bitcoin, plus tokens such as provided by Omni Layer
Ether, plus tokens that can be issued by contracts.
BOScoin
Governance system
None
None
Commons budget, Proposal, Voting
Smart Contracts:
- Computational Power
Stack-based language with few instructions
Turing complete
Timed Automata Model
- Decidability
Decidable
Not Decidable, using instruction fee(gas)
Decidable
- Runtime Architecture
Script runs on Bitcoin Core, Libbitcoin, and other native implementations
Ethereum Virtual Machine implemented on multiple platforms
OWL inference Engine on multiple platforms
- Programming Language
Bitcoin Script
Solidity, Serpent, LLL and any other languages that get implemented on the EVM.
OWL + TAL
[Table 1] Comparison of Blockchains
Owlchain’s hierarchy is designed as a generic blockchain model to accommodate multiple ontology models.
Owlchain combines the feature of the Inference Engine and Consensus protocols to handle the Trust Contract.
The class types related to features such as the transaction and voting method are implemented in the blockchain as the primitives data type of the inference engine.
The blockchain based TAL is used to expand the limits of the expressions and calculations of the Ontology based programming language.
[Figure 2] BOScoin Architecture Diagram
Contract Types
Features
Smart Contract
(Ethereum)
Ricardian Contract
(R3CEV CORDA)[1,2]
Trust Contract
(BOScoin)
Programming method
LLL, Serpent, Solidity
Ricardian Contract + pure function
OWL* + TAL*
Contract
(decidability)
undecidable with gas(fee)
undecidable
(3rd party evaluation)
decidable(TAL)
blockchain type
Permission-less
Permission
Permission-less
Consensus
PoW*
various
mFBA*
Contract Inference
None
None
OWL Reasoning
OWL*: Web Ontology Language
TAL*: Timed Automata Language
PoW*: Proof of Work
mFBA*: modified Federated Byzantine Agreement
[Table 2] Contract Comparison
BOScoin's transactions support Trust Contract based on OWL 2 Profile which can be defined by users.
Traditional blockchain contract with virtual machines could not provide the semantic reasoning.
BOScoin’s node can distinguish the transaction, which is a form of the Trust Contract, through the Inference Engine that was originated from Semantic Web Technologies.
Thus, the Inference Engine interprets the input to prevent the occurrence of the false Contract.
The way in which accurate knowledge is represented in the web environment is being conducted as one of the key tasks of W3C standardization.
OWL is a standard language developed to support the Semantic in the web.
OWL 2 standardization was introduced to solve the performance problem that was problematic in the previous version.
The OWL 2 Profile consists of three standard profiles, two of which are applied in owlchain.
In the case of a complex expression(TBOX), it is possible to obtain optimized ontology results by selecting the OWL 2 EL profile.
In other case, where there are lots of individuals to declare, selecting OWL 2 QL profile can result in creating a better ontology database.
Owlchain supports a user to select an appropriate OWL 2 profile to configure the blockchain.
The user shall select the profile according to the type of ontology database that they plan to build.
OWL, which is a language for knowledge representation(KR), does not support the computational power needed for processing the blockchain.
In the case of Ethereum, the computing capacity required for processing Smart Contract is resolved by implementing the turing complete Ethereum virtual machine(EVM).
However, the method of using virtual machines will result in the undecidability of the blockchain, which is not resolved in terms of security aspects of the blockchain network.
We use the Timed Automata Language execution environment in a manner that considers the computational power and decidability.
The timed automata ensures that all programs base on the timed automata is guaranteed to operate in a finite time limit.
Timed Automata Language(TAL) is a programming language designed to support the computational functionalities within a range that do not impair the integrity of the blockchain.
Instead of supporting turing completeness, TAL provides the computational power through a finite automata model.
owlchain(t`, OWLdata) = OWLdata @ owlchain(t)
owlchain(t`) : New blockchain status
owlchain(t): Current blockchain status
OWLdata: OWL defined individual data set
@ : TAL (Timed Automata Language) Operator defined and saved Timed Automata operator
[Code 1] owlchain (mathematical model)
The remittance of BOScoin follows the same pattern as the UTOX pattern of the bitcoin.
However, unlike bitcoin script, the method of constructing transactions is written in accordance with OWL 2 EL specification.
These generated documents are verified by the inference engine and distributed to the blockchain network via the consensus algorithm.
The proposal to be eligible for voting is made up of Ricardian Contract form.
[Example 2] illustrates a suggestion in the form of Ricardian Contract.
The format of the provided contract is serialized in the form of SDLang.
Once a proposal is recorded in a transaction, the Proposal is granted a unique transaction number and is ready for voting.
The proposal supports two types, with or without the collateral.
The purpose of BOScoin’s voting is to distribute the Commons budget generated by block confirmation.
The voting is available in three options under a proposed proposal.
Choice options are available in three different modes: positive, negative and neutral.
The neutral vote has a null function.
The budget for the proposal is covered by Commons budget.
Commons budget is provided in two ways.
As a node confirms a block, a certain amount of coin is issued in the form of a special transaction of UTXO type and is deposited in the Commons budget account.
Some portion of the transaction fee shall be deposited into Commons budget account.
Owlchain is designed to allow data to be self-descriptive through the inference engine.
The inference engine is designed to interpret the standard OWL 2 and execute the contract with the operator.
The inference engine validates the documentation written in the OWL 2 specification.
The OWL document consists of three components: class, individual and property.
The class defines the type of data, and the property describes the properties, and the individual is a statement for generating individual instances of class types.
The Semantic Reasoner is implemented to interpret the specification of W3C OWL 2 profile.
The OWL 2 profile is designed to ensure consistent performance along the Description Logic grammar.
[Table 3] shows the analysis time of OWL 2 profile.
Owlchain is implemented within the constraints of OWL 2 profiles: QL, EL and RL.
The inference engine implemented within the Profile guarantees the time complexity described in [Table 3].
This operates as a mechanism in which the inference engine ensures decidability.
Language
Reasoning Problems
Taxonomic Complexity
Data Complexity
Query Complexity
Combined Complexity
OWL 2 EL
Ontology Consistency,
Class Expression Satisfiability,
Class Expression Subsumption,
Instance Checking
PTIME-complete
PTIME-complete
Not Applicable
PTIME-complete
Conjunctive Query Answering
in EXPTIME
PTIME-complete
NP-complete
in EXPTIME
OWL 2 QL
Ontology Consistency,
Class Expression Satisfiability,
Class Expression Subsumption,
Instance Checking
NLogSpace-complete
In AC0
Not Applicable
NLogSpace-complete
Conjunctive Query Answering
NLogSpace-complete
In AC0
NP-complete
NP-complete
OWL 2 RL
Ontology Consistency
PTIME-complete
PTIME-complete
Not Applicable
PTIME-complete
Class Expression Satisfiability,
Class Expression Subsumption,
Instance Checking
PTIME-complete
PTIME-complete
Not Applicable
co-NP-complete
Conjunctive Query Answering
PTIME-complete
PTIME-complete
NP-complete
NP-complete
[Table 3] OWL 2 Profile Time Complexity
Originally, OWL 2 Profile uses the IRI(Internationalized Resource Identifiers) to expand the ontology on the Internet.
The prefix in [Example 4] is an example of an IRI expansion.
If the ontologies stored in the external node are used, the ontology area will exist outside the blockchain.
In the case of the external reference ontology, the integrity of the consensus algorithm may not be guaranteed.
The data outside of the blockchain network can not guarantee the integrity of the whole blockchain.
BOScoin's IRI reference namespace is restricted to the https://blockchianos.org IRI namespace, which can guarantee the integrity of the consensus algorithm for the blockchain.
This is located within the blockchain and is recognized as an authorized area to record transactions in the blockchain.
Future considerations may occur in ontology sharing with other blockchains.
Ontology sharing is an important issue in inter blockchain transaction.
Although it is important to make a consent to the transactions between the blockchains, it will not consider for this current specification.
In the future work, we will be able to discuss the need for Trust Contract between ontologies based blockchains.
The user layer of a blockchain can be divided into developers, wallet users and contract writers.
Their common interest is the content of Trust Contract.
The SDLang was chosen to balance the usability between the three groups of users.
The SDLang format itself is based on the data representation of the development language familiar to the developer and can easily represent structured data.
For more information, refer to the SDLang website.
MessagePack is a specification for serializing of files or data structures, such as Google protocolBuffer.
MessagePack does not require an IDL file for serialization, so programmers can easily serialize.
There is also a performance benefit to protocol packet exchanges over large networks, such as blockchain networks, by ensuring zero-copy serialization.
It is difficult to maintain the integrity of the global blockchain network.
Bitcoin's p2p Byzantine problem has been studied as a field of cryptography before the introduction of blockchain technology.
Studies show that if there are a sufficient number of normally operating nodes, the system may have resistance from abnormal operation or attack of other nodes, but solutions of conventional Byzantine general problems such as PBFT(Practical Byzantine Fault Tolerance) required nodes control by administrator.
Bitcoin has succeeded in open membership through a differentiated approach called Proof-of-Work(PoW), but it has been shown that the existing PBFT features such as low-latency, flexible trust, and asymptotic security are not guaranteed.
Recently, research on achieving openness of networks with maintaining the advantages of Byzantine generic solutions is of interest.
The Federated Byzantine Agreement is one of the most completed outcomes.
The core value of mFBA is the openness of the network.
Conventional Byzantine general solutions were based on a reliable closed network because systemwide agreement was required to determine abnormal behavior.
FBA system has a high degree of freedom in network configuration because it is designed in such a way that the entire system is divided into quorum slices and the agreed content in a quorum is eventually shared by the entire network.
Therefore, the nodes constituting the BOScoin ecosystem can freely become members of the network if they satisfy the minimum conditions required by the network.
For example, a minimum network bandwidth size may be required to maintain the block generation rate.
Along with BOScoin membership, the minimum stake is required to generate blocks.
10,000 BOS unit can create a single transaction, and through this transaction, a member can participate in confirming blocks by proving ownership of such transaction.
The validation of BOScoin nodes differs from the recent implementation of the FBA, Stellar Consensus Protocol(SCP), which only requires the proof of the Quorum membership.
BOScoin is developed in priority of related features and in conjunction with future services.
P2P
FBA Consensus
Remittance
Web Interface
Ricardian Contract Proposal & Vote
SPV(simple payment verification) wallets
Inference Engine
Smart Contract Modeler
RPC & REST API
Milestone ?
? Module
M1
M2
M3
M4
P2P
Protocol specification & Implementation
Unit & Acceptance Test
mFBA Consensus
Key design Implementation
mFBA Acceptance Test
Remittance
Address design
UTXO Pattern
Send & Receive coin
Data Store
Store specs &
SQLite Store implementation
MessagePack
History
Blockchain backup & restore using ISP(AWS,Azure and google)
CLI & Web Interface
CLI design & implementation
Web UX design
Trust Contract Proposal & Vote
Trust Contract design & specification
Proposal & Vote implementation
SPV(simple payment verification) wallets
Wallet Formal specification
UX design Application PoC Test
Android & iOS Wallet
Inference Engine
Formal specification and key design elements available
Reasoner integration with Blockchain
Trust Contract Modeler
Formal specification and key design elements available
App Deployment & Demo Site
RPC & REST API
Blockchain Explorer
[Table 4] Implementation roadmap
name::
* McsEngl.A. Reference@cptIt,
name::
* McsEngl.A.1 FBA Consensus@cptIt,
https://www.stellar.org/papers/stellar-consensus-protocol.pdf
https://medium.com/a-stellar-journey/on-worldwide-consensus-359e9eb3e949#.izg7ydd08
https://news.ycombinator.com/item?id=9341687
https://www.reddit.com/r/ethereum/comments/338mip/stellar_consensus_protocol_canwill_something_like/
name::
* McsEngl.A.2 Web Ontology Language - OWL@cptIt,
http://www.semantic-web-journal.net/sites/default/files/swj120_2.pdf
https://www.w3.org/TR/owl2-primer/
https://www.w3.org/TR/owl2-overview/
https://www.w3.org/TR/owl2-profiles/
http://www.semantic-web-journal.net/sites/default/files/swj120_2.pdf
fact++ owl reasoner - http://owl.man.ac.uk/factplusplus/
name::
* McsEngl.A.3 TAL(Timed Automata Language)@cptIt,
A theory of timed automata* - http://www.cis.upenn.edu/~alur/TCS94.pdf
uppaal language reference - http://www.uppaal.com/index.php?sida=217&rubrik=101
Modeling Bitcoin Contracts by Timed Automata - https://arxiv.org/pdf/1405.1861v2
name::
* McsEngl.A.4 Serialization & Parsing Tools@cptIt,
Structured Ontology Format - http://webont.org/owled/2007/PapersPDF/submission_18.pdf
SDLang - https://sdlang.org/
MessagePack - http://msgpack.org/
PEG - https://en.wikipedia.org/wiki/Parsing_expression_grammar
Bitcoin Script - https://en.bitcoin.it/wiki/Script
Bitcoin UTXO - https://bitcoin.org/en/glossary/unspent-transaction-output
[1] Jamie Redman, R3CEV Unveils Corda, But ‘Is Not Building a Blockchain’, April 6, 2016, https://news.bitcoin.com/r3cev-corda-is-not-building-a-blockchain/
[2] Richard Gendal Brown, Introducing R3 Corda™: A Distributed Ledger Designed for Financial Services, April 5, 2016, http://www.r3cev.com/blog/2016/4/4/introducing-r3-corda-a-distributed-ledger-designed-for-financial-services
name::
* McsEngl.B. Appendix@cptIt,
B.1 Timed Automata Language PEG(Parsing Expression Grammar)
{
TAL Design Specifications are required
}
Operator repository specification
name::
* McsEngl.C. Coding Style Guide@cptIt,
C.1 D Coding Style
Adhering to the coding conventions for writing D programs increases the readability of the code you write and makes it easier to collaborate with others over code.
* Whitespace
- One sentence in a single line
- Use the space instead of the tab
- Each indentation level is 4 spaces
* General Code Creation
Unless otherwise noted below, the default is camelCased, including all variables.
Thus, when combining multiple words together, the first letter of the first word will not be an uppercase letter. Also, do not start with an underscore '_' if it is not private.
ex) int myFunc();
string myLocalVar;
* Modules
Module and package names must be all lowercase and contain only the characters [a..z] [0..9] [_].
This will not cause any problems when dealing with case-insensitive file systems.
ex) import std.algorithm;
* Classes, Interfaces, Structs, Unions, Enums, Non-Eponymous Templates
The name of the user-defined type is written in PascalCased.
(Same as camelCased except that the first letter is in uppercase)
Enum member is written in camelCased.
ex) class Foo;
struct FooAndBar;
enum Direction { bwd, fwd, both }
*Eponymous Templates
A template with the same name as a symbol in the template is displayed in uppercase.
(Therefore, instantiation of that template is replaced by the corresponding symbol)
ex) template GetSomeType(T) { alias GetSomeType = T; }
template isSomeType(T) { enum isSomeType = is(T == SomeType); }
template MyType(T) { struct MyType { ... } }
template map(fun...) { auto map(Range r) { ... } }
* Functions
Function names are created with camelCased, and include attributes and member functions.
ex) int done();
int doneProcessing();
* Constants
Constants are written in camelCased, same as normal variable.
ex) enum secondsPerMinute = 60;
immutable hexDigits = "0123456789ABCDEF";
* Keywords
If a name conflicts with keywords, it is advisable to use keywords instead of choosing a different name, and in this case, an underlined ‘_’ should be added to the keyword. To avoid conflicts with keywords, do not capitalize the name.
ex) enum Attribute { nothrow_, pure_, safe }
C.2 HTML5 Coding Style
The HTML5 coding conventions of the owlchain project are based on the following Google style guide and are revised.
(refer to - https://google.github.io/styleguide/htmlcssguide.xml#HTML_Formatting_Rules)
name::
* McsEngl.bosnet'Resource (bosrsc)@cptIt,
_ADDRESS.WPG:
* https://www.boscoin.io//
* https://github.com/owlchain/owlchain-core,
===
* contact@boscoin.io
name::
* McsEngl.bosnet.EVOLUTING (bosevn)@cptIt,
* McsEngl.bosevn@cptIt,
{time.2017-05-10-2017-06-20}
=== ICO:
DURATION: The ICO will be carried out from “May 10, 2017” to “June 20, 2017”.
===
ICO will start on April 17th 2017 and will last 45 days until May 31st 2017.
In total 276,093,688.786 coins will be distributed.
name::
* McsEngl.bcnnet.Cardano@cptIt,
* McsEngl.Cardano-network@cptIt,
* McsEngl.DccCardano@cptIt,
_ADDRESS.WPG:
* https://www.youtube.com/watch?time_continue=5&v=LP0vq6b6kec&feature=emb_logo,
* https://cardanostake.org/ NOT official: https://twitter.com/CardanoStiftung/status/955820681270263808,
* {2018-01-06} https://steemit.com/cardamon/@dan/peer-review-of-cardano-s-ouroboros,
ned (69) · 11 days ago
Here’s a snippet of events in order to color in context:
Dan writes early BTS paper (though it’s unclear if this was a paper prior to the one published by Charles and Dan together) - sees locking up of BTS for BitAsset as a holy grail in supply reduction.
Charles is in the crypto space already talking about DEX and other later-to-be-developed concepts; teaching courses on bitcoin and cryptocurrency; gets put in touch w Dan
Early BTS; Dan and Charles clash on personal level - stemming from competing technical desires and ego desires. They split.
Charles rebounds immediately and is the first technologist to recognize Turing Complete potential when introduced to Vitalik by Anthony Di Orio. Dan has no awareness to the effort and Ethereum concept.
Ethereum announced.
Dan purports any successes of Eth can be adopted by BTS.
Dan tells confidants (including me but I was later than others) he will attempt Turing Complete one day.
7.5 Dan leaves BTS.
Dan does Steem with me and founding team.
8.25 Steem working; July 2016; Dan begins selling Ned about the wow factor of Wren in Dan’s living room.
8.5. Cob and associate calls Ned. Ned tells them about possible future token protocols on Steem.
Dan tells Steem he will build Turing Complete on Steem (Wren). (I was not pre-aware or expecting the public communications from Dan on this. Others in the organization were skeptical of Wren).
Dan leaves Steem. Tells community he will not be posting anymore.
10.5. Dan asks Ned not to compete with EOS because of market clarity
EOS begins building by copying BTS STEEM and Ethereum - Wren concept is dropped - subsequently Web Assembly ideas of Ethereum are harnessed - and reverse auction IPO levered for fundraising EOS.
11.5 Ned writes SMT Whitepaper with @theoretical. Ned includes section criticizing the weaknesses of general purpose / Turing Complete / general scripting on blockchain - and advocates application specific programs tailored to high demand use cases - I.e. specialized programmability tokens for fundraising, monetization and growth.
Dan writes post about Ouroboros and comments about Hoskinson from his very own viewpoint.
The cult of personality on Steem begs for more!
Luckily this is nearly 1/1000th of the gory details and barely magnified! Ive got all the rest in my journals (and tapes from when things got dicey) (that get released by my lawyers if I die (/not only if I am killed/) before deciding to include or not include these chapters in a book).
Despite the commentary, at the end of the day Hoskinson and Larimer are both credibly respectable for certain things - no one is perfect and I believe we can consider them both thoughtful technologists, and to see some of the name calling - frankly from glass houses, it calls to advise everyone to take the “think about yourself” approach before judging others and spreading memes that physically cannot be whole truths because everything is interpretation.
On the whole, and from what seems to have spawned these posts, I’d love to see more real academic style accreditation in crypto industry whitepapers. Other than Bitcoin’s Whitepaper, not many are arguably sound from a formally-correct academic perspective.
In short response, the falling out between the pair, Hoskinson and Larimer, clearly had little impact on the conceptual elements of these new projects, Cardano and EOS, because the pair’s falling out predates even the mother concept, Ethereum - but rather the pair’s falling out was one of the key catalysts for Ethereum coming into existence as successfully as it did because it put Charles on a path to spearhead it.
Contributed from my iPhone. Please excuse any grammatical mistakes or errors.
$318.49
206 votes
Reply
name::
* McsEngl.Adanet.EVOLUTING@cptIt,
{2015}
=== IOHK:
After leaving Ethereum, Jeremy consulted on cryptocurrencies before starting Input Output with Charles Hoskinson in 2015.
[https://iohk.io/team/jeremy-wood/]
name::
* McsEngl.bcnnet.ChronoBank (chbnet)@cptIt,
* McsEngl.bcnchb@cptIt,
* McsEngl.ChronoBank@cptIt,
* McsEngl.ChronoBank-blockchain-based-project@cptIt,
* McsEngl.ChronoBank-initiative@cptIt,
* McsEngl.ChronoBank-platform@cptIt,
_DESCRIPTION:
ChronoBank is a new blockchain-based project that takes aim at the short-term recruitment sector. By placing buyers and sellers of labour in direct contact, and paying in a native Labour Hour token (LH), the platform offers the possibility of substantial savings for employers, since it cuts out the expensive middlemen of the recruitment industry -- in the same way that Uber disintermediates the taxi business.
[https://blog.chronobank.io/chronobanks-time-launches-on-four-exchanges-71c2bb5c989a#.wnktm5kng]
===
ChronoBank is designed to allow businesses to connect directly with professionals seeking work, cutting out recruitment agencies in much the same way that Uber disintermediates the taxi business.
[https://blog.chronobank.io/chronobank-partners-with-nem-to-create-chrononem-wallet-eebdc176351d]
===
Have you ever wanted a service that would let you do what you’re good at and get paid at the same time, but you struggle to find clients for your work? Chronobank solves this problem by utilizing a system that allows anybody to sell their labor and get money for it, as Chronobank’s system is designed to be similar to Uber’s in the sense that anybody can get paid and anyone can get work quickly without a middleman (which can get costly) and without any other fees.
[https://www.crypto-news.net/chronobank-time/]
name::
* McsEngl.chbnet'Protocol (chbprl)@cptIt,
* McsEngl.chbprl@cptIt,
* McsEngl.chronobank-protocol@cptIt,
name::
* McsEngl.chbprl'White-paper (chbwpr)@cptIt,
* McsEngl.chbwpr@cptIt,
* McsEngl.chronobank-whitepaper@cptIt,
_ADDRESS.WPG:
* https://chronobank.io/files/whitepaper.pdf,
* https://github.com/ChronoBank/Documentation/blob/master/whitepaper.pdf,
CHRONOBANK - PHASE 1: A NON-VOLATILE DIGITAL TOKEN BACKED BY LABOUR-HOURS
THE CHRONOBANK TEAM
CHRONOBANK.IO
INFO@CHRONOBANK.IO
{Retrieved 2017-03-20}
This whitepaper abstractly describes a system designed to tokenise labour-hours using blockchain technology.
ChronoBank is a proposed implementation of the described system that can be deployed in several economic localities.
The proposed system leverages smart contract techniques to automate a process whereby a country-specific ‘labour-hour’ token may be redeemed for real labour-hours via legally binding (traditional) contracts with labour-offering companies.
The proposed ‘stable-coin’ implementation provides a non-volatile, inflation-resistant digital asset transfer system.
With the advent of cryptocurrencies, relatively instant low-cost transfers of value have become a reality.
Blockchain technology, which is a defining feature of most cryptocurrencies, has recently been applied to solve a great variety of problems.
Currently the most widespread implementation of blockchain technology is Bitcoin [-1-#ql:idChbwprref1#], which is a simple asset transfer system.
The asset in Bitcoin’s case is a bitcoin (BTC).
The value of this token has seen rapid variation since its inception in 2009, which has hindered its feasibility as a global currency.
There have been a variety of attempts to realise the advantages of blockchain technology while simultaneously mitigating issues regarding the stability of value for cryptocurrency applications.
To achieve this, many attempts employ the notion of a stable-coin, whereby each token of value in the system has a counterpart of equal worth stored in a non-digital and tangible form in the ‘real world’.
Two example implementations of the aforementioned stable-coin paradigm are listed below:
USDT by Tether[-2-#ql:idChbwprref2#]:
Each USDT token is backed by an equivalent amount of United States Dollars (USD) held in a reserve account by the private company Tether Limited.
Digix[-3-#ql:idChbwprref3#]:
Each token is backed by an equivalent amount of gold, which is stored in reserves by a dedicated precious metal storage custodian.
In both examples, it is always possible for a token holder to redeem that token for its counterpart, thus ensuring its fundamental ‘stable’ value.
Another notable example of a stable-coin is Bitshares [-4-#ql:idChbwprref4#], which attempts to decentralise the entire system through the use of digital Contract For Differences (CFD) [-5-#ql:idChbwprref5#] interactions.
The system presented in this whitepaper does not attempt to achieve decentralisation, but instead attempts to address some of the drawbacks surrounding existing centralised stable-coins.
These drawbacks include difficulties regarding the storage of physical or economic wealth, and the increasing likelihood of attacks, as a single entity centralises the entire wealth of the system.
Typical stablecoins are also subject to fluctuations in the value of their underlying asset.
While these fluctuations are usually very small when compared with fluctuations in traditional cryptocurrencies, they are still significant.
For example, USDT is subject to the devaluation of USD due to inflation.
In this paper, we propose a stable cryptocurrency system which addresses the aforementioned drawbacks of existing stable currency solutions.
Specifically, we propose a new type of token which is not backed by any existing fiat currency or physical store of wealth, but instead is backed by legally binding contractual obligations to provide real-world labour-hours.
As such, the system and its controlling entity are not responsible for the centralised storage and management of wealth.
Further, the value of an unskilled labour-hour in a particular geographic region naturally adjusts according to economic conditions such as inflation, thereby maintaining the long-term intrinsic value of the cryptocurrency.
This paper is organised as follows:
In Section 2 we provide an overview of the system as a whole before discussing the technical details of the necessary system components and processes.
Section 3 provides economic considerations in brief, regarding the real-world deployment of this system and its feasibility.
Finally, Section 4 discusses future directions and applications of the system and of ChronoBank.
The appendix of this document provides supporting reference of several concepts introduced throughout the paper.
In particular Appendix B and C list the variables that encapsulate the functionality of the system.
These variables are also summarised in Table-1#ql:idChbwprtbl1#.
#idChbwprCBE#Similar to existing stable-coins (such as USDT by Tether and Digix), we propose a centralised entity that coordinates the creation, redemption, and destruction of Labour-Hour Tokens (LHT).
We refer to this entity as the ChronoBank Entity (CBE).
It is responsible for the acquisition and coordination of legally binding contracts for labour, in addition to the creation and dissemination of LHT.
Ultimately the role of the CBE is to ensure the stability of the LHT system through careful management of the system’s underlying processes.
This section will provide details describing the proposed processes, practices, and operations undertaken by the CBE and its associates.
An overview of the functionality of the ChronoBank system’s
constituents is shown in Figure-1#ql:idChbwprfig1#.
#idChbwprfig1#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgChbwprFig1.png!#
Figure 1.
An overview of the ChronoBank system.
This diagram shows the system’s constituents and their interactions.
CBE#ql:idChbwprCBE# refers to the ChronoBank Entity, LOC#ql:idChbwprLOC# to Labour-Offering Companies, LHT to Labour-Hour Tokens and TIME to the token purchased during the crowdsale.
The system as a whole is designed with the intent of a single deployment per economic region.
For instance, the system could be deployed once in Australia using the value of one labour-hour in the Australian economy, measured in Australian dollars.
As this document is an abstract description of the system, it does not refer to any region-specific implementation but instead refers to generalised system parameters that must be tailored for each region.
With few exceptions, all processes and structures described in this document may have slight variations in implementation between regions in which ChronoBank operates.
The initial implementation of the CBE#ql:idChbwprCBE# will utilise the Ethereum[-6-#ql:idChbwprref6#] blockchain; however, future implementations may tokenise assets on alternative blockchain systems (e.g. Waves [-7-#ql:idChbwprref7#], Bitcoin [-1-#ql:idChbwprref1#]) when it is deemed appropriate.
The CBE#ql:idChbwprCBE# provides economic benefit both to the environment in which it is deployed, and to a group of stakeholders that assist the CBE by providing initial operating capital.
Unlike the region-specific deployment of the CBE system, only one group of CBE stakeholders (a.k.a. TIME token holders) exists globally.
These stakeholders provide initial operating capital to the CBE in the form of both fiat and cryptocurrencies, in exchange for a portion of future profits attained by the CBE.
In order to fund the development and operation of the ChronoBank system, there will be a fundraising phase known as the crowdsale.
During the crowdsale, individuals may purchase TIME tokens at a fixed rate, which provides the token holder with the right to receive a proportion of the profits arising from the operation of the system.
In addition to the entitlements regarding the system’s operating profit, holders of TIME tokens will also be granted the right to vote on important decisions regarding the ChronoBank system.
TIME tokens will be developed utilising the Ethereum ecosystem, specifically leveraging the ERC20 token standard[-8-#ql:idChbwprref8#].
The ERC20 specification will be extended to provide voting functionality and rewards distribution; this is discussed further in Sections 2.1.3#ql:idChbwpr213# and 2.1.2#ql:idChbwpr212# below.
During the crowdsale, TIME tokens will be created as necessary and sold at the fixed price of 100 TIME tokens for 1 bitcoin (BTC).
There is no limit to the number of TIME tokens generated during the crowdsale; however, no further TIME tokens will be generated after this phase of the project.
#idChbwprtbl1#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgChbwprTbl1.png!#
| ρ | Total percentage of minted LHT taken by the CBE#ql:idChbwprCBE# |
| fc | Fee taken during minting by the CBE |
| fr | Fee taken during redemption by the CBE |
| fi | Issuance fee taken during minting |
| S | Percentage of minted LHT put into the-SGF#ql:idChbwpr232# |
| LT | Percentage of minted LHT put into the-Liquidity-Reserve#ql:idChbwpr231# |
| L0 | Percentage of minted LHT used for LOC#ql:idChbwprLOC# insurance |
| M | Number of months until L0 is transferred into the-SGF#ql:idChbwpr232# |
| l | Percentage of LT used for LOC insurance |
| P | Interval between TIME token reward payouts |
Table 1. List of abstract variables and constants used throughout this paper for reader’s reference.
See the Appendix for further details.
All TIME tokens purchased during the crowdsale will constitute 88% of the total TIME tokens generated during the initialisation of the ChronoBank system.
The remaining 12% of tokens will be split with 10% given to the ChronoBank.io team (for ongoing research and development) and 2% to advisors and early adopters of the system.
#idChbwprfig2#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgChbwprFig2.png!#
Figure 2.
Issuance fees (fi) and transaction fees (ft) are deposited into the rewards contract.
TIME holders can withdraw a portion of the LHT after each snapshot, if their TIME tokens were deposited into the contract.
For the use of the LHT, users will be charged a fixed fee, ft = 0.15% on all transactions.
Complementary to transaction fees, issuance fees (fi) will be taken during the minting process (further details in Section-2.2.1#ql:idChbwpr221#).
The issuance fees will start at 3% during the first year of operation and will stepwise decrease by 1% each year until a final issuance fee of 1% is achieved and maintained.
Both the transaction and issuance fees will be automatically collected and sent to a rewards contract on the Ethereum blockchain as shown in Figure-2#ql:idChbwprfig2#.
The rewards contract is designed such that TIME token holders can withdraw their earned rewards in a manner that makes them non-unique (i.e. withdrawal of rewards is not tracked on a per-token basis) and hence tradeable on exchanges for equal value.
The rewards contract will allow TIME token holders to retrieve their rewards at regular payout intervals, P.
At any given stage, TIME holders may deposit their tokens into the rewards contract.
At the onset of a payout interval, a snapshot of deposited TIME tokens and the current contract reward balance will be taken.(-1-#ql:idChbwprnot1#)
The rewards will be divided equally among the TIME tokens that were deposited at the time of the snapshot.
Depositors may then withdraw their share of rewards during the following payout interval.
At the next payout snapshot, any unclaimed rewards will be forfeited and added to the total balance of that snapshot.
Figure 3 illustrates this concept by plotting the rewards contract balance over time.
We also note that we expect P to be of the order of a few months.
TIME holders may deposit and withdraw their TIME tokens at any stage, however only TIME holders who have deposited before the snapshot of each payout interval can claim rewards.
Withdrawing TIME tokens from the contract will also withdraw any rewards currently owed to the depositor.
TIME holders may also leave their tokens deposited in the rewards contract indefinitely and claim their rewards periodically.
#idChbwprfig3#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgChbwprFig3.png!#
Figure 3.
The rewards contract receives Pr rewards for every payout interval P (in our example, we assume that Pr is constant).
At each snapshot, the portion of rewards that are not withdrawn is d.
Rewards that are not withdrawn roll over to the following payout interval P.
The dashed line indicates the withdrawable balance, which reduce over each payout interval as TIME holders withdraw their rewards.
This reward payout system gives upper bounds to the amount of rewards that can be stored in the contract in any interval, under some reasonable assumptions.
The total rewards obtained via fees for a particular payout interval, P, is Pr.
If we assume a constant amount of transaction and issuance fees per payout interval (i.e. a constant Pr), and an average percentage of locked TIME holders that do not withdraw in any payout interval, d, we can calculate the upper bound of the LHT stored in the smart contract through the limiting geometric series relation(-2-#ql:idChbwprnot2#):
#idChbwpreqt1#
X8 k=0 Prd k = Pr(1 - d)-1. (1)
To clarify this, let us take a conservative estimate, that 90% of all locked TIME token holders do not withdraw their rewards in every payout interval (only 10% actually withdraw).
In this scenario, no more than 10Pr worth of rewards will be stored in the rewards contract at any given time.
A less conservative estimate, being 50% of locked TIME holders withdrawing each payout interval, will ensure the rewards contract never contains more than 2Pr worth of rewards.
Through the careful (and potentially dynamic) choice of P we can find a balance between practicality (frequency of reward withdrawal) and security (safe level of stored value in a smart contract).
From time to time, the CBE#ql:idChbwprCBE# may hold polls on the Ethereum blockchain to elicit the opinion of TIME token holders.
Poll results will be incorporated into decisions made by the CBE concerning the financial or technical direction and/or implementation of the CBE system.
Only valid TIME holders are considered current stakeholders in the CBE system and are the only parties authorised to participate in a poll.
#idChbwprLHT#Labour-Hour Tokens (LHT) are the fundamental unit of value within the ChronoBank system.
The purpose of these tokens is to provide a non-volatile, inflationary-resistant digital store of value on various blockchains.
We envisage these tokens for utilisation in future systems, such as LaborX (see Section-4#ql:idChbwpr4# for a brief overview).
A Labour-Hour Token will be derived from a standard Ethereum ERC20 token and will be tradeable on all major exchanges.
The ChronoBank system will ensure that these tokens will always have a 1 to 1 mapping with legally bound promises of labour-hours from various Labour-Offering Companies (LOC)#ql:idChbwprLOC#.
As such, token holders may also redeem these tokens at any given time for their real-world labour-hour counterpart.
This section details the various processes required to feasibly sustain the 1 to 1 mapping of LHT to offered labour-hours and ensure the economic stability of the ChronoBank system.
#idChbwprLOC#The minting process takes place when a company offering labour-hours (Labour-Offering Company (LOC)) chooses to enter into a legally binding agreement with the CBE#ql:idChbwprCBE#.
The CBE must then run strict checks (the guidelines of which are described in the business outline [-9-#ql:idChbwprref9#]) of the LOC wishing to participate in the ChronoBank system.
Once the LOC is approved, the CBE and LOC will negotiate on various parameters (summarised in Appendix B#ql:idChbwpradxB#) before entering a legally binding contract whereby the LOC promises labour-hours in exchange for LHT (or the fiat equivalent).
The CBE#ql:idChbwprCBE# will then publish a hash of the contract on the Ethereum blockchain and store the contract on a decentralised storage system such as IPFS [10#ql:idChbwprref10#] or SWARM [11#ql:idChbwprref11#].
This gives a transparent ledger detailing the current state of the backed LHT.
The exact mechanisms behind the minting process are non-trivial and we refer the reader to Figures 4#ql:idChbwprfig4# and 5#ql:idChbwprfig5# during the following discussion of the process.
When an LOC#ql:idChbwprLOC# and the CBE#ql:idChbwprCBE# have agreed on terms, the CBE mints the equivalent amount of LHT as labour-hours offered by the LOC, ensuring the 1 to 1 relationship between the two.
Of the newly minted tokens, the CBE will retain ρ percent(-3-#ql:idChbwprnot3#), providing the remaining (1 - ρ) of minted LHT to the LOC.
In practice, the CBE#ql:idChbwprCBE# can sell the (1 - ρ) of minted LHT on exchanges and provide the LOC#ql:idChbwprLOC# with the fiat equivalent, should they not wish to deal with cryptocurrencies.
The ρ percent held by the CBE will be immediately subdivided into the following portions (shown diagrammatically in Figure 5).
• fc ;sblisin; [0, 0.01] - A fee charged by the CBE#ql:idChbwprCBE# for services provided.
• fi - The issuance fee which will go to the rewards contract for TIME token holders (see Section-2.1.2#ql:idChbwpr212#).
• S - A portion to be sent to the Security Guarantee Fund (SGF) (see Section-2.3.2#ql:idChbwpr232#).
• LT - The total portion sent to the Liquidity Reserve (Section-2.3.1#ql:idChbwpr231#). This fund is further split by a variable percentage, l, into LI (LOC insurance) and L0 (liquidity) (see Section-2.3.1#ql:idChbwpr231# for further details).
#idChbwpreqt2#For clarity, we write the obvious explicit relation,
ρ#ql:idChbwprtbl1# = fc + fi + S + LT . (2)
We expect that the system will maintain fixed fees, but will vary S, l and LT (and hence ρ#ql:idChbwprtbl1#) on a case-by-case basis to control the stability and viability of the ChronoBank ecosystem.
The purpose of the-Liquidity-Reserve#ql:idChbwpr231# and Security Guarantee Funds are detailed in the Funds Section-(2.3)#ql:idChbwpr23# and a brief discussion of the economic feasibility of this system is discussed in Section-3#ql:idChbwpr3#.
#idChbwprfig4#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgChbwprFig4.png!#
Figure 4.
Procedural overview of the ChronoBank minting process.
#idChbwprfig5#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgChbwprFig5.png!#
Figure 5.
Fund distribution of minted LHT.
As LHT are fundamentally backed by real-world labourhours, holders may redeem their tokens at any time for these backed hours.
To do so, holders will deposit their LHT into a redemption contract on the Ethereum blockchain.
Along with the deposit, holders will provide relevant data detailing their redemption request, such as labour type(s), location(s) of work, date/time of work, contact information, etc.
The request will trigger the CBE#ql:idChbwprCBE# to search and match relevant LOCs#ql:idChbwprLOC# to the redemption request.
If found, the CBE will return the most suitable LOCs that fit the request.
To discourage recurrent requests and to remunerate the CBE for its service, the CBE will take a small fee, fr ;sblisin; [0, 0.01] from the deposited tokens.
The amount of labour-hours matched will be less than or equal to the LHT tokens deposited, less the CBE’s fee.
Any unmatched requests or unfulfilled hours can be withdrawn from the redemption contract by the depositor.
As a redundancy, the redemption contract will have a built-in holding period, after which depositors may withdraw their deposited LHT.
This protects depositors from inactive or stagnant CBEs.
Once the CBE#ql:idChbwprCBE# has returned a list of compatible LOCs#ql:idChbwprLOC#, a depositor may accept or reject the offered LOC(s).
If rejected, the depositor can withdraw their deposited LHT less the CBE’s service fee.
If accepted, the CBE will advise the chosen LOC of all relevant details.
The redemption contract will hold the LHT until the work has been completed and the depositor is satisfied.
A dispute resolution system may be used to ensure work is completed as requested.
Once the labour has been satisfactorily completed, the deposited LHT will be destroyed, again ensuring the 1 to 1 relationship of LHT to backed labour-hours.
We have thus far ensured a 1 to 1 correspondence between LHT and labour-hours but have not yet defined the value of either.
The intrinsic value of one LHT and thus one labour-hour is region-dependant.
Although any arbitrary value can be chosen, we peg the value of one LHT to be roughly the average hourly wage of a region for practical reasons.
The average hourly wage of a region will be defined via the official statistics bureau of that specific region.
If one were to trivially adjust the LHT to the most recent statistics released for a given region, the price of LHT would stepwise shift on the release date of the statistics.
Typically these statistics are released yearly and in such scenarios a predictive stepwise jump each year would occur.
To implement a smooth transition from one statistics point to another, we propose that the pegged price of LHT be a linear interpolation between the two points.
This would require the LHT price to lag behind the most recent statistics by the duration of at least one extra statistics release.
Let us illustrate this with a clear example, as depicted in Figure 6.
Let us determine the price of LHT during April, 2010 in a region where the statistics bureau publishes a data point in January each year.
This data point indicates the average wage in that region for the previous year.
The price will be calculated by retrieving two data points: A2008
and A2009, the average wage in 2008 (released in January, 2009) and the average wage in 2009 (released in January, 2010) respectively.
We take a linear interpolation between these two points to find the price of LHT in April, 2010.
In this example, this will over-approximate(-4-#ql:idChbwprnot4#) the average wage in April, 2008.
This example shows that the LHT price in April 2010 will be the over-approximated average wage in April 2008, demonstrating how the pegged price of LHT will lag behind the current actual average wage.
It should be noted that this doesn’t affect any aspects of offering or redeeming labour.
The value of labour offered or redeemed is independent of the price of a single LHT.
However, the value will be measured with respect to the fixed price of a single LHT token.
#idChbwprfig6#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgChbwprFig6.png!#
Figure 6. The base price of one LHT in April 2010, X, can be calculated as the linear interpolation between the average wage in 2008 and 2009 (A2008 and A2009).
For any given region, typically there are sub-regions which have varying costs associated with providing labour work.
We wish to integrate these costs within our definition of a single LHT.
To do so, we take the maximum of each cost within a sub-region and add it to the average wage of the region to provide the fundamental price of LHT.
Specifically we have:
#@idChbwpreqt3 L = (1 + max(Y )) X , (3)#@
where X is the linearly interpolated function of average wages described above and Y is the individual cost in a sub-region as a percentage of work done.
L as defined in equation (3) is the pegged price of LHT for any given region.
This value will vary linearly throughout each year in a transparent and predictable manner.
The uniqueness of backing a digital token with contractual debt requires various safeguards to ensure contracts are always upheld and potential defaulting is accounted for.
There are a number of adverse scenarios that can occur with a debt-backed system.
Our proposed solutions involve the careful maintenance of two extra funds, the-Liquidity-Reserve#ql:idChbwpr231# and the-Security-Guarantee-Fund-(SGF)#ql:idChbwpr232#.
In this section we detail the operation of these funds and how they address some of the issues that can arise in this system.
'def.The-liquidity-reserve' is an offline LHT storage fund controlled by the CBE#ql:idChbwprCBE#.
It receives a percentage, LT, of newly minted LHT during the minting process (Section-2.2.1#ql:idChbwpr221#).
There are two services that this function provides the ChronoBank system:
(1) LOC Risk Mitigation - During the minting process, an LOC#ql:idChbwprLOC# will be paid (1 - ρ#ql:idChbwprtbl1#) percent of the labourhours they contractually agree to provide.
Therefore LOCs inherently take some risk in the form of immediate redemption.
If an LOC’s promise of
labour-hours is immediately redeemed, they stand
to lose ρ percent of these hours. To mitigate this,
the CBE#ql:idChbwprCBE# will store a percentage of minted LHT,
LI (see Section 2.2.1) for each LOC, to reimburse
the LOC in the event that more than (1 - ρ) labourhours
are redeemed. LI will cover all excess (i.e. more than (1 - ρ) ) redeemed tokens until the reserve, LI , is depleted.
We formalise this by introducing the mitigated tokens payed to an LOC#ql:idChbwprLOC#, LM, as
#@idChbwpreqt4 LM = min(LI , E) . (4)#@
where E is the excess LHT to be redeemed by the LOC, defined as:
#@idChbwpreqt4 E =
a) R - (1 - ρ#ql:idChbwprtbl1#), if R > (1 - ρ).
b) 0, if R = (1 - ρ). (5)#@
with R being the total percentage of LHT redeemed.
The mitigation reserve, LI is not constant, but is gradually transferred to the SGF (Section-2.3.2#ql:idChbwpr232#).
The rate at which this fund is transferred is derived from the parameter, M, which specifies the total number of months until the funds are entirely transferred, and is negotiated during the minting process.
The mitigation reserve funds will be transferred monthly at a uniform rate (LI / M).
This procedure then allows the CBE#ql:idChbwprCBE# to statistically choose ρ#ql:idChbwprtbl1#, LT and M given the risk profile and reputation of any given LOC#ql:idChbwprLOC# during the minting process.
For example, ρ, LT and M can be designed such that within a 95 percent confidence interval, an LOC does not lose more than (ρ - ζ) worth of the labour-hours promised over a given time(-5-#ql:idChbwprnot5#).
Here ζ is a number that quantifies the risk that the LOC is willing to accept.
This degree of freedom allows the CBE to manage LOCs of varying risk profiles.
(2) LHT Liquidity - The price of LHT will ultimately be governed by the price at which the CBE#ql:idChbwprCBE# buys and sells LHT(-6-#ql:idChbwprnot6#).
The funds used for this are stored in the-Liquidity-Reserve#ql:idChbwpr231#.
L0 of newly minted tokens (see Section-2.2.1#ql:idChbwpr221#) will be accrued in this fund.
The CBE will then stabilise the price of LHT and provide liquidity in various markets by buying and selling LHT at the fundamental price detailed in Section-2.2.3#ql:idChbwpr223#.
The parameter, l, chosen during contract negotiations, specifies the percentage of LT that goes to LI (the amount used for LOC insurance and which is gradually transferred to the Safety Guarantee Fund) and L0 (the amount that is permanently used for liquidity).
Through careful management of the parameter, l, the CBE#ql:idChbwprCBE# can maintain the desired volume of funds in the-Liquidity-Reserve#ql:idChbwpr231#.
As this fund will hold both LHT and volatile currencies, care must be taken to manage volume due to the potential price fluctuations of the held currencies.
One immediate-use case of this fund will be in the initial system set-up.
When the first LOCs become part of the system, the freshly minted LHTs will need to be sold to transfer the resulting funds to the LOC#ql:idChbwprLOC#.
Initially the demand for LHT will be low and funds from the-Liquidity-Reserve#ql:idChbwpr231# will be used to bootstrap this process.
A percentage of the crowdsale funds will be deposited into the Liquidity Reserve for this purpose.
One of the major drawbacks in a debt-backed currency system is the possibility of backers (LOC#ql:idChbwprLOC# in our case) defaulting on their contractual obligations.
Despite the care in vetting LOCs during the minting process, we expect there to be a percentage of companies that will inevitably default.
The SGF’s main purpose is to provide a fund reservoir as insurance to protect against defaulting companies.
In practice, this fund will burn held LHT tokens to the equivalent amount of outstanding labour-hours promised by the defaulting LOC.
Statistical estimates should be taken for the average probability of LOCs#ql:idChbwprLOC# defaulting.
These estimates will give a measure defining the amount of LHT that should be stored inside the SGF fund at any given time.
The amount stored in the SGF will be proportional to the amount of debt, and hence be proportional to the amount of LHT in existence (as every LHT is backed by one owed labour-hour).
This required value can be reached and maintained through the management of the minting variables, S, l and LT .
In this section we briefly mention some interesting properties and immediate economic consequences of this system.
First and foremost, the system must be designed such that there are economic incentives for both LOCs#ql:idChbwprLOC# and LHT holders to participate in the system.
For an LOC, the incentive to participate in the ChronoBank system comes in the form of an interest-free-like loan.
When an LOC agrees to participate in the system and offers labour-hours, the company effectively receives an interest-free loan, which needs to be paid back when their contract expires.
For this to be enticing to an LOC, we require that over the period of the contract the amount of money paid for the service of the loan is less than that of alternate means for loans, e.g. local bank loans.
We consider a simplistic example to demonstrate the feasibility of such a scenario.
Consider that a bank loan, which charges IB percent in interest per annum, has an upfront cost of C and is of total amount H.
Over a period of time, t, and assuming no regular repayments are necessary(-7-#ql:idChbwprnot7#), the LOC#ql:idChbwprLOC# stands to lose:
C + H((1 + IB)t - 1) - HIIt . (6)
The first term corresponds to the upfront cost of the loan,
the second term to total interest owed at time, t, and
the final term is potential interest earnings from external
investments. Here we’ve defined an average yearly interest
gain from external investments, II .
Alternatively, the LOC#ql:idChbwprLOC# may participate with the
ChronoBank system. If the LOC offers H hours of labour,
it would receive H(1 - ?) LHT in return, and would be
required to pay (1 + st)H worth of LHT back upon the
expiration of the contract (assumed at time, t). Here s is a
percentage representing the average yearly price increase8
of LHT. It quantifies an inflated price of LHT due to an
assumed increase in average wage over the contract period.
Therefore, with the ChronoBank system, the LOC stands
to lose,
H(? + st) - (1 - ?)HII t . (7)
The first term here originates from the initial sum taken
by ChronoBank, H?, and from the price fluctuation of
LHT over time. The second term comes from the potential
earnings from external investments with the (1-?)H LHT
received.
In this simplistic example, an LOC#ql:idChbwprLOC# would be economically
incentivised to participate in the ChronoBank system
if the total fees of the ChronoBank system are less than
the total fees of the alternative bank loan, explicitly:
H(? + (s + ?II )t) < C + H
(1 + IB)
t - 1
. (8)
Here, (s + ?II ) represents the average yearly price fluctuation
of LHT combined with ? percent of an average
expected investment return. With the reasonable assumption
that this quantity is less than the interest rate of a
bank loan, IB, equation (8) can always be satisfied for
some time period, t, given all other variables fixed. In
fact, the longer the contractual time, t, the greater the
cost-saving is to the LOC#ql:idChbwprLOC#.
So in this simplistic example, wecan see that this system incentivises LOCs to participate in the ChronoBank system for longer periods of time(-9-#ql:idChbwprnot9#).
Furthermore, the CBE#ql:idChbwprCBE# and LOC#ql:idChbwprLOC# are able to adjust both H and ρ#ql:idChbwprtbl1# during the negotiations of their initial contractual agreement, enabling the tuning of economic incentives in less favourable economic regions/scenarios.
As for LHT holders, their economic incentive is more obvious.
LHT, compared to its stable-coin predecessors, is inflationary-resistant.
Therefore, holders should have an economic incentive to use LHT as its value should increase relative to local inflationary fiat currencies.
We should note that buying and holding LHT as an investment (and therefore decreasing the liquidity of the token) is not in a holder’s best interest, as the gains in doing so are often less than external investment strategies.
This section is concerned with the ability of the ChronoBank system to sustain various economic hurdles, which we refer to as its stability.
The stability of the ChronoBank system hinges on the CBE#ql:idChbwprCBE# correctly managing the minting process.
Through the minting process, the two funds, Liquidity-Reserve#ql:idChbwpr231# and SGF#ql:""#, are controlled and maintained.
As the system grows, funds will accrue in both the-Liquidity-Reserve#ql:idChbwpr231# and the-SGF#ql:idChbwpr232#.
LHT is only removed from the-SGF#ql:idChbwpr232# in the event of an LOC#ql:idChbwprLOC# defaulting.
The Liquidity Reserve only decreases in value in the event that a held volatile currency devalues.
Therefore, both funds should grow as the system evolves.
As the funds reach a sustainable level, the percentage of LHT taken during the minting, ρ#ql:idChbwprtbl1#, can be decreased, further enhancing the economic incentive for more LOCs to join the system.
A greater number of LOCs participating will mean a greater number of LHT in existence and a greater volume of funds accrued in both the-SGF#ql:idChbwpr232# and Liquidity-Reserve#ql:idChbwpr231#.
The stability of the system will be proportional to the value stored in the-SGF#ql:idChbwpr232# and Liquidity Reserve and, therefore, we expect the system to become more stable as it develops.
A number of potential pitfalls can occur during the operation of this system.
In this section we briefly summarise the major and most obvious ones, along with our proposed solutions.
• An LOC#ql:idChbwprLOC# defaulting on its promise of labour-hours.
As previously mentioned, this will be covered by the-SGF#ql:idChbwpr232#.
The CBE#ql:idChbwprCBE# will burn the necessary LHT from the SGF fund to maintain the 1 to 1 relation of LHT to labour-hours.
• Large supply/demand causing price fluctuations.
This can be handled by a sufficiently deep Liquidity-Reserve#ql:idChbwpr231#, which will provide demand in times of high supply and vice versa.
Initially funds from the crowdsale will be placed into the liquidity fund, and as the system grows the liquidity fund will be maintained at a level deemed operationally safe to cover this scenario.
• Redemption of all LHT.
The LHT at any given time will always be backed by contractual labourhours in a 1 to 1 mapping.
Therefore, this scenario is possible and the system will continue to function in this event.
However, the risk in this occurrence lies with the participating LOCs, who will be required to pay back their LHT in the form of labour.
The SGF (Section-2.3.1#ql:idChbwpr231#) can also absorb some of the cost of this scenario.
It will be at the CBE’s#ql:idChbwprCBE# discretion to use the-SGF#ql:idChbwpr232# to assist in this very unlikely scenario.
• Increased demand at contract expiry.
As a contract expires, an LOC#ql:idChbwprLOC# will be required to buy back an equivalent amount of LHT to the labour-hours that are left on the contract.
This could potentially create periods of large demand.
In these scenarios, we will counter the demand with the-Liquidity-Reserve#ql:idChbwpr231# and, if necessary, the-SGF#ql:idChbwpr232#.
Economic Models.
Key to the success of the ChronoBank system is an informed choice of the aforementioned economic parameters.
It is essential to perform further analysis so as to determine how parameter modification impacts the feasibility and sustainability of the system in a wider context.
This will necessarily be performed before a realworld implementation is constructed.
LaborX.
The digital asset transfer system described in this document is proposed as a first step towards a larger decentralised labour system.
LHT as described by this paper forms the base currency for a decentralised labour exchange platform entitled LaborX.
The intention of LaborX is to enable peer-to-peer exchange of labour-hours with LHT, thereby reducing the centralisation of the proposed ChronoBank system.
LaborX will incorporate a rating system whereby holders of LHT can identify fair trades by examining the quality and/or specialisation of the labour provider, given their history on the platform.
By enabling direct exchange of LHT with labour-hours, the system’s dependency on contractual arrangements with LOCs is significantly reduced.
This potentially reduces the cost and increases the stability of the system as a whole.
This paper proposes a non-volatile, inflationaryresistant, digital asset transfer system.
This innovative system is only made possible by recent advancements in blockchain and cryptographic technologies.
Leveraging these technologies, this system tokenises contractual debt in a manner that can be both economically feasible and highly practical for digital platforms, such as LaborX.
The intrinsic value of the proposed token mirrors the average hourly rate of human labour - the most fundamental unit of economic value.
#idChbwprref1#[1] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008.
#idChbwprref2#[2] Tether.to. Tether: Fiat currencies on the bitcoin blockchain. 2014.
#idChbwprref3#[3] Anthony C. Eufemio Kai C. Chng Shaun Djie. Digix’s whitepaper: The gold standard in crypto-assets. 2016.
#idChbwprref4#[4] Fabian Schuh Daniel Larimer. Bitshares 2.0: Financial smart contract platform. 2015.
#idChbwprref5#[5] Investopedia. Contract for difference.
#idChbwprref6#[6] Gavin Wood. Ethereum: A secure decentralised generalised transaction ledger. Ethereum Project Yellow Paper, 2014.
#idChbwprref7#[7] Sasha Ivanov. Waves whitepaper. 2016.
#idChbwprref8#[8] Ethereum Request for Comments (ERC) 20.
#idChbwprref9#[9] The ChronoBank Team. ChronoBank: Business Outline.
#idChbwprref10#[10] IPFS: A peer-to-peer hypermedia protocol to make the web faster, safer, and more open.
#idChbwprref11#[11] Viktor Tron Aron Fisher Daniel A. Nagy.
#idChbwprnot1#(1) The transaction for which may be initiated by anyone, but typically by the CBE#ql:idChbwprCBE#.
#idChbwprnot2#(2) Assuming 0 ;sblle; d < 1.
#idChbwprnot3#(3) All percentages introduced in this document should be read as decimals. Hence (1 - ρ#ql:idChbwprtbl1#) ;sblge; 0.
#idChbwprnot4#(4) This is a poor approximation that assumes a linear growth, where the start of the year is the average wage of that year and the end of the year the is average wage of the following year.
#idChbwprnot5#(5) This can occur because the holdings of an LOC#ql:idChbwprLOC# increase over time due to assumed external investment.
#idChbwprnot6#(6) Combined with the fact that one LHT has a fundamental intrinsic value of one labour-hour.
#idChbwprnot7#(7) We use a no-repayment loan to clarify the analogy to our system and remove some mathematical complexity which obscures our point.
#idChbwprnot8#(8) This could also potentially decrease.
#idChbwprnot9#(9) Adding regular repayments to bank loans adds complexity to this simplistic example and although decreasing the size of the right-hand side of equation (8) it does not change our final result.
The following is a list of terms used throughout this document.
• CBE#ql:idChbwprCBE# - The ChronoBank Entity.
• LHT - Labour-Hour Token.
• LOC#ql:idChbwprLOC# - Labour-Offering Company.
• SGF---Security-Guarantee-Fund#ql:idChbwpr232#.
There are number of parameters that are required to be negotiated during the minting process.
For clarity we list here the variables that should be considered and determined by the CBE#ql:idChbwprCBE# during the minting process:
• S - A percentage of the minted tokens to be stored in the-Security-Guarantee-Fund#ql:idChbwpr232#.
• LT - The total percentage to be stored in the-liquidity-fund#ql:idChbwpr231#.
• l - The percentage of LT dictating how much of the liquidity fund is used as LOC insurance, LI . The remaining funds will be kept for liquidity in L0.
• M - The total number of months until the LOC Insurance LI is transferred to the-Security-Guarantee-Fund#ql:idChbwpr232#. This dictates the rate at which the funds are transferred, i.e. LI /M per month.
• Expiry Date - The expiry date of the contract, whereby the LOC#ql:idChbwprLOC# must buy back the value of the minted LHT.
Through the definition of the above variables, the CBE#ql:idChbwprCBE# on a case-by-case basis will fix ρ#ql:idChbwprtbl1#, the total percentage deducted from LOCs initially through the relation (2).
The fees of the ChronoBank system can be summarised in the following:
• fc - This is the fee taken by the CBE#ql:idChbwprCBE# during the minting process for services rendered. We expect fc ;sblisin; [0, 0.01].
• fi - This is the issuance fee, which will be taken during minting and deposited into the TIME token holder’s rewards contract. This will start at 3 percent and decrease by 1 percent each year until it is maintained at a steady 1 percent.
• ft - These are transaction fees, which are deposited into the TIME token holders rewards contract. This is a flat fee of 0.15%.
• fr - This is a fee taken by the CBE#ql:idChbwprCBE# during the redemption process for services provided and to add a deterrent to continual redemption requests. We expect fr ;sblisin; [0, 0.01].
name::
* McsEngl.chbprl'LaborX-white-paper (chblxw)@cptIt,
WORKING DRAFT: CHRONOBANK - PHASE 2: LABORX DECENTRALISED MARKETPLACE
THE CHRONOBANK TEAM
CHRONOBANK.IO
INFO@CHRONOBANK.IO
{retrieved 2017-03-20}
In Phase 1, Chronobank introduced labour-hour tokens which represent the average value of one labour hour.
This phase involves the design and construction of a decentralised platform capable of making labour exchange as easy as riding a taxi with Uber.
This white paper describes a decentralised marketplace where people of real-world professions will be able to sell their labour to any participating client#ql:idChblxwclient# of the system.
LaborX is a proposed implementation of the described system.
This is a draft version of the white paper prepared for community review.
A Bounty of 1000 TIME tokens (an equivalent of 10 BTC) will be divided between the best contributors.
To participate, join our#whitepaper Slack channel.
To a get Slack invite, visit https://chronobank.herokuapp.com
In 2009 (the same year that Bitcoin emerged), Uber, a mobile application which revolutionised the taxi business, was developed.
The easy to use, fast and comfortable service made Uber a worldwide company with $1.5 billion in revenue.
Uber removes the middleman – in its case, the taxi dispatcher - from the buyer/seller equation, allowing each driver to be his boss and work independently of a central company[-1-#ql:idChblxwref1#].
Similarly, LaborX aims to revolutionise the labour hiring industry by providing an open and decentralised ecosystem.
It has the potential to benefit both highly skilled workers, who prefer independence or a more flexible work schedule, as well as low-skilled labourers who will be able to find flexible part-time work when it is convenient for them.
LaborX targets offline workers providing real-life services which cannot be done remotely or supervised by special software.
The Problem.
Currently, numerous agencies are providing centralised services which offer to hire workers listed in their internal databases.
The reputation of such a system is fundamentally linked to the centralised agency which verifies and endorses the workers within the system.
Further, such systems often fail to disclose employee’s experience, reputation, or past jobs.
The situation is complicated even more by inflated agency fees and a plethora of agencies to choose from for any particular job.
Proposed Solution.
The LaborX Platform is a decentralised system that not only provides a labour hire marketplace but also is capable of automating (at least in part) the process of hiring individual workers given specific contract work.
This includes the selection and vetting of workers based on the main attributes, such as availability, location, a field of work, skills, and reputation.
This system leverages blockchain technology, specifically Ethereum, for its core systems and can therefore significantly lower operational and maintenance costs relative to competitors in the labour-hire industry.
Moreover, the public nature of Ethereum will allow participants to view all worker’s previous experience and recommendations.
The system will also utilise the commercial side of blockchain enabling immediate payments for completed work.
In addition, decentralisation allows the system to be global, autonomous, and versatile in the sense that workers and clients can accept a variety of location-independent currencies, in the form of any ERC20[-2-#ql:idChblxwref2#] compatible tokens (such as Labour Hour tokens[-3-#ql:idChblxwref3#]).
Contributions.
This paper provides a high-level overview of a blockchain-based decentralised labour hiring system and its conceptual realisation in real world applications.
Section 3 provides an overview of the base system components and processes including minor technical details.
Section 4 provides economic considerations in brief, regarding the real-world deployment of this system and its feasibility.
Section 5 describes the rating system that allows the community to have control over LaborX.
Section 6 is focused on interface features.
Section 7 details how privacy issues are handled.
We aim to make short-term employment as accessible and rewarding as long-term employment, giving workers the flexibility to determine their schedules while being paid a fair rate for their time, expertise, and reputation.
We plan to achieve this through the LaborX platform, which will enable trading of labour time at market rates.
A decentralised reputation system will facilitate feedback for each entity, allowing employers to hire the most competent professionals.
It will also enable individual workers to secure payment in line with their training, skills, and experience.
LaborX system is designed specifically to target workers in the labour industry (areas such as cleaning, plumbing, gardening, etc.).
The system is intended to be distributed and have no central controlling authority.
This means that it wouldn’t be controlled by any single individual or company, but by a set of publicly verifiable predefined rules.
Anyone can fork, modify and redeploy the system, like it can be done with the Ethereum network itself[-4-#ql:idChblxwref4#].
The system has to satisfy the following usage requirements:
(1) The client#ql:idChblxwclient# should be offered a selection from the most competent workers based on their search preferences.
(2) Workers that have higher ratings should have higher compensations.
(3) A worker can set their own rate.
(4) Both the client and the worker should have a rating.
(5) Both the client and the worker can reject a given sealed job contract (see more at Section-3.2#ql:idChblxw32#).
(6) The worker always receives money for the time they spent on labour.
(7) The client should be able to stop work at any time.
(8) The system should vet clients and workers that have bad ratings.
(9) The client could pay with any ERC20 cryptocurrency, should the worker accept these tokens.
The decentralised nature of this system allows clients#ql:idChblxwclient# to hire workers using the Ethereum blockchain.
Thus the core features of the system will run as a set of smart contracts[-5-#ql:idChblxwref5#], making the system available for use independently of any particular user interface realisation.
These contracts will govern the behaviour of the system, dictate the agreements between parties, and serve as a public ledger containing profiles of clients and workers.
#idChblxwfig1#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgChblxwFig1.png!#
Figure 1. Sequence diagram
This section defines the six most important entities
within the system: the client#ql:idChblxwclient#, worker, evaluator, verificator,
provider, and the LaborX core (whose functionalities
are depicted in Figure 1).
#idChblxwclient#The client - a person or party that requires work to be completed.
They create job(s) with key attributes (such as field of work, skills required, etc(-1-#ql:idChblxwnot1#)) which gets posted to the ledger.
The client then retrieves a list of available and qualified workers which they can select based on preference.
The worker(s) may then accept the job and provide approximate estimates for the amount of time required to complete it.
At this point, the system will allow the client and worker(s) to begin direct communication, should it be desired.
Then the client has to agree on the estimations given by the worker.
Upon agreement, a smart contract will facilitate the withdrawal of funds (equivalent to the value of the estimated hours of work) from the client’s account to an escrow-like smart contract on the blockchain.
The funds will then be released on a per-hour basis to the worker as work is completed.
To ensure correct hours are paid, a stop-start timer is used.
As a worker arrives, they seek approval from the client to begin the timer and commence the paid work period.
The same is done at the end of the period or work segment.
The client can revoke the job before it begins and can withdraw the deducted funds from the escrow-like smart contract.
The client may give a rating to the worker upon job completion/termination and optionally a recommendation.
#idChblxwworker#The worker - any person or party seeking jobs who is capable of working and getting paid.
A worker creates a public profile containing labour scopes, working hours, and other relevant information.
Based on this profile, a worker would be offered by LaborX to clients for jobs matching their labour scopes.
If selected, a worker will be notified and asked to provide time estimates to complete the specific job.
The worker is then able to contact the client to finalise details (if needed) before finalising the agreement.
The worker should then arrive at the negotiated time to begin the work.
The approval to start/stop the timer for paid work can then be given by the client, as described above.
Upon completion/termination of a job, the worker can rate the client and optionally provide additional comments.
#idChblxwevaluator#The evaluator.
The highest ranked members of a community will be able to evaluate and confirm corresponding skills of workers, building a chain of trust.
In this way, clients will be sure that the assigned worker has all the required skills for completing the job.
Workers will be required to have a high rating and enough activity points to become an evaluator.
Evaluators may verify and endorse skills of other workers ensuring clients have a more accurate description of their potential workforce.
Workers with endorsed skills will typically have a greater chance to be selected for any given job by the LaborX core.
After performing worker’s skill assessment the evaluator publishes a record in blockchain.
Evaluator’s profile displays statistics of appraised workers and evaluator’s reputation among LaborX users depends on it.
#idChblxwverifier#The verifier - a worker who offers services to verify clients and workers in a particular region (See the functionality in Figure-1#ql:idChblxwfig1#).
The fundamental role of verifiers is to check required documents for their respective areas, such as work permit, certificate, injury insurance or other types of insurance.
These entities are essential to adhere to local laws, enhance security, and potentially minimise spam issues.
Both parties (clients and workers) may choose a single or many verifiers to review their documents, based on their rating and popularity.
Each worker has a public profile and private data.
The public profile is available in the blockchain and is accessible to everyone.
The private data is verified and electronically signed by a verifier.
It is only available to a client after they enter into a contract with the worker (more information is given in Section-7#ql:idChblxw7#).
#idChblxwprovider#The provider - an entity who has created a job board.
The nature of the blockchain means that participants are pseudonymous by default.
This opens wide opportunities for spammers, marketing bots and other parties whose behaviour would be disruptive for LaborX.
The decentralisation of the system means that there is no single authority who can ban these entities.
A proposed solution is to give participants ability to create job boards, where the creator is also the moderator.
Each board would have a rating from other participants and each participant having a threshold of activity points would be able to vote up or down on boards.
The job board creator will be able to appoint other members as moderators.
Each board member having sufficient activity points would be able to flag any suspicious entry for review and receive activity points for helpful reports.
The boards would be filtered by tags and sorted by rating in the client application to easily remove/filter all junk boards.
The job board creators also can enforce requirements for the clients and workers that want to use the board.
They could include a requirement to pass verification by one of the listed verifiers, to have at least specified minimal rating, to perform a job in defined fields of work, to accept payment in selected cryptocurrency, to be located in specified area etc.
#idChblxwlaborxcore#LaborX core - a sub-system of the LaborX platform encapsulating the majority of the core inner functionality and blockchain-dependent logic.
This system provides the mechanisms that allow jobs, profiles, and other public data to be stored in the blockchain.
It is capable of searching for available workers in job boards based on location, field of work, and skills thus giving clients a choice to pick worker(s) that best suits their needs.
After a client makes this selection, LaborX core provides the functionality that sends notifications to the worker to accept/decline a specific job via Ethereum events.
LaborX core is also responsible for calculating, storing, and retrieval of rating on the blockchain.
Every client and worker will have a rating which increases/decreases as recommendations accrue after jobs are completed.
LaborX core is a complex system powered by the Ethereum network.
It contains all users’ public profiles, completed jobs with description, executor, status, and mutual ratings.
However, considering the system complexity, we have chosen to distinguish LaborX core from LaborX DApp.
LaborX DApp functionality will include interface for creating profiles, verification, evaluation, searching workers, concluding contracts etc (see Section-6#ql:idChblxw6# for full description of features).
This section will provide a more specific description of the key parts of LaborX core and we will postpone further discussion of LaborX DApp to Section-6#ql:idChblxw6#.
A job object (the programmatic object relating to a real-world job) will contain a location, provider used and work description.
The work description includes attributes such as field of work, job due date, address of ERC20 token contract (that will be used for payment), required skills, and further optional job-specific requirements.
A client would be capable of searching through the list of workers in job boards or choosing a familiar worker.
Fields of work and required skills can be selected from a list offered by the smart contract.
A location is also a selectable parameter that will typically represent a city/region.
If a city/region is large, then a district/sub-region may be specified.
A city/region includes all of its districts/sub-regions.
A location is used to map workers to nearby clients.
Precise addresses (for job locations) will be revealed to workers once the job has been mutually agreed on and solidified by the smart contract.
A job due date can be a present or future time.
If the current time is selected, then LaborX returns all currently available workers ready to start a work now.
If instead a future time was chosen, then the system will find workers available to work at the chosen time.
Once the worker accepts the job, the smart contract will publicly mark the worker as busy, preventing further bookings in that period.
#idChblxwtbl1#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgChblxwTbl1.png!#
Table 1. Responsibilities distribution of LaborX core and LaborX DApp
Billing will be governed by the following scheme:
Once a worker’s estimates have been approved by the client, a smart contract withdraws the required tokens/currency from the client’s account.
If the work takes more time than initially estimated and approved by the client, then the smart contract verifies the client’s balance and automatically withdraws additional funds to account for the overtime.
As this is an automatic process, the worker can continue to work freely and be sure that their overtime will be paid.
This procedure repeats hourly.
The process stops if either the job is paused, or marked as finished, or the client runs out of money, or the smart contract reaches a maximum withdraw limit(-2-#ql:idChblxwnot2#).
If this limit is reached, the smart contract may ask the client to increase the maximum withdrawal limit.
If the client declines, the job is considered finished, and any remaining funds are released to the worker.
If the worker works less than the estimated time, the difference is transferred back to the client.
Part of the tokens paid for the job is automatically withdrawn as a fee (see more at Section-4#ql:idChblxw4#).
Worker has an ability to pause and continue job timer at any time.
If the client is not satisfied with the worker, their accountability, or their work they can cancel the job at any time.
Nevertheless, the client is required to pay a minimum of one hour (which is a minimal time unit that can be paid).
The client may then leave a negative recommendation and rating that will negatively flag the worker for future clients.
A negative rating will also adversely affect evaluator’s reputation.
If the worker doesn’t start work within the agreed time, the client will not be charged but is still able to rate the worker and leave a comment.
It should be noted that client does not pay the worker’s transportation time and expenses.
Instead, they should be included in the worker’s individual rates.
The implementation of LaborX DApp, specifically the
search and worker selection, will allow the system to be
easily scalable. Yet, due to the systems complexity, it is
probable that software bugs will be discovered. Therefore,
a mechanism to upgrade smart contracts and core
system functionality will be required. LaborX will use the
following approach:
(1) Application data will be stored in contracts that
are separated from business logic.
(2) Each record will contain a version number.
(3) Each contract will have a constant external interface.
(4) No migration can happen without a user’s consent.
In this way, contracts can be upgraded without the need
to migrate data. Switching to a new contract version is
the smart contract equivalent of accepting terms of service,
updated by a service provider. Each user will have an
option to either migrate to a new contract version or to
continue using the current one.
#idChblxwfig2#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgChblxwFig2.png!#
Figure 2. Relationships between different parties inside decentralised LaborX system.
LaborX is a multi-currency service that will support any token that complies with the ERC20 standard[-2-#ql:idChblxwref2#] including, but not limited to, Labor Hour tokens.
A simple multi-currency wallet capable of receiving and sending any supported ERC20 token will be integrated into the LaborX platform.
Users will be able to pay and get paid by tokens they choose from a list of supported on job boards tokens.
Providers may list local currencies, allowing communities to pay for jobs in unusual digital assets, should both the client and the worker accept the currency by selecting the job board.
As mentioned in the previous section, the LaborX system will deduct 1%(-3-#ql:idChblxwnot3#) from each completed job part of which will go as a revenue to TIME token holders and other part to providers for their services.
Provider receives payment only for completed jobs posted on provider’s job board.
For clients.
There are numerous benefits for clients.
Because of smaller mediator fees than in traditional labour hiring companies, the resulting work price will be lower.
Decentralisation of the service makes it fast, reliable, secure, and permanently available.
A public worker rating system ensures that clients are seeing profiles of real workers along with their unique histories and therefore genuine ratings.
The ability to pay with a variety of digital tokens makes the system universal and not tied to any particular country/region.
Furthermore, LaborX will implement an easy to use interface, paying serious attention to UX.
For workers.
Benefits for workers are also significant.
Due to lower fees than in traditional labour hiring companies workers may ask for higher hourly rates.
The most skilled and responsible workers with the best ratings will be highly sought after and may, therefore, demand a higher hourly fee than their not-so-amazing colleagues.
For the first time in the labour hire industry, diligent and attentive workers will be rewarded for providing better services.
The decentralised nature of LaborX will not only guarantee that workers will get paid, but will enable real-time payment to the worker as the work is completed.
Since the system is fully automated, the workers will be able to plan their schedules corresponding to their preferences.
For every worker and client there are two metrics called
rating and activity points. The first describes how well a
client or worker performs their duties and is dictated by
their partners. The second is a point system based on all
LaborX activity.
The better the individuals rating (based on previous
work), the higher the price they are be able to demand for
an hour of work. After a job is completed, both the client
and worker are asked to rate to each other. The rating is
in the range between 1 and 10, where 1 corresponds to a
total disaster and 10 represents exceptional work.
The rating system will be time and quantity aware. By
this, we mean that older ratings should contribute less to
the current rating than recent ratings (i.e., the ratings are
recency-weighted). This means, for example, a bad rating
accrued a year ago by a worker, can be redeemed by a
series of recent good ratings, thus restoring the reputation
of the worker.
Activity points are used only in the LaborX DApp
and have a crucial security role by limiting the amount of
available functionality to newcomers. This limits threats
such as spamming, posting advertisements with ambiguous
links, or evildoers trying to overload the system with an
infinite job posting.
Every new user begins with a single activity point which
will automatically increase when performing various actions
inside the app (see Table 2). An alternative way
to gain activity points is by verifying one’s identity with
various verificators or by passing skill assessment with an
evaluators. The activity points count will always be greater
than or equal to 1.
An example of activity point elevators are given in Table
2. Some of the proposed features that will require some
amount of activity points is given in Table 3. The listed
values in these tables are examples only and may change
during the implementation and system testing period.
#idChblxwfig3#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgChblxwFig3.png!#
Figure 3. Contract interaction diagram
#idChblxwtbl2#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgChblxwTbl2.png!#
Table 2. Actions that affect activity points.
#idChblxwtbl3#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgChblxwTbl3.png!#
Table 3. Actions that require activity points.
#idChblxwtbl4#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgChblxwTbl4.png!#
Table 4. Rating and activity points growth example.
One of the top priorities of the LaborX platform is to ensure that every client is comfortable letting workers into their house/workplace and every worker is provided with a safe workplace environment.
To this end, LaborX is designed with specific focus on worker/client confidence.
This is achieved through decentralised verification and evaluation features.
They will offer a range of verification possibilities allowing workers to choose those that suits them best.
The following gives a non-exhaustive list of possible options(-4-#ql:idChblxwnot4#):
• Verification.
Entities with high reputation could serve as verification hubs and be paid for their services by workers.
They will check that worker’s documents correspond to the worker’s identity, scan documents, publish document hashes[-6-#ql:idChblxwref6#] in the blockchain and confirm this action by signing the hashes with their digital signature (see Section-7#ql:idChblxw7# for more information).
• Evaluation.
The highest ranked members of a community will be able to evaluate and confirm corresponding skills of workers, building a chain of trust.
In this way, clients will be sure that the assigned worker has all the required skills for completing the job.
• Evaluation by Clients.
Any verified client may advertise individual worker’s skills after completing the job if some of them are exceptional.
This information would be used to separately promote the workers who are constantly rated 10/10.
According to the current model, the governing smart contract returns a selection of workers that fit the criteria of a given job posted by a client.
The LaborX DApp takes preference of workers who have more completed jobs and higher ratings.
The system may grow such that the ratio of workers to jobs becomes quite large.
It is therefore important that the LaborX DApp does some advanced filtering.
This means that the application should not show all workers capable of performing a given job, instead select only several of the available best workers with varying rates and ratings.
In this way, the most competent workers will get more work and will be paid more for their reputation.
Clients may also use different custom filters that will help them to find the most fitting worker to suit their needs.
They may also pick specific workers they are already familiar with.
The application will also utilise smart filtering to minimise the worker intersection between clients.
This is crucial for the system, especially when considering similar jobs.
The LaborX platform will include multi-currency support, making sure users can use different ERC20 tokens to purchase labour.
Each LaborX provider will be able to set cryptocurrencies that will be permitted for payments on their job boards.
Clients and workers who choose a job board, agree to use one of the supported methods of payment.
High load testing and analysis would be performed while developing LaborX to determine exact implementation and architecture of the search system.
The main part of a search logic should be performed in the LaborX LaborX core.
Only Ethereum transactions that write to blockchain have gas limit and cost Ether.
The search operation is read-only, therefore it would perform computations on user’s Ethereum node and will not require paying Ether.
A worker-to-job matching will include complex queries and therefore require a significant amount of computational power of the machine where Ethereum node software is running.
Therefore LaborX DApp could handle part of the filtering and caching logic on client’s side.
This approach will significantly improve the user experience.
LaborX will use a messaging system with an underlying protocol like Whisper[-7-#ql:idChblxwref7#], enabling client and worker to establish an encrypted connection.
These messages could be used to exchange job details, address, confidential instructions, etc.
The exact realisation will be decided at the time of development (specified in the LaborX road map), taking into account the potential research and new possibilities that will be available in 2017.
Other features that are planned for LaborX but not described in this white paper include moderation and arbitration system powered by providers, usage of IPFS for data storage, and the Truffle framework for smart contracts on Solidity.
The LaborX DApp will have a modern responsive interface (see, for example, the ’Post new job’ and ’Edit worker profile’ wireframes in the appendix A#ql:idChblxwadxa#).
It is truly unsafe to publish sensitive, private data in a blockchain.
However, we have to eliminate the possibility of a worker re-registering to reset their profile.
Therefore, we have to maintain a balance between anonymity and notoriety.
To achieve this, each worker will have a publicly available blockchain profile containing their nickname (first name and the first letter of their surname), small photo, field(s) of work, skills, rating, rate, activity points, approximate location, a list of completed jobs and payments.
Optionally, a worker may apply for a document verification or a skill evaluation (see Sections 3#ql:idChblxw3#, 6#ql:idChblxw6#) which will be reflected in his public profile and confirmed by the electronic signature of the governing party.
There will be a data set which will never appear on the blockchain.
This includes, but is not limited to, the exact geolocation of the client and the worker, additional private instructions for the worker, document scans.
Hashes[-6-#ql:idChblxwref6#] of private data blocks will be published on the blockchain to prove that they have not been altered.
These hashes should also be electronically signed by submitter of the stored information and linked to the worker’s public profile.
In this way, only the signature and hash of the sensitive information will be publicly available, and any confidential data may be stored without revealing it to the public.
An entity which gains authorised access to the information will also be able to check the signature to prove the origin of information.
#idChblxwfig4#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgChblxwFig4.png!#
Figure 4. Verification of documents
This white paper proposes a decentralised system designed to revolutionise the labour-hire industry.
It will be capable of automatically matching available workers to corresponding jobs according to their location, field of work, skills, and reputation.
Using the Ethereum blockchain as a basis, this system can significantly lower fees for system maintenance, relative to traditional systems offering a similar service.
Moreover, decentralisation makes the system autonomous and global as it runs on Ethereum and is capable of using any currently existing ERC20[-2-#ql:idChblxwref2#] tokens.
This innovative system is only made possible by recent advancements in blockchain and cryptographic technologies.
Leveraging these technologies this system allows people to trade human labour - the most fundamental unit of economic value.
#idChblxwref1#[1] The Huffington Post. ’uberization’ of everything is happening, but not every ’uber’ will succeed. http://www.huffingtonpost.ca/2015/04/01/uberization-uber-of-everything_n_6971752.html, 2015.
#idChblxwref2#[2] Ethereum Foundation. Erc20: Ethereum token standard. https://github.com/ethereum/EIPs/issues/20, 2015.
#idChblxwref3#[3] The ChronoBank Team. Chronobank - phase 1: A non-volatile digital token backed by labour-hours. https://chronobank.io/files/whitepaper.pdf, 2016.
#idChblxwref4#[4] Ethereum Classic. Website. https://ethereumclassic.github.io/, 2016.
#idChblxwref5#[5] D. Tapscott and A. Tapscott. Blockchain Revolution: The Brilliant Technology Changing Money, Business and the World. Penguin Books Canada, 2016.
#idChblxwref6#[6] Wikipedia. Cryptographic hash function. https://simple.wikipedia.org/wiki/Cryptographic_hash_function.
#idChblxwref7#[7] Ethereum Foundation. Whisper wiki article. https://github.com/ethereum/wiki/wiki/Whisper, 2016.
#idChblxwnot1#(1) Additional requirements are detailed in section-3.2#ql:idChblxw32#.
#idChblxwnot2#(2) This is typically double the estimated total price, but can be adjusted on a per-job basis.
#idChblxwnot3#(3) Percentage may change during the implementation and system testing period.
#idChblxwactivitypoint#activity points:
is an integer in a range of 1 to infinity which measures positive contribution to LaborX ecosystem.
The more activity points the user has, the more advanced actions they can perform.
See the full list in Table 2. 2, 3, 5
client:
is a person that has some work and needs to get it done.
Client posts a job and pays for it. 2
#idChblxwdapp#DApp:
is an abbreviated form for decentralised application.
A DApp has its back-end code running on a decentralised peer-to-peer network.
Contrast this with an app where the back-end code is running on centralised servers. 3–7
evaluator:
a highly rated worker with lots of experience and reputation which prove they are a master in their field of work and thus can verify skills of other workers. 2, 5
#idChblxwjob#job:
is some work or task to get done.
Job can be a list of tasks but all within one field of work. 2
#idChblxwjobboard#job board:
is a publicly available database managed by the creator.
It will be implemented as a smart contract in Ethereum network.
More information in Section 6. 3, 5, 6
LaborX core:
this is a sub-system of the LaborX platform encapsulating the majority of the core inner functionality and blockchain-dependent logic. 2, 3, 6
#idChblxwledger#ledger:
is a publicly available database that holds information.
It will be implemented as a smart contract in Ethereum network. 2
provider:
is an entity which offers its services to connect clients and workers through a job board because of legal, security, or spam issues.
Anyone can become a provider, and both parties (a client and a worker) could choose which providers they trust.
Providers get paid for their services by receiving a percentage of job payment fees. 2, 3, 5–7
#idChblxwrate#rate:
amount of money that will be paid hourly to a worker. 1, 2, 6, 7
#idChblxwrating#rating:
is an integer in a range from 1 to 10 (where 1 is a disaster and 10 is perfect) which measures
the quality of work done by a worker.
LaborX uses rating to select workers for a job. 2–6
verificator:
a worker with flawless reputation who offers services of verification for documents and
identity of other entities. 2, 5
worker:
is a person that is assigned to fulfil client’s job and get paid for it. 2
#idChblxwfig5#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgChblxwFig5.png!#
Figure 5. Client’s jobs screen10
#idChblxwfig6#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgChblxwFig6.png!#
Figure 6. Worker’s profile editing
name::
* McsEngl.chbprl'Business-outline (chbbon)@cptIt,
* McsEngl.chbbusiness-outline@cptIt,
* McsEngl.chronobank-business-outline@cptIt,
_ADDRESS.WPG:
* https://chronobank.io/files/business_outline.pdf,
name::
* McsEngl.chbnet'Blockchain@cptIt,
_DESCRIPTION:
ChronoBank.io is a blockchain project aimed to disrupt HR/recruitment/finance industry similar way as Uber revolutionised taxi business.
{2017-01-19}
Why ChronoBank will use multiple blockchains
ChronoBank will use several different blockchains to issue and trade LH tokens, likely including Waves, Ethereum and NEM. The reasons are financial, cultural and ideological.
Many new crypto projects launch their own blockchain and have a single, dedicated token to represent value on their network. ChronoBank is taking the approach of issuing both its native asset, TIME, and Labour Hour (LH) tokens on multiple blockchains. As time goes on and popular new protocols arise, we will issue tokens on those as well. There are several reasons for this, both practical and ideological.
1. Sustainability
Our priority is to create a long-term blockchain-based solution for the labour-hire industry. Cryptocurrency is still in its infancy and we currently don’t know which protocols will survive. Technical problems may become evident in due course, rendering one or more blockchains non-viable. Others may be impacted in ways we cannot foresee. In the past, for example, different cryptocurrencies have fallen from favour due to a large number of factors: the loss of one or more core developers; poor distribution, which led to large quantities of coins being sold and loss of wider confidence; unpopular changes or forks; inadequate funding for promotion and development. All of these and more have hamstrung otherwise healthy blockchain projects.
Therefore we are decentralising our issuance across many blockchains; should popular new platforms arise in the future, we will use these too. That way, ChronoBank will never be rendered obsolete in the way that some other projects that launched on blockchains the market eventually deemed wanting have been.
2. Synergy
We want to engage many different communities to achieve our aims. This means not only seeking investment from several of the major blockchain ecosystems in order to give us the funding to launch ChronoBank, but working with them for their expertise and to build business relationships. As a cross-blockchain project, we think that ChronoBank has the ability to bring together the best elements of these protocols and communities under one roof. That will inevitably bring benefits for our own project, but to each of the others, too.
3. Success
The priority is crypto adoption, the creation of fair money and a more just economy. Using many blockchains is simply the best way to do this. The crypto world is fragmented, with tribal loyalties to specific blockchains often taking precedence over broader ideals like disintermediation and the redistribution of financial power. We know that restricting ourselves to a single blockchain will very likely hamper our overall chances of making the impression we need to in the crypto world and bringing about meaningful change in the recruitment sector. The more communities we work with, the more liquid and better traded our tokens will be; the higher profile our project will have; the more people will have a reason to help us succeed. We’re pleased to be blockchain-agnostic in order to prioritise the success of ChronoBank.
[https://blog.chronobank.io/why-chronobank-will-use-multiple-blockchains-9da5a70eaaea]
name::
* McsEngl.chbnet'Program (chbpgm)@cptIt,
name::
* McsEngl.chbpgm'Doing@cptIt,
name::
* McsEngl.chbpgm'Developing@cptIt,
_DESCRIPTION:
Two Week Software Cycle
We are pleased to announce that we will be switching from a feature-based versioning and release model to a continuous release model with a two-week, two-phase software cycle.
The first phase is a one week merge period. In this week any stable Pull Requests will be accepted into the development branch. The second phase is a one week test/regression and release period. During this stage we will branch a new release/version, then test, patch or undo any PRs that are unstable.
This will allow a process of continual deployment and incremental improvement for LaborX, while also allowing features to develop and mature before being included into the release version. The approach also allows us to ‘roll back’ or regress certain changes, should they become problematic. Hopefully this will enable us to release a new version of LaborX consistently every two weeks .
[https://blog.chronobank.io/chronobank-dev-update-7-49b387396b2c#.odbp6hdr9 {2017-03-26}]
name::
* McsEngl.chbnet'SmartContracts (chbctp)@cptIt,
* McsEngl.chbctp@cptIt,
* McsEngl.chronobank-smart-contracts@cptIt,
_ADDRESS.WPG:
* https://github.com/ChronoBank/SmartContracts,
_DESCRIPTION:
ChronoMint, Labour Hours and Time contracts.
ChronoBankPlatform.sol acts as a base for all tokens operation (like issuing, balance storage, transfer).
ChronoBankAsset.sol adds interface layout (described in ChronoBankAssetInterface.sol)
ChronoBankAssetWithFee.sol extends ChronoBankAsset.sol with operations fees logic.
ChronoBankAssetProxy.sol acts as a transaction proxy, provide an ERC20 interface (described in ERC20Interface.sol) and allows additional logic insertions and wallet access recovery in case of key loss.
EventsHistory.sol holds all operations events to avoid events lost in case of contract replacement during upgrade or extension.
ChronoBankPlatformEmitter.sol provides platform events definition.
[https://github.com/ChronoBank/SmartContracts]
_SPECIFIC:
* ChronoBankAsset.sol
* ChronoBankAssetInterface.sol
* ChronoBankAssetProxy.sol
* ChronoBankAssetProxyInterface.sol
* ChronoBankAssetWithFee.sol
* ChronoBankAssetWithFeeProxy.sol
* ChronoBankPlatform.sol
* ChronoBankPlatformEmitter.sol
* ChronoBankPlatformInterface.sol
* ChronoMint.sol
* Configurable.sol
* ContractsManager.sol
* ERC20Interface.sol
* EternalStorage.sol
* EventsHistory.sol
* Exchange.sol
* ExchangeInterface.sol
* LHT.sol
* LOC.sol
* Managed.sol
* Migrations.sol
* Owned.sol
* Rewards.sol
* Rooted.sol
* Shareable.sol
* TIME.sol
* Vote.sol
name::
* McsEngl.chbctp.ChronoBankPlatform.sol@cptIt,
_DESCRIPTION:
ChronoBankPlatform.sol acts as a base for all tokens operation (like issuing, balance storage, transfer).
- keep balances,
- manage transfers,
- manage asset issuance,
name::
* McsEngl.chbctp.ChronoBankAsset.sol@cptIt,
_DESCRIPTION:
ChronoBankAsset.sol adds interface layout (described in ChronoBankAssetInterface.sol)
[https://github.com/ChronoBank/SmartContracts]
_SPECIFIC:
* ChronoBankAssetWithFee##
* TIME##
name::
* McsEngl.chbctp.ChronoBankAssetWithFee.sol@cptIt,
_DESCRIPTION:
ChronoBankAssetWithFee.sol extends ChronoBankAsset.sol with operations fees logic.
[https://github.com/ChronoBank/SmartContracts]
name::
* McsEngl.chbctp.ChronoBankAssetProxy.sol@cptIt,
_DESCRIPTION:
ChronoBankAssetProxy.sol acts as a transaction proxy, provide an ERC20 interface (described in ERC20Interface.sol) and allows additional logic insertions and wallet access recovery in case of key loss.
[https://github.com/ChronoBank/SmartContracts]
name::
* McsEngl.chbctp.EventsHistory.sol@cptIt,
_DESCRIPTION:
EventsHistory.sol holds all operations events to avoid events lost in case of contract replacement during upgrade or extension.
[https://github.com/ChronoBank/SmartContracts]
name::
* McsEngl.chbctp.ChronoBankPlatformEmitter.sol@cptIt,
_DESCRIPTION:
ChronoBankPlatformEmitter.sol provides platform events definition.
[https://github.com/ChronoBank/SmartContracts]
name::
* McsEngl.chbctp.Owned@cptIt,
_SPECIFIC:
* ChronoBankPlatform
name::
* McsEngl.chbctp.ChronoBankAssetInterface@cptIt,
contract ChronoBankAssetInterface {
function __transferWithReference(address _to, uint _value, string _reference, address _sender) returns(bool);
function __transferFromWithReference(address _from, address _to, uint _value, string _reference, address _sender) returns(bool);
function __approve(address _spender, uint _value, address _sender) returns(bool);
function __process(bytes _data, address _sender) payable {
throw;
}
}
name::
* McsEngl.chbctp.ChronoBankAssetProxyInterface@cptIt,
contract ChronoBankAssetProxyInterface {
function __transferWithReference(address _to, uint _value, string _reference, address _sender) returns(bool);
function __transferFromWithReference(address _from, address _to, uint _value, string _reference, address _sender) returns(bool);
function __approve(address _spender, uint _value, address _sender) returns(bool);
}
name::
* McsEngl.chbctp.ChronoBankPlatformInterface@cptIt,
contract ChronoBankPlatformInterface {
/**
* Returns asset balance for a particular holder id.
*
* @param _holderId holder id.
* @param _symbol asset symbol.
*
* @return holder balance.
*/
function _balanceOf(uint _holderId, bytes32 _symbol) returns(uint);
/**
* Returns current address for a particular holder id.
*
* @param _holderId holder id.
*
* @return holder address.
*/
function _address(uint _holderId) returns(address);
function reissueAsset(bytes32 _symbol, uint _value) returns(bool);
}
name::
* McsEngl.chbctp.ERC20Interface@cptIt,
contract ERC20Interface {
event Transfer(address indexed from, address indexed to, uint256 value);
event Approval(address indexed from, address indexed spender, uint256 value);
function totalSupply() constant returns (uint256 supply);
function balanceOf(address _owner) constant returns (uint256 balance);
function transfer(address _to, uint256 _value) returns (bool success);
function transferFrom(address _from, address _to, uint256 _value) returns (bool success);
function approve(address _spender, uint256 _value) returns (bool success);
function allowance(address _owner, address _spender) constant returns (uint256 remaining);
}
name::
* McsEngl.chbctp.ExchangeInterface@cptIt,
contract ExchangeInterface {
function setPrices(uint _buyPrice, uint _sellPrice) returns(bool);
}
name::
* McsEngl.chbnet'ChronoMint@cptIt,
* McsEngl.ChronoMint@cptIt,
_DESCRIPTION:
Control panel for ChronoBank and Labour-Offering Companies.
[https://github.com/ChronoBank/ChronoMint]
name::
* McsEngl.chbnet'ChronoWallet@cptIt,
* McsEngl.ChronoWallet@cptIt,
_DESCRIPTION:
Secure wallet for storing tokens
[https://github.com/ChronoBank/ChronoWallet]
name::
* McsEngl.chbnet'Exchange-Value-Token (chbevt)@cptIt,
* McsEngl.chbevtkn@cptIt,
* McsEngl.chbtoken@cptIt,
* McsEngl.chronobank-exval-token@cptIt,
_SPECIFIC:
* LH-evtoken#ql:idChblht#,
* TIME-evtoken#ql:idChbtmt#
name::
* McsEngl.chbevt.LH-token (chblht)@cptIt,
* McsEngl.chblht@cptIt,
* McsEngl.mnyLh@cptIt,
* McsEngl.labour-hours-cryptocurrency@cptIt,
* McsEngl.money.blockchain.labour-hours@cptIt,
* McsEngl.money.cryptocurrency.LH@cptIt,
* McsEngl.money.LH@cptIt,
_DESCRIPTION:
One of the major drawbacks in a debt-backed currency system is the possibility of backers (LOC#ql:idChbwprLOC# in our case) defaulting on their contractual obligations.
[idChbwpr232]
===
The first stage of our project is to create the financial backbone of ChronoBank.io: national Labour-Hour (LH) tokens.
LH are linked to average hourly wages in the host country and are backed by a real labour force from big recruitment and labour-hire companies.
Labour is abundant enough for everyone to have access to it, yet scarce enough to be valuable. It is the most tradeable resource in the real economy.
LH tokens will tokenise this resource. Because they are backed by real labour, they are absolutely inflation-proof and have next to zero volatility – in comparison to bitcoin and other cryptocurrencies.
This solution is far more sustainable than any of the fiat-pegged or backed coins that currently exist in the crypto market. LH tokens will be hyper-liquid and accessible 24/7 via the LH debit card.
[https://chronobank.io/]
name::
* McsEngl.chblht'Baker@cptIt,
_DESCRIPTION:
One of the major drawbacks in a debt-backed currency system is the possibility of backers (LOC#ql:idChbwprLOC# in our case) defaulting on their contractual obligations.
[idChbwpr232]
name::
* McsEngl.chblht'Issuance@cptIt,
Q: Who are the issuing labour-hire companies?
A: Chronobank selects labour hire/recruitment and HR companies based on their credibility, size, and financial performance, among other factors.
Please refer to our company selection methodology in our business description document, available on our website.
Initial list of companies who agreed to issue LH tokens:
Anderson Recruitment and Training Pty Ltd
http://www.andersonrecruitment.com.au
canderson@andersonrecruitment.com.au
Host Group/Host Labour Hire
http://www.hostaustralia.com.au
john.allery@hostaustralia.com.au
AES Labour Hire Pty Ltd
http://www.aesau.com.au
jammiek@aesau.com.au
Edway Labour Hire
http://www.edwaylabourhire.com.au
stan@edway.com.au
[https://blog.chronobank.io/chronobank-io-faq-4b920f003640#.sraeqe3iv]
name::
* McsEngl.chblht'Exchange-rate@cptIt,
Q: What will guarantee that LH value will stay stable relative to fiat, in the case of a massive short-sale attack by speculators?
A: To stop a possible short-sale attack by speculators, Labour Hour tokens will always be refundable at a small discount less the issuance fee. That will remove any motivation for any short-sale attack.
[https://blog.chronobank.io/chronobank-io-faq-4b920f003640#.sraeqe3iv]
name::
* McsEngl.chblht'Resource@cptIt,
_ADDRESS.WPG:
* https://etherscan.io/token/0x47dfa143923e3e0bd3c3fb6b70e0d2629eb4432d,
* {2017-05-03} ChronoBank starts issuing Labour Hour tokens: https://blog.chronobank.io/chronobank-starts-issuing-labour-hour-tokens-19311d03737b,
name::
* McsEngl.chblht.AGGREGATE@cptIt,
Q: What are the total number of LH tokens?
A: The total number of coins will always depend on the number of companies in the system and labour hours available in those companies that companies are able to fulfill.
[https://blog.chronobank.io/chronobank-io-faq-4b920f003640#.sraeqe3iv]
name::
* McsEngl.chbnet'Human@cptIt,
Sergenko.Sergei:
Chronobank CEO Sergei Sergienko,
The team features Luke Anderson, a PhD candidate in blockchains, and Adrian Manning, one of the developers of Zcash GPU miners.
[https://www.cryptocoinsnews.com/lifetime-might-become-money-ethereum-blockchain-thanks-startup/]
Q: Who is actually programming the smart contracts and wallets?
A: Smart contract architecture by Sigma Prime, Ethereum wallet by in-house developers, smart contract security audit by Mikko Ohtamaa (CTO at Revoltra).
Q: Could you tell us more about the ChronoBank staff and where the headquarters of the company is located?
A: Chronobank core team is based in Sydney, Australia. There are a few members of our team that are based all over the world.
[https://blog.chronobank.io/chronobank-io-faq-4b920f003640#.sraeqe3iv]
name::
* McsEngl.chbnet'LaborX (chblrx)@cptIt,
* McsEngl.LaborX@cptIt,
* McsEngl.laborX@cptIt,
* McsEngl.chblrx@cptIt, {2017-03-20}
_DESCRIPTION:
The heart of the ChronoBank project is the LaborX exchange: a decentralised marketplace for work opportunities.
Freelancers and businesses will be able to trade labour on a peer-to-peer basis, without the costs and frictions of using a traditional recruitment company.
The efficiencies this brings can be passed on to both parties, raising pay and lowering costs whilst simultaneously increasing quality of work.
[https://blog.chronobank.io/laborx-core-and-laborx-dapp-c4088a01f12#.5ctlxxa1z]
===
The second stage is to create LaborX, a decentralised marketplace where people in real-world professions will be able to sell labour-hours to anyone.
[https://chronobank.io//]
===
LaborX also introduces a decentralized reputation system that enables workers to be rewarded in line with their talent and experience.
[https://cointelegraph.com/news/how-ethereum-based-uber-of-time-chronobank-could-boost-cryptocurrency-adoption? {2017-01-22}]
name::
* McsEngl.chblrx'Attribute@cptIt,
chblrx'ledger:
is a publicly available database that holds information.
It will be implemented as a smart contract in Ethereum network.. 2
[https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf]
name::
* McsEngl.chblrx'LaborX-Core (chblxc)@cptIt,
* McsEngl.chblrx'core@cptIt,
* McsEngl.chblxc@cptIt, {2017-03-22}
_DESCRIPTION:
LaborX core is a complex system powered by the Ethereum network.
It contains all users’ public profiles, completed jobs with description, executor, status, and mutual ratings.
However, considering the system complexity, we have chosen to distinguish LaborX core from LaborX DApp.
[https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf]
===
this is a sub-system of the LaborX platform encapsulating the majority of the core inner functionality and blockchain-dependent logic. 2, 3, 6, 7
[https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf]
===
Contains all ratings and recommendations
Contains full job history
Contains all payment logic
Contains all profiles
Stores public profile data
Needs time for transactions to be mined
Is based on smart contracts
name::
* McsEngl.chblrx'LaborX-DApp (chblxd)@cptIt,
* McsEngl.chblrx'DApp@cptIt,
* McsEngl.chblxd@cptIt, {2017-03-22}
_DESCRIPTION:
LaborX dapp, meanwhile, can be considered the ‘frontend’ of the ChronoBank project or the front desk of the recruitment agency. Whereas LaborX core is based on Ethereum’s smart contracts, LaborX dapp is a client-side application written in Javascript. Its job is to communicate with the LaborX core and provide a user interface for workers and businesses seeking to post or accept jobs -- in the same way that a regular cryptocurrency wallet provides the functionality to interface conveniently with the blockchain.
Employers and employees, as well as TIME investors, will use the LaborX dapp. Employers will create jobs to their required specifications and filter prospective employees by their availability and skill set, whilst freelancers can use the dapp to view their profiles and ratings, and search the database for tasks they may wish to undertake (based on sector, location, pay and so on). TIME holders can use the dapp to lock their tokens to a mining contract, thereby receiving rewards.
It is therefore the LaborX dapp’s task to parse the information held in the Ethereum blockchain, return it in a useful format, and facilitate interaction with LaborX core -- enabling users to make the best choices with regards to the employment opportunities offered by ChronoBank.
[https://blog.chronobank.io/laborx-core-and-laborx-dapp-c4088a01f12#.5ctlxxa1z]
===
is an abbreviated form for decentralised application.
A DApp has its back-end code running on a decentralised peer-to-peer network.
Contrast this with an app where the back-end code is running on centralised servers.. 3–7
[https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf]
===
However, considering the system complexity, we have chosen to distinguish LaborX core from LaborX DApp.
LaborX DApp functionality will include interface for creating profiles, verification, evaluation, searching workers, concluding contracts etc (see Section 6 for full description of features).
===
Calculates and displays rating
Performs search over all completed jobs
Provides a user-friendly payment interface
Shows profile data in an informative way
Handles public and private data
Compensates LaborX response time by reactive and fast user interface
Is a client-side application written in JavaScript
If the client is not satisfied with the worker or their work they can cancel the job at any time.
Nevertheless, the client is required to pay a minimum of one hour (which is a minimal time unit that can be paid).
The client may then leave a negative recommendation and rating#ql:lbrx'rating# that will negatively flag the worker for future clients.
name::
* McsEngl.chblrx'Worker (employee)@cptIt,
* McsEngl.chbworker@cptIt,
* McsEngl.chronobank'worker@cptIt,
* McsEngl.chblrxwkr@cptIt,
* McsEngl.chblrx'employee@cptIt,
* McsEngl.chblrx'worker@cptIt,
* McsEngl.chbwkr@cptIt,
_DESCRIPTION:
is a person that is assigned to fulfil client’s job and get paid for it. 2
[https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf]
name::
* McsEngl.chblrx'Compensation-per-hour (rate)@cptIt,
* McsEngl.chblrx'rate@cptIt,
_DESCRIPTION:
amount of money that will be paid hourly to a worker. 1, 2, 6, 7
[https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf]
===
It should be noted that client does not pay the worker’s transportation time and expenses.
Instead, they should be included in the worker’s individual rates.
name::
* McsEngl.chblrxwkr'Evaluation@cptIt,
For workers.
Benefits for workers are also significant.
Due to lower fees than in traditional labour hiring companies workers may ask for higher hourly rates.
The most skilled and responsible workers with the best ratings will be highly sought after and may, therefore, demand a higher hourly fee than their not-so-amazing colleagues.
For the first time in the labour hire industry, diligent and attentive workers will be rewarded for providing better services.
The decentralised nature of LaborX will not only guarantee that workers will get paid, but will enable real-time payment to the worker as the work is completed.
Since the system is fully automated, the workers will be able to plan their schedules corresponding to their preferences.
name::
* McsEngl.chblrxwkr'Profile@cptIt,
To achieve this, each worker will have a publicly
available blockchain profile containing their nickname
(first name and the first letter of their surname), small
photo, field(s) of work, skills, rating, rate, activity points,
approximate location, a list of completed jobs and payments.
Optionally, a worker may apply for a document
verification or a skill evaluation (see Sections 3, 6) which
will be reflected in his public profile and confirmed by the
electronic signature of the governing party. There will be
a data set which will never appear on the blockchain. This
includes, but is not limited to, the exact geolocation of the
client and the worker, additional private instructions for
the worker, document scans
name::
* McsEngl.chblrxwkr'Rating@cptIt,
_DESCRIPTION:
is an integer in a range from 1 to 10 (where 1 is a disaster and 10 is perfect) which measures the quality of work done by a worker.
LaborX uses rating to select workers for a job.. 2–6
[https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf]
===
A negative rating will also affect evaluator’s reputation.
chblrx'evaluator:
a highly rated worker with lots of experience and reputation which prove they are a master in their field of work and thus can verify skills of other workers. 2, 5
[https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf]
Evaluation by Clients. Any verified client may
advertise individual worker’s skills after completing
the job if some of them are exceptional. This
information would be used to separately promote
the workers who are constantly rated 10/10.
chblrx'verificator:
a worker with flawless reputation who offers services of verification for documents and identity of other entities. 2, 5
[https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf]
===
Verification. Entities with high reputation could
serve as verification hubs and be paid for their
services by workers. They will check that worker’s
documents correspond to the worker’s identity,
scan documents, publish document LaborX core
in the blockchain and confirm this action by signing
the hashes with their digital signature (see
Section 7 for more information).
name::
* McsEngl.chblrx'Employer (client)@cptIt,
* McsEngl.chbemployer@cptIt,
* McsEngl.chronobank'employer@cptIt,
* McsEngl.chblrxemr@cptIt,
* McsEngl.chblrx'employer@cptIt,
* McsEngl.chblrx'client@cptIt,
_DESCRIPTION:
is a person that has some work and needs to get it done.
Client posts a job and pays for it. 2
[https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf]
name::
* McsEngl.chbemr'Evaluation@cptIt,
For clients.
There are numerous benefits for clients.
Because of smaller mediator fees than in traditional labour hiring companies, the resulting work price will be lower.
Decentralisation of the service makes it fast, reliable, secure, and permanently available.
A public worker rating system ensures that clients are seeing profiles of real workers along with their unique histories and therefore genuine ratings.
The ability to pay with a variety of digital tokens makes the system universal and not tied to any particular country/region.
Furthermore, LaborX will implement an easy to use interface, paying serious attention to UX.
name::
* McsEngl.chbemr'Searching-for-worker@cptIt,
6.2. Workers selection
According to the current model, the governing smart
contract returns a selection of workers that fit the criteria
of a given job posted by a client. The LaborX DApp takes
preference of workers who have more completed jobs and
higher ratings. The system may grow such that the ratio
of workers to jobs becomes quite large. It is therefore
important that the LaborX DApp does some advanced
filtering. This means that the application should not show
all workers capable of performing a given job, instead select
only several of the available best workers with varying rates
and ratings. In this way, the most competent workers will
get more work and will be paid more for their reputation.
Clients may also use different custom filters that will help
them to find the most fitting worker to suit their needs.
They may also pick specific workers they are already familiar
with. The application will also utilise smart filtering to
minimise the worker intersection between clients. This is
crucial for the system, especially when considering similar
jobs.
name::
* McsEngl.chbemr'Protection@cptIt,
_DESCRIPTION:
However, protections are also built in for the client in the case of poor performance on the part of the worker. Clients can cancel work at any time, though they will always have to pay for time so far worked. If it turns out that a worker has not spent the time well and has been bad value for money, the employer can end the contract and leave negative feedback for the worker. They will need to pay for a minimum of one hour of the worker’s time before doing this, to prevent malicious individuals from trying to ruin a worker’s reputation at no cost to themselves.
[https://blog.chronobank.io/laborx-getting-paid-on-time-every-time-364700e3709#.fa8sj2r0p]
name::
* McsEngl.chblrx'Trust-system@cptIt,
_DESCRIPTION:
Trust, in such community services, mainly addresses whether a remote user -- called a trustee -- behaves as expected by an interested user (the trustor), through the activity of other users called recommenders. A ‘trust graph’ consists of a trustor, a trustee, recommenders, and the trust relationships among them.
[https://blog.chronobank.io/how-laborxs-reputation-system-will-work-478cdd7aab8e#.vd7xhx1px]
name::
* McsEngl.chblrx'Recommender@cptIt,
* McsEngl.chblrx'recommender@cptIt,
_DESCRIPTION:
In LaborX, in addition to the commonly-used roles of Worker and Client, we have introduced another three roles -- Evaluator, Verifier and Provider. Together, these will serve the purpose of recommenders.
[https://blog.chronobank.io/how-laborxs-reputation-system-will-work-478cdd7aab8e#.vd7xhx1px]
name::
* McsEngl.chblrx'Evaluator (chblrxevr)@cptIt,
_DESCRIPTION:
The Evaluator. The highest-ranked members of a community will be able to evaluate and confirm relevant skills of workers, building a chain of trust. In this way, clients can be sure that the assigned worker has all the required skills for completing the job. Workers will be required to have a high rating and sufficient activity points in order to become an Evaluator. Evaluators may verify and endorse skills of other workers, ensuring clients have a more accurate description of their potential workforce. Workers with skills endorsements will typically have a greater chance of being selected for any given job by the LaborX core. After performing a worker’s skill assessment, the Evaluator publishes a record on the blockchain. The Evaluator’s profile displays statistics of appraised workers, and the Evaluator’s reputation among LaborX users will depend on this.
[https://blog.chronobank.io/how-laborxs-reputation-system-will-work-478cdd7aab8e#.vd7xhx1px]
name::
* McsEngl.chblrx'Evaluator (chblrxvfr)@cptIt,
_DESCRIPTION:
The Verifier. This is a worker who offers services to verify clients and workers in a particular region. The fundamental role of a Verifier is to check required documents for their respective areas, such as work permits, certificates, injury insurance or other types of relevant cover. These entities are essential for ensuring local laws are observed, enhancing security, and potentially minimising spam issues. Both parties (clients and workers) may choose either a single Verifier or multiple Verifiers to review their documents, based on their rating and popularity. Each worker has a public profile and private data. The public profile is readily available on the blockchain and is accessible to everyone. Private data is verified and electronically signed by a Verifier. It is only available to a client after they enter into a contract with the worker.
[https://blog.chronobank.io/how-laborxs-reputation-system-will-work-478cdd7aab8e#.vd7xhx1px]
name::
* McsEngl.chblrx'Provider (mediator)@cptIt,
* McsEngl.chbmediator@cptIt,
* McsEngl.chbprovider@cptIt,
* McsEngl.chblrx'provider@cptIt,
* McsEngl.labor-hiring-company@cptIt,
* McsEngl.chblrx'mediator@cptIt,
_DESCRIPTION:
is an entity which offers its services to connect clients and workers through a job board because of legal, security, or spam issues.
Anyone can become a provider, and both parties (a client and a worker) could choose which providers they trust.
Providers get paid for their services by receiving a percentage of job payment fees. 2, 3, 5–7
[https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf]
Provider receives payment only for completed jobs posted on provider’s job board.
name::
* McsEngl.chblrx'Job-board@cptIt,
chblrx'job_board:
is a publicly available database managed by the creator.
It will be implemented as a smart contract in Ethereum network.
More information in Section 6. 3, 5, 6
[https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf]
===
Each LaborX provider will be able to set cryptocurrencies that will be permitted for payments on their job boards.
Clients and workers who choose a job board, agree to use one of the supported methods of payment.
A client would be capable of searching through the list of workers in job boards or choosing a familiar worker.
name::
* McsEngl.chblrx'Job@cptIt,
chblrx'job:
is some work or task to get done.
Job can be a list of tasks but all within one field of work. 2
[https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf]
===
A job object (the programmatic object relating to a real-world job) will contain a location, provider used and work description.
The work description includes attributes such as field of work, job due date, address of ERC20 token contract (that will be used for payment), required skills, and further optional job-specific requirements.
name::
* McsEngl.chblrxjob'Location@cptIt,
_DESCRIPTION:
A location is also a selectable parameter that will typically represent a city/region.
If a city/region is large, then a district/sub-region may be specified.
A city/region includes all of its districts/sub-regions.
A location is used to map workers to nearby clients.
Precise addresses (for job locations) will be revealed to workers once the job has been mutually agreed on and solidified by the smart contract.
name::
* McsEngl.chblrxjob'Work-description@cptIt,
name::
* McsEngl.chblrxjob'Time-due@cptIt,
_DESCRIPTION:
A job due date can be a present or
future time. If the current time is selected, then LaborX
returns all currently available workers ready to start a
work now. If instead a future time was chosen, then the
system will find workers available to work at the chosen
time. If several clients wish to book one particular worker
for the same period, the system prioritises clients based on
the time when clients offered the work. Once the worker
accepts the job, the smart contract will publicly mark the
worker as busy, preventing further bookings in that period.
name::
* McsEngl.chblrx'Rating-system@cptIt,
* McsEngl.chblrx'metrics@cptIt,
_DESCRIPTION:
For every worker and client there are two metrics called rating and activity points.
The first describes how well a worker performs their duties and is dictated by clients.
The second is a point system based on all LaborX activity.
[https://blog.chronobank.io/how-laborxs-reputation-system-will-work-478cdd7aab8e#.vd7xhx1px]
name::
* McsEngl.chblrx'Activity-points@cptIt,
* McsEngl.chblrx'activity-points@cptIt,
_DESCRIPTION:
is an integer in a range of 1 to infinity which measures positive contribution to LaborX ecosystem.
The more activity points the user has, the more advanced actions they can perform.
See the full list in Table 2. 2, 3, 5
[https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf]
Activity points are used only in the LaborX DApp and have a crucial security role by limiting the amount of available functionality to newcomers.
This limits threats such as spamming, posting advertisements with ambiguous links, or evildoers trying to overload the system with an infinite job posting.
Every new user begins with a single activity point which will automatically increase when performing various actions inside the app (see Table 2).
An alternative way to gain activity points is by verifying one’s identity with various verificators or by passing skill assessment with an evaluators.
The activity points count will always be greater
than or equal to 1.
An example of activity point elevators are given in Table 2.
Some of the proposed features that will require some amount of activity points is given in Table 3.
The listed values in these tables are examples only and may change during the implementation and system testing period.
Action AP effect
Fill in profile information +5 points
Upload a photo after registration +5 points
Complete a job, get rated N
(1 <= N <= 10) +N points
Pay a worker for a job, get rated N 10+N points
Pass verification +10 points
Pass evaluation +10 points
Flag content which is later removed +5 points
Flag content which is later approved -1 points
Post content which is later removed -15 points
Table 2. Actions that affect activity points
Action AP required
Post to a job board 10 points
Vote up 25 points
Post links 25 points
Flag content for review 25 points
Vote down 125 points
Add items to global job board catalog 125 points
Table 3. Actions that require activity points
name::
* McsEngl.chblrx'Rating@cptIt,
_DESCRIPTION:
is an integer in a range from 1 to 10 (where 1 is a disaster and 10 is perfect) which measures the quality of work done by a worker.
LaborX uses rating to select workers for a job.. 2–6
[https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf]
===
A negative rating will also affect evaluator’s reputation.
name::
* McsEngl.chblrx'Wallet@cptIt,
_DESCRIPTION:
LaborX is a multi-currency service that will support any token that complies with the ERC20 standard[2] including, but not limited to, Labor Hour tokens.
A simple multi-currency wallet capable of receiving and sending any supported ERC20 token will be integrated into the LaborX platform.
Users will be able to pay and get paid by tokens they choose from a list of supported on job board tokens.
Providers may list local currencies, allowing communities to pay for jobs in unusual digital assets, should both the client and the worker accept the currency by selecting the job board.
As mentioned in the previous section, the LaborX system will deduct 1%2 from each completed job part of which will go as a revenue to TIME token holders and other part to providers for their services.
Provider receives payment only for completed jobs posted on provider’s job board.
name::
* McsEngl.chblrx'Resource@cptIt,
_ADDRESS.WPG:
* https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf,
name::
* McsEngl.chblrx'Messaging@cptIt,
_DESCRIPTION:
6.5. Messaging
LaborX will use a messaging system with an underlying
protocol like Whisper[6], enabling client and worker to
establish an encrypted connection. These messages could
be used to exchange job details, address, confidential instructions,
etc. The exact realisation will be decided at
the time of development (specified in the LaborX road
map) taking into account the potential research and new
possibilities that will be available in 2017.
name::
* McsEngl.chblrx'Searching@cptIt,
_DESCRIPTION:
6.4. Search
High load testing and analysis would be performed
while developing LaborX to determine exact implementation
and architecture of the search system. The main
part of a search logic should be performed in the LaborX
LaborX core. Only Ethereum transactions that write to
blockchain have gas limit and cost Ether. The search operation
is read-only, therefore it would perform computations
on user’s Ethereum node and will not require paying Ether.
A worker-to-job matching will include complex queries and
therefore require a significant amount of computational
power of the machine where Ethereum node software is
running.
Therefore LaborX DApp could handle part of the filtering and caching logic on client’s side.
This approach will significantly improve the user experience.
name::
* McsEngl.chblrx'Matching@cptIt,
_DESCRIPTION:
It will be capable of automatically matching available workers to corresponding jobs according to their location, field of work, skills, and reputation.
name::
* McsEngl.chbnet'Organization (chbogn)@cptIt,
name::
* McsEngl.chbogn.Exchange@cptIt,
FAQ:
Q: Can I redeem LH tokens to USD or EUR if so how?
A: Redeeming will be either from an ATM or at any exchange that will trade LH
[https://blog.chronobank.io/chronobank-io-faq-4b920f003640#.sraeqe3iv]
name::
* McsEngl.chbogn.Merchant@cptIt,
FAQ:
Q: What will I be able to buy with LH tokens? Which firms will accept them in exchange of (physical) goods?
A: We will issue LH denominated visa/mastercard cards, will work similar to bitcoin cards. We will be converting LH directly into fiat at the start with a small spread. So technically, you will be able to buy anything you buy now, at any organisation you buy it from now.
[https://blog.chronobank.io/chronobank-io-faq-4b920f003640#.sraeqe3iv]
name::
* McsEngl.chbnet'Wallet@cptIt,
name::
* McsEngl.chbnet'ChronoWAVES@cptIt,
_DESCRIPTION:
Waves is a natural partner for ChronoBank due to its straightforward and user-friendly token-creation facilities. ‘We consider every blockchain with CATs (Custom Application Tokens) functionality as a potential infrastructure for LH tokens,’ comments ChronoBank’s lead developer. ‘We have recently started development of ChronoWAVES and have been in touch with Waves’ developers from the beginning, familiarising ourselves with all the technical details of the platform. ChronoWAVES will be an advanced lite wallet implemented in Javascript and fully compatible with the original Waves GUI.’
In addition to basic features such as blockchain data validation on the client side and multi-address accounts, the Waves version of the ChronoWallet will be tightly integrated with ChronoBank’s services, natively supporting LH tokens issued on the Waves blockchain. A key feature to be used by the wallet is Waves’ decentralised exchange (DEX), soon to be released on mainnet.
‘After release it will allow trades to be settled on the blockchain and we are going to utilise this fully for the exchange of Labour Hours. Additionally, a token-swap feature will offer potential integration of Ethereum tokens with the Waves blockchain. We definitely plan to share our contribution in the JavaScript infrastructure for Waves Platform with the community. We see it as an advanced JavaScript framework similar to the web3.js one that exists for the Ethereum project.’
[https://blog.chronobank.io/chronobank-partners-with-waves-to-create-chronowaves-wallet-c6e24be533a4?goal=0_c14d97ba45-da6d178ca4-32550077#.v6d9i1dc5]
name::
* McsEngl.chbnet'Resource (chbrsc)@cptIt,
* McsEngl.chbresource@cptIt,
_ADDRESS.WPG:
* https://github.com/ChronoBank,
===
* {2017-03-13} https://blog.chronobank.io/laborx-getting-paid-on-time-every-time-364700e3709#.fa8sj2r0p
* {2017-03-08} ChronoBank’s TIME launches on four exchanges
https://blog.chronobank.io/chronobanks-time-launches-on-four-exchanges-71c2bb5c989a#.wnktm5kng,
* {2017-03-04} TIME token reward model https://blog.chronobank.io/time-token-reward-model-1c3508208791#.l64hi7pdn,
=== COMMUNITY:
* https://chronobank.slack.com//
* https://blog.chronobank.io//
name::
* McsEngl.chbrsc'ChronoBank.io-website@cptIt,
* McsEngl.ChronoBank.io@cptIt,
* McsEngl.ChronoBank-website@cptIt,
_DESCRIPTION:
ChronoBank.io is an ambitious and wide-ranging blockchain project, aimed at disrupting the HR/recruitment/finance industries in a similar way to how Uber disrupted the taxi business and how Upwork represented an evolution in freelancing.
[https://chronobank.io//]
name::
* McsEngl.chbnet'DOING@cptIt,
name::
* McsEngl.chbnet'SERVICE@cptIt,
* McsEngl.chbsvc@cptIt, {2017-03-20}
* McsEngl.ChronoBank-service@cptIt,
_DESCRIPTION:
The ChronoBank project aims to make short-term employment as accessible and rewarding as long-term employment, giving workers the flexibility to determine their own schedules whilst being paid a fair rate for their time, expertise and reputation.
[https://blog.nem.io/the-chronobank-project/]
name::
* McsEngl.chbnet.EVOLUTING@cptIt,
{time.2016-12-15-2017-02-14}
=== CROWDSALE:
- 5,416 BTC
- 2,985 participants
[https://chronobank.io/]
Q: How long will it take to go from where Chronobank is now to where it needs to be to start challenging Labour Hire and Recruitment companies?
A: We anticipate this time period to be between a year and year and a half from February 2017
[https://blog.chronobank.io/chronobank-io-faq-4b920f003640#.sraeqe3iv]
name::
* McsEngl.bcnnet.Dfinity (DFNnet)@cptIt,
* McsEngl.bcnnet.dfinity@cptIt,
* McsEngl.dfnnet@cptIt,
_DESCRIPTION:
DFINITY is conceived as a compatible sister network for Ethereum that extends the ecosystem by intoducing governance by an omnipotent distributed intelligence called the "Blockchain Nervous System".
The traditional "Code is Law" paradigms of Bitcoin and Ethereum are made subject to the distributed intelligence, which can also upgrade the protocol, update economic parameters and run special smart contract code that uses privileged instructions to reverse hacks such as The DAO.
The DFINITY project also represents the culmination of several years research into new cryptography and network protocols referred to collectively as "crypto:3" that vastly improve the performance of the virtual computer produced and lay a roadmap to infinite scalability and a true "decentralized cloud" where smart contracts can implement open versions of mainstream services such as Uber and high load business systems - exciting benefits Ethereum may be able to gain too by backporting selected techniques.
Special properties granted by crypto:3 also make it possible for DFINITY private clouds to host smart contracts that can call into smart contracts on the public DFINITY network.
[https://dfinity.network/donate]
_GENERIC:
* Blockchain-network-with-builtin-decentralized-governance#ql:idBcnnetBig#,
* program-blockchain-network#ql:idBcnnetPgm#
name::
* McsEngl.dfnnet'Protocol@cptIt,
name::
* McsEngl.dfnprl'Threshold-Relay@cptIt,
_DESCRIPTION:
Threshold Relay chains increase security while pushing speed 50X faster than Ethereum today, greatly improving the user experience Dapps provide.
[https://medium.com/dfinity-network-blog/the-dfinity-blockchain-nervous-system-a5dd1783288e#.n8qx1rump]
name::
* McsEngl.dfnprl'USCID (Unique State Copy IDs)@cptIt,
name::
* McsEngl.dfnnet'Governance-system@cptIt,
* McsEngl.Blockchain-nervous-System-of-Dfinity@cptIt,
* McsEngl.dfnbns@cptIt,
_DESCRIPTION:
BLOCKCHAIN NERVOUS SYSTEM
Governance by a distributed intelligence
Decentralized Intelligence
DFINITY is a different kind of decentralized world compute platform. It is platform managed by a decentralized intelligence integrated into its systems that can make arbitrary changes. This acts to mitigate misuse, protect users, fix problems, optimize network configuration and seamlessly upgrade its protocols.
A recent blog post explains how the Blockchain Nervous System works. The system depends upon human-controlled "neurons" operated by special client software. These follow each other and cascade to decisions. Neurons are created by depositing dfinities and earn rewards for performance of voting services. While the expertise within the crowd is leveraged, follow relationships exist at the edges of the network making the decision process unknowable, protecting participants.
Protecting Users
In DFINITY the "Code is Law" is contingent upon the decisions of the nervous system. As we have seen, with the recent Bitfinex theft and hack of The DAO, hackers steal keys and can sometimes break smart contract systems with design flaws. A key purpose of the BNS is to return funds where possible, and reverse the damage of hacks. The BNS can also fix systems that have simply failed due to engineering errors, such as a complex autonomous system that has deadlocked.
This increases comfort for consumers and businesses alike, many of whom will be unable to adopt decentralized systems without such protection and recourse.
Accelerating Technical Evolution
In systems such as Bitcoin and Ethereum, upgrades to the protocol occur as a result of contentious and disruptive "hard forks". In DFINITY there is no equivalent notion and the BNS upgrades the protocol transparently on a regular basis, quickly introducing fixes and optimizations and driving network evolution forward as quickly as possible.
The process is simple: the network client is wrapped by a reverse proxy wrapper that systems and Dapps interact with. The wrapper is aware of the BNS, and when instructed upgrades the client while buffering requests, making upgrades transparent.
Adaptive Network Policy
In DFINITY economic parameters such as "mining rewards" or the cost of a "mining identity" are set dynamically by the Blockchain Nervous System, rather than according to a fixed schedule as in a traditional network. The BNS ultimately seeks to increase the value of "dfinities" and indirectly to drive adoption of the network. This invisible market hand will drive the BNS to strike more sophisticated and beneficial economic balances.
[https://dfinity.network/]
===
To compliment Ethereum and truly broaden the options the ecosystem offers, DFINITY introduces the fundamental difference of governance by a novel decentralized decision-making system called the “Blockchain Nervous System” (or “BNS”).
[https://medium.com/dfinity-network-blog/the-dfinity-blockchain-nervous-system-a5dd1783288e#.n8qx1rump]
name::
* McsEngl.dfngov'Neuron@cptIt,
name::
* McsEngl.dfnnrn'Controller@cptIt,
* McsEngl.dfinity'neuron-controller@cptIt,
name::
* McsEngl.dfnnet'Resource@cptIt,
_ADDRESS.WPG:
* https://dfinity.network//
* {2017-01-21} https://medium.com/dfinity-network-blog/the-dfinity-blockchain-nervous-system-a5dd1783288e#.n8qx1rump,
name::
* McsEngl.bcnnet.Emercoin (EMCnet {2013-12-11})@cptIt,
* McsEngl.emercoin-network@cptIt,
* McsEngl.netEmc@cptIt,
* McsEngl.emercoin-network@cptIt,
* McsEngl.netEmc@cptIt,
_DESCRIPTION:
A World of Blockchain Services
Emercoin's decentralized blockchain is used by a growing number of innovative services. Official services include EMCSSH (PKI management for system admins), EMCLNX (text advertising network), EMCSSL (passwordless website logins), InfoCard (business card / profile management), Magnet (torrent links), EMCTTS (digital timestamps) and EMCDPO (proof of ownership). For more information, see the "Technology" and "Guides" sections of this website.
[http://emercoin.com/getstarted]
name::
* McsEngl.emcnet'Blockchain@cptIt,
name::
* McsEngl.emcbcn'Block-explorer@cptIt,
_ADDRESS.WPG:
* https://emcblock.info//
* https://emercoin.mintr.org//
* BlockH1 https://emcblock.info/block/00000000cd06950728b4e60a852a2f09d564da3ee05fa69f8db9ee3d119c23c6,
name::
* McsEngl.emcnet'Consensus-evt (EMCcevt)@cptIt,
* McsEngl.mnyEmc@cptIt,
name::
* McsEngl.emccevt'Exchange-rate (emcexr)@cptIt,
_ADDRESS.WPG:
* https://coinmarketcap.com/currencies/emercoin//
name::
* McsEngl.emccevt'Geting@cptIt,
_DESCRIPTION:
EMC is the currency which is used to transact on the Emercoin network and pay network fees for blockchain services. The easiest way to obtain EMC is to buy it on an exchange, however EMC can also be earned through mining or by selling goods and services.
[http://emercoin.com/getstarted]
name::
* McsEngl.emcnet'DOING@cptIt,
name::
* McsEngl.emcnet'Service@cptIt,
_DESCRIPTION:
In addition to being used for the payment of goods and services, Emercoin provides a platform for a wealth of novel applications such as decentralized domain names and an advertising network. How you decide to use Emercoin is really up to your imagination.
[http://emercoin.com/getstarted]
name::
* McsEngl.bcnnet.EOS@cptIt,
* McsEngl.DccEos@cptIt,
* McsEngl.Eos-net@cptIt,
_DESCRIPTION:
Decentralized applications on WebAssembly
_ADDRESS.WPG:
* https://steemit.com/trending/eosio,
* https://steemit.com/eosio/@dan/eos-io-development-update,
* Grigg.Ian: http://iang.org/papers/EOS_An_Introduction.pdf,
* https://www.steem.center/index.php?title=EOS,
* https://steemit.com/eos/@trogdor/introduction-to-eos-the-epic-blockchain-operating-system,
=== community:
* https://forums.eosgo.io/
===
* dapp-database: https://docs.google.com/spreadsheets/d/1gaQrP0fsssLE_yUXqhjwdBQPrUKmnAWcVc0STU5qnEY/edit#gid=0,
* https://steemit.com/eos/@dan/response-to-vitalik-buterin-on-eos,
Dawn 3.0 Alpha Announcement
EOS.IO contact@block.one
Dawn 3.0 Alpha Announcement
As many in the EOS.IO development community are aware, we've been working since December on merging two lines of development, Dawn 2.x and Dawn 3.0. The merged code base is now stable enough to make public as an Early Alpha and will now become our Github master branch. The prior master will be renamed “dawn-2.x” and will continue to be available as a non-master branch.
Community developers will notice that the next time they “git pull” from Master, they will obtain the new Dawn 3.0 code. Those wishing to continue to pull the Dawn 2.x code that connects to the current TestNet can do so by following instructions in the new readme.md, being made available at the same time as the re-mastering.
Please note that the Dawn 3.0 code is still in Early Alpha and is not compatible with the current block.one-provided public TestNet; it will not be available in a public TestNet until the end of Q1 2018. In the interim, developers may create their own testnets with the new Dawn 3.0 code. As a reminder, Dan Larimer and the development team have changed the way we forecast development. This means we won't be announcing the date for the Dawn 3.0 Testnet until the timeline is close enough for us to have high confidence in its capabilities.
The current public TestNet at “https://testnet1.eos.io” will continue to run the Dawn 2.x software until the release of the Dawn 3.0 Testnet, and will then be retired.
Smart contracts written for the Dawn 2.x codebase will need to be revised to work on the new 3.0 codebase and take advantage of the new features.
Major changes in Dawn 3.0 include changing “eos” to “eosio” in all locations throughout the code. We have also renamed "message" to "action", and removed the need for developers to manually specify 'scope'; all scope specification is now automated.
Additional new features in the Dawn 3.0 Alpha Release include: deferred transactions, staking pools, a new currency contract, and a new emerging token standard. A complete list of new features will be included in the 3.0 Final Release notes, expected by the end of Q1 2018. A complete list of EOS.IO Software Releases can be found here:
https://github.com/EOSIO/eos/wiki/Releases
Block.one {2018-01-26}
name::
* McsEngl.Eos-net'EOS-token@cptIt,
_DESCRIPTION:
Having it staked allows you the rights to vote and also keeps it safe as it is “locked” and you will have 72hrs to act if anyone scams you. Staked EOS can not be used to transact or utilize for any purpose other than voting and building upon via the EOS blockchain.
[https://www.reddit.com/r/eos/comments/8vulpc/how_to_keep_eos_unstacked_or_stacked_on_cpu_net/]
_DESCRIPTION:
Unstaked u can move it around and transact with ur EOS as it is basically “unlocked”.
[https://www.reddit.com/r/eos/comments/8vulpc/how_to_keep_eos_unstacked_or_stacked_on_cpu_net/]
name::
* McsEngl.Eos-net'wallet@cptIt,
You can use POPULAR wallets like:
GreyMass https://github.com/greymass/eos-voter/releases
SimplEOS https://github.com/eosrio/simpleos/releases
EOS Tool Kit + Scatter (Chrome plugin) https://github.com/generEOS/eostoolkit
https://github.com/EOSEssentials/Scatter
name::
* McsEngl.Eos-app.Eosdac@cptIt,
* McsEngl.Eosdac@cptIt,
name::
* McsEngl.Eoddac'core-principles (code-of-conduct)@cptIt,
eosDAC Core Principles
(Code Of Conduct)
Excellence of Service Provision
The primary objective of eosDAC is to ensure that it is able to continuously produce blocks required by EOS.IO software driven blockchains.
Openness and Transparency
All decisions made by the eosDAC governance structures and all operations of eosDAC will be open and transparent.
Support of EOS Communities Worldwide
We want EOS.IO blockchains to flourish so we will engage with EOS communities with a view to initiating and supporting projects that benefit all EOS.IO blockchain communities. This will include tools for other DACs.
Fairness
eosDAC will treat all members fairly and reward contributions appropriately. No one member should have less information about a decision than others.
Independence
eosDAC will not seek any significant stake in, or undue influence over, other block producers. It will also take appropriate measures to protect its own independence.
Electoral Fraud
eosDAC will never provide payment for votes from EOS token holders.
[https://eosdac.io/]
name::
* McsEngl.Eosdac'constitution@cptIt,
_ADDRESS.WPG:
* https://github.com/eosdac/constitution/blob/master/constitution.md
CONSTITUTION of eosDAC
[A decentralized autonomous community]
In this Constitution, if not inconsistent with the context, the words and expressions shall bear the meanings set opposite them respectively.
1.1 Registration means the process prescribed by the DAC, pursuant to and/or in accordance with the Constitution, whereby DAC Tokens are activated or enabled through the use of prescribed software, as a method by which, and for the purposes of, accepting a DAC Token and constituting the holder thereof as a Member of the DAC and subject to the Constitution and the Terms and Conditions, to the extent of such DAC Tokens held from time to time
1.2 Blockchain or "distributed ledger technology" means a consensus of replicated, shared and synchronized digital data geographically spread across multiple sites, countries and institutions
1.3 Constitution This Constitution as originally framed or as from time to time amended, restated, supplemented or otherwise modified in accordance with the Constitution
1.4 Eosdac'Custodian means a member of the Custodian Board
1.5 Eosdac'Custodian_Board or "Board"means the representative and governance board of the DAC that, save and except for the Genesis Board, shall consist of a maximum of twelve (12) persons appointed by the Members in accordance with the provisions of the Constitution, which Custodian Board shall be first constituted upon the transfer of the DAC Tokens onto an EOSIO blockchain and the initialization of a voting Dapp, and which Board shall have such powers and duties as are set out in the Constitution
1.6 Custodian Proposal means a proposal submitted by a Custodian to the Custodian Board for consideration and determination by the Custodian Board
1.7 DAC the eosDAC decentralized autonomous community of Members governed by and administered in accordance with the terms and conditions of the Constitution, which community of Members shall be collectively referred to as the "eosDAC"
1.8 DAC Token means an eosDAC Token, the acceptance of which shall constitute the holder thereof as a Member of the DAC, represent the membership of such holder of the DAC and facilitate the automated governance of the DAC, all subject to and in accordance with the provisions of the Constitution
1.9 DAPP means a decentralized application running on a Blockchain
1.10 Extraordinary Resolution means a resolution, determination or decision consented to by not less than 83% of the Custodians constituting the Custodian Board casting votes on such resolution, determination or decision
1.11 Genesis Member means BlockMaker Ltd, a company duly incorporated under the Anguilla International Business Companies Act (c. I20)
1.12 Genesis Board means BlockMaker Ltd, in the capacity of, and which shall be deemed, the Custodian Board pending the constitution of the first Custodian Board pursuant to and in accordance with the Constitution
1.13 Member means a member of the DAC, entitled, qua Member, to all the benefits and subject to all the obligations set out in the Constitution
1.14 Nomination Directive means rules and regulations, approved by Special Resolution, as amended, restated, supplemented or otherwise modified from time to time, prescribing the procedure, qualifications (including staking) and mechanism for the nomination, election and appointment of Custodians to the Custodian Board
1.15 Person means an individual, a corporation, a trust, the estate of a deceased individual, a partnership or an unincorporated association of persons
1.16 Proposal means a proposal submitted by a Member to the Custodian Board for consideration and determination by the Custodian Board, in accordance with the provisions of the Constitution, and shall include but not be limited to proposals on bounties, technical choices, services providers, contingency levels and allocations of tokens raised through block production by or through the DAC
1.17 Quorum when used in relation to Members of the DAC means the minimum number of DAC Tokens linked to votes cast by Members, in relation to any matter prescribed by the Constitution to be subject to the determination by Members, required to render such vote valid, and when used in relation to the Custodian Board means the minimum number of Custodians present and able to cast votes, in relation to any matter prescribed by the Constitution to be subject to the determination by the Custodian Board, required to render such vote valid
1.18 Proposal Directive means rules and regulations, approved by Special Resolution, as amended, restated, supplemented or otherwise modified from time to time, prescribing the subject matter of, and the procedure, qualifications and mechanism for, the submission of Proposals by Members or Custodians to the Custodian Board for their consideration and determination
1.19 Resolution means a resolution, determination or decision consented to by a majority of Custodians of the Custodian Board casting votes on such resolution, determination or decision
1.20 Eosdac'Special_Resolution means a resolution, determination or decision consented to by not less than 75% of Custodians of the Custodian Board casting votes on such resolution, determination or decision
1.21 Stake when used in reference to the DAC tokens refers to the mechanism by which DAC tokens are rendered non transferrable by the holder thereof, and upon such terms (including slashing clauses) and for such period, as prescribed by any Nomination Directive, Proposal Directive or Voting Directive and/or pursuant to the Constitution
1.22 Terms & Conditions means the terms and conditions relating to the DAC and DAC Tokens, attached to the Schedule to this Constitution and incorporated into this Constitution and from time to time
1.23 Tokens means any cryptographically secured digital representation of a set of rights, including smart contracts, provided on a digital platform and includes any fractional part thereof
1.24 Token Distribution means the initial distribution of the DAC Tokens by the Genesis Member to specified persons, or their assignees or transferees, inviting such persons to accept and hold DAC Tokens, gratis, and to become members of the DAC
1.25 Eosdac'Voting_Directive means rules and regulations, approved by Special Resolution, as amended, restated, supplemented or otherwise modified from time to time, prescribing the subject matter of (where applicable), and the procedure, qualifications and mechanism for, voting by Members and Custodians, including but not limited to quorums, consensus and staking of DAC Tokens
1.26 Website means the website published and maintained by or on behalf of the DAC and hosted at https://eosdac.io/ or such other URL prescribed by Resolution.
1.27 Written or any term of like import includes words typewritten, printed, painted, engraved, lithographed, photographed or represented or reproduced by any mode of representing or reproducing words in a visible form, including telex, telegram, facsimile, cable or other form of writing produced by electronic communication
1.28 Whenever the singular or plural number, or the masculine, feminine or neuter gender is used in this Constitution, it shall equally, where the context admits, include the others
1.29 A reference in this Constitution to voting in relation to Members shall be construed as a reference to voting by Members to the extent of the number of DAC Tokens held by such Members, with the votes being allocated to the number of such DAC Tokens being counted as voted and not the number of Members who actually voted
1.30 A reference to money in this Constitution is, unless otherwise stated, a reference to the fiat currency of any nationality
2.1 The DAC shall be a decentralized autonomous community governed by this Constitution and administered through the medium of blockchain technology.
2.2 The DAC shall be founded on the following core principles:
2.2.1 Nurturing the Ecosystem: The primary objective of the DAC shall be to nurture and support the EOSIO ecosystem
2.2.2 Excellence of Service: DAC shall always strive to ensure that it is able to produce or procure the continuous production of blocks required by EOSIO software driven blockchains.
2.2.3 Openness and Transparency: All decisions made by the DAC governance structures and all operations of the DAC will be open and transparent.
2.2.4 Support of EOSIO Communities Worldwide: DAC shall engage with the communities, listen and support projects that benefit all EOSIO blockchain communities.
2.2.5 Fairness: DAC shall treat all members fairly, reward contributions appropriately and not seek unmerited profits. No one member should have less information about a decision than others.
2.2.6 Independence: DAC will not seek any stake in, or exert undue influence over, other block producers and shall take appropriate measures to protect its own independence.
2.2.7 Respect of the EOS Constitution: DAC shall respect the EOS blockchain(s) on which the DAC operates: To the extent that each EOSIO blockchain, for which DAC produces or procures continuous production of blocks, will have its own constitution or equivalent organizational instrument, DAC shall use its best efforts to adhere to such constitutions or organizational documents whilst acting in the interest of all chain token holders.
2.3 To the furthest extent permissible the provisions of the Constitution shall be interpreted in a manner consistent with the core principles.
3.1 Nature: DAC Tokens shall, upon registration, constitute and represent the holder thereof as a Member of the DAC, to the extent of DAC Tokens held from time to time, and shall enable the automated governance of the DAC, all subject to and in accordance with the provisions of the Constitution.
3.2 Number: An initial number of 1, 200, 000, 000 (One Billion and Two Hundred Million) DAC Tokens shall be made available for distribution by the Genesis Member at the Token Distribution, and thereafter the number of tokens shall be determined, or be determinable, in the manner prescribed by the Custodian Board, from time to time, by Extraordinary Resolution.
3.3 Membership: DAC Tokens shall, upon registration, constitute and represent the holder thereof, from time to time, as a Member of the DAC, entitled qua Member to all the benefits, and subject to all the obligations, set out in this Constitution and in proportion to the number of DAC Tokens held by such holder, from time to time, PROVIDED ALWAYS that Membership shall be inseparably linked to possession and control of the DAC Tokens and should any holder thereof lose possession or control of or over any such DAC Tokens, such holder shall be deemed immediately terminated as a Member and shall not be entitled qua Member to any benefits, or subject to any obligations, as aforesaid, to the extent of the DAC Tokens over which possession or control was lost.
3.4 Benefits of Members: The DAC Tokens shall entitle the holder thereof and from time to time, qua Member of the DAC, to the following rights in proportion to the number of DAC Tokens held by such holder as measured against the total number of outstanding DAC Tokens:
(a) Right to Benefits to Members of the DAC prescribed by and pursuant to the Constitution, which right shall be governed by and administered in accordance with the provisions of the Constitution.
(b) Right to Vote in the DAC on any matter requiring or permitting a vote of member's of the DAC prescribed by and pursuant to the Constitution, which right shall be governed by and administered in accordance with the provisions of the Constitution.
(c) Right to Distribution of Assets of the DAC, required or permitted to be distributed to Members of the DAC pursuant to the Constitution, which right shall be governed by and administered in accordance with the provisions of the Constitution.
(d) Right to Ownership of Assets of the DAC, in common with each other Member and inseparable from Membership, which right shall be subject to, governed by and administered in accordance with the provisions of the Constitution.
(e) Right on Dissolution of DAC to distribution of any surplus assets of the DAC, which right shall be subject to, governed by and administered in accordance with the provisions of the Constitution.
PROVIDED ALWAYS that, save and except as otherwise provided by the Constitution, no benefits of or accruing to Members, or any part thereof, under this provision, may be amended, restated, supplemented or otherwise modified other than by Extraordinary Resolution.
3.5 Obligations of Members: The DAC Tokens shall subject the holder thereof and from time to time, qua Member of the DAC, to the following obligations in proportion to the number of DAC Tokens held by such holder as measured against the total number of outstanding DAC Tokens:
(a) Obligation for Liabilities of the DAC, in common with each other Member and inseparable from Membership, which obligation shall be governed by and administered in accordance with the provisions of the Constitution.
(b) Obligation of Governance by the DAC, binding each Member, and each Member's property rights held in common with each other Member, to governance by, and administration in accordance with, the provisions of the Constitution with respect to any matter relating to the DAC Tokens, the DAC and/or the Constitution.
PROVIDED ALWAYS that, save and except as otherwise provided by the Constitution, no obligation accruing to Members, or any part thereof, under this provision may be amended, restated, supplemented or otherwise modified other than by Extraordinary Resolution
3.6 No Redemption: DAC Tokens shall not be redeemable at the instance of the holder of a DAC Token or the DAC.
3.7 Voluntary Cancellation of DAC Tokens: DAC Tokens may be "burnt" at the instance of any holder thereof, subject to and in accordance with this Constitution. Members wishing to "burn" DAC Tokens (or any part thereof) shall be permitted to do so in accordance with the "burn transaction" prescribed by the DAC. Upon "burning" of a DAC Token, the membership of the DAC linked to such DAC Token shall expire immediately and the holder thereof shall have no further entitlements qua member to any benefit, and shall be subject to no further obligations, linked to the "burnt" DAC Token, which rights and obligations shall stand assigned and/or distributed amongst the remaining DAC Tokens.
3.8 Transfer of DAC Tokens:
3.8.1 DAC Tokens shall be transferable by any holder thereof by delivery of possession and control thereof.
3.8.2 Any transfer of DAC Tokens shall be completed by registration of such DAC Tokens by the transferee thereof and in accordance with the Constitution.
3.8.3 Upon transfer of any DAC Token, the transferor thereof shall cease to be a Member of the DAC, to the extent of the DAC Tokens transferred, and the transferee thereof shall be constituted as a Member of the DAC and entitled qua Member to all the benefits, and be subject to all the obligations, set out in this Constitution and in proportion to the number of DAC Tokens transferred to such transferee and, for the purposes of the Constitution, all unrealized and/or undistributed benefits and obligations accruing with respect to the transferred DAC Tokens shall be deemed assigned to the transferee as of the date of transfer.
3.9 Member Information and Documentation: Upon request or notification each Member shall immediately provide information and documents that the Custodian Board, in its sole discretion, deems necessary to comply with the laws, regulations or rules of or in relation to any applicable jurisdiction or blockchain, including but not limited to judicial decrees, order, processes or arbitral awards. Such documents or information shall include, but not be limited to, certified copies of Member's passport, utility bills, government identification cards, sworn statements and information and documentation relating to persons or entities affiliated with Member. Each Member expressly and irrevocably consents to the disclosure of such information and documentation, and the recording or making of copies thereof, required for compliance with any laws, regulations or rules of or in relation to any applicable jurisdiction or blockchain. Failure by a Member to immediately comply with any such request for information or documentation may result in measures taken against such Member, including but not limited to the unregistering of such Member, in accordance with the Constitution.
3.10 Unregistering of Member: Where expressly permitted by the provisions of the Constitution, a Member may be unregistered by Special Resolution of the Custodian Board whereupon any or all benefits accruing to such Member may be blocked, restricted and/or rendered inoperable, including but not limited to Right to Vote in the DAC and Right to Distribution of Assets of the DAC PROVIDED ALWAYS no amendment, restatement, supplement or other modification of the Constitution, providing any additional basis for the unregistering of a Member, shall be effected other than by Extraordinary Resolution
3.11 Joint Holders: If several persons exercise joint possession and control of any DAC Tokens, then such persons shall be constituted as joint Members of the DAC and any one of such persons may exercise and/or give receipt for any benefit linked to such DAC Tokens held by such joint holders and such joint owners shall be jointly and severally subject to the obligations linked to such DAC Tokens.
3.12 No Partnership, Joint Venture or Agency: Nothing in this Constitution and no action taken by any Member shall constitute, or be deemed to constitute a partnership, joint venture or any other association between the Members, and no action taken by any Member pursuant to this Constitution or otherwise shall constitute, or be deemed to constitute, any Member as the agent of any other Member or the DAC for any purpose whatsoever and no Member has, pursuant to this Constitution or otherwise, any authority or power to bind or to contract or to otherwise act in the name of or on behalf of any other Member or the DAC, all save and except as expressly provided in the Constitution and to the extent applicable with respect to the Custodian Board.
4.1 Each Member shall be permitted to vote on the appointment of Custodians to the Custodian Board, and on any other matters prescribed by or pursuant to the Constitution, in proportion to the number of DAC Tokens held by such Member and in accordance with the provisions of the Constitution.
4.2 Subject to the provisions of any Voting Directive, a quorum for the purposes of any vote of Members prescribed by the Constitution shall be 2% of the outstanding DAC Tokens, from time to time, save and except that a quorum with respect to the vote of Members for the formation of the first Custodian Board, superseding the Genesis Board, shall be 15% of the outstanding DAC Tokens ("Activation Threshold").
4.3 Voting by Members on the appointment of Custodians to the Custodian Board, and on any other matters prescribed by the Constitution, shall be in accordance with the procedure, qualifications and mechanism for voting, including but not limited to quorums, consensus, and staking of DAC Tokens as prescribed by Voting Directive from time to time.
4.5 Any Member shall be entitled to submit Proposals for the consideration and determination of the Custodian Board in accordance with the subject matter, procedure, qualifications and mechanism, including but not limited to staking of DAC Tokens, as prescribed by Proposal Directive from time to time.
4.6 The usage of any DAC Tokensfor the purposes of submission of Proposals and voting of Members, or any other purpose prescribed by the Constitution, shall be deemed the usage by the holder thereof, whether or not such usage was effected by such holder, any servant or agent thereof or any other person whether authorized or unauthorized.
4.7 Members may be permitted to vote by proxy in the manner prescribed, and subject to, any Voting Directive from time to time.
5.1 Until such time as the first Custodian Board is constituted, the Genesis Member shall be deemed, and shall have the powers and duties of, the Custodian Board for the purposes of the Constitution.
5.2 The Custodian Board shall be elected by vote of the Members, with the twelve (12) candidates receiving the highest number of votes being appointed to serve on the Custodian Board ("Appointment Event").
5.3 Each Custodian shall be entitled to cast one (1) vote with regard to any Resolution, Special Resolution or Extraordinary Resolution in relation to any Proposal or Custodian Proposal, or any other matter prescribed by the Constitution to be determined by the Custodian Board.
5.4 Each candidate for the position of Custodian must be a Member and may be an individual or a legal entity.
5.5 Custodians shall be nominated, elected and appointed in accordance with the procedure, qualifications and mechanism prescribed by Nomination Directive, from time to time, which Nomination Directive shall include, but shall not be limited to, provisions requiring each candidate to make a declaration specifying the emoluments that such candidate shall require if appointed, up to a maximum amount 50 EOS for each one week term, ("Candidate Emoluments Declaration"), such maximum amount being subject to change by Special Resolution.
5.6 Each Custodian shall hold office for the term of one (1) calendar week, commencing at midnight on the date of appointment and concluding at midnight on the final day of such calendar week, save and except that the term for the first Custodian Board, superseding the Genesis Board, shall be deemed to commence at midnight of the day of attainment of the Activation Threshold.
5.7 In the case of a Custodian who is an individual the term of office for such member shall terminate on the individual's death, resignation or removal. The bankruptcy, resignation or removal of a corporate Custodian shall terminate the term of office of such Custodian.
5.8 Emoluments of each Custodian during a term shall be the median of the Candidate Emoluments Declaration of Custodians appointed for such term divided by twelve (12), and shall be paid to each Custodian automatically and at the expiration of each term held by such Custodian or as otherwise provided by Nomination Directive.
5.9 A Custodian may be removed from office, with or without cause, by Special Resolution of the Custodian Board.
5.10 A Custodian may resign his office by giving written notice of his resignation to the Custodian Board and the resignation shall have effect from the date the notice is received by the Custodian Board or from such later date as may be specified in the notice.
5.11 A vacancy in the Custodian Board shall immediately, and without more, be filled, for the remainder of the term, by the appointment of the Candidate holding the highest number of votes on the candidate voting roster, but not currently serving as a Custodian, at the time of the creation of the vacancy ("Replacement Custodian").
5.12 The Custodian Board may determine by Resolution to maintain a record, in such form determined by the Custodian Board, of Custodians containing:
5.12.1 the name, contact details (including email addresses) and/or addresses of the persons appointed as Custodians;
5.12.2 the date on which eachperson whose name is entered in the record of Custodians was appointed as a Custodian; and
5.12.3 the date onwhich each person named as a Custodian ceased to be a Custodian of the Custodian Board.
6.1 The operations and affairs of the DAC, including but not limited to the governance and administration of assets and liabilities of the DAC, shall be vested, determined and managed by and through the Custodian Board, as constituted from time to time, which shall hold and exercise all such powers pursuant to and in accordance with this Constitution, and for the purposes aforesaid, the Custodian Board may do all acts, matters and things, and execute all contracts, instruments, deeds or other document, whatsoever and wheresoever, for and on behalf of the DAC and the Members, and each of them, thereof PROVIDED ALWAYS that any such action shall be considered by the Custodian Board by means of a Proposal or Custodian Proposal and determined by, and effected pursuant to, Resolution, Special Resolution or Extraordinary Resolution of the Custodian Board.
6.2 The aggregate and collective rights of Members to and to determine the operations and affairs of the DAC, held in common with each other Member of the DAC, shall be and shall be deemed the operations and affairs of the DAC and shall be governed by and administered in accordance with the provisions of the Constitution.
6.3 The aggregate and undistributed assets and liabilities of Members, held in common with each other Member of the DAC, from time to time, shall be and shall be deemed the assets and liabilities of the DAC and shall be subject to, governed by and administered in accordance with the provisions of the Constitution.
6.4 Any action or omission by the Custodian Board and each Custodian thereof, pursuant to and in accordance with the provisions of the Constitution, relating to the operations and affairs of the DAC shall be and shall be deemed authorized by, on behalf of and binding upon each Member of the DAC, in common with each other Member, regardless of any assent or dissent by such Member to such action or omission.
6.5 Any acquisition or disposition of, or any other action or omission relating to, the assets and liabilities of the DAC, by the Custodian Board and each Custodian thereof and pursuant to and in accordance with the provisions of the Constitution, shall be deemed authorized by, on behalf of and binding upon each Member of the DAC, in common with each other Member, regardless of any assent or dissent by such Member to such acquisition, disposition, action or omission.
6.6 The Custodian Board may, by Resolution, appoint any person, including a person who is a Custodian to act as agent for the Custodian Board and/or the DAC. The Resolution appointing such agent may authorize the agent to appoint one or more substitutes or delegates to exercise some or all of the powers conferred on the agent by the Custodian Board.
6.7 Without prejudice to the appointment of a Replacement Custodian, the continuing Custodians may act notwithstanding any vacancy in the Custodian Board, save that where the number of Custodians is reduced below the number fixed by or pursuant to this Constitution as the necessary quorum for the Custodian Board, and no Replacement Custodian is available, the continuing Custodian or Custodians may appoint Custodians to fill any vacancy that has arisen by Resolution.
6.8 All cheques, promissory notes, drafts, bills of exchange and other negotiable instruments, and all receipts for value, whether in the form of money, cryptocurrencies or any other store of value, paid to the DAC or Custodian Board shall be signed, drawn, accepted, endorsed or otherwise executed, as the case may be, in such manner as shall from time to time be determined by Resolution.
6.9 To the furthest extent permitted by any applicable law, any claims, demands, liabilities or any other recourse whatsoever, arising out or related to any act or omission of the DAC, the Custodian Board or any servant or agent thereof, shall be limited to the assets of the DAC, as exist from time to time, and there shall be no claim, demand, liability or any other recourse against or permitted against the Custodian Board or any Member of the DAC.
6.10 Any contract, agreement or other arrangement entered into by or on behalf of the DAC, by or through the Custodian Board or in any other manner permitted by this Constitution shall limit and restrict any claims, demands, liabilities or any other recourse whatsoever thereon to the assets of the DAC, as exist from time to time, and there shall be no claim, demand, liability or any other recourse against or permitted against the Custodian Board or any Member of the DAC.
6.11 The Custodian Board may from time to time and at any time by power of attorney appoint any company, firm or person or body of persons whether appointed directly or indirectly by the Custodian Board, to be the attorney or attorneys of the Custodian Board for such purposes and with such powers, authorities and discretions (not exceeding those vested in or exercisable by the Custodian Board under this Constitution) and for such period and subject to such conditions as the Custodian Board may think fit and any such power of attorney may contain such provisions for the protection and convenience of persons dealing with such attorney or attorneys as the Custodian Board may think fit and may also authorize any such attorney or attorneys to delegate all or any powers, authorities and discretions vested in them.
6.12 The Custodian Board may be Extraordinary Resolution prescribe, and amend, restate, supplement or otherwise modify, a code of conduct for Custodians ("Custodian Code of Conduct") including provisions for the removal of Custodians who do not conform to such Code of Conduct, by the remaining Custodian Board by Special Resolution.
7.1 The Custodians of the Custodian Board may meet, whether in person, by video or audio communication, electronic mail/messaging or such other or further means of communication, at such times and in such manner and at such places as the Custodians may determine to be necessary or desirable.
7.2 A Custodian shall be deemed to be present at a meeting of Custodians of the Custodian Board if he participates in person, by video or audio communication, electronic mail/messaging or such other or further means of communication that allows all other Custodians participating in the meeting to be able to view, hear or otherwise interact with each other's communication in real time.
7.3 A Custodian shall be given not less than twenty four (24) hours notice of meetings of Custodians of the Custodian Board, but such meeting of Custodians held without twenty four (24) hours notice having been given to all Custodians shall be valid if all the Custodians entitled to vote at such meeting who do notattend, waive notice of the meeting; and for this purpose, the presence or vote of a Custodian at the meeting shall be deemed to constitute waiver on his part. The inadvertent failure to give notice of a meeting to a Custodian, or the fact that a Custodian has not received the notice, does not invalidate the meeting.
7.4 All proceedings of the Custodian Board shall be conducted in the English language.
7.5 Voting by Custodians with respect to any Resolution, Special Resolution or Extraordinary Resolution determining a Proposal, Custodian Proposal or on any other matter prescribed by the Constitution, shall be in accordance with the subject matter, procedure, qualifications and mechanism for voting, including but not limited to quorums, consensus, and any staking of DAC Tokens, prescribed by Voting Directive from time to time and which may or may not require a meeting of the Custodian Board.
7.6 Any Custodian shall be entitled to submit Custodian Proposals, relating to the operations and affairs of the DAC and for the consideration and determination of the Custodian Board, in accordance with the subject matter, procedure, qualifications and mechanism, including but not limited to staking of DAC Tokens, as prescribed by Proposal Directive from time to time.
7.7 Unless otherwise stated in the Constitution or any Voting Directive, from time to time, all matters for determination by the Custodian Board shall be determined by simple Resolution.
7.8 Immediately upon determination of any matter by Resolution, Special Resolution or Extraordinary Resolution, the Custodian Board shall publish on the blockchain (a) whether or not the matter has been approved or rejected by Resolution, Special Resolution or Extraordinary Resolution (b) the number of votes in favour and against in reaching such determination and (c) the vote of each Custodian with respect to such Proposal.
7.9 Subject to the provisions of any Voting Directive, a quorum for any vote by the Custodian Board with respect to any Resolution, Special Resolution or Extraordinary Resolution shall be eight (8) Custodians able to cast votes in the manner prescribed by Voting Directive.
7.10 The Custodian Board may, by Resolution, cause the following records ("Records") to be kept:
7.10.1 minutes of any meetings of Custodians;
7.10.2 copies of all Resolutions, Special Resolutions or Extraordinary Resolutions by the Custodian Board; and
7.10.3 such other accounts and records as the Custodian Board considered necessary or desirable inorder to reflect the financial position of the Custodian Board or DAC.
7.11 The Records shall be kept at the at such place or places, and in such form (including electronic form) as the Custodian Board, from time to time, determines by Resolution.
7.12 The Custodian Board may, by a Resolution, designate one or more committees, each consisting of one or more Custodians to do such things, make such investigations or inquiries and make such reports as determined by the Custodian Board by Resolution.
7.13 The Custodian Board may, but shall not be required to, by Special Resolution determine, from time to time, that specific issues substantially affecting or capable of substantially affecting the DAC shall be put before the DAC for determination by vote of Members ("Members Referendum Proposal").
8.1 No agreement or transaction between the DAC and one or more of its Custodians, or any person inwhich any Custodian has a financial interest or to whomany Custodian is related, is void or voidable for this reason only or by reason only that the Custodian participates in any voting on such agreement or transaction and that the vote of such Custodian counted for that purpose PROVIDED ALWAYS that the material facts of the interest of the relevant Custodian shall be disclosed in good faith to the other Custodians prior to any vote with respect to the agreement or transaction.
9.1 Subject to the limitations hereinafter provided, the Custodian Board shall, out of the assets of the DAC, indemnify against all expenses, including legal fees, and against all judgments, fines, damages and amounts paid insettlement and reasonably incurred in connection with legal, administrative or investigative proceedings any person who:
9.1.1 is or was a party or is threatened to be made a party to any threatened, pending or completed proceedings, whether civil, criminal, administrative or investigative, by reason of the fact that the person is or was a Custodian or an officer, consultant, advisor, affiliate, servant, agent or service provider, past, present or future, of the DAC or Custodian Board.
9.1.2 is or was a party or is threatened to be made a party to any threatened, pending or completed proceedings, whether civil, criminal, administrative or investigative, by reason of the fact that the person is a Member of the DAC and such proceedings is or was alleged or premised on the basis of joint or several liability of such Member for any act or omission of the DAC or Custodian Board.
9.2 The Custodian Board may restrict indemnification of any person on the prerequisite that the person acted honestly and in good faith with a view to the best interests of the DAC or Custodian Board and was not aware that his conduct was unlawful.
9.3 The decision of the Custodian Board as to whether the person acted honestly and in good faith and with a view to the best interests of the DAC or Custodian Board is, in the absence of fraud, sufficient for the purposes of this Constitution, unless aquestion of law is involved.
9.4 In furtherance of the indemnification of any person, the Governing Board shall provide moneys, or any other medium of value, in advance, for the purposes of meeting any legal fees and expenses required in the defending or prosecuting any legal, administrative or investigative proceedings by or against the indemnified person.
9.5 The Custodian Board may purchase and maintain insurance in relation to any obligation to indemnify any person pursuant to the Constitution.
9.6 The Custodian Board shall establish an indemnification reserve, in such amounts, in such currencies or stores of value and to be funded or accumulated in such manner, as is determined by the Custodian Board by Resolution.
10.1 The Custodian Board shall by Resolution and from time to time determine that any assets of the DAC, including but not limited to cryptocurrencies, moneys or other stores of value, received by or on behalf of the DAC or Custodian Board be distributed to the Members of the DAC in proportion to the number of DAC Tokens held by such Members ("Distribution of Assets").
10.2 The Custodian Board shall, before any Distribution of Assets, set aside out of the assets of the DAC, such assetsas the Custodian Board considers proper for the purposes of any reserve funds, and may invest such assets so set apart for any reserve funds in such manner as the Custodian Board may determine by Resolution PROVIDED ALWAYS that the reserve funds shall at all times, to the furthest extent possible, be sufficient to maintain the normal operations and affairs of the DAC for a period of no less than six (6) months.
10.3 No Distribution of Assets shall be made unless the Custodian Board determines that immediately after such Distribution of Assets the DAC or Custodian Board will be able to satisfy the liabilities of the DAC (including any reserve funds) as they come due in the ordinary course of its operations and affairs, and the realisable value of the assets of the DAC will not be less than the sum of its total liabilities. In the absence of fraud, the decision of the Custodian Board as to the realisable value of the assets of the DAC shall be conclusive.
10.4 No Distribution of Assets shall bear interest as against the DAC.
10.5 Notwithstanding any other provision of the Constitution, the entitlement of any Member to a Distribution of Assets, as effected by the DAC or Custodian Board from time to time, shall be conditional on such Member electing to receive such Distribution of Assets, in accordance with the procedure and mechanism prescribed by the Custodian Board, from time to time and failing such election by the time of any Distribution of Assets, the entitlement of such Member shall be deemed to have been irrevocably waived and the relevant assets shall be distributed in lieu thereof amongst the remaining Members of the DAC.
10.6 Distribution of Assets may be in specie or in any other medium of value that the Custodian Board deems fit.
11.1 All decisions, transactions and/or accounting for the DAC shall be viewable by all Members on the Website and/or on the blockchain hosting the DAC.
12. AUDIT
12.1 The Custodian Board may, but shall not be required to, call for the accounts to be examined by auditors and upon such terms and conditions, including appointment of auditors, as the Custodian Board may determinate by Special Resolution.
13.1 Any agreements, notices, disclosures and other communications provided or to be provided to Member pursuant to the Constitution may be provided to Member or Custodian by publication on the Website or dissemination in electronic form or in such other form or manner as determined by Resolution of the Custodian Board from time to time and, immediately upon such publication or dissemination, Member or Custodian shall be deemed to have notice thereof.
14.1 In any case (if any) where under the Constitution any act or thing may be done by, on behalf of, or in relation to the DAC either by vote of Members or by Resolution of the Custodian Board and there is a difference, then the determination of the Members shall prevail.
15.1 Informal Dispute Resolution: Members and Custodians shall cooperate in good faith to resolve any dispute, controversy or claim arising out of, relating to or in connection with the Constitution or the DAC, including with respect to the formation, applicability, breach, termination, validity or enforceability thereof ("Dispute"). If the parties to any Dispute are unable to resolve a Dispute within ninety (90) days of notice of such Dispute being received by all parties thereof, such Dispute shall be finally settled by Binding Arbitration, as defined hereinafter.
15.2 Binding Arbitration: Any Dispute not resolved within 90 days as set forth hereinbefore shall be referred to and finally resolved by arbitration under the London Court of International Arbitration (LCIA) rules in effect at the time of the arbitration, except as they may be modified herein or by mutual agreement of the parties to such arbitration. The number of arbitrators shall be one, who shall be selected by the parties to the arbitration. The seat, or legal place, of arbitration shall be London, England. The language to be used in the arbitral proceedings shall be English. The governing law, for the purposes only of the interpretation and constructions of the provisions of the Constitution, and the contractual relations created thereby, shall be the laws of Anguilla. The arbitration award shall be final and binding on the parties thereto ("Binding Arbitration"). Each Member and Custodian undertakes to carry out any award without delay and waive its right to any form of recourse insofar as such waiver can validly be made. Judgment upon the award may be entered by any court having jurisdiction thereof or having jurisdiction over the relevant party or its assets. Without prejudice to any indemnification provision of the Constitution, each party to arbitration shall pay their respective attorneys' fees and expenses.
15.3 No Class Arbitrations, Class Actions or Representative Actions: Any dispute arising out of or related to the Constitution shall be personal to the parties to the arbitration and shall not be brought as a class arbitration, class action or any other type of representative proceeding. There shall be no class arbitration or arbitration in which an individual attempts to resolve a dispute as a representative of another individual or group of individuals. Further, and to the furthest extent permitted by applicable law, a dispute cannot be brought as a class or other type of representative action, whether within or outside of arbitration, or on behalf of any other individual or group of individuals.
15.4 Without prejudice to any other limitation of liability, disclaimer, waiver or release prescribed by the Constitution or any part thereof (including but not limited to the Terms and Conditions), and to the furthest extent permitted by any applicable law, any claims, demands, actions, damages or proceedings by any Member against the DAC, Custodian Board (or any servant or agent thereof), or any other Member, with respect to any action or omission of such persons and arising out of or related to the Constitution shall be limited to the assets of the DAC, as exist from time to time.
16.1 Subject to any provision to the contrary in the Constitution the DAC may voluntarily commence to wind up and dissolve by Extraordinary Resolution of the Custodian Board. Upon the dissolution of the DAC and distribution of any net assets of the DAC to Members, each Member shall be immediately and without more released from any obligation, and no longer entitled to any benefit, pursuant to this Constitution.
17.1 Save as otherwise provided in this Constitution, the Custodian Board may by Special Resolution make, amend, restate, supplement or otherwise modify any provision of this Constitution and same shall thereupon and without more be effective and binding on or against each Member of the DAC.
18.1 The Terms and Conditions issued by Genesis Member at the Token Distribution shall be incorporated herein and form a part of this Constitution. The Custodian Board may by Special Resolution make, amend, restate, supplement or otherwise modify any provision of the Terms and Conditions and same shall thereupon and without more be effective and binding on or against each Member of the DAC.
19.1 The governing law for the purposes only of the interpretation and constructions of the provisions of the Constitution, and the contractual relations created thereby, shall be the laws of Anguilla.
20.1 The Constitution, including any exhibits attached hereto, materials incorporated herein by reference and material issued pursuant to the provisions of the Constitution from time to time, constitutes the entire agreement between the parties hereto and supersedes all prior or contemporaneous agreements and understandings, both written and oral, between such parties with respect to the subject matter hereof, including, without limitation, any public or other statements or presentations made by any Genesis Member, DAC or any member, officer, director, consultant, advisor, parent, subsidiary affiliate, servant or agent, past, present or future, thereof, save and except for the Terms and Conditions.
20.2 If any of the provisions of the Constitution are deemed to be invalid, void or unenforceable under any applicable law, the remaining provisions shall continue in full force and effect.
20.3 By acceptance ofDAC Tokens, whether at the Token Distribution or upon transfer from any holder of DAC Tokens or usage of DAC Tokens, Member expressly acknowledges, accepts, agrees and shall be subject to the terms and conditions of the Constitution and the Terms and Conditions, each as amended, restated, supplemented or otherwise modified from time to time.
21.1 The provisions of the Constitution shall constitute the agreement by and between each Member and each other Member of the DAC, from time to time, inter se.
TERMS AND CONDITIONS
These Terms and Conditions (the "T&C") apply to each holder of the eosDAC token(s) and/or member of the eosDAC decentralized autonomous community. PLEASE READ THESE TERMS CAREFULLY BEFORE ACCEPTING EOSDAC TOKENS AND/OR PARTICIPATING IN THE MEMBERSHIP OF THE EOSDAC. THE T&C AFFECTS THE LEGAL RIGHTS AND OBLIGATIONS OF HOLDERS OF EOSDAC TOKENS AND/OR MEMBERS OF THE EOSDAC, INCLUDING, BUT NOT LIMITED TO, WAIVERS OF RIGHTS AND LIMITATION OF LIABILITY. IF ANY PERSON OR ENTITY DOES NOT AGREE TO THE TERMS AND CONDITIONS HEREOF, SUCH PERSON OR ENTITY MUST NOT ACCEPT THE EOSDAC TOKEN(S).
By accepting and holding eosDAC token(s), holder thereof agrees with each other holder of eosDAC token(s), from time to time and inter se, to be bound by the T&C, and shall be bound by the terms and conditions thereof, along with such further or other terms and conditions incorporated by reference in the T&C including but not limited to the Constitution (as hereinafter defined). The acceptance and holding of eosDAC token(s) is made expressly subject to this T&C.
NOW THEREFORE in consideration of the mutual promises contained in this T&C it is hereby agreed as follows:
Binding Agreement
The following terms and conditions constitute the agreement ("Agreement") by and between any person or entity accepting and holding an eosDAC token (or any fractional part thereof) ("Member"), and each other person or entity accepting or holding an eosDAC token (or any fractional part thereof), inter se. By accepting and holding an eosDAC token, or any fractional part thereof ("Token"), the Member hereof agrees to be, and shall be constituted, without more, as a member of the eosDAC decentralized autonomous community ("eosDAC") and shall be bound by the T&C, as amended from time to time. The Member is aware that eosDAC may change the T&C at any time and in any manner, in accordance with the constitution governing the organization, rights and liabilities of the eosDAC and the members thereof ("Constitution").
By accepting a Token, Member confirms that it is the holder of the Token, a member of the eosDAC and has read, understands and agrees to the T&C. A person or entity shall indicate their acceptance of a Token by:
(a) In the case of any initial recipient of a Token (or assignee/transferee thereof), pursuant to the Token Distribution (as defined hereinafter), by registering the Token through the eosDAC software.
(b) In any other case, by accepting the transfer or assignment of a Token from a holder of Tokens and/or registering the Token through the eosDAC software.
(c) In either case, and in any event, by any usage of Tokens including but not limited to exercise of voting rights or receipt of distributions of assets.
BlockMaker Ltd has prepared a website, available at www.eosdac.io ("Website"), describing the proposed activities of eosDAC and the mechanisms through which such activities shall be conducted. By accepting and holding a Token, Member confirms that it has read and understands the Website.
The eosDAC
eosDAC is an decentralized autonomous community governed by the Constitution of eosDAC and administered through the medium of blockchain technology. The use of a blockchain technology enables eosDAC to be decentralized and governed, in accordance with its Constitution, on an automated basis. The terms and conditions of the Constitution are incorporated by reference into the T&C and shall be binding on each member of the eosDAC, inter se. By accepting and holding a Token, Member also confirms that it has read, understands and agrees to the terms and conditions of the Constitution and the rules of governance of the eosDAC.
The eosDAC Tokens ("Token")
BlockMaker Ltd shall distribute an initial supply of 1, 200, 000, 000 (One Billion and Two Hundred Million) Tokens to specified persons or entities, inviting such persons or entities, or their transferees or assignees, ("Token Distribution") to accept and hold such Tokens, gratis, and to become a member of the eosDAC.
Tokens are not redeemable by Member or eosDAC but Member may request cancellation of Tokens, in accordance with the provisions of the Constitution, whereupon the membership linked to such cancelled Tokens shall expire immediately and Member shall be entitled to no further rights and shall be subject to no further obligations in and under eosDAC with respect to said Tokens, save and except such rights and obligations accrued to Member to the date of cancellation of said Tokens.
During the Token Distribution, Tokens shall be distributed by BlockMaker Ltd in the following tranches:
(a) 75% to holders of EOS tokens as at 1:00 UTC on 15thApril 2018, on the basis of one (1) eosDAC token for each one (1) EOS token held by a person or entity in an account with balance in excess 100 EOS (or, upon request, with a balance of less than 100 EOS) ("Open Token Distribution").
Any tokens not distributed from this tranche shall be "burnt" thereby permanently removing same from circulation.
(b) 25% to launch team, advisors, community supporters and eosDAC Ltd.
Each Token shall constitute the holder thereof as a member of the eosDAC, entitled to all the benefits and subject to all the obligations set out in the Constitution.
The acceptance and holding of Tokens shall constitute the holder thereof as a member of the eosDAC in proportion to the number of Tokens held by such holder. By accepting and holding a Token, Member is constituted as the holder of such Token and as a member of the eosDAC.
Beyond membership and automated governance of the eosDAC in accordance with its Constitution, a Token does not maintain, represent or enable any rights, uses, purpose, attributes, functionalities or features, express or implied. Immediately upon transfer or cancellation of a Token, Member shall cease to be a member of the eosDAC to the extent of the Token transferred or cancelled.
A Token does not grant the holder thereof the right to any part of the share capital of BlockMaker Ltd, to any vote at any shareholders meeting of BlockMaker Ltd or to any voting rights with respect the appointment of directors or managers of BlockMaker Ltd. Tokens are not being distributed by BlockMaker Ltd in exchange for or in expectation of any monetary or other consideration. Tokens shall be non-refundable and non-redeemable. Tokens are not, and are not intended to be an investment, security, commodity or any other financial instrument or investment.
Member expressly acknowledges and represents that it has carefully reviewed the T&C and fully understands the risks and benefits associated with the acceptance and holding of the Tokens.
Token Distribution Restrictions
No U.S. Persons: The Tokens are not being and/or are not intended to be distributed to any S. Person, citizen, resident or entity ("Excluded Person") pursuant to the Open Token Distribution. If any Excluded Person accepts or purports to accept any Tokens pursuant to the Open Token Distribution by BlockMaker Ltd, such person would have taken such action in an inapplicable, unauthorized and/or unlawful manner and the Tokens shall not be deemed as accepted by such Excluded Person. Any Excluded Person who accepts Tokens pursuant to the Open Token Distribution shall be solely liable for any legal, regulatory, judicial or contractual consequences therefrom and shall indemnify, defend and hold harmless BlockMaker Ltd, eosDAC and any member, employee, officer, director, consultant, advisor, parents, subsidiaries, affiliates, servants or agents, past, present or future, thereof (collectively "Indemnified EP") from any penalties, damages, losses, liability, costs or expenses, whether direct or indirect, consequential, compensatory, punitive, actual, exemplary, incidental or special and including without limitation any loss of business, revenues, profits, data, use, goodwill or other intangible losses (collectively, "EP Damages") arising out of or related to such Excluded Person's acceptance or purported acceptance of Tokens pursuant to the Open Token Distribution.
Knowledge Required
Member acknowledges and agrees that it has sufficient knowledge in technological, business and financial matters, including but not limited to sufficient understanding of blockchain, digital ledger technology, cryptographic tokens, digital assets, smart contracts, block production, storage mechanisms (including online or offline digital, token or cryptocurrencies wallets), blockchain based software systems and/or other matters set out in this T&C, to evaluate and render an informed decision as to the risks and merits of the acceptance of Tokens and further acknowledges and agrees that it is able to bear such risks including risk of loss of Tokens and/or any risks or rewards accrued by reason of holding such Tokens and/or membership of the eosDAC. Member expressly acknowledges that it has obtained or procured sufficient information in order to make an informed decision as to whether or not to accept and hold Tokens.
Member shall ensure that it understands and has significant experience of cryptocurrencies, blockchain systems and services, and that it fully understands the risks and mechanisms associated with the Token and Token Distribution, as well as the risks and mechanisms related to the use and custody of cryptocurrencies and/or other representations utilizing distributed ledger technology.
Neither BlockMaker Ltd nor eosDAC shall be responsible for any loss of Tokens held by Member, or any situation rendering it impossible for Member to access Tokens, which may result from, by or through any actions or omissions of Member.
It shall be the sole responsibility of Member to implement and appropriate measures to secure access to (a) any device associated with Member in connection with the acceptance, holding and use of Tokens; (b) private keys to Member's blockchain wallet or account; and (c) any other username, password or other login or identifying credentials. In the event that Member loses possession or control of Member's private keys or any device associated with Member's blockchain related account or is not able to otherwise provide Member's login or identifying credentials, Member may lose all of Member's Tokens and/or access to Member's blockchain related account. Neither BlockMaker Ltd nor eosDAC shall be under any obligation to recover or replace any Tokens rendered inaccessible and/or disabled thereby, or to provide any other compensation or reimbursement to Member thereof.
Member acknowledges, understands and agrees that (a) the acceptance and holding of Tokens may have tax and regulatory consequences for Member; (b) Member is solely responsible for Member's compliance with any such or any tax or regulatory consequences of Member linked to the acceptance and holding of Tokens and/or membership of the eosDAC; (c) Member shall have consulted with and taken advice from Member's own tax and regulatory professional prior to accepting and holding the Tokens; and (d) neither BlockMaker Ltd nor eosDAC bears any responsibility or liability to Member with respect to any tax or regulatory consequences linked to Member's acceptance and holding of Tokens and/or membership of the eosDAC.
Members Representation and Warranties
By accepting any Token, Member agrees to be bound by the T&C and in particular, Member represents and warrants that:
(a) It is authorized and has full power and authority to accept and hold the Token according to the laws that apply in Member's jurisdiction of domicile or other applicable jurisdiction;
(b) It is authorized and has full power to execute, deliver and be bound by the T&C and to carry out and perform its obligations thereunder;
(c) If an individual, it is at least 18 years old and of sufficient legal age and capacity to accept and hold the Tokens and, if a legal person, it is validly constituted and in good standing under the laws of its domicile and each jurisdiction in which it operates or conducts business;
(d) That the execution, delivery and performance of and by Member under the T&C requires no approval, authorization or other action from any governmental or regulatory authority or any other person, entity or bureau, whatsoever, other than Member;
(e) That the execution delivery and performance of and by Member under the T&C shall not, and will not in the future, result in any violation of, be in conflict with or constitute a material default under (i) any provision of Member's constitutional documents (if applicable), (ii) any provision of any judgment, order or decree to which Member is a party, by which Member is bound or to which Member's material assets are subject, (iii) any material agreement, obligation, duty or commitment to which Member is a party or is bound, or (iv) any laws, regulations, rules or contracts applicable to Member.
(f) It is not accepting and holding the Tokens for the purpose of any speculative investment;
(g) It will not use any Tokens for any illegal activity, including but not limited to money laundering and the financing of terrorism;
(h) It shall be responsible for determining whether the acceptance and holding of the Tokens is appropriate for it;
(i) It shall accept and hold the Tokens exclusively for usage in accordance with the Constitution of the eosDAC;
(j) It understands the risks associated with acceptance and holding of the Tokens (including but not limited to the risks related to the non-development of the eosDAC and its operations).
Upon request of or notification by BlockMaker Ltd or eosDAC, and from time to time, Member shall immediately provide information and documents that BlockMaker Ltd or eosDAC, in its or their sole discretion, deems necessary to comply with the laws, regulations, rules or agreements of or in relation to any applicable jurisdiction or blockchain, including but not limited to judicial decrees, order, processes or arbitral awards. Such documents or information shall include, but not be limited to, certified copies of Member's passport, utility bills, government identification cards, sworn statements and information and documentation relating to persons or entities affiliated with Member. Member expressly and irrevocably consents to the disclosure of such information and documentation, and the recording or making of copies thereof, required for compliance with any laws, regulations, rules or agreements of or in relation to any applicable jurisdiction or blockchain. Failure by Member to comply with any such request for information or documentation may result in measures taken against such Member, including but not limited to the unregistering of such Member as a member the eosDAC.
By accepting and holding any Tokens, Member represents and warrants that, to the extent required by any applicable law, Member complies with all anti-money laundering and prevention of terrorism rules, regulations and procedures and neither Member nor any person for whom Member is acting as agent or nominee in relation to the Tokens is subject to any sanctions administered or enforced by any government or regulatory body, or is organized or resident in any country or territory that is subject to any country or territory wide sanctions by any government or regulatory body, or is a politically exposed person.
Risks
Member acknowledges, understands and agrees that acceptance and holding of Tokens and storage thereof involves various risks and Member accepts the Tokens and membership of the eosDAC subject to such risks, as set out in the T&C and otherwise, without any claim, right or remedy that Member may otherwise have at law, equity or otherwise, including but not limited to any claims for compensation, damages, refunds or redemptions, against BlockMaker Ltd, eosDAC or any member, employee, officer, director, consultant, advisor, parents, subsidiary, affiliate, servant or agent, past, present or future, thereof.
Member acknowledges, understands and agrees to the risk that eosDAC may not be able to launch its network, develop its operations and/or provide any benefits to Member and, accordingly, prior to acceptance of Tokens, Member confirms that it has considered the risks, costs, and benefits of acceptance of Tokens, the Token Distribution, the T&C and membership of the eosDAC, and, if necessary, shall have obtained any and all independent and professional advice in this regard.
Member acknowledges, understands and agrees that Tokens and/or membership of the eosDAC shall, beyond such benefits set out in the Constitution, have no rights, uses, purpose, attributes, functionalities or features express or implied.
Member acknowledges, understands and agrees that all matters set out in the T&C, Constitution and Website are new and untested and that the eosDAC and related technology may not be capable of completion, implementation or adoption and, even if the eosDAC and related technology is completed, implemented and adopted, it may not function as intended and/or many not have the functionality that is necessary or desirable and/or may become outdated and/or may be subject to technical errors and delays.
Member acknowledges, understands and agrees that the software associated with the eosDAC is under development, may undergo significant modifications over time and new related or replacement software may be developed from time to time and such development and modifications may result in added or reduced features to those set forth in this T&C, the Constitution and/or the Website.
Member acknowledges, understands and agrees that the development of the eosDAC and related software may be abandoned for a number of reasons including but not limited to lack of interest from Members or potential Members, lack of funding, lack of prospects or the departure of valuable personnel and technicians related to or utilized by the eosDAC.
Member acknowledges, understands and agrees that Tokens may be or become non-transferrable following Member's acceptance of Tokens pursuant to the Token Distribution or thereafter, whether by reason of the Constitution or by technical error or inability, and/or may not be tradable on any exchanges.
Member acknowledges, understands and agrees that the following further risks relate to the governance and/or operations of the Tokens and eosDAC:
(a) Strong competition resulting in difficulty of eosDAC being voted/appointed as a main block producer of EOS blockchain;
(b) Insufficient capacity to effectively implement activity and decisions of the eosDAC;
(c) Crypto market crash and/or low EOS token inflation resulting in token payments being insufficient to cover operating costs of eosDAC;
(d) Governance of eosDAC being subject to the control by small self interested groups;
(e) DDoS or "flood attacks";
(f) Regulatory and Legal threats;
(g) Inappropriate content on EOS blockchain;
(h) Governance paralysis or other inability to reach quorum or effect governance decisions;
(i) Difficulties arising from use of block production revenue to pay for infrastructure including but not limited to difficulties in exchange of EOS tokens for fiat currency;
(j) Delays in implementation of EOSIO software.
Member acknowledges, understands and agrees that the regulatory status of decentralized autonomous communities, cryptographic tokens, digital assets, blockchain technology and distributed ledger technology is unsettled and/or unclear in many jurisdictions, and it is difficult to predict how or whether international, governmental, regulatory and judicial authorities will regulate such technologies and organizations and how or whether such international, governmental, regulatory and judicial authorities may interpret or modify existing laws, regulations or rules that affect such matters. Member acknowledges, understands and agrees that such interpretation or modification may have adverse consequences to the Tokens, and their holders and usage thereof, and the eosDAC; such interpretations and modifications including but not limited to characterizing the Tokens as regulated financial instruments or characterizing the eosDAC as a regulated investment vehicle. Member acknowledges, understands and agrees the eosDAC may cease operations in any jurisdiction, and discontinue membership of any persons residing or affected by any jurisdiction, in the event that the laws or regulations in such jurisdictions render it unlawful or commercially undesirable to maintain any link with such jurisdictions.
Member acknowledges, understands and agrees that the embryonic nature of decentralized autonomous communities, cryptographic tokens, digital assets, blockchain technology and distributed ledger technology may result in increased and/or disproportionate oversight and scrutiny from international, governmental, regulatory and judicial authorities with respect the Tokens and/or the eosDAC (or persons or entities related to or interacting therewith) and that there can be no assurance that such authorities will not examine same or pursue investigatory, enforcement, compliance or other actions against the Tokens or the eosDAC and members thereof (or persons or entities related thereto or interacting therewith). Member acknowledges, understands and agrees that such actions may subject the eosDAC and/or its members to judgments, settlements, fines or penalties and/or may cause the eosDAC to restructure the organization and the benefits and obligations thereunder and lead to damage to the eosDAC's reputation, operational costs or effectiveness.
Important Disclaimers
The T&C, Website, Token Distribution and membership of the eosDAC are not intended to, and shall not, be considered as an invitation to any person enter into an investment and are not intended to, and do not, constitute or relate in any way as an offering of securities in any jurisdiction. Neither the T&C nor the Website includes or contains any information that may or should be considered a recommendation or that may be used as a basis for any investment decision.
Any information in the T&C or Website is given for general information purpose only and neither BlockMaker Ltd nor eosDAC r any member, employee, officer, director, consultant, advisor, parent, subsidiary affiliate, servant or agent, past, present or future, thereof, shall be construed as providing any representation or warranty as to the accuracy and completeness of such information.
The Tokens are not, and are not intended to be, shares or securities of any type and do not entitle the holder thereof to any ownership or other interest in BlockMaker Ltd or any person or entity related thereto, and are merely the representation of the holder's entitlement to membership of the eosDAC and the means by which the governance of the eosDAC is effect.
Neither the T&C nor the Website contains, or should be considered to, contain any representations, warranties, promises or guarantees, express, implied or statutory, arising or related to the Tokens or the eosDAC and same are expressly disclaimed, including but not limited to any representations, warranties, promises or guarantees, express, implied or statutory, relating to title, non infringement, merchantability, usage, suitability or fitness for any particular purpose, or as to workmanship or technology (including technical coding), or the absence of any defects, whether latent or patent.
By accepting Tokens, Member accepts the T&C, including but not limited to the waiver by Member of any claim, right or remedy that Member may otherwise have at law, equity or otherwise, against BlockMaker Ltd, eosDAC and any member, employee, officer, director, consultant, advisor, parent, subsidiary affiliate, servant or agent, past, present or future, thereof, arising out of or related to the usage of the Token or the membership of the eosDAC, save and except with respect to the benefits and obligations expressly set out in the Constitution.
eosDAC shall use best endeavours to develop, launch and carry out the decentralized autonomous community, the software and blockchain tokens to enable membership of the decentralized autonomous community, effect automated governance thereof and the operations of the decentralized autonomous community, all as described in the Constitution and the Website. There is, however, no guarantee (and any such guarantee is expressly disclaimed by the T&C) that such decentralized autonomous community, software and blockchain token and/or operations shall be successfully delivered or realized as described in this T&C, the Constitution or the Website, or at all. Member acknowledges, understands and agrees to said risks, and further, to the fullest extent permitted by law, and in relation to same, expressly waives, relinquishes and releases, as against BlockMaker Ltd, eosDAC and any member, employee, officer, director, consultant, advisor, parent, subsidiary affiliate, servant or agent, past, present or future, thereof (collectively "Disclaimed Parties"), any claim, right or remedy that Member may otherwise have at law, equity or otherwise.
To the fullest extent permitted by law, and except as otherwise expressly stated in this T&C, the Disclaimed Parties disclaim any representations, warranties, promises or guarantees arising out of or related to BlockMaker Ltd, the Token Distribution, the Website, the Tokens and/or membership of the eosDAC, the eosDAC, and further, to the fullest extent permitted by law, and in relation to same, Member expressly waives, relinquishes and releases, as against the Disclaimed Parties, any claim, right or remedy that Member may otherwise have at law, equity or otherwise.
Member expressly acknowledges, understands and agrees that it is accepting and holding the Tokens and maintaining membership of the eosDAC, at Member's sole risk and that same are provided to, and used and acquired by, Member on an "AS IS" and "AS AVAILABLE" basis without any representations, warranties, promises or guarantees whatsoever by the Disclaimed Parties and Member shall have relied on its own examinations and investigations thereof and further, to the fullest extent permitted by law, and in relation to same, Member expressly waives, relinquishes and releases, as against the Disclaimed Parties, any claim, right or remedy that Member may otherwise have at law, equity or otherwise.
Member expressly acknowledges, understands and agrees that eosDAC may be considered an unincorporated association and, notwithstanding any provisions of the T&C or Constitution, any liabilities incurred by or attributed to the eosDAC may be considered as the unlimited liabilities of each Member of the eosDAC, jointly or severally.
Limitation of Liability
To the fullest extent permitted by applicable law, neither BlockMaker Ltd, eosDAC nor any member, employee, officer, director, consultant, advisor, parent, subsidiary affiliate, servant or agent, past, present or future, thereof ("Released Parties"), assumes any liability or responsibility for any loss arising or related to the Token Distribution or any transfer or assignment of Tokens, or any technical, interruption or malfunction of thereof.
To the fullest extent permitted by applicable law, Member disclaims any right or cause of action against the Released Parties, of any kind and in any jurisdiction, that would give rise to any damages, losses, liabilities, costs or expenses of any kind, whether direct or indirect, consequential, compensatory, incidental, actual, exemplary, punitive or special and including, without limitation, any loss of business, revenues, profits, data, use, goodwill or other intangible losses (collectively, "Damages") whatsoever, on the part of any of the Released Parties. Each of the Released Parties shall not be liable to Member for any type of Damages, even if and notwithstanding the extent any of the Released Parties has been advised of the possibility of such Damages. Member agrees not to seek any refund, compensation or reimbursement from any of the Released Parties, regardless of the reason, and regardless of whether the reason is identified in the T&C.
Without prejudice to the foregoing, in no circumstances shall the aggregate liability of the Released Parties, whether in contract, warrant, tort or other theory, for Damages to Member under this T&C exceed the amount of monetary value received by BlockMaker Ltd or eosDAC (if any) in exchange for the Member's acceptance and holding of the Tokens pursuant to the Token Distribution.
Member acknowledges, understands and agrees that none of the Released Parties shall be liable, and such Released Parties disclaim all liability to Member, in connection with any force majeure event, including acts of God, labour disputes or other industrial disturbances, electrical, telecommunications, hardware, software or other utility failures, software or smart contract bugs or weaknesses, earthquakes, storms, or other nature-related events, blockages, embargoes, riots, acts or orders of government, acts of terrorism or war, technological change, changes in interest rates or other monetary conditions, and, for the avoidance of doubt, changes to any blockchain-related technology.
To the fullest extent permitted by applicable law, Member releases the Released Parties from any and all responsibility, liability, claims, demands, and/or Damages of every kind and nature, known and unknown (including, but not limited to, claims of negligence), including but not limited to claims arising out of or related to disputes between Member and the acts or omissions of third parties, save and except with respect to the benefits and obligations expressly set out in the Constitution.
Indemnification: To the fullest extent permitted by any applicable law, Member shall indemnify, defend and hold harmless and reimburse the Released Parties from and against any and all actions, proceedings, claims, Damages, demands and actions (including without limitation fees and expenses of counsel), incurred by any of the Released Parties arising from or relating to: (i) Member's acceptance or use of Tokens; (ii) Member's responsibilities or obligations under the T&C; (iii) Member's breach of or violation of the T&C; (iv) any inaccuracy in any representation or warranty of Member; (v) Member's violation of any rights of any other person or entity; and/or (vi) any act or omission of Member that is negligent, unlawful or constitutes willful misconduct. The Released Parties, or any of them, reserve the right to exercise sole control over the defense, at Member's expense, of any claim subject to indemnification hereunder. This indemnity is in addition to, and not in lieu of, any other indemnities set forth in the T&C and/or Constitution.
Transfer of Tokens
Member acknowledges, understands and agrees that Tokens shall be transferable, and membership of the eosDAC assignable upon transfer of Tokens, in the manner set out in the Constitution.
As at the date of transfer of the Tokens, as determined in accordance with the Constitution, the transferee thereof shall be entitled and subject to all unrealized benefits and obligations accruing to or with respect to the Tokens or in the membership of the eosDAC at such date and all benefits and obligations thereafter, and the transferor shall, as at said date of transfer and thereafter, cease to be entitled or subject to any benefits or obligations with respect to the transferred Tokens, or in the membership of the eosDAC.
As at the date of transfer of Tokens, the transferee thereof shall, upon acceptance and holding of such Tokens, be bound by the terms and conditions of the T&C.
Entire Agreement and Severability
This T&C, including any exhibits attached hereto and the materials incorporated herein by reference, constitutes the entire agreement between the parties hereto and supersedes all prior or contemporaneous agreements and understandings, both written and oral, between such parties with respect to the subject matter hereof, including, without limitation, any public or other statements or presentations made by any of BlockMaker Ltd, eosDAC or any member, employee, officer, director, consultant, advisor, parent, subsidiary affiliate, servant or agent, past, present or future, thereof.
If any of the provisions of this T&C are deemed to be invalid, void or unenforceable under applicable law, the remaining provisions shall continue in full force and effect.
Electronic Communications
Member agrees and acknowledges that all agreements, notices, disclosures and other communications provided to Member pursuant to the T&C or in relation to Member's acceptance and holding of Tokens, including but not limited Member's acceptance and holding of Tokens pursuant to the Token Distribution, may be provided to Member in electronic form.
Applicable Law
The governing law for the purposes only of the interpretation and construction of the provisions of the T&C, and the contractual relations created thereby, shall be the laws of Anguilla.
Dispute Resolution
Informal Dispute Resolution: Member shall cooperate in good faith to resolve any dispute, controversy or claim arising out of, relating to or in connection with the T&C, including with respect to the formation, applicability, breach, termination, validity or enforceability thereof ("Dispute"). If the parties to any Dispute are unable to resolve a Dispute within ninety (90) days of notice of such Dispute being received by all parties thereof, such Dispute shall be finally settled by Binding Arbitration, as defined hereinafter.
Binding Arbitration: Any Dispute not resolved within 90 days as set forth hereinbefore shall be referred to and finally resolved by arbitration under the London Court of International Arbitration (LCIA) rules in effect at the time of the arbitration, except as they may be modified herein or by mutual agreement of the parties to such arbitration. The number of arbitrators shall be one who shall be selected by the parties to the arbitration. The seat, or legal place, of arbitration shall be London, England. The language to be used in the arbitral proceedings shall be English. The governing law of the T&C, for the purposes only of the interpretation and constructions of the provisions of the Constitution, and the contractual relations created thereby, shall be the laws of Anguilla. The arbitration award shall be final and binding on the parties thereto ("Binding Arbitration"). Member undertakes to carry out any award without delay and waive its right to any form of recourse insofar as such waiver can validly be made. Judgment upon the award may be entered by any court having jurisdiction thereof or having jurisdiction over the relevant party or its assets. Without prejudice to any indemnification provision of the T&C, each party to arbitration shall pay their respective attorneys' fees and expenses.
No Class Arbitrations, Class Actions or Representative Actions: Any dispute arising out of or related to the T&C shall be personal to the parties to the arbitration and shall not be brought as a class arbitration, class action or any other type of representative proceeding. There shall be no class arbitration or arbitration in which an individual attempts to resolve a dispute as a representative of another individual or group of individuals.
57. The provisions of the T&C relating to Dispute Resolution shall become operational only in the event that the relevant dispute does not fall within the ambit and/or jurisdiction of the dispute resolution provisions set out in the Constitution of the eosDAC. To the extent that any dispute falls within the ambit and/or jurisdiction of the Constitution of the eosDAC, whether exclusively or concurrently with the T&C, Member shall first and exclusively seek dispute resolution pursuant to the dispute resolution provisions of the Constitution.
I accept the Constitution Constitution Hash: 51c6a3db7c90801f81cdd2645228aa47
name::
* McsEngl.Eosdac'resource@cptIt,
_ADDRESS.WPG:
* https://eosdac.io/
* https://members.eosdac.io/wallet
name::
* McsEngl.Eos-app.EVERIPEDIA@cptIt,
* McsEngl.Everipedia@cptIt,
_ADDRESS.WPG:
* https://everipedia.org/wiki/everipedia-whitepaper/
* https://github.com/EveripediaNetwork
* editing: https://everipedia.org/wiki/everipedia-tutorial-english//
===
* {2018-10-05} https://cryptovest.com/news/wikipedia-co-founder-talks-about-blockchain-based-competitor-everipedia-at-malta-delta-summit/
* https://hackernoon.com/the-revolution-of-knowledge-how-everipedia-is-decentralizing-history-6eb44bb9ea75,
* https://jaxenter.com/everipedia-blockchain-moghadam-interview-141261.html?
name::
* McsEngl.Everipedia'page@cptIt,
_DESCRIPTION:
Everipedia is just like Wikipedia but much simpler to edit and contribute.
Each page is composed of
- an infobox area for short concise facts,
- a main article written in a neutral 3rd person tense,
- a media gallery of pictures, videos, audio etc about the topic,
- a list of references to webpages and files that are used as citations in the article and infobox.
[Help]
name::
* McsEngl.Everipedia'link@cptIt,
_DESCRIPTION:
To link to another Everipedia page click the 'Link Page' button. You can also press the '@' or key when typing and a dropdown should appear. Try to link to as many pages as necessary to make each page as rich and informative as possible.
name::
* McsEngl.Everipedia'infobox@cptIt,
_DESCRIPTION:
The infobox is designed for concise, quick facts.
Suggested items appear in the dropdown depending on the selected topic, but any type of infobox can be added.
name::
* McsEngl.Everipedia'references@cptIt,
_DESCRIPTION:
As you add links and files, they will show up in the Reference Links section. You can edit or remove them as well.
Make sure to cite your sources when adding information to the page by adding links and files here so you can show where the information is coming from.
name::
* McsEngl.bcnnet.IBM-Blockchain@cptIt,
* McsEngl.bcnnet.ibm@cptIt,
_ADDRESS.WPG:
* http://www.ibm.com/blockchain//
_DESCRIPTION:
the tech giant recently announced the development of its independent Blockchain network that is capable of operating on smart contracts for the world’s leading financial institutions and businesses, and the release of its report that suggests the technology will be implemented by 15 percent of big banks by 2017.
[https://cointelegraph.com/news/ibms-next-step-in-launching-one-of-the-worlds-largest-blockchain-implementations]
name::
* McsEngl.bcnnet.KSI@cptIt,
* McsEngl.bcnnet.KSI@cptIt,
_DESCRIPTION:
Blockchain meets Security
Keyless Signature Infrastructure (KSI) is designed to provide scalable digital signature based authentication for electronic data, machines and humans.
Unlike traditional approaches that depend on asymmetric key cryptography, KSI uses only hash-function cryptography, allowing verification to rely only on the security of hash-functions and the availability of a public ledger commonly referred to as a blockchain.
A blockchain is a distributed public ledger; a database of transactions such that there is a set of pre-defined rules as to how the ledger gets appended, achieved by distributed consensus of participants in the system.
The KSI blockchain overcomes three major weaknesses of mainstream blockchain technologies - which were designed to facilitate asset transactions - making KSI suitable also for cybersecurity and data governance applications:
Scalability: One of the most significant challenges with traditional blockchain approaches is scalability – they scale at O(n) scale complexity, meaning they grow linearly with the number of transactions. In contrast the KSI blockchain scales at O(t) space complexity – it grows linearly with time and independently from the number of transactions. KSI can sustain billions of asset registration events every second without growing out of control.
Settlement time: In contrast to the widely distributed crypto-currency approach, the number of participants in KSI blockchain distributed consensus protocol is limited. By limiting the number of participants it becomes possible to achieve consensus synchronously, eliminating the need for Proof of Work and ensuring settlement can occur within one second.
Formal security proof: Unlike other blockchains, KSI blockchain has been subjected to end-to-end formal mathematical proof that provides assurance that the protocol does precisely what it says it does.
[https://guardtime.com/technology/ksi-technology]
name::
* McsEngl.bcnnet.Expanse (EXPnet {2015})@cptIt,
* McsEngl.Expanse-network@cptIt,
* McsEngl.expnet@cptIt,
_DESCRIPTION:
bcnrrr
A-fork to ethereum.
Docs are a-copy of Ethereum with ONLY a-chage in name!?
name::
* McsEngl.expnet'Resource@cptIt,
_ADDRESS.WPG:
* http://www.expanse.tech//
* https://bitcointalk.org/index.php?topic=1173722.0,
* https://docs.google.com/document/d/1ITNRmZ0dTse-aZqjbWiC9w1n2XpPvKyl4J9BP-liuxw//
* https://github.com/expanse-org,
name::
* McsEngl.Bcnnet.Humaniq (HMQnet)@cptIt,
* McsEngl.Humaniq@cptIt,
_DESCRIPTION:
Launched in 2016, Humaniq is designed for those who don’t possess identification, with the mobile app utilizing a new reputation concept based on facial recognition for identity management. The fourth-generation mobile bank is based on the Ethereum blockchain and is attempting to tackle the global problem of financial exclusion for those who don’t have bank accounts. It is set to launch the first version of its mobile app on iOS and Android.
Initially, the alpha version of the application is by invitation only to 1,000 people; however, they expect to conduct a global rollout by October.
Speaking to Bitcoin Magazine, Alex Fork, founder of Humaniq, said that when he was talking with Ethereum co-founder Vitalik Buterin at a conference last year, he was struck by how blockchain technology can be a solution to improve the lives of disadvantaged people. After seeing that the current system doesn’t work, Fork decided to create his own tool.
“Unbanked people find it difficult to use banks for three main reasons: lack of ID, lack of minimum funds and geographical distance to the nearest branch,” he said. “We’re using facial and voice recognition technology for new user sign-up.”
[https://bitcoinmagazine.com/articles/humaniq-aims-tackle-barriers-economic-inclusion-blockchain-app/]
_GENERIC:
* dependent-bcnnet#ql:idBcnnetDpt#, (Ethereum)
name::
* McsEngl.hmqnet'Protocol@cptIt,
name::
* McsEngl.hmqnet'White-paper@cptIt,
Humaniq Whitepaper
Alex Fork[-†-#ql:idHmqwprnot0#]
The Humaniq team is building a next generation model for financial services (Banking 4.0) which is based on Blockchain technology, mobile devices and biometric identification systems.
We will use cryptofinancing (Initial Coin Offering) for growth capital rather than traditional venture capital and shareholders.
Our aim is to empower a market of 2 billion people who currently don’t have access to banking across the world.
Almost half the world — over three billion people — live on less than $2.50 a day.
At least 80% of humanity lives on less than $10 a day.
More than 80 percent of the world’s population lives in countries where income differentials are widening.
We believe Humaniq can help reverse these trends and help bring people out of poverty by giving them banking tools that can provide liquidity for entrepreneurial ventures via loans, investment, online work and cryptofinancing as well as create new opportunities in the digital economy, locally, nationally and internationally.
Humaniq can also help mitigate the refugee crises occurring in many countries in the West due to economic disparity and lack of opportunities in emerging economies.
Our unique selling proposition (USP) in the digital banking market is our use of Blockchain technology combined with biometrics and a focus on mobile technology.
We plan to not only provide a software solution but also bring mobile hardware (phones) into the markets we are aiming for in Africa, Asia and South America.
“A small body of determined spirits fired by an unquenchable faith in their mission can alter the course of history.”
Mahatma Gandhi
# idHmqwprfig1#Look at this map:
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgHmqwprFig1.png!#
Figure 1: indeed, where they are?..
You may notice: there are unbanked regions on Earth.
As a matter of fact, nearly 2.5 billion people live in regions where no banking infrastructure exist.
The only form of payment available in those regions is manually giving banknotes (and/or coins) to a counterparty.
What makes it worse, even in banked regions, there are millions of people without passports or any other forms of identity or documentation, thus they are cut off from modern banking facilities.
According to a recent World Bank estimate, the total number of people who did not have identification documents amounted to 1.5 billion by 2016.
We at Humaniq, will provide a new financial infrastructure for everyone who has a smartphone with a camera.
The smartphone is necessary to make and receive payments, and the camera is needed to earn the first coins.
The price of smartphones is falling every year and they are currently priced at between $10-$20 on the low end.
# idHmqwprfig2#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgHmqwprFig2.png!#
Figure 2: 2.5 billion adults are unbanked
To put it in simple words, Humaniq is banking for the unbanked.
Our ultimate goals are:
? to integrate 2.5 billion people disconnected from the international business community, and empower them to free themselves from the chains of poverty,
? to shift emerging economies into the cryptoeconomy.
“The biggest room in the world is the room for improvement.”
Helmut Schmidt
It is natural to ask why the problem of banking for the unbanked cannot be solved by Bitcoin or any other cryptocurrency.
And the questions can also be asked: «What makes Humaniq special?», «Are you just another startup offering yet another mobile wallet app?»
At first glance, it looks like any Bitcoin mobile wallet could be used in unbanked regions.
But if you think deeper about this, you will discover the following issues:
? The problem: the number of satoshis in circulation (or any other small units of crypto) is insufficient for some regions.
E.g., in Indonesia (250 million people), there’s just not enough digital currency to have substantial daily turnover (volume).
Bitcoin is scarce, and if you don’t have bitcoins, you are inclined not so to be interested in the network.
For regions poorly integrated into the international financial system, it would take a lot of time for sufficient liquidity to appear in the local market.
But there’s no doubt that such regions have their own domestic economy today.
It’s just they are almost exclusively cashbased.
? Our solution: unlike other cryptocurrencies, Humaniq provides an egalitarian emission mechanism.
The amount of coins that one person can mint is limited, and this is what makes Humaniq so special.
This mechanism has nothing to do with competing in specialized hardware, having access to specialized hardware, wasting electricity, or owning the coins preliminarily.
It may be called proof-of-face, and nothing is more fair than that.
? The problem: the lack of local exchanges.
Even now in 2017, there are lots of countries where no infrastructure to buy or sell cryptocurrency exists.
This is the issue even for some European countries, which have no problems with Internet adoption and where virtually the entire population is using smartphones.
We’d like to stress that it has been more than 8 years since the first cryptocurrency launched, and more than 7 years since the first cryptocurrency exchange ever appeared.
? Our solution: since our platform provides infrastructure for people to earn Humaniq coins from home, we understand that people would eventually like to exchange cryptocurrency for local currency.
Of course, we provide such infrastructure in our app.
(And still, we are in talks with some national and international shopping franchises in various countries we are targeting — and engaging them to add Humaniq as a payment option.)
? The problem: some states are concerned with pseudo-anonymity of cryptocurrencies, which causes recurring legal issues associated with them.
? Our solution: since app users have to pass bio-identification, there is no anonymity in Humaniq.
That is good news for transparency advocates, and that makes Humaniq unviable for financing terrorism, trading drugs and all the other deadly sins Bitcoin is accused of.
Another point is, Humaniq provides the ability to earn while working from countries abroad.
This enables an export-driven economy in depressed regions, improves living standards of depressed regions, and reduces the impetus for migration, which is great for all governments both in developed and in developing countries.
? The problem: the network effect of Bitcoin (and other cryptocurrencies) is relatively small because of relative usage complexity.
According to the report from Juniper Research, the number of active Bitcoin users around the world could reach 4.7 million people by the end of 2019.
Even now the network has reached the capacity limit of 250 thousand transactions.
Eight years of the Bitcoin era have passed; compared to PayPal, after 8 years it had 100 million active accounts, despite the fact that it appeared with less developed online infrastructure and can require passport details for use.
? Our solution: we discarded the private and public key approach, which confuses newcomers; we also had to reject using fractional amounts of coins, since decimal fractions may be uneasy for people with little or no education.
It’s very simple.
Coins are whole numbers (integers), faces are used as passwords — if you think it gets any easier than that, please tell us what could be simpler.
? The problem: complexity of reputation accounting in anonymous communities, needed for various p2p-solutions (p2p-insurance, p2pbanking).
? Our solution: we handle this problem with our bio-identification procedure.
By the beginning of 2017, elegant solutions for biometric authentication already exist.
If we take a combination of authentication methods it increases the likelihood of a near hundred-percent authentication.[-1-#ql:idHmqwprnot1#]
Our approach is to use one random authentication method each time.
Every authentication takes no more than two seconds and is as easy as unlocking a smartphone.
? The problem: the lack of crypto evangelists in undeveloped regions, which contributes to people’s unawareness of innovative payment systems.
? Our solution: the reasons why people don’t promote cryptocurrencies in undeveloped regions are understandable: technical complexity of the subject, language difficulties, no financial incentive etc.
But we’ve targeted our project directly at such regions.
Working on the problem, we have studied nearly everything about the current state of developing countries.
We talked to ~100 prominent bitcoiners who live in developing countries such as Sierra Leone, Afghanistan, Botswana, Pakistan and Indonesia.
Dozens of them decided to enter our Humaniq Ambassador Program: they will teach people about how to use Humaniq and earn cryptocurrency for that.
This is why Bitcoin or any other crypto isn’t used in unbanked regions.
And won’t be used.
The currency of unbanked regions (the dark ones on Figure-1#ql:idHmqwprfig1#) is called Humaniq.
“Visions are worth fighting for. Why spend your life making someone else’s dreams?”
Tim Burton
In Humaniq, the amount of coins that one person can mint is limited, and that is what makes Humaniq truly special.
This may sound really strange for an experienced crypto-community member.
How did we achieve this?
We did it with the help of bio-identification.
Our bio-identification has to be passed only once, taking less than 20 seconds and does not require to have any e-mail or passport.
And modern face recognition algorithms for neural networks can check one’s identity with incredible accuracy.
Briefly, bio-identification is obligatory to create a wallet; every user is given coins for passing bio-identification; the process consists of taking series of photos, recording videos of the user making facial gestures, and recording the user’s speech.
For details, move to subsection-9.3#ql:idHmqwpr93#.
To prevent theft of coins, every time a user signs in into the app, he or she must pass the authentication procedure.
The authentication is similar to bio-identification, but much shorter: the user has to repeat just one of the recorded gestures in the front of the camera.
It is as easy as unlocking a smartphone.
The software we have developed works with the cheapest hardware solutions on Android 5.0: with smartphones that cost $10-$15.
Such affordable devices are usually fitted with a front-facing camera and microphone, and thus are sufficient to install a mobile wallet and to authenticate the user.
After passing the bio-identification, everyone is invited to earn additional coins by inviting friends and making transactions.
Moreover, we enable the possibility for everyone to earn a living with their mobile phones, and that’s what is truly impressive.
You may ask — how?
Well, we work with local companies and brands to achieve this.
Our cherished will is to make Humaniq the de facto currency of the world where over three billion people live on less than $2.50 a day.
Humaniq can give these people the opportunity to break free from poverty, improving the lives of their families and themselves by entering and helping create a new mobile digital economy.
Imagine now... over two billion users improving capitalization of popular services by getting used to them — isn’t that what brands dream of?
Isn’t that why Facebook is making a play with internet.org?
Our user may purchase a smartphone perhaps even with a loan — and after the purchase, cover his or her expenses within several weeks, by executing simple actions.
“Cryptoeconomic system may contain its own currency and token system which would be useful in any sense in some system aspect. Units of currency can be generated by the system and then sold or distributed directly as award for participation in system operation.”
Vitalik Buterin
We feel honored to repeat it once more: Humaniq provides an egalitarian emission mechanism.
The amount of coins that one person can mint is limited, and that is what makes Humaniq so special.
This mechanism has nothing to do with competing in specialized hardware, having access to specialized hardware, wasting electricity, or owning the coins preliminarily.
It may be called proof-of-face, as we’ve mentioned, and there’s nothing more fair than that.
In this section, we are about to present the details of the emission model we chose.
Developing it, we pursued the following objectives:
1) The early adopters should receive more money than the later ones.
2) The total amount of coins that will ever be issued must be five times bigger than the amount of coins issued via Pre-ICO + ICO.
3) Emission proceeds until kmax people are registered. kmax should be relatively big.
4) In average, one user is granted with 500 coins.
5) Tokens are issued by the smart contract upon request.
6) Emission per one person is carried out not by one-time payment[-2-#ql:idHmqwprnot2#], but in accordance with a scoring function which depends on the person’s activity: passing through bio-identification, inviting friends, making transactions.
Let E(k) be the amount of HMQ coins that may be granted to the person who was k-th to pass the bioidentification in the Humaniq app (the user number k).
The objective number 1 tells that the function E(k) should be decreasing one.
We chose the simplest decreasing function — the linear one:
E(k) = Emax - (Emax - Emin / kmax) · k
Thus, at k = 0 E(k) = Emax, and at k = kmax the correspondence E(k) = Emin holds.
We chose Emax equal to 860, and Emin equal to 140.
Finally for the maximum possible amount for the k-th video registrant
E(k) = round (860 - 720/kmax · k) (4.1)
Let us draw a graph showing the controlled supply of coins:
# idHmqwprfig3#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgHmqwprFig3.png!#
Figure 3: The distribution of Humaniq coins. Red line represents the maximum possible amount of coins a user can be granted with respect to the scoring function. Blue line represents the number of coins that the user is granted if his or her only action is passing bio-identification.
Denote the total amount of coins sold via Pre-ICO + ICO by Vico.
According to the objective number 2, only 4Vico coins will be earned by users of the Humaniq app.
Thus, the maximum possible amount of Humaniq coins is limited by 5Vico.
The objective number 4 states that the total average number of coins that a user can mint in-app must be close to 500, thus giving immediately follows.
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgHmqwpreqn42.png!#
This provides the restriction upon the total amount of people who can mint the tokens in-app.[-3-#ql:idHmqwprnot3#]
We use the conventional rounding
function to guarantee that kmax is integer.
The scoring function mentioned in objective number 5 describes how people can earn their E(k) coins in the Humaniq app.
It is structured as follows:
(denoting the HMQ/USD exchange rate by r, so that 15r becomes the Humaniq equivalent of $15)
• mobile app installation — min(round(0.01 · c1 · E(k)); 15r) HMQ
• receiving first coins from a friend — min(round(0.04 · c2 · E(k)); 15r) HMQ (one-time payment)
• passing the bio-identification — min(round(0.15 · c3 · E(k)); 15r) HMQ (one-time payment)
• a referred friend passed bio-identification4 — min(round(0.1 · c4 · E(k)); 15r) HMQ (for every 5 first friends invited)
• execution of a transaction within first month after installation — min(round(0.05 · c5 · E(k)); 15r) HMQ (one-time payment)
• execution of a transaction within second month after installation — min(round(0.1 · c6 · E(k)); 15r) HMQ (one-time payment)
• execution of a transaction within the third month — min(round(0.15 · c7 · E(k)); 15r) HMQ (one-time payment)
• additional earning opportunities are provided by local and global startups and senior companies.
For moments when exchange rate HMQ/USD diminishes, the emission can be delayed.
The exchange rate is treated diminished, if
current rate < average rate for the last week.
By the start, every coefficient in the tuple (c1, c2, c3, c4, c5, c6, c7) is set to 1, but after some time these coefficients are going to become mutable.
For the first period of their mutability, the control over these coefficients will be community-driven, but eventually this control will be forwarded to a neural network, whose goal will be to maximize several reasonable metrics (the installations’ rate of growth, transactions’ number rate of growth).
Thus, the amount of HMQ that can be granted to a user is E(k), where k is the number of users who passed the identification before him or her.
The formula (4.1) can be used to calculate the potential benefit.
The earning opportunities aren’t limited by this.
Start-ups and senior companies pay additional amounts of HMQ to people executing their tasks.
The list of tasks available at you region can be found in the tab «Offers».
Our ultimate dream is that everyone could purchase the smartphone, install the Humaniq app and then cover his or her expenses on the same day, executing simple actions.[-5-#ql:idHmqwprnot5#]
That is why we tether our emission to the Humaniq equivalent of $15.
“Just as treasures are uncovered from the earth, so virtue appears from good deeds, and wisdom appears from a pure and peaceful mind.
To walk safely through the maze of human life, one needs the light of wisdom and the guidance of virtue.”
Buddha
Despite we have enough money to develop the project on our own, we think it is fair to allow everyone to invest in the project.
To make the procedure egalitarian, we have chosen to utilise cryptofinancing via an initial coin offering (ICO) rather than take on venture capital.
Moreover, a crowdsale is a brilliant way to attract media attention.
Our crowdsale has two stages — the Pre-ICO and the ICO. T
he Pre-ICO took place since 15 Dec 2016 till 28 Dec 2016.
The ICO starts by 6 Apr 2017, CET 00:00 and
ends by 26 Apr 2017, CET 23:59.
To buy Humaniq, the only payment options during the ICO are Bitcoin (BTC) and Ethereum (ETH).
During the ICO, the rates are as follows:
1 ETH buys 1000 HMQ (+ bonuses)
for BTC-buyers: your BTC counts as the equivalent amount of ETH[-6-#ql:idHmqwprnot6#]
We also offer the following bonuses for those who invest earlier:
6-7th of Apr + 49.9%
8-14th of Apr + 25%
15-21th of Apr + 12.5%
22-26th of Apr + 0%
Since all Humaniq balances are whole numbers (integers) and fractional amounts of coins are not possible (see subsection «Coins are integer» for the reasoning), we had to come with the solution for the arising subtlety.
We chose different ways to handle the problem of fractional HMQ for Bitcoin-using and Ethereum-using participants.
For Bitcoin participants, if the amount of HMQ to be bought is less than 112358 HMQ, rounding down is performed; otherwise, if a buyer wishes to buy more than 112358 HMQ, the amount of HMQ to be bought is rounded up.
For Ethereum participants, we decided to conduct bounce-back transactions (and hardcode them in the smart contract).
E.g. if you transfer 3.1415926 ETH and no bonuses are applied, you are about to receive 3141.5926 HMQ, but since HMQ balances are integer, the amount of ether equal to 0.5926 HMQ is sent back to you.
Participating in the ICO doesn’t require passing bio-identification.
Our fundkeepers are:
Alex Fork
George Basiladze
Bitcointalk user btcsec
The purpose of the Pre-ICO was to create a discussion on issues raised by the project, to attract the attention of leading experts in the industry, and to raise funds to prepare the promotion and public relations of the project, as well as prepare a quality ICO.
We chose the following rates for the Pre-ICO stage:
1 ETH buys 1500 HMQ (+ bonuses)
for BTC-buyers: for the whole Pre-ICO campaign,
we treated every your bitcoin as 93.5 ETH
We announced that if the amount collected is less than 10000 ETH, all funds will be returned. Fortunately, we collected[-7-#ql:idHmqwprnot7#] 99.002855 BTC and 3122.362977 ETH, which amounted to more than the announced threshold.
The following bonuses were available during the Pre-ICO stage:
First 12 hours + 70%
16th of Dec + 50%
17-19th of Dec + 33%
20-22nd of Dec + 20%
23-25th of Dec + 7%
26-28th of Dec + 0%
We are delighted to inform you that 31824818 HMQ tokens have already been distributed during the Pre-ICO (in complete accordance with these bonuses), and we look forward to our upcoming ICO, which will provide the answer on the final quantity of tokens that can ever be generated Vico and thus determine the constant kmax from (4.2).
All rewards and bounties were distributed within one week after the end of Pre-ICO, just as it was claimed.
“Success or failure of a team is determined by how its members communicate and interact.”
Ichak Adizes
Future Fintech keeps in contact with more than 200 fintech start-ups.
One of the challenges of most projects is access to the customer base.
This is why the implementation of our solution will help young projects (P2P lending, insurance, mobile wallets, scoring, freelance, etc.) offer their ideas to people who have no experience in the financial sector.
Therefore, the project will be developed as follows.
The main development team develops the core.
Others join later and develop their start-ups or solutions on a ready-made platform.
We use Github to bring the core team and third parties together.
We are open to get suggestions and ideas from ordinary users — from the Community.
We always keep in touch with them via the Humaniq app, as well as on Bitcointalk and on our brand blog on Medium.
Users also join us via our Slack channel, read the latest news on Facebook and Twitter, and participate in discussions on our subreddit.
# idHmqwprfig4#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgHmqwprFig4.png!#
Figure 4: join us to see how we work
Close interaction with users and testing an idea or a prototype on potential consumers allows us to make the right decisions and save resources.
This is why customer development greatly reduces the investor risk.
After all, theory often differs from practice, and developers’ opinions on ergonomics and ease of use may differ from the perceptions of the product’s end users.
Users often have their own understanding of a set of must have functions, and ignorance of their real needs can lead to the failure of the entire start-up.
As such, our analysts and trend watchers, together with the developers, will consider every feature request communicated by users in the community.
Some ideas greatly improve the product; but, at the same time, the development of one option can take an hour or two, while the implementation of another can take a few days.
Analysts and trend watchers will also evaluate the feasibility of each request and explore it within the context of market trends.
The developers, in their turn, will integrate them properly if new ideas are given thumbs up.
At the same time, budget and deadlines must be met.
Therefore, some ideas are rejected for one reason or another, while others form the list of tasks for the team of developers.
Thanks to this, analysts, trend watchers, investors, users, project managers and programmers themselves are always aware of the current development stage of a project.
Any interested user and even a developer can connect to it from various sides and get a respective reward:
• participate in beta testing;
• voice their ideas for improving the product in the Community;
• develop their start-up;
• become an analyst or a trend watcher.
As you can see, our project development scheme allows and supports the active participation of users.
Customer development allows us to create a product that meets their needs and wishes, which eventually ensures its success.
“The best way to predict the future is to create it.”
Peter Drucker
The milestones on this road are:
• 2016, October-November — Humaniq Whitebook is written
• 2016, December — Launch of Humaniq.co website.
• 2016, December — the pre-ICO.
• 2017, January-February — smart contract development, due diligence, marketing campaign
• 2017, February — a meeting with Humaniq project partners in India.
• 2017, February — announcing Humaniq online-hackathon in partnership with (yet undisclosed) well-known blockchain media
• 2017, February — the start of the ICO (crowdsale).
• 2017, April — headlining the BlockShow Europe 2017, giving talks on panel discussions, concluding results of the hackathon and giving awards to winners
• 2017, April — crowdsale concludes.
• 2017, May — prototype of Android mobile app.
• 2017, July — Product launch: the mobile app (wallet with bioID) + exchange app.
• 2017, September — global expansion in two directions: to underdeveloped regions (expansion of the network of users in Africa, Asia, South America) and to the cities that are crucial to modern business (London, Singapore, Hong Kong and San Francisco).
• 2018 — integration of virtual cards, of fintech start-ups, and further decentralization of Humaniq architecture.
“Architecture is inhabited sculpture.”
Constantin Brancusi
From the technical point of view, to implement the idea, the following ingredients are required:
1) mobile app, which is what users see.
We’re talking about Android app, since in underdeveloped regions market share of Android OS is close to 95%.
Making an iOS App is less important in our case, but for the sake of perfection we actively develop it.
2) appropriate bio-identification/authentication software
3) such software essentially produces a «chunk» of every person’s identity; these chunks are used for identification/authentication and must be stored somewhere in decentralized manner
4) these chunks must be encrypted
5) identification procedure must cost zero for end users (at least for the first time)
6) authentication procedure must cost zero for end users (at least for the first time)
7) secure consensus algorithm (e.g. robust blockchain)
8) transactions should cost zero for senders if possible.
To satisfy the first and second conditions, it is enough to build the apps, and to buy licensing rights for the best available bioID solution.
Chapter 9.2 is devoted entirely to how we made our choice of the solution.
To satisfy the third condition, we should allow every PC to become a Humaniq node.
On encryption (fourth condition), our approach is similar to Storj and (announced by Ethereum) Swarm’s one.
To meet the fifth condition, it is enough to specify in the protocol that nodes have to add «chunks» of a new person to their database, keep their databases synchronized, and are not paid for that.
It’s exactly like in Bitcoin: full nodes kept on their hard drives containing the ledger of all transactions that have ever happened without any financial incentive.
The sixth condition resolves like the previous one: people verify and broadcast identities of authenticating users for free.
Again, exactly like in Bitcoin: peers verify and broadcast new blocks and transactions, and nobody gets paid for that.
Speaking on condition eight, for the first few months of the network’s existence transaction fees will be zero for end users.
However, this is to be changed in future, since the founders cannot pay Ethereum fees forever.
We are about to decentralize the project architecture and to make it nondependent on founders, giving everyone the possibility to run a Humaniq node.
We are using Ethereum for the project and the ICO campaign because this platform allows us to create a secure solution quickly, with few resources, and without loss of quality thanks to:
• smart contracts (we plan to conduct the audit of our smart contracts);
• reliability of a ready and operating blockchain, in contrast to the risks associated with deploying own blockchain;
• future development of the Ethereum project and stated opportunities.
# idHmqwprfig5#
#!http://synagonism.net/dirMiwMcs/dirTchInf/filMcsBcnnet.files/imgHmqwprFig5.png!#
Figure 5: The inner structure of the Humaniq platform
The only tough issue is the centralization.
Humaniq has several components: software part, neural network and database.
In the future, all these components are to be decentralized.
Humaniq is based on blockchain technology.
Major component — transaction settlement will be done on Ethereum blockchain using Standard Token (ERC20) contract.
New tokens are emitted for every authenticated user and the rules of emission are controlled by «Emission smart contract».
Humaniq servers are responsible for authorization of users on the blockchain via Biometric ID services as well as approving additional token emission.
Users will only interact with Mobile Wallet for their smartphones.
Scrupulous readers may say that this system has a number of centralized places carrying risks.
But there are answers to this:
1. Each user can use the Ethereum client wallet without using additional services.
2. It should be admitted that Bitcoin protocol add-on services are used by an overwhelming majority of Bitcoin users; and this is the normal operation of a payment system, and our operation will be based on the same principles.
And since security issues are undertaken by Ethereum, this allows us to focus on the client-oriented decentralized business model.
3. With reference to bio-identification and mobile wallet, we will move towards open source and hereafter decentralization.
4. Besides the above-mentioned, the service development strategy is a decentralized business model, i.e. stimulating creation of several mobile wallets by third-party teams, chatbots, exchange services, service rendering.
5. Today there is no technological opportunity to put bio-identification into blockchain, however if there is a possibility to help people now, and to develop ecosystem of cryptoeconomics — it should be done.
There are three key components of Humaniq:
• the app (which is essentially also the mobile wallet)
• Humaniq servers
• contracts on Ethereum blockchain.
We understand that biometry is not finance, and we’re not specialists in this technology.
As a consequence, we’re actively working with various well-established companies, who specialize in computer vision and/or image recognition.
Hence, to execute bio-identification, we are going to invite a solution provider when we are ready to make the choice.
We have not yet signed any formal agreements, and, due to the high responsibility of this step, we are not rushing.
We plan to announce which service provider we have chosen and to provide corresponding formal agreements during the crowdsale.
During the first launch of the Humaniq app, one must pass through the
bio-identification procedure[-8-#ql:idHmqwprnot8#].
Otherwise, the Humaniq interface just won’t show up.
This bio-identification is arranged as follows.
A registrant is required to make a photo of themselves with the smartphone, to record a video of smiling and grinning, and to pronounce the text shown on the screen.
To avoid counterfeits, the device ID is added and the text is chosen at random out of very large pool; it eliminates the ability to use pre-prepared audio tracks.
All the instructions are shown on the mobile phone screen, so of course no prerequisite knowledge is needed to use the app; you don’t need to know anything about the app in advance.
You may download the app from Google Play and try it yourself.
This authentication method takes less than five seconds and requires no e-mail, SMS, passport, and you don’t have to worry about losing or forgetting your password.
This is the real proof of identity.
The Mobile Wallet is an interface for mobile (iOS, Android) users that provides them with quick access to their balances and lets them transact with other users/merchants.
The Mobile Wallet manages private and public keys for the user, which are used to sign transactions locally.
It also has a built-in module for collecting biometric user data, such as voice and video, which can be used to bind a user with their identity and provide them with additional features of the platform, such as action-based emission.
The Mobile Wallet also includes an API for third-party developers so they can interact with the Wallet: access balances, send transactions.
There are two contracts that are already deployed on the blockchain.
First one is Standard Token Contract (ERC20) that keeps track of user balances and allows them to transfer tokens between each other.
Second one is responsible for token emission.
However, we understand that with the decentralization proceedings we will be involved in the development of an ample web of contracts; follow our Github to stay keen on updates.
1. Transaction is generated on the smartphone and then signed using local
private key.
2. Signed transaction data is submitted to Humaniq servers.
3. Transaction is relayed to the Ethereum blockchain to the Humaniq
Token Smart Contract.
1. If the user already has Humaniq tokens they might transact directly
using Token smart contract bypassing Humaniq servers.
2. After signing the transaction user might send it directly to Ethereum
blockchain.
3. This brings an advantage of control over the transaction publication
and propagation (because there might be a delay due to a high load
on the Humaniq servers).
Any Humaniq balance cannot be fractional. It can only be integer.
We’re targeted at providing undereducated people with modern finance, and we don’t expect all of our users to be great at fraction calculus.
The integer amount of coins makes it easier for undereducated people to count their money.
The Humaniq project was launched to create a financial infrastructure for people who were previously isolated from it.
We are using the most advanced and mass technologies: the blockchain with the possibility to connect thirdparty projects, a mobile application, along with bio-identification.
Humaniq will also add to the science of cryptoeconomics, the well-being of developing countries, and can even benefit the European economy.
For cryptoeconomy:
• expanding the amount of cryptoeconomy users will result in a positive development in this industry
• original inherently friendly and open source architecture of Banking 4.0 will help start-ups to get instant access to customers around the world and obtain financial support from the Humaniq project
• bio-identification will allow testing reputation systems and personalized interaction programs, introducing this realm to charitable organisations, NGOs and United Nation services.
For developing countries:
• poverty level reduction
• remote work and economic growth: greater opportunities for savings will increase the lending capacity of the population; collection of customer financial data will reduce lending risks
• innovation and infrastructure: electronic finances will allow the creation of new business models and products
• reduction in class inequality: financial services can provide new opportunities for billions people living on less than $2.50 a day and bring them to the middle class, greatly improving their lives
• establishing gender equality: engaging the female population in the electronic finance system will raise incomes of health care and education systems; a barrier for women in financial account registration will dissolve, and women will have more control over their funds and business
• improving the quality of education through remote access and payment capabilities.
For the EU:
• improving the economic situation in third world countries will reduce the current immigration challenges faced by advanced economies, particularly in the European Union where the influx is creating huge strains on the social welfare systems and high costs associated with the problem.
Humaniq is not welfare or charity, we are more about empowering people to change their lives and pull themselves out of economic disparity by participating in a new digital economy that they can help build.
# idHmqwprnot0#[†] alex@humaniq.co, fb.com/fork.alex, linkedin.com/in/alexfork
# idHmqwprnot1#[1] It is worth noting that the use of hardware solutions, for example, a fingerprint scanner, allows signal counterfeiting at hardware level.
# idHmqwprnot2#[2] We think that it is fair to issue coins stepwise depending on the everyday involvement of a user.
We wish to avoid the mistake of some altcoins, which made their rewards onetime payments and which suffered from users not having incentives to use the platform on a regular basis.
# idHmqwprnot3#[3] The Pre-ICO has passed, and some conclusions may be already done.
Exactly 31824818 HMQ tokens were generated; thus, even before the start of the ICO, the inequality Vico > 31 · 106 holds, and, due to (4.2), kmax > 248000.
# idHmqwprnot4#[4] Humaniq balances cannot be fractional.
You are invited to guess why, and then check your guess in the subsection 9.8.
# idHmqwprnot5#[5] The price of cheapest smartphone able to perform mobile wallet functions and fitted with front-facing camera falls down every year and is now about $10-20.
# idHmqwprnot6#[6] with respect to the BTC/ETH exchange rate at the moment of purchase
# idHmqwprnot7#[7] To stress his personal responsibility for the pre-ICO, our founder Alex Fork decided to use the bitcoin wallet he uses since 2013.
To make accounting easier, right before the start all the bitcoins were drained away from there, making the balance zero.
# idHmqwprnot8#[8] Fortunately, a frontal camera and a microphone are now built in all devices.
name::
* McsEngl.hmqnet'Exchange-value-token (HMQevt)@cptIt,
_GENERIC:
* Ethereum-consensusNo-exchange-value-token#ql:idEthcevtN#
name::
* McsEngl.hmqnet'Resource@cptIt,
_ADDRESS.WPG:
* https://github.com/humaniq,
* {2017-04-18} Blockshow voices: https://blog.humaniq.co/blockshow-voices-7659e13d97e1,
* {2017-03-23} Humaniq Aims to Tackle Barriers to Economic Inclusion With Blockchain App: https://bitcoinmagazine.com/articles/humaniq-aims-tackle-barriers-economic-inclusion-blockchain-app//
name::
* McsEngl.bcnnet.Ontology@cptIt,
* McsEngl.ontology-blockchain-net@cptIt,
_DESCRIPTION:
Ontology isn’t trying to be a currency like Bitcoin. It’s not even trying to be the next Ethereum. What it is doing is acting as the Robin to NEO’s Batman. Together, they’re a powerful team with the potential to disrupt the business world using blockchain technology.
- Ontology was created by the same team responsible for NEO but exists as a separate entity.
- Ontology is actually a network of blockchains instead of one single blockchain.
- Ontology follows NEO’s dual-token model with the ONT and ONG tokens.
- There is no public ICO – airdrops are the only way to receive ONT and ONG.
Onchain certainly understands why so many institutions are hesitant to adopt blockchain technology. Whether or not Ontology will convince these late bloomers to join the party remains to be seen, but it’s one of the best shots we’ve seen so far.
[https://cryptobriefing.com/what-is-ont-introduction-to-ontology/]
name::
* McsEngl.bcnnet.Qtum@cptIt,
_DESCRIPTION:
Smart-Contract Value-Transfer Protocols on a Distributed Mobile Application Platform
Blockchain-enabled smart contracts that employ proof-of-stake validation for transactions, promise significant performance advantages compared to proof-of-work solutions.
For broad industry adoption, other important requirements must be met in addition.
For example, stable backwards-compatible smart-contract systems must automate cross-organizational information-logistics orchestration with lite mobile wallets that support simple payment verification (SPV) techniques.
The currently leading smart-contract solution Ethereum, uses computationally expensive proof-of-work validation, is expected to hard-fork multiple times in the future and requires downloading the entire blockchain.
Consequently, Ethereum smart contracts have limited utility and lack formal semantics, which is a security issue.
This whitepaper fills the gap in the state of the art by presenting the Qtum smart-contract framework that aims for sociotechnical application suitability, the adoption of formalsemantics language expressiveness, and the provision of smart-contract template libraries for rapid best-practice industry deployment.
We discuss the Qtum utility advantages compared to the Ethereum alternative and present Qtum smart-contract future development plans for industrycases applications.
[https://qtum.org/uploads/files/cf6d69348ca50dd985b60425ccf282f3.pdf]
name::
* McsEngl.bcnnet.RSK@cptIt,
* McsEngl.bcnnet.rsk@cptIt,
* McsEngl.rsknet@cptIt,
_DESCRIPTION:
RSK is the first general purpose smart contract platform secured by the Bitcoin Network.
[https://faq.rsk.co/]
===
RSK is the first open-source smart contract platform with a 2-way peg to Bitcoin that also rewards the Bitcoin miners via merge-mining, allowing them to actively participate in the Smart Contract revolution. RSK goal is to add value and functionality to the Bitcoin ecosystem by enabling smart-contracts, near instant payments and higher-scalability.
[http://www.rsk.co/#about-rsk]
name::
* McsEngl.bcnnet.Synereo@cptIt,
* McsEngl.bcnnet.synereo@cptIt,
* McsEngl.synereo-network@cptIt,
_DESCRIPTION:
Synereo’s Attention Economy
The Future of Content Creation, Publishing and Distribution
Synereo is developing tools which allow content creators to easily monetize original works without having to turn their channels into advertisment real estate, while granting their followers the opportunity to be rewarded for getting the word out.
[http://www.synereo.com/]
===
Blockchain 1.0 brought us Bitcoin, and it was good, but we wanted a foundation for the fully decentralized ecosystem we envisioned.
The Synereo team has built an entirely new, calculus-powered blockchain 2.0 framework - ready to build the decentralized economy of the future.
[https://www.synereo.com//]
name::
* McsEngl.snrnet'Exchange-value-token (AMPevt)@cptIt,
* McsEngl.mnyAMP@cptIt,
* McsEngl.AMP-money@cptIt,
_DESCRIPTION:
Synereo (AMP)
$0.094086 (-0.56%)
0.00007926 BTC (-1.69%)
Market Cap
$7,739,201
6,520 BTC
Volume (24h)
$139,818
117.79 BTC
Circulating Supply
82,256,324 AMP
Total Supply
949,291,063 AMP
[https://coinmarketcap.com/assets/synereo/ {2017-04-15}]
===
Synereo AMP
Synereo is a "next generation" decentralized social network that incorporates blockchain technology to overcome problems associated with centralized social networks such as privacy, security and commodification of users' personal data.
[https://changelly.com/supported-currencies]
name::
* McsEngl.bcnnet.Tezos (tzsnet)@cptIt,
_DESCRIPTION:
WHAT IS TEZOS?
Tezos is a secure, future-proof smart contract system.
Because Tezos has a built-in consensus mechanism, its protocol can evolve, and incorporate new innovations over time, without the risk of hard forks splitting the market.
Tezos is its own blockchain, not a derivative of any other blockchain. We didn’t just fork Bitcoin or Ethereum and add a layer onto it. We built our own from the ground up.
Our smart contract language makes it easier to apply formal verification to any smart contract running on the Tezos blockchain. This allows developers to rule out weaknesses in code before uploading that code on the blockchain.
Tezos relies on a less onerous, less computationally intensive, and less power-consuming proof-of-stake consensus algorithm, where bonded stakeholders validate transactions.
[https://tezos.com/index.html]
_GENERIC:
* program-blockchain-network#ql:idBcnnetPgm#
name::
* McsEngl.tzsnet'Resource@cptIt,
_ADDRESS.WPG:
* https://tezos.com//
_ADDRESS:
Tezos
100 question mark way
Brooklyn, New York 11221
name::
* McsEngl.tzsnet.Evoluting@cptIt,
{time.2017.Q2}:
Tezos is currently scheduled for release in early Q2 2017
[https://tezos.com/index.html]
name::
* McsEngl.bcnnet.Wings (WINGSnet)@cptIt,
* McsEngl.bcnnet.Wings@cptIt,
* McsEngl.netWings@cptIt,
_DESCRIPTION:
WINGS is a platform designed to solve the problem of a project’s early backing and accountability, by providing tools for backers to work together on providing funds and efficient decision making on business critical items.
WINGS puts emphasis on ease of use and efficient collaboration, and on encouraging careful consideration of available choices.
The effort put on this consideration defines whether the decision will result in reward, thus directly rewarding those who bring the most net benefit to the platform efficiency.
With higher efficiency, higher quality projects get more attention both from the backers and the public.
[https://wings.ai/docs/WINGS_Whitepaper_V1.1.2_en.pdf]
===
When will the Wings Platform be launched?
Avatar Stas Oskin
Thursday at 17:37
Follow
WINGS public beta is estimated to be launched around Q1 2017. Users can, however, test the WINGS platform concept through our Alpha test platform, which currently provides the basic features of project creation and management, forecasting, milestone releases, and project funding.
Everything on the Alpha platform runs on testnet tokens that allow the community to test the concept without the need to send any real crypto-currencies. Click here to test the WINGS Alpha Platform
[https://wings.zendesk.com/hc/en-us/articles/208276389-When-will-the-Wings-Platform-be-launched-]
===
Does WINGS run on its blockchain?
Amadeira
January 22, 2017 00:10
WINGS will run on the RSK sidechain/drivechain which provides the same smart contract and DApp capabilities as the Ethereum Virtual Machine, while enabling projects to be funded with Bitcoin.
[https://wings.zendesk.com/hc/en-us/articles/115000058730-Does-WINGS-run-on-its-blockchain-]
name::
* McsEngl.wingsnet'Consensous-evt (WINGScevt)@cptIt,
When will the WINGS token start trading?
Amadeira
March 20, 2017 21:43
The WINGS tokens have not been created yet, therefore it is not possible to transfer, withdraw or trade the tokens at the moment. We are in contact with all major exchanges and will update once we have any news.
WINGS tokens are scheduled to be released around March 2017. At this time, the WINGS tokens will be created and allocated by the smart contract, which means that they can then be added to exchanges that wish to feature WINGS token trading.
It has also come to our attention that the exchange Liqui has launched an I.O.U market for the WINGS token (tokens there are not "real"). This means that the exchange has participated in the WINGS donation campaign and is currently trading it's own tokens that have not yet been created and allocated.
[https://wings.zendesk.com/hc/en-us/articles/115000058670-When-will-the-WINGS-token-start-trading-]
name::
* McsEngl.wingsnet'Organization@cptIt,
name::
* McsEngl.dao.wings@cptIt,
* McsEngl.wings'dao@cptIt,
_DESCRIPTION:
What is a DAO
Amadeira
January 21, 2017 15:12
DAO stands for Decentralized Autonomous Organization. At its most basic level, a DAO is an organization that relies on no form of central authority to operate. Instead, DAOs make decisions based on the votes made by all the members of the organization. This system is automatized on the blockchain through the issuance of cryptographic tokens, which are used to vote on certain decisions, projects or changes proposed to the organization.
These organizations usually come together by means of crowdfunding. The funds are then used to carry out the project that it was created to do or projects that are proposed to the organization.
[https://wings.zendesk.com/hc/en-us/articles/115000062610-What-is-a-DAO]
name::
* McsEngl.wingsdao'Managing@cptIt,
_DESCRIPTION:
How are DAOs managed?
Amadeira
January 21, 2017 19:59
The tokens issued by DAOs allow members of the organization to vote on certain decisions, projects or changes proposed to the organization. This system is also used to factor in the power of each voter. Typically, this means that the more tokens a member has, the more his vote will weight, although other aspects may also come into play.
This system acts as an anti-sybil measure, ensuring that one user can not vote multiple times without having to purchase more tokens from other members of the community (usually through an exchange). Since these tokens have a real-live value and can only be attain through an exchange or crowdfunding campaign, token holders who have a large stake in the organization have a direct benefit to behave in the DAO’s best interest.
[https://wings.zendesk.com/hc/en-us/articles/115000062910-How-are-DAOs-managed-]
name::
* McsEngl.wingsnet'Resource@cptIt,
_ADDRESS.WPG:
* https://wings.ai//
* {2017-01-26} https://blog.wings.ai/wings-roadmap-update-a2638904fe3c#.4gwyrvhec,
name::
* McsEngl.bcnnet.user.PUBLIC@cptIt,
* McsEngl.bcnnet.public@cptIt,
* McsEngl.public-bcnnet@cptIt,
_DESCRIPTION:
Public blockchains, like Bitcoin or NEM, allow anyone to join and set up a node to share and receive data.
However, many real-world business and financial uses require that those who can participate in a blockchain be restricted; these are called permissioned blockchains and Mijin provides this powerful functionality.
[http://mijin.io/en/about-mijin]
name::
* McsEngl.bcnnet.user.PUBLIC.NO@cptIt,
* McsEngl.bcnnet.publicNo@cptIt,
* McsEngl.publicNo-bcnnet@cptIt,
_DESCRIPTION:
Public blockchains, like Bitcoin or NEM, allow anyone to join and set up a node to share and receive data.
However, many real-world business and financial uses require that those who can participate in a blockchain be restricted; these are called permissioned blockchains and Mijin provides this powerful functionality.
[http://mijin.io/en/about-mijin]
name::
* McsEngl.bcnnet.publicNo.Mijin@cptIt,
* McsEngl.bcnMijin@cptIt,
* McsEngl.bcnnet.Mijin@cptIt,
* McsEngl.netMijin@cptIt,
_DESCRIPTION:
Mijin is being built by the NEM development team, using their proven experience and technological prowess.
Working with other developers at Tech Bureau, the NEM team is making Mijin the fastest and most secure blockchain platform in existence.
Rather than trusting other projects that are copies of bitcoin or source code that others wrote, it is important to use reliable, professionally developed software that is made by a unified team.
Mijin is currently the only platform in existence that fulfills this.
[http://mijin.io/en/about-mijin]
===
Public blockchain networks will always have an issue with bandwidth (max. no. of transactions per second). This is because of technical limitations derived from the node network synchronization throughout the large network. Maintaining a chain of many nodes with variation in connectivity and geographical distance in sync simply requires time.
Thus, in the opinion of NEM, the future lies in permissioned chains based on technologies like NEM and anchor these to the public chain - which means to embed hashes of e.g. every tenth private chain block into the public chain. That way immutability and certain public auditability can be achieved using private chain technology with its benefits without compromising public chain advantages.
Mijin is NEM's private chain project. It is built and licensed by the Japanese company Tech Bureau Corp., NEM's strategic partner for permissioned-chain implementations. Mijin is currently in the process of being future proofed as a new 4-tier architecture design. Codenamed Catapult, it is being implemented and written in C++. The current end-to-end prototype has been independently tested by third parties at over 4000 tx/s.
[https://blog.nem.io/nem-mijin-blockchain-technology-briefing-january-2017/]
===
[http://wiki.nem.io/index.php/Mijin]
name::
* McsEngl.bcnnet.EVOLUTING (bcnevg)@cptIt,
* McsEngl.bcnevn@cptIt,
* McsEngl.bcnnet.evoluting@cptIt,
{time.2017-04-19}:
=== iEx.ec ICO:
French distributed cloud computing network iEx.ec has closed its ICO in just three hours, having raised its target of $12 mln.
... iEx joins a host of startups in the crypto space and further afield to have closed hugely successful crowd sale schemes well ahead of schedule.
Recent examples include the Digital Liquid Venture Fund, which earlier this month reached its $10 mln target in six hours. Humaniq and Matchpool also feature among 2017’s high flyers.
[https://cointelegraph.com/news/iexec-closes-worlds-5th-largest-ico-with-12-mln-in-6-hours]
{time.2013}:
=== COLORED-COINS:
Blockchain assets and colored coins approaches emerged around 2013, when several protocols utilizing Bitcoin’s blockchain were implemented.
[idWavwpr21#ql:idWavwpr21#]
=== ALTCOINS:
Alt coins continued to proliferate in 2011 and 2012, either based on bitcoin or on Litecoin.By 2013, there were 20 alt coins vying for position in the market. By the end of 2013, this number had exploded to 200, with 2013 quickly becoming the "year of the alt coins." The growth of alt coins continued in 2014, with more than 500 alt coins in existence at the time of writing. More than half the alt coins today are clones of Litecoin.
[https://github.com/bitcoinbook/bitcoinbook/blob/first_edition/ch09.asciidoc#alt-coins]
=== PROOF-OF-STAKE
In 2013, we saw the invention of an alternative to proof of work, called proof of stake, which forms the basis of many modern alt coins.
[https://github.com/bitcoinbook/bitcoinbook/blob/first_edition/ch09.asciidoc#consensus-innovation-peercoin-myriad-blackcoin-vericoin-nxt]
{time.2012-08}:
=== Peercoin
Peercoin was introduced in August 2012 and is the first alt coin to use a hybrid proof-of-work and proof-of-stake algorithm to issue new currency.
[https://github.com/bitcoinbook/bitcoinbook/blob/first_edition/ch09.asciidoc#peercoin]
{time.2011-09}:
=== script-proof-of-work:
In September 2011, Tenebrix was launched. Tenebrix was the first cryptocurrency to implement an alternative proof-of-work algorithm, namely scrypt, an algorithm originally designed for password stretching (brute-force resistance). The stated goal of Tenebrix was to make a coin that was resistant to mining with GPUs and ASICs, by using a memory-intensive algorithm. Tenebrix did not succeed as a currency, but it was the basis for Litecoin, which has enjoyed great success and has spawned hundreds of clones.
[https://github.com/bitcoinbook/bitcoinbook/blob/first_edition/ch09.asciidoc#alt-coins]
{time.2011-08}:
=== first altcoin:
Based on the date of announcement, the first alt coin that was a fork of bitcoin appeared in August 2011; it was called IXCoin. IXCoin modified a few of the bitcoin parameters, specifically accelerating the creation of currency by increasing the reward to 96 coins per block.
[https://github.com/bitcoinbook/bitcoinbook/blob/first_edition/ch09.asciidoc#alt-coins]
{time.2010}:
=== name-registration-system:
Namecoin - created in 2010, Namecoin is best described as a decentralized name registration database. In decentralized protocols like Tor, Bitcoin and BitMessage, there needs to be some way of identifying accounts so that other people can interact with them, but in all existing solutions the only kind of identifier available is a pseudorandom hash like 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. Ideally, one would like to be able to have an account with a name like "george". However, the problem is that if one person can create an account named "george" then someone else can use the same process to register "george" for themselves as well and impersonate them. The only solution is a first-to-file paradigm, where the first registerer succeeds and the second fails - a problem perfectly suited for the Bitcoin consensus protocol. Namecoin is the oldest, and most successful, implementation of a name registration system using such an idea.
[https://github.com/ethereum/wiki/wiki/White-Paper#alternative-blockchain-applications]
{time.2009}:
=== after bitcoin:
After 2009, however, once Bitcoin's decentralized consensus was developed a number of alternative applications rapidly began to emerge.
[https://github.com/ethereum/wiki/wiki/White-Paper#alternative-blockchain-applications]
{time.2009-01-03 18:15:05}
=== Block#0: Bitcoin genesis block.
=== Block#1: {Timestamp 2009-01-09 02:54:25}
The first block the-network added.
[https://blockchain.info/block-height/1]
{time.2008-10-31}:
=== Bitcoin: A Peer-to-Peer Electronic Cash System
Satoshi Nakamoto White-Paper.
{time.2005}:
===
In 2005, Nick Szabo came out with the concept of "secure property titles with owner authority", a document describing how "new advances in replicated database technology" will allow for a blockchain-based system for storing a registry of who owns what land, creating an elaborate framework including concepts such as homesteading, adverse possession and Georgian land tax. However, there was unfortunately no effective replicated database system available at the time, and so the protocol was never implemented in practice.
[https://github.com/ethereum/wiki/wiki/White-Paper#alternative-blockchain-applications]
name::
* McsEngl.bcnnet.HARDFORK (bcnhfk)@cptIt,
* McsEngl.bcnhardfork@cptIt,
* McsEngl.bcnnet.hardfork@cptIt,
* McsEngl.hardbork-of-bcnnet@cptIt,
_DESCRIPTION:
Protocol upgrades (formerly known as hard forks)
[http://docs.bitshares.eu/bitshares/user/you-should-know.html]
===
The basic difference between the two is that soft forks change the rules of a protocol by strictly reducing the set of transactions that is valid, so nodes following the old rules will still get on the new chain (provided that the majority of miners/validators implements the fork), whereas hard forks allow previously invalid transactions and blocks to become valid, so clients must upgrade their clients in order to stay on the hard-forked chain. There are also two sub-types of hard forks: strictly expanding hard forks, which strictly expand the set of transactions that is valid, and so effectively the old rules are a soft fork with respect to the new rules, and bilateral hard forks, where the two rulesets are incompatible both ways.
[http://vitalik.ca/general/2017/03/14/forks_and_markets.html]
name::
* McsEngl.bcnhardfork'Evaluation@cptIt,
* McsEngl.bcnhardfork'evaluation@cptIt,
_DESCRIPTION:
The benefits commonly cited for the two are as follows.
- Hard forks allow the developers much more flexibility in making the protocol upgrade, as they do not have to take care to make sure that the new rules “fit into” the old rules
...
Aside from this, one major criticism often given for hard forks is that hard forks are “coercive”. The kind of coercion implied here is not physical force; rather, it’s coercion through network effect. That is, if the network changes rules from A to B, then even if you personally like A, if most other users like B and switch to B then you have to switch to B despite your personal disapproval of the change in order to be on the same network as everyone else.
Proponents of hard forks are often derided as trying to effect a “hostile take over” of a network, and “force” users to go along with them. Additionally, the risk of chain splits is often used to bill hard forks as “unsafe”.
[http://vitalik.ca/general/2017/03/14/forks_and_markets.html]
name::
* McsEngl.bcnnet.SOFTFORK@cptIt,
* McsEngl.bcnnet.softfork@cptIt,
* McsEngl.bcnsoftfork@cptIt,
_DESCRIPTION:
The basic difference between the two is that soft forks change the rules of a protocol by strictly reducing the set of transactions that is valid, so nodes following the old rules will still get on the new chain (provided that the majority of miners/validators implements the fork), whereas hard forks allow previously invalid transactions and blocks to become valid, so clients must upgrade their clients in order to stay on the hard-forked chain.
[http://vitalik.ca/general/2017/03/14/forks_and_markets.html]
name::
* McsEngl.bcnsoftfork'Evaluation@cptIt,
* McsEngl.bcnsoftfork'evaluation@cptIt,
_DESCRIPTION:
The benefits commonly cited for the two are as follows.
- Soft forks are more convenient for users, as users do not need to upgrade to stay on the chain
- Soft forks are less likely to lead to a chain split
- Soft forks only really require consent from miners/validators (as even if users still use the old rules, if the nodes making the chain use the new rules then only things valid under the new rules will get into the chain in any case); hard forks require opt-in consent from users
[http://vitalik.ca/general/2017/03/14/forks_and_markets.html]
name::
* McsEngl.bcnnet'TODO@cptIt,
@VitalikButerin @aantonop I published the-STRUCTURED-CONCEPT 'blockchain-network' with its major specifics.
ChronoBank:
I publishd the-LaborX-whitepaper as a-hitp-structured-concept inside my-blockchain-network-webpage.
@aantonop @chdimosthenis I published Mastering-Bitcoin in Greek in hitp-format.
Facebook: announce masterring-bitcoin in greek
Meta-info:
This is the-second major hitp-structured-concept I am-publishing.
The-first was 'Javascript'.
The-webpage is full of quotes about the-concepts I am-resenting.
DO-NOT-USE my definitions on the-same names in these quotes.
We must-use the-author's definitions.
My goal is to have-defined ALL the-names I am-using in my sentences.
I can-not-do this in my website.
But I almost do it in my notes, where I have-defined more than 100,000 concepts in more than 30 years work.
[hmnSngo.2017-04-11]
_CREATED: {2018-01-31} {2017-06-15}
name::
* McsEngl.conceptIt1019,
* McsEngl.Dchain-net@cptIt,
* McsEngl.FvMcs.Dchain-net@cptIt,
* McsEngl.Dchain-net@cptIt,
* McsEngl.DlgrNet@cptIt,
* McsEngl.Dag-network@cptIt,
* McsEngl.Decentralized-ledger-network@cptIt,
* McsEngl.Distributed-ledger-network@cptIt,
* McsEngl.chainnet@cptIt,
* McsEngl.chain-net@cptIt,
* McsEngl.chain-network@cptIt,
* McsEngl.Dtc-net@cptIt,
* McsElln.αποκεντρωτικό-δίκτυο-αλυσίδας@cptIt,
_DESCRIPTION:
DLedger-network is peer-to-peer-nerwork thats stores THE-HISTORY of transactions among its nodes in a-decetralized-ledger.
[hmnSngo.2017-06-15]
name::
* McsEngl.dchnet'Exchange-organization@cptIt,
* McsEngl.chain-exchange-organization@cptIt,
_DESCRIPTION:
OKEx is a popular Hong Kong cryptocurrency exchange, a subsidiary of OKCoin, with a total volume of transactions at 160,000 BTC per day, low fees (0.03% for open positions) and high liquidity in BTC / USD and LTC / USD. Traders at OKEx have the opportunity to use a leverage of up to x20. Margin trading, this is the own derivative financial instruments of the OKEx exchange, allows you to work with small amounts and receive high returns in case of correct forecasts. Traders can sell futures for the desired token and earn additional funds on the fall of the crypto currency.
[Alexander Borodich <ab@universa.io>]
name::
* McsEngl.dchnet'tax@cptIt,
Ελλάδα
Στην Ελλάδα το bitcoin αντιμετωπίζεται σαν ένα ακόμα μέσο τροφοδότησης του κράτους με έσοδα. Η Ελληνική εφορία φορολογεί το κέρδος από το bitcoin, το ίδιο με το αν τα κέρδη προέρχονταν από forex trade και φορολογείται κλιμακωτά με 22% και από ένα ποσό και πάνω με 45%.
ΑΠΟ ΗΛΙΑΣ ΚΟΥΚΟΥΤΣΑΣ - 22/01/2018
[https://emea.gr/%CE%AD%CF%87%CE%B5%CF%84%CE%B5-bitcoin-%CF%84%CE%B9-%CF%86%CF%8C%CF%81%CE%BF-%CE%B8%CE%B1-%CF%80%CE%BB%CE%B7%CF%81%CF%8E%CF%83%CE%B5%CF%84%CE%B5/536313/536313/]
name::
* McsEngl.dchnet'resource@cptIt,
_ADDRESS.WPG:
* https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3326244,
awalch@stmarytx.edu
Ms Walch
I would like to ask permission to include a link to your paper ... in my structured-concept "chain-network"
"structured-concepts-Mcs", are a method[a] to store MONOSEMANTIC, consistent, subjective information which[a] I present in my site [2]
below is my description of decentralization:
"· decentralization[a] is an ambiguous name and most important UNDEFINED name used in chain-net literature.
· this is in contrast to most of its[a] users who are programers and they know that just a single undefined-variable in programing-text is the-cause of failure of entire programs.
· there are many types of decentralization: trust, storage, governance, different degrees 50%, 75%, 100%, ...
· the first type of chain-decentralization was "the-decentralized-trust".
· digital-money, because it is just information, need a trusted entity for book-keeping.
· Bitcoin-network replaced the central trusted entities of payment-systems with a-decentralized one with no human involvement but dependent of computer processing power.
· at the same time the-chain-networks have another type of decentralization, "the-decentralized-storage" because information is stored in many computers and not in a central one.
· but "decentralized-governance" never achieved in chain-networks for the simple fact they operate on accounts (token) and not on humans which govern the-networks. "
[hmnSngo.2018-11-07]
[https://synagonism.net/dirMiwMcs/dirTchInf/filMcsDtcnet.last.html#idDtcattdcrz]
_SPECIFIC:
* Blockchain-network,
* DAG-network,
===
* IOTA-network,
name::
* McsEngl.dchnet.DAGNET@cptIt,
* McsEngl.DagNet@cptIt,
* McsEngl.Dag-network@cptIt,
_DESCRIPTION:
Dagnet is peer-to-peer-nerwork thats stores THE-HISTORY of transactions among its nodes in a-DAG (Directed-Acyclid-Graph).
[hmnSngo.2017-06-15]
name::
* McsEngl.dchnet.IOTA@cptIt,
* McsEngl.IotaNet@cptIt,
* McsEngl.Iota-network@cptIt,
_DESCRIPTION:
Iota-net is a-dagnet.
[hmnSngo.2017-06-15]
name::
* McsEngl.iotanet'Tangle@cptIt,
* McsEngl.IotaTangle@cptIt,
_DESCRIPTION:
The Tangle (read the whitepaper here) is a directed acyclic graph (DAG) as a distributed ledger which stores all transaction data of the IOTA network. It is a Blockchain without the blocks and the chain (so is it really a Blockchain?). The Tangle as implemented in IOTA is the first public distributed ledger to achieve scalability, no fee transactions, as well as quantum-computing protection. Contrary to today’s Blockchains, consensus is no-longer decoupled but instead an intrinsic part of the system, leading to a completely decentralized and self-regulating peer-to-peer network.
[https://learn.iota.org/faqs]
name::
* McsEngl.iotanet'Evaluation@cptIt,
IOTA has a range of features that are uniquely enabled due to its architecture:
1. Scalability: IOTA can achieve high transaction throughput thanks to parallelized validation of transactions with no limit as to the number of transactions that can be confirmed in a certain interval.
2. No Transaction Fees: IOTA has no transaction fees.
3. The Decentralization: IOTA has no miners. Every participant in the network that is making a transaction, actively participates in the consensus. As such, IOTA is more decentralized than any Blockchain.
4. Quantum-immunity: IOTA utilized a newly designed trinary hash function called Curl, which is quantum immune (Winternitz signatures)
[https://support.binance.com/hc/en-us/articles/115001835032-IOTA-IOTA-]
CT: What exact difference are you bringing to the landscape that is not already there?
DS: The most obvious differences that IOTA brings is a complete overhaul of the blockchain, by getting rid of the blocks and the chain and instead creating a Tangle/Directed Acyclic Graph. We have resolved the largest problems of blockchain: fees, scalability and centralization.
Having no fees means that micropayments are finally a reality. In IOTA, you can send 0.00001 cents if you want to and the recipient gets it all: this is a game changer in itself. For the first time ever you can conduct trustless transactions digitally without any fees. The other large issue that IOTA resolves is that of scaling: it is no secret that all public blockchains suffer from a terrible performance in terms of throughput. Even under ideal conditions, they do not scale to meet even slight real world demands.
"Because IOTA has no blocks and no chain, it has no bottleneck. Instead, the throughput grows in proportion to activity on the network. The more users/activity, the higher throughput. This means that we can finally take the public distributed ledger ideas and visions out of the lab and deploy it into the real world."
Finally, IOTA gets rid of the centralization incentive that exists within blockchain architecture. Blockchains always centralize around resources in the form of mining and staking-pools, because it makes economic sense. However, this leads to centralization of the ledger: the largest blockchains are controlled by a handful of mining pool operators, which again are at the mercy of their ISP providers.
[https://cointelegraph.com/news/time-has-come-for-blockchainless-technology-iotas-david-s%C3%B8nsteb%C3%B8] {2017-06-21}
name::
* McsEngl.iotanet'Resource@cptIt,
_ADDRESS.WPG:
* https://iota.org/,
* http://iotasupport.com/,
name::
* McsEngl.conceptIt286,
* McsEngl.electronic-voting-system-It286@cptIt, {2012-12-02}
* McsEngl.evoting-system@cptIt286, {2012-05-28}
* McsEngl.e-voting@cptIt286,
* McsEngl.elections-its@cptIt,
* McsEngl.online-voting-system@cptIt,
* McsEngl.its.elections@cptIt286,
* McsEngl.voting-system.online@cptIt,
* McsEngl.voting-electronic-system@cptIt286, {2012-05-28}
* McsElln.ΗΛΕΚΤΡΟΝΙΚΟ-ΠΛΗΡΟΦΟΡΙΑΚΟ-ΣΥΣΤΗΜΑ-ΕΚΛΟΓΩΝ@cptIt,
name::
* McsEngl.stmIthVot'EVOLUTION@cptIt,
{time.1994}:
1994, ΙΟΥΝ:
Δοκιμάζονται οι ηλεκτρονικές κάλπες στις ευρωεκλογές στο στρασβούργο.
[ΚΑΘΗΜΕΡΙΝΗ, 19 ΙΟΥΝ 1994, 52]
name::
* McsEngl.stmIthVot'Resource@cptIt,
_ADDRESS.WPG:
* DARPA Is Developing an Open-Source Voting System, https://www.schneier.com/blog/archives/2019/03/darpa_is_develo.html,
* {2014} https://estoniaevoting.org/findings/summary// Recommendation: E-voting should be withdrawn
7 ΜΑΡ 2000 15:47 Στην Αριζόνα η πρώτη ψηφοφορία μέσω Internet
in.news
Αριζόνα: Μέσω Internet θα ψηφίσουν οι δημοκρατικοί εκλέκτορες στην Αριζόνα, για την επιλογή του υποψηφίου του κόμματός τους για τις προεδρικές εκλογές του προσεχούς Νοεμβρίου. Eίναι η πρώτη φορά που γίνονται επίσημα αποδεκτές οι "ηλεκτρονικές ψήφοι".
Αυτήν τη φορά οι εκλέκτορες δεν θα ρίξουν ψηφοδέλτια στην ξύλινη ή γυάλινη κάλπη, αλλά θα στείλουν κάποια bit στην ψηφιακή κάλπη που θα έχει στηθεί στον κυβερνοχώρο.
Για το θέμα των ψηφοφοριών μέσω Internet οι απόψεις είναι μέχρι στιγμής αντικρουόμενες. Πέραν των θετικών τους πλευρών, η αλήθεια είναι ότι υπάρχουν σοβαρά εμπόδια στην άμεση τουλάχιστον αποδοχή ενός γενικευμένου ηλεκτρονικού εκλογικού συστήματος. Κυριότερο από αυτά είναι το πολυεπίπεδο θέμα της ασφάλειας της διαδικασίας.
Δεν είναι λίγοι εκείνοι που επισημαίνουν ότι, όταν πέφτουν θύματα των χάκερ ακόμα και το FBI ή το υπουργείο Αμύνης των ΗΠΑ, είναι αδύνατον να διασφαλιστεί το αδιάβλητο των ιντερνετικών ψηφοφοριών.
Οι υπεύθυνοι του κόμματος των Δημοκρατικών στην Πολιτεία της Αριζόνα παραδέχονται ότι δεν έχουν εξασφαλίσει το αδιάβλητο της ιντερνετικής εκλογικής διαδικασίας. Σύμφωνα όμως με τον Μαρκ Φλέισερ, πρόεδρο των Δημοκρατικών της Αριζόνα, "κάποιος πρέπει να κάνει την αρχή. Αν θέλουμε να δούμε σύντομα τις εκλογές να διεξάγονται μέσω Internet, θα πρέπει να είμαστε τολμηροί."
Οι Δημοκρατικοί της Αριζόνα δεν είναι οι μόνοι τολμηροί. Το υπουργείο Αμύνης των ΗΠΑ θα επιτρέψει σε μερικές εκατοντάδες αξιωματικούς, στρατιώτες αλλά και κάποια μέλη του πολιτικού του προσωπικού που υπηρετούν σε διάφορες μονάδες μέσα στις ΗΠΑ, να ψηφίσουν στις επικείμενες προεδρικές εκλογές μέσω Internet.
Η ψηφοφορία θα γίνει μέσω ενός ειδικού πιλοτικού προγράμματος, το οποίο ίσως αποτελέσει τη βάση για να δημιουργηθεί ένα ολοκληρωμένο ηλεκτρονικό εκλογικό σύστημα.
Οι ψηφοφόροι στην Αριζόνα θα πρέπει να πάνε κανονικά στα εκλογικά τους κέντρα, στα οποία θα έχουν τοποθετηθεί οι υπολογιστές-κάλπες.
Πάντως, η εποχή που θα ψηφίζουμε όλοι από τα σπίτια μας δεν φαίνεται να είναι και τόσο μακρινή, όσο ίσως κάποιοι πίστευαν μέχρι πριν από λίγα χρόνια.
name::
* McsEngl.stmIthVot'Security@cptIt,
Ευπάθειες στα συστήματα e-voting
ΑΘΗΝΑ 05/03/2012
Διαφημίσεις Google
ασφάλιστρα αυτοκινήτων
Τηλεφωνικές προσφορές και τιμές
από 40 ασφαλιστικές εταιρίες.
www.asfalistra.gr
Σύμφωνα με ερευνητή ασφάλειας από το RSA Conference 2012, τα συστήματα ηλεκτρονικής ψηφοφορίας είναι πολύ ανασφαλή και δεν πρέπει να επιτραπεί η χρήση τους στις επικείμενες γενικές εκλογές (Η.Π.Α.).
Ο David Jefferson, ένας ειδικός Η/Υ στο Lawrence Livermore National Laboratories και πρόεδρος του Verified Voting, κάλεσε τους εκπροσώπους των εκλογικών γραφείων από όλη τη χώρα για να παρουσιάσει τα σχέδια του, που εκτιμάται ότι θα επιτρέψουν σε περίπου 3,5 εκατομμύρια ψηφοφόρους να «προσέλθουν στις κάλπες» μέσω του Διαδικτύου στις φετινές εκλογές.
Σε μια συνέντευξη στο Computerworld, ο Jefferson προειδοποίησε ότι τα συστήματα, που εκτελούν ηλεκτρονικές ψηφοφορίες, είναι πολύ ανασφαλή και δεν είναι αξιόπιστα, όποτε θα πρέπει να εξεταστούν πολύ προσεκτικά.
Ο Jefferson συμμετέχει επίσης και στη συζήτηση, που πραγματοποιεί η RSA σε συνεργασία με τον «γκουρού» της κρυπτογράφησης, Ron Rivest, για τα ηλεκτρονικά συστήματα ψηφοφορίας (e-voting systems).
Πηγή: secnews
[http://www.nooz.gr/tech/provlimata-sta-sustimata-ilektronikis-psifoforias]
name::
* McsEngl.stmIthVot.CIVIS@cptIt,
* ΕΙΝΑΙ ΤΟ ΓΑΛΛΙΚΟ ΗΛΕΚΤΡΟΝΙΚΟ ΣΥΣΤΗΜΑ ΨΗΦΟΡΟΡΙΑΣ.
* 502 ΨΗΦΟΦΟΡΟΙ ΨΗΦΙΣΑΝ ΚΑΙ Μ'ΑΥΤΟ ΣΤΙΣ ΒΟΥΛΕΥΤΙΚΕΣ ΕΚΛΟΓΕΣ ΤΟΥ 1993
* ΨΗΦΙΖΕΙ ΣΕ ΜΙΑ ΗΛΕΚΤΡΟΝΙΚΗ ΚΑΡΤΑ ΚΑΙ ΜΕΤΑ ΒΑΖΕΙ ΑΥΤΗ ΤΗΝ ΚΑΡΤΑ ΣΕ ΜΙΑ ΗΛΕΚΤΡΟΝΙΚΗ ΚΑΛΠΗ ΠΟΥ ΠΑΙΡΝΕΙ ΤΑ ΣΤΟΙΧΕΙΑ ΚΑΙ ΤΑΞΙΝΟΜΕΙ ΤΟΥΣ ΨΗΦΟΥΣ.
* Ο ΓΑΛΛΙΚΟΣ ΝΟΜΟΣ ΕΠΙΤΡΕΠΕΙ ΑΠΟ ΤΟ 1969 ΤΗ ΧΡΗΣΗ ΜΗΧΑΝΗΜΑΤΟΣ. ΤΟ CIVIS ΔΕΝ ΕΧΕΙ ΠΑΡΕΙ ΑΔΕΙΑ ΑΚΟΜΑ.
[ΒΗΜΑ, 4 ΑΠΡΙ 1993, Δ21]
* ΠΛΕΟΝΕΚΤΗΜΑΤΑ:
-ΔΥΣΚΟΛΗ Η ΝΟΘΕΙΑ
-ΚΑΤΑΡΓΕΙ ΔΙΠΛΟΨΗΦΙΣΑΝΤΕΣ ΚΑΙ ΔΙΠΟΕΓΓΕΓΡΑΜΜΕΝΟΥΣ
-ΑΠΟΤΕΛΕΣΜΑΤΑ ΑΜΕΣΩΣ
* ΜΕΙΟΝΕΚΤΗΜΑΤΑ:
-ΚΟΣΤΟΣ
[ΒΗΜΑ, 4 ΑΠΡΙ 1993, Δ21]
ΧΩΡΕΣ ΠΟΥ ΤΟ ΔΟΚΙΜΑΖΟΥΝ: ΒΕΛΓΙΟ, ΝΟΡΒΗΓΙΑ, ΔΑΝΙΑ, ΣΟΥΗΔΙΑ
[ΒΗΜΑ, 4 ΑΠΡΙ 1993, Δ21]
name::
* McsEngl.stmIthVot.END-TO-END-AUDITABLE@cptIt,
* McsEngl.end-to-end-auditable-voting-system@cptIt286i, {2012-05-28}
* McsEngl.voter-verifiable-system@cptIt286i, {2012-05-28}
End-to-end auditable or end-to-end voter verifiable (E2E) systems are voting systems with stringent integrity properties and strong tamper-resistance. E2E systems often employ cryptographic methods to craft receipts that allow voters to verify that their votes were not modified, without revealing which candidates were voted for. As such, these systems are sometimes referred to as receipt-based systems.
[http://en.wikipedia.org/wiki/End-to-end_auditable_voting_systems]
name::
* McsEngl.stmIthVot.DIRECT-DEMOCRACY@cptIt,
* McsEngl.conceptIt187,
* McsEngl.direct-democracy-its@cptIt,
* McsEngl.its.DirectDemocracy@cptIt187,
* McsElln.ΑΜΕΣΗΣ-ΔΗΜΟΚΡΑΤΙΑΣ-ΣΠΤ@cptIt,
name::
* McsEngl.stmIthVot.I-VOTING@cptIt,
* McsEngl.i-voting@cptIt,
* McsEngl.internet-voting@cptIt,
_DESCRIPTION:
i-Voting
Internet voting, or ‘i-voting’, is a system that allows voters to cast their ballots from any internet-connected computer, anywhere in the world.
Unrelated to the electronic voting systems used elsewhere, which involve costly and problematic machinery, the Estonian solution is simple, elegant and secure.
During a designated pre-voting period, the voter logs onto the system using a ID card or Mobile ID, and casts a ballot. The voter’s identity is removed from the ballot before it reaches the National Electoral Commission for counting, thereby ensuring anonymity.
With any method of remote voting, including traditional mail-in ballots, the possibility of votes being forced or bought is a concern. Estonia’s solution was to allow voters to log on and vote as many times as they want during the pre-voting period. Since each vote cancels the last, a voter always has the option of changing his or her vote later.
In 2005, Estonia became the first country in the world to hold nation-wide elections using this method, and in 2007, it made headlines as the first country to use i-voting in parliamentary elections.
Thanks to its convenience, i-voting is proving highly popular with the Estonian electorate. In the Parliamentary elections 2011, 24,3 percent of voters cast their ballots in this way.
In the case of i-voting, the cumulative time savings in the Estonian parliamentary elections of 2011 were 11,000 working days, which would amount to around 504,000 euros in average wages.
[https://e-estonia.com/component/i-voting/]
name::
* McsEngl.stmIthVot.internet@cptIt,
_DESCRIPTION:
Internet Voting in Puerto Rico
Puerto Rico is considered allowing for Internet voting. I have joined a group of security experts in a letter opposing the bill.
Cybersecurity experts agree that under current technology, no practically proven method exists to securely, verifiably, or privately return voted materials over the internet. That means that votes could be manipulated or deleted on the voter's computer without the voter's knowledge, local elections officials cannot verify that the voter's ballot reflects the voter's intent, and the voter's selections could be traceable back to the individual voter. Such a system could violate protections guaranteeing a secret ballot, as outlined in Section 2, Article II of the Puerto Rico Constitution.
The ACLU agrees.
Tags: ACLU, authentication, cybersecurity, Internet, secrecy, voting
Posted on March 24, 2020 at 6:01 AM • 6 Comments
[https://www.schneier.com/blog/archives/2020/03/internet_voting.html {2020-03-24}]
name::
* McsEngl.stmIthVot.PHONE@cptIt,
December 13, 2008 5:28 PM PST
Estonia votes to vote by phone
Posted by Jennifer Guevin
Citizens in Estonia can now vote with their cell phones.
Parliament in Estonia voted on Thursday [Dec 9] in favor of a measure that would allow citizens to vote via mobile phone in the next Parliamentary election (in 2011), according to the Associated Press.
Estonia has a history of being tech-forward. In 2005, it became the first country to offer online voting for a national election--although only about 1 percent of the votes cast that year were made online. In that election, people were required to insert their nationally-mandated ID cards into readers attached to their computers so their identity could be verified.
In order to vote by phone, Estonians will have to get a special chip for their handsets from the SK Certification Centre, which issues ID certificates and provides the mobile payment and ticketing system used on publish transportation. The chip will verify the voter's identity and authorize them to vote.
I'm all for technology, especially technology that encourages people to vote and allows them to be spend less time in long lines waiting to do so. And certainly, some types of jobs, personal obligations, and physical limitations make it extremely difficult for voters to get to the polls on election day. So, for many people, this will be a big win. But given how long ballots tend to be here in California (and in San Francisco, in particular), I have to wonder if this convenience would be more trouble than it's worth for others. Personally, I'll think twice about subjecting my poor thumbs to voting by phone if this technology ever makes its way to the States.
[http://news.cnet.com/8301-1035_3-10122656-94.html?tag=newsEditorsPicksArea.0] 2008-12-14
name::
* McsEngl.stmIthVot.SOCIETY@cptIt,
What Was the First Country to Adopt Online Voting?
In 2005, Estonia became the first country to allow citizens nationwide to vote online.
The first country to adopt online voting nationwide was Estonia, which
allowed citizens to submit their ballots over the Internet in 2005. This
first online voting was used for municipal elections in which citizens
voted for city councils and mayors, and it was an attempt to make voting
more accessible. About 1% of the registered voters in Estonia used online
voting in 2005, with no reported instances of hacking attempts or other
flaws. The online voting was expanded for other types of elections in
Estonia, and by the parliamentary elections of 2011, nearly 25% of the
country's voters cast their ballots online. As of 2014, no other countries
had adopted online voting nationwide, mainly because of security concerns.
Read More: http://www.wisegeek.com/what-was-the-first-country-to-adopt-online-voting.htm?m, {2014-05-31}
_DESCRIPTION:
A-stmIth which is an independent device (except humans who operate it) like a-computer, a-car, ...
[hmnSngo.2015-08-23]
name::
* McsEngl.stmIthDvc.specific@cptIt,
_SPECIFIC:
* stmIth.device.CAR#cptItsoft212#
* stmIth.devide.COMPUTER#cptItsoft227.9#
* stmIth.device.BOOK#cptItsoft316.1#
* stmIth.device.NEWSPAPER#cptItsoft23#
* stmIth.device.PERIODICAL#cptItsoft328#
name::
* McsEngl.stmIthDvc.CAR@cptIt,
* McsEngl.conceptIt212,
* McsEngl.CAR-its@cptIt,
* McsEngl.stmIth.car@cptIt212,
name::
* McsEngl.conceptIt23,
* McsEngl.stmIth.device.NEWSPAPER@cptIt,
* McsEngl.FvMcs.stmIth.device.NEWSPAPER@cptIt,
* McsEngl.NEWSPAPER-its@cptIt,
* McsEngl.ELECTRONIC'NEWSPAPER@cptIt23,
* McsEngl.online-newspaper@cptIt,
* McsEngl.electronic-newspaper@cptIt,
* McsEngl.its.newspaper@cptIt23,
* McsEngl.online-newspaper@cptIt23, {2012-05-20}
====== lagoGreek:
* McsElln.ΗΛΕΚΤΡΟΝΙΚΗ-ΕΦΗΜΕΡΙΔΑ@cptIt,
* McsElln.ΗΛΕΚΤΡΟΝΙΚΗ'ΕΦΗΜΕΡΙΔΑ@cptIt23,
ΣΥΜΦΩΝΑ ΜΕ ΤΙΣ ΕΤΑΙΡΙΕΣ ΠΛΗΡΟΦΟΡΙΚΗΣ ΤΩΝ ΗΠΑ ΘΑ ΕΙΝΑΙ ΜΙΑ ΑΠΛΗ ΠΛΑΚΑ ΜΕ "ΟΘΟΝΗ-ΣΕΛΙΔΑ" ΚΑΙ ΜΕ ΚΟΥΜΠΙΑ ΠΟΥ ΘΑ ΠΑΤΑ Ο ΑΝΑΓΝΩΣΤΗΣ ΓΙΑ ΝΑ ΑΛΛΑΖΟΥΝ ΟΙ ΣΕΛΙΔΕΣ. ΕΝΑ ΜΕΓΑΦΩΝΟ ΣΤΟ ΚΑΤΩ ΜΕΡΟΣ ΘΑ ΔΙΑΒΑΖΕΙ ΜΕΓΑΛΟΦΩΝΩΣ ΤΑ ΑΡΘΡΑ ΣΕ ΟΠΟΙΟΝ ΤΟ ΠΡΟΤΙΜΑ. Η "ΦΟΡΤΩΣΗ" ΤΗΣ "ΠΛΑΚΑΣ" ΜΕ ΤΟ ΚΑΘΗΜΕΡΙΝΟ ΤΗΣ ΠΕΡΙΕΧΟΜΕΝΟ ΘΑ ΓΙΝΕΤΑΙ ΜΕ ΑΠΛΗ ΣΥΝΔΕΣΗ-ΤΗΣ ΓΙΑ ΛΙΓΑ ΔΕΥΤΕΡΟΛΕΠΤΑ ΣΕ ΜΙΑ ΠΡΙΖΑ ΤΗΛΕΦΩΝΟΥ.
[ΝΕΑ, 6 ΝΟΕΜ 1993]
1995 APR:
128 αμερικάνικες εφημερίδες με κυκλοφορία 25 εκ. φύλα, προσχωρούν στο στρατόπεδο των online εφημερίδων.
[ΚΑΘΗΜΕΡΙΝΗ, 30 ΑΠΡ. 1995, 19]
1995: ΣΥΜΦΩΝΑ ΜΕ ΕΚΘΕΣΗ ΤΟΥ ΑΜΕΡΙΚΑΝΙΚΟΥ ΥΠΟΥΡΓΕΙΟΥ ΕΜΠΟΡΙΟΥ ΤΟ 1995 ΘΑ ΕΧΟΥΝ ΥΠΟΣΚΕΛΙΣΕΙ ΑΥΤΕΣ ΠΟΥ ΘΑ ΤΥΠΩΝΟΝΤΑΙ ΑΚΟΜΗ ΣΕ ΧΑΡΤΙ.
[ΝΕΑ, 6 ΝΟΕΜ 1993]
Θα γινει πριν το τελος του αιώνα. Μέσω δορυφόρου. Οταν οι εγχρωμοι φορητοί γινουν πιο ισχυροί και πιο φτηνοί.
[Καθημερινη 6 Σεπτ. 92]
H ΠΡΩΤΗ ΗΛΕΚΤΡΟΝΙΚΗ ΕΦΗΜΕΡΙΔΑ ΠΟΥ ΚΥΚΛΟΦΟΡΗΣΕ, ΠΑΓΚΟΣΜΙΩΣ, ΕΙΝΑΙ Η "ΜΕΡΚΙΟΥΡΙ" ΤΟΥ ΣΑΝ ΧΟΣΕ, ΣΤΗΝ ΚΑΛΙΦΟΡΝΙΑ.
[ΝΕΑ, 6 ΝΟΕΜ 1993]
ΜΕΡΚΙΟΥΡΙ, ΣΑΝ ΧΟΣΕ (Η ΠΡΩΤΗ ΠΑΓΚΟΣΜΙΩΣ)
ΣΙΚΑΓΟ ΤΡΙΜΠΙΟΥΝ (1993)
ΟΥΑΣΙΓΚΤΟΝ ΠΟΣΤ
ΟΥΟΛ ΣΤΡΙΤ ΤΖΕΡΝΑΛ (1993)
ΤΑΙΜΣ ΜΙΡΟΡ, ΠΑΡΑΡΤΗΜΑ ΤΗΣ ΛΟΣ ΑΝΤΕΛΕΣ ΤΑΙΜΣ
Την παρουσίασαν στη σύνοδο της ευρωπαικής επιτροπης με θέμα τις λεωφορους πληροφοριών, Φεβ. 1995.
Μέσω του Internet με δυνατότητα ήχου και βιντεο σε πραγματικο χρόνο.
[ΒΗΜΑ, 26 ΦΕΒ. 1995, Ε3]
name::
* McsEngl.conceptIt328,
* McsEngl.stmIth.device.PERIODICAL@cptIt,
* McsEngl.FvMcs.stmIth.device.PERIODICAL@cptIt,
* McsEngl.application'periodical@cptIt328,
* McsEngl.electronic-periodical@cptIt,
* McsEngl.electronic'periodical@cptIt328,
* McsEngl.online-periodical@cptIt328, {2012-05-20}
* McsElln.ΗΛΕΚΤΡΟΝΙΚΟ-ΠΕΡΙΟΔΙΚΟ@cptIt,
ΤΗΝ ΠΟΛΛΑ ΥΠΟΣΧΟΜΕΝΗ ΕΠΟΧΗ ΤΗΣ ΑΜΦΙΔΡΟΜΗΣ ΕΠΙΚΟΙΝΩΝΙΑΣ ΜΕΤΑΞΥ ΕΝΟΣ ΠΕΡΙΟΔΙΚΟΥ ΠΑΓΚΟΣΜΙΑΣ ΚΥΚΛΟΦΟΡΙΑΣ ΚΑΙ ΤΩΝ ΑΝΑΓΝΩΣΤΩΝ ΤΟΥ, ΕΓΚΑΙΝΙΑΖΕΙ ΑΠΟ ΣΗΜΕΡΑ ΤΟ TIME. ΑΡΧΙΚΑ ΓΙΑ ΤΟΥΣ ΑΜΕΡΙΚΑΝΟΥΣ ΑΝΑΓΝΩΣΤΕΣ, ΠΟΥ ΜΠΟΡΟΥΝ ΝΑ ΣΥΝΔΕΘΟΥΝ ΣΤΟ ΔΙΚΤΥΟ AMERICA ONLINE.
Η ΚΑΘΗΜΕΡΙΝΗ ΕΧΕΙ ΤΗΝ ΑΠΟΚΛΕΙΣΤΙΚΗ ΑΝΤΙΠΡΟΣΩΠΙΑ ΤΟΥ TIME ONLINE.
[ΚΑΘΗΜΕΡΙΝΗ, 12 ΣΕΠΤ 1993, 49]
name::
* McsEngl.conceptIt223,
* McsEngl.sysDataWebsite@cptIt223, {2011-09-07}
* McsEngl.sysWebsite@cptIt223, {2011-09-07}
_DESCRIPTION:
The system comprised with the computer-network, the computer that stores the website-files, the programs used, the users and the creators of the site.
[hmnSngo.2012-05-27]
name::
* McsEngl.conceptIt205,
* McsEngl.stmIth.ogn.COMPANY-DOINGS@cptIt,
* McsEngl.FvMcs.stmIth.ogn.COMPANY-DOINGS@cptIt,
* McsEngl.business computer system@cptIt,
* McsEngl.business-information-system@cptIt,
* McsEngl.economic organization it system@cptIt,
* McsEngl.MIS@cptIt205,
* McsEngl.management information system@cptIt,
* McsEngl.management-information-system@cptIt,
* McsEngl.its.business@cptIt205,
* McsEngl.sysIth.OrgPrd@cptIt205, {2012-05-20}
* McsEngl.stmIthCpn@cptIt205, {2015-08-29}
* McsEngl.sysIthPrd@cptIt205, {2012-05-20}
_DESCRIPTION:
In the mid 60's the term MANAGEMENT INFORMATION SYSTEM (MIS) was coined to signal a new attempt to develop integrated computer-based information systems that where capable of processing and suppling ALL, information needed by management.
[ER, 1988, 355#cptResource15]
===
A management information system (MIS) provides information that is needed to manage organizations efficiently and effectively.[1] Management information systems involve three primary resources: people, technology, and information or decision making. Management information systems are distinct from other information systems in that they are used to analyze operational activities in the organization.[2] Academically, the term is commonly used to refer to the group of information management methods tied to the automation or support of human decision making, e.g. decision support systems, expert systems, and executive information systems.[2]
[http://en.wikipedia.org/wiki/Management_information_systems]
_PART:
* EXECUTIVE ITS#cptItsoft205.3#
* OFFICE'AUTOMATION ITS#cptItsoft311#
* EDI#cptItsoft130#
Functional Areas
The following are common functional areas covered in an ERP System. In many ERP Systems these are called and grouped together as ERP Modules:
Financial Accounting
General Ledger, Fixed Asset, Payables, Receivables, Cash Management, Financial Consolidation[disambiguation needed]
Management Accounting
Budgeting, Costing, Cost Management, Activity Based Costing
Human Resources
Recruiting, Training, Payroll, Benefits, 401K, Diversity Management, Retirement, Separation
Manufacturing
Engineering, Bill of Materials, Work Orders, Scheduling, Capacity, Workflow Management, Quality Control, Manufacturing Process, Manufacturing Projects, Manufacturing Flow, Product Life Cycle Management
Supply Chain Management
Supply Chain Planning, Supplier Scheduling, Order to Cash, Purchasing, Inventory, Product Configurator, Claim Processing
Project Management
Project Planning, Resource Planning, Project Costing, Work Break Down Structure, Billing, Time and Expense, Performance Units, Activity Management
Customer Relationship Management
Sales and Marketing, Commissions, Service, Customer Contact, Call Center Support - CRM systems are not always considered part of ERP systems but rather BSS systems . Specifically in Telecom scenario
Data Services
Various "self–service" interfaces for customers, suppliers and/or employees
Access Control
Management of user privileges for various processes
Components
Transactional database
Management portal/dashboard
Business intelligence system
Customizable reporting
External access via technology such as web services
Search
Document management
Messaging/chat/wiki
Workflow management
[http://en.wikipedia.org/wiki/Enterprise_resource_planning]
The 'classic' view of Information systems found in the textbooks[28] of the 1980s was of a pyramid of systems that reflected the hierarchy of the organization, usually transaction processing systems at the bottom of the pyramid, followed by management information systems, decision support systems and ending with executive information systems at the top. Although the pyramid model remains useful, since it was first formulated a number of new technologies have been developed and new categories of information systems have emerged, some of which no longer fit easily into the original pyramid model.
Some examples of such systems are:
data warehouses
enterprise resource planning
enterprise systems
expert systems
geographic information system
global information system
office automation
[http://en.wikipedia.org/wiki/Information_systems]
name::
* McsEngl.stmIthCpn'subsystem.ACCOUNTING-INFORMATION-SYSTEM@cptIt,
* McsEngl.conceptIt205.4,
* McsEngl.accounting-information-system@cptIt205.4, {2012-12-04}
_DESCRIPTION:
An accounting information system (AIS) is a system of collection, storage and processing of financial and accounting data that is used by decision makers. An accounting information system is generally a computer-based method for tracking accounting activity in conjunction with information technology resources. The resulting statistical reports can be used internally by management or externally by other interested parties including investors, creditors and tax authorities. The actual physical devices and systems that allows the AIS to operate and perform its functions
Internal controls and security measures: what is implemented to safeguard the data
Model Base Management
[http://en.wikipedia.org/wiki/Accounting_information_system] 2012-12-04
History
Initially, accounting information systems were predominantly developed “in-house” as legacy systems. Such solutions were difficult to develop and expensive to maintain. Today, accounting information systems are more commonly sold as prebuilt software packages from vendors such as Microsoft, Sage Group, SAP and Oracle where it is configured and customized to match the organization’s business processes. As the need for connectivity and consolidation between other business systems increased, accounting information systems were merged with larger, more centralized systems known as enterprise resource planning (ERP). Before, with separate applications to manage different business functions, organizations had to develop complex interfaces for the systems to communicate with each other. In ERP, a system such as accounting information system is built as a module integrated into a suite of applications that can include manufacturing, supply chain, human resources. These modules are integrated together and are able to access the same data and execute complex business processes. With the ubiquity of ERP for businesses, the term “accounting information system” has become much less about pure accounting (financial or managerial) and more about tracking processes across all domains of business.
[http://en.wikipedia.org/wiki/Accounting_information_system] 2012-12-04
name::
* McsEngl.stmIthCpn'subsystem.EXECUTIVE-INFORMATION-SYSTEM@cptIt,
* McsEngl.conceptIt205.3,
* McsEngl.conceptIt349,
* McsEngl.EIS@cptIt,
* McsEngl.eis@cptIt349,
* McsEngl.ececutive-information-technology-system@cptIt,
* McsEngl.its.eis@cptIt349,
* McsEngl.sysItBusiness.EXECUTIVE@cptIt,
_GENERIC:
* entity.whole.system.it_human#cptItsoft180#
_DESCRIPTION:
An executive information system (EIS) is a type of management information system intended to facilitate and support the information and decision-making needs of senior executives by providing easy access to both internal and external information relevant to meeting the strategic goals of the organization. It is commonly considered as a specialized form of decision support system (DSS).[1]
The emphasis of EIS is on graphical displays and easy-to-use user interfaces. They offer strong reporting and drill-down capabilities. In general, EIS are enterprise-wide DSS that help top-level executives analyze, compare, and highlight trends in important variables so that they can monitor performance and identify opportunities and problems. EIS and data warehousing technologies are converging in the marketplace.
In recent years, the term EIS has lost popularity in favor of business intelligence (with the sub areas of reporting, analytics, and digital dashboards).
[http://en.wikipedia.org/wiki/Executive_information_system]
=== analytic:
With an EIS, you can pull together, view, analyze, and report on data that's in assorted formats such as spreadsheets or mainframe databases.
An EIS
create graphically rich charts
find data in multiple distributed sources
help discover relationships between data
provide information at or near real time
suggest pertinent data and how to present it
give you statistical-analysis tools for summarizing and structuring data.
[BYTE, JUN 1993, 127]
name::
* McsEngl.stmIthCpn'subsystem.CUSTOMER-RELATIONSHIP-MANAGEMENT@cptIt,
* McsEngl.conceptIt205.2,
* McsEngl.CRM@cptIt205.2, {2012-12-04}
* McsEngl.customer-relationship-management-system@cptIt205.2, {2012-12-04}
_WHOLE:
* sysIthPrd#cptItsoft205#
_DESCRIPTION:
Customer relationship management (CRM) is a widely implemented model for managing a company’s interactions with customers, clients, and sales prospects. It involves using technology to organize, automate, and synchronize business processes—principally sales activities, but also those for marketing, customer service, and technical support.[1] The overall goals are to find, attract, and win new clients; nurture and retain those the company already has; entice former clients back into the fold; and reduce the costs of marketing and client service.[2] Customer relationship management describes a company-wide business strategy including customer-interface departments as well as other departments.[3] Measuring and valuing customer relationships is critical to implementing this strategy.[4]
[http://en.wikipedia.org/wiki/Customer_relationship_management]
name::
* McsEngl.stmIthCpn'Data-warehouse@cptIt,
* McsEngl.data-warehouse@cptIt205i,
In computing, a data warehouse (DW or DWH) is a database used for reporting and analysis. The data stored in the warehouse are uploaded from the operational systems (such as marketplace, sales etc., shown in the figure to the right). The data may pass through an operational data store for additional operations before they are used in the DW for reporting.
The typical ETL-based data warehouse uses staging, integration, and access layers to house its key functions. The staging layer or staging database stores raw data extracted from each of the disparate source data systems. The integration layer integrates the disparate data sets by transforming the data from the staging layer often storing this transformed data in an operational data store (ODS) database. The integrated data is then moved to yet another database, often called the data warehouse database, where the data is arranged into hierarchal groups often called dimensions and into facts and aggregate facts. The combination of facts and dimensions is sometimes called a star schema. The access layer helps users retrieve data.[1]
A data warehouse constructed from integrated data source systems does not require ETL, staging databases, or operational data store databases. The integrated data source systems may be considered to be a part of a distributed operational data store layer. Data federation methods or data virtualization methods may be used to access the distributed integrated source data systems to consolidate and aggregate data directly into the data warehouse database tables. Unlike the ETL-based data warehouse, the integrated source data systems and the data warehouse are all integrated since there is no transformation of dimensional or reference data. This integrated data warehouse architecture supports the drill down from the aggregate data of the data warehouse to the transactional data of the integrated source data systems.
Data warehouses can be subdivided into data marts. Data marts store subsets of data from a warehouse.
This definition of the data warehouse focuses on data storage. The main source of the data is cleaned, transformed, cataloged and made available for use by managers and other business professionals for data mining, online analytical processing, market research and decision support (Marakas & O'Brien 2009). However, the means to retrieve and analyze data, to extract, transform and load data, and to manage the data dictionary are also considered essential components of a data warehousing system. Many references to data warehousing use this broader context. Thus, an expanded definition for data warehousing includes business intelligence tools, tools to extract, transform and load data into the repository, and tools to manage and retrieve metadata.
[http://en.wikipedia.org/wiki/Data_warehouses]
name::
* McsEngl.stmIthCpn'Doing@cptIt,
Any MIS, whether computerized or manual, should be designed to provide informatin with following characteristics in order to afford managers the maximum utility from the information. Informtion should be
timely - up to date
accurate - correct
concise - essential
relevant - what the manager needs to know
complete - everything that is needed.
name::
* McsEngl.stmIthCpn'doing.CREATION@cptIt,
Developing Information Systems
"The actions that are taken to create an information system that solves an organizational problem are called system development".[6] These include system analysis, system design, programming/implementation, testing, conversion, production and finally maintenance. These actions usually take place in that specified order but some may need to repeat or be accomplished concurrently.
Conversion is the process of changing or converting the old system into the new. This can be done in three basic ways, though newer methods (prototyping, Extreme Programming, JAD, etc.) are replacing these traditional conversion methods in many cases:
Direct cut – The new system replaces the old at an appointed time.
Pilot study – Introducing the new system to a small portion of the operation to see how it fares. If good then the new system expands to the rest of the company.
Phased approach – New system is introduced in stages.
[http://en.wikipedia.org/wiki/Management_information]
name::
* McsEngl.stmIthCpn'digital-nervous-stmtem@cptIt,
* McsEngl.digital-nervous-system@cptIt,
_DESCRIPTION:
Digital nervous system is a phrase, popularly associated with Bill Gates of Microsoft, used to describe a vision for how the IT infrastructure of an enterprise could be analogous to the autonomic nervous system of a biological organism. Gates made extensive use of the term in his 1999 book Business @ the Speed of Thought.[1] The actual phrase digital nervous system may not have originated with Gates however, as it has been reported that Judith Dayhoff used the term before Gates did.[2]
Steve Ballmer attempted to explain the digital nervous system by saying the following:
If you think of the human body, what does our nervous system let us do? It lets us hear, see, take input. It lets us think and analyze and plan. It lets us make decisions and communicate and take action. Every company essentially has a nervous system: companies take inputs, they think, they plan, they communicate, they take action. The question is how does the nervous system in your company operate? Is the IT infrastructure really adding value?[3]
Gates himself offered the following explanation as part of a keynote speech at Microsoft's Second Annual CEO Summit in 1998.
The term 'digital nervous system' is kind of an interesting one. The analogy, of course, is to the biological nervous system where you always have the information you need. You always are alert to the most important things, and you block out the information that's not important. And companies really need to have that same kind of thing: the information that's valuable getting to the people who need to know about it.[4]
Digital nervous system has also been described as being synonymous with the term 'Zero Latency Enterprise', another phrase representing the way an enterprise uses IT systems to rapidly communicate between customers, employees and trading partners.[5]
History[edit]
The term digital nervous systems was used in 1987–89 at the IBM Guide/Share Conference in a presentation originally titled "The Body Enterprise" later retitled "The Cybernetic Factory -- the next generation in CIM". The author/presentor Brian K Seitz was later a Microsoft employee and later a DMR Consultant contributing to Business @ The Speed of Thought through a series of interviews with his research staff arranged by a fellow DMR consultant Ricardo Buenaventura.
Mr Seitz had developed the concept and an architecture for business design based on the General Systems Theory by Ludwig von Bertalanffy taxonomy while designing a computer-integrated manufacturing system at Rockwell Int'l NAAO B1-B division in the mid-80s before joining IBM.[6]
[http://en.wikipedia.org/wiki/Digital_nervous_system]
name::
* McsEngl.stmIthCpn'European-research-Center-for-information-stmtems@cptIt,
* McsEngl.ERCIS@cptIt205i,
* McsEngl.European-research-Center-for-information-systems@cptIt205i,
The European Research Center for Information Systems (ERCIS) was founded in 2004 at the University of Mόnster in Mόnster, North Rhine-Westphalia, Germany. The objective of ERCIS is connecting research in Information systems with Business, Computer Science, Communication Sciences, Law, Management and Mathematics. The ERCIS consists of leading national and international universities and companies in the field of Information
[http://en.wikipedia.org/wiki/European_Research_Center_for_Information_Systems]
name::
* McsEngl.sysIthPrd.specific@cptIt,
_SPECIFIC:
* BANK ITS#cptIt186#
* CAR AGENT#cptItsoft256#
* COOPERATIVE/ΣΥΝΕΤΑΙΡΙΣΜΟΣ#cptItsoft254#
name::
* McsEngl.stmIthCpn.ENTERPRISE-INFORMATION-SYSTEM@cptIt,
* McsEngl.conceptIt205.1,
* McsEngl.enterprise-information-system@cptIt205.1,
An enterprise information system is generally any kind of computing system that is of "enterprise class". This means typically offering high quality of service, dealing with large volumes of data and capable of supporting some large organization ("an enterprise").
Enterprise information systems provide a technology platform that enables organizations to integrate and coordinate their business processes. An enterprise information system provides a single system that is central to the organization and that ensures information can be shared across all functional levels and management hierarchies. Enterprise systems create a standard data structure and are invaluable in eliminating the problem of information fragmentation caused by multiple information systems within an organization.
A typical enterprise information system would be housed in one or more data centers, would run enterprise software, and could include applications that typically cross organizational borders such as content management systems.
The word enterprise can have various connotations. Frequently the term is used only to refer to very large organizations. However, the term may be used to mean virtually anything, by virtue of it having become the latest corporate-speak buzzword. (See Criticisms of enterprise software)
[http://en.wikipedia.org/wiki/Enterprise_Information_System]
name::
* McsEngl.stmIthCpn.ENTERPRISE-PLANNING-SYSTEM@cptIt,
* McsEngl.enterprise-planning-system@cptIt, {2012-11-25}
An enterprise planning system covers the methods of planning for the internal and external factors that affect an enterprise.
These factors generally fall under PESTLE. PESTLE refers to political, economic, social, technological, legal and environmental factors. Regularly addressing PESTLE factors fall under operations management. Meanwhile, addressing any event, opportunity or challenge in any one or many factors for the first time will involve project management.
As opposed to enterprise resource planning (ERP), enterprise planning systems have broader coverage. Enterprise planning systems address the resources that are available or not available to an enterprise and its ability to produce products or resources and/or provide services. It also considers those factors that will positively or negatively affect the firm's ability to run these actions.
Enterprise planning systems will tend to vary and are flexible. These are due to the periodic and adaptive nature of strategy formation. These will also have tactical aspects. Typically, enterprise planning systems are part of a firm's knowledge base or corporate structure whether it formally identified and structured or simply executed these when the need appeared.
[http://en.wikipedia.org/wiki/Enterprise_planning_systems]
_CREATED: {2012-12-14} {2011-07-25}
name::
* McsEngl.stmIthCpn.ENTERPRISE-RESOURCE-PLANNING@cptIt,
* McsEngl.conceptIt205.5,
* McsEngl.enterprise-resource-planning@cptIt279.1,
* McsEngl.enterprise-resource-planning-system@cptIt205.5, {2012-12-04}
* McsEngl.ERP@cptIt279.1,
_DESCRIPTION:
Enterprise resource planning (ERP) systems integrate internal and external management information across an entire organization, embracing finance/accounting, manufacturing, sales and service, customer relationship management, etc. ERP systems automate this activity with an integrated software application. The purpose of ERP is to facilitate the flow of information between all business functions inside the boundaries of the organization and manage the connections to outside stakeholders.[1]
ERP systems can run on a variety of computer hardware and network configurations, typically employing a database as a repository for information.[2]
[http://en.wikipedia.org/wiki/Enterprise_resource_planning]
===
Enterprise resource planning (ERP) is a term used to describe a software system providing multiple application modules to run a business in the areas of Financial Management, Logistics, Manufacturing, Human Resources and extended supply chain operations.
[http://open-source-erp-site.com/Definition-of-ERP.html]
===
Enterprise resource planning (ERP) systems integrate internal and external management information across an entire organization, embracing finance/accounting, manufacturing, sales and service, customer relationship management, etc. ERP systems automate this activity with an integrated software application. Their purpose is to facilitate the flow of information between all business functions inside the boundaries of the organization and manage the connections to outside stakeholders.[1]
ERP systems can run on a variety of computer hardware and network configurations, typically employing a database as a repository for information.[2]
[http://en.wikipedia.org/wiki/Enterprise_resource_planning]
PostBooks:
* https://www.xtuple.com/
- The March 2013 Project of the Month is PostBooks. PostBooks is ERP, accounting and CRM software, backed by the xTuple company.
- Qt framework
SOSE!(SITE Open Source ERP) S I T E methodology.
Select Implement Train Expand
* http://open-source-erp-site.com/index-2.html
name::
* McsEngl.stmIthCpn'time.EVOLUTING@cptIt,
{time.1990s.middle}:
In 1990 Gartner Group first employed the acronym ERP[3] as an extension of material requirements planning (MRP), later manufacturing resource planning[4][5] and computer-integrated manufacturing. Without supplanting these terms, ERP came to represent a larger whole, reflecting the evolution of application integration beyond manufacturing.[6] Not all ERP packages were developed from a manufacturing core. Vendors variously began with accounting, maintenance and human resources. By the mid–1990s ERP systems addressed all core functions of an enterprise. Beyond corporations, governments and non–profit organizations also began to employ ERP systems.[7]
name::
* McsEngl.stmIthCpn.CAR-AGENT@cptIt,
* McsEngl.conceptIt256,
* McsEngl.CAR-AGENT-its@cptIt,
* McsEngl.its.caragent@cptIt256,
* McsElln.ΑΝΤΙΠΡΟΣΩΠΕΙΑΣ-ΑΥΤΟΚΙΝΗΤΩΝ-ΣΠΤ@cptIt,
name::
* McsElln.Κ. ΘΕΟΔΩΡΙΔΗΣ@cptIt,
ΕΤΑΙΡΕΙΑ: HTC, ΚΕΝΤΡΟ ΥΨΗΛΗΣ ΤΕΧΝΟΛΟΓΙΑΣ
ΣΥΣΤΗΜΑ: ΔΙΚΤΥΟ NOVELL, ΚΕΝΤΡΙΚΟΣ IBM PS/2 95-VO2, 15 TERMATIKA ΚΑΙ ΤΟ ΠΛΗΡΕΣ ΠΑΚΕΤΟ "ΚΕΦΑΛΑΙΟ" ΤΗΣ UNISOFT.
[COMPUTER ΓΙΑ ΟΛΟΥΣ, ΦΕΒ 1993, 92]
name::
* McsEngl.stmIthCpn.COOPERATIVE@cptIt,
* McsEngl.conceptIt254,
* McsEngl.COOPERATIVE-its@cptIt,
* McsEngl.its.cooperative@cptIt254,
* McsElln.ΣΥΝΕΤΑΙΡΙΣΜΟΥ@cptIt,
ΕΤΑΙΡΙΑ: ICL
ΥΠΟΛΟΓΙΣΤΗ: DRS 6000, ΜΕ ΔΙΠΛΟ ΕΠΕΞΕΡΓΑΣΤΗ RISC.
ΚΟΣΤΟΣ: 30 ΕΚ. ΔΡΧ.
ΣΥΝΔΕΣΗ: online ΜΕ 7 ΚΑΤΑΣΤΗΜΑΤΑ ΠΩΛΗΣΕΩΝ ΚΑΙ 3 supermarkets ΤΟΥ ΣΥΝΕΤΑΙΡΙΜΟΥ.
[COMPUTER ΓΙΑ ΟΛΟΥΣ, ΦΕΒ 1993, 87]
ΕΤΑΙΡΕΙΑ: SDC AE
ΣΥΣΤΗΜΑΤΑ: Altos, Super-Mini UNIX με 26 θέσεις εργασίας. Σύνδεση με 3 απομακρισμένους σταθμούς με modems.
ΠΡΟΓΡΑΜΜΑΤΑ: AIXMES-2 της SDC
[COMPUTER ΓΙΑ ΟΛΟΥΣ, ΦΕΒ 1993, 87]
name::
* McsEngl.stmIthCpn.EDUCATION@cptIt,
* McsEngl.conceptIt329,
* McsEngl.educational-organization-its@cptIt,
* McsEngl.its.knowledgeOrganization@cptIt329,
* McsEngl.stmIth.school@cptIt,
* McsElln.ΕΚΠΑΙΔΕΥΣΗΣ-ΣΠΤ@cptIt,
ΜΕΧΡΙ ΤΕΛΟΥΣ ΤΟΥ 1993 700 ΓΥΜΝΑΣΙΑ-ΛΥΚΕΙΑ ΘΑ ΠΑΡΟΥΝ ΕΞΟΠΛΙΣΜΟ 2,5 ΔΙΣ ΔΡΧ. Η ΧΡΗΜΑΤΟΔΟΤΗΣΗ ΠΡΟΕΡΧΕΤΑΙ ΑΠΟ ΤΑ ΜΟΠ.
[ΒΗΜΑ, 26 ΣΕΠΤ 1993, Ε5]
ΜΕΛΛΟΝ:
1992-1997: ΘΑ ΔΑΠΑΝΗΘΟΥΝ 37 ΔΙΣ. ΔΡΧ.
[ΒΗΜΑ, 26 ΣΕΠΤ 1993, Ε5]
ΣΤΕΛΕΧΗ ΤΟΥ ΥΠΟΥΡΓΕΙΟΥ ΘΕΩΡΟΥΝ ΟΤΙ Η ΟΥΣΙΑ ΤΗΣ ΠΡΟΣΠΑΘΕΙΑΣ ΔΕΝ ΕΙΝΑΙ Η ΕΓΚΑΤΑΣΤΑΣΗ ΥΠΟΛΟΓΙΣΤΩΝ ΚΑΙ Η ΕΚΜΑΘΗΣΗ ΤΗΣ ΧΡΗΣΗΣ ΤΟΥΣ, ΑΛΛΑ Η ΧΡΗΣΗ ΕΚΠΑΙΔΕΥΤΙΚΩΝ ΠΑΚΕΤΩΝ ΛΟΓΙΣΜΙΚΟΥ ΓΙΑ ΤΗ ΔΙΔΑΣΚΑΛΙΑ ΑΛΛΩΝ ΜΑΘΗΜΑΤΩΝ (ΠΧ. ΓΕΩΓΡΑΦΙΑ, ΜΑΘΗΜΑΤΙΚΑ).
ΣΥΜΦΩΝΑ ΜΕ ΤΟ ΧΡΟΝΟΔΙΑΓΡΑΜΜΑ ΠΟΥ ΕΧΕΙ ΚΑΘΟΡΙΣΕΙ ΤΟ ΥΠΟΥΡΓΕΙΟ ΠΑΙΔΕΙΑΣ, ΜΕΧΡΙ ΤΟ 1997 ΠΡΕΠΕΙ ΝΑ ΔΗΜΙΟΥΡΓΗΘΟΥΝ 13 ΕΚΠΑΙΔΕΥΤΙΚΑ ΠΑΚΕΤΑ ΛΟΓΙΣΜΙΚΟΥ (ΠΡΟΓΡΑΜΜΑΤΑ) ΓΙΑ ΜΑΘΗΜΑΤΑ ΓΥΜΝΑΣΙΩΝ, ΓΕΝΙΚΩΝ ΛΥΚΕΙΩΝ, ΤΕΧΝΙΚΩΝ ΛΥΚΕΙΩΝ, ΠΟΛΥΚΛΑΔΙΚΩΝ ΛΥΚΕΙΩΝ ΚΑΙ ΔΗΜΟΤΙΚΩΝ.
ΩΣΤΟΣΟ ΚΑΝΕΙΣ ΔΕΝ ΞΕΡΕΙ ΜΕΧΡΙ ΣΗΜΕΡΑ ΠΟΙΟΣ ΘΑ ΑΝΑΠΤΥΞΕΙ ΤΑ ΕΚΠΑΙΔΕΥΤΙΚΑ ΠΡΟΓΡΑΜΜΑΤΑ. ΤΟ ΥΠΟΥΡΓΕΙΟ ΠΡΟΣΑΝΑΤΟΛΙΖΕΤΑΙ ΠΑΝΤΩΣ ΣΤΗΝ ΑΝΑΘΕΣΗ ΤΟΥ ΕΡΓΟΥ ΑΥΤΟΥ ΣΕ ΕΚΠΑΙΔΕΥΤΙΚΑ ΙΔΡΥΜΑΤΑ (ΑΕΙ, ΤΕΙ) ΚΑΙ ΣΥΜΦΩΝΑ ΜΕ ΠΛΗΡΟΦΟΡΙΕΣ ΗΔΗ ΚΑΠΟΙΑ ΠΑΝΕΠΙΣΤΗΜΙΑ ΕΧΟΥΝ ΑΝΑΛΑΒΕΙ ΤΗΝ ΑΝΑΠΤΥΞΗ ΠΡΟΓΡΑΜΜΑΤΩΝ.
[ΒΗΜΑ, 26 ΣΕΠΤ 1993, Ε5]
name::
* McsEngl.conceptItsoft1067,
* McsElln.ΑΒΑΚΙΟ@cptItsoft1067,
_GENERIC:
School Management Program#cptItsoft1049#
Database-Application#ql:[Level CONCEPT:rl? conceptIt851]##cptIt851#
Το αβάκιο χρησιμοποιεί την τυποποίηση της PARADOX. Ετσι κάθε άλλο σύστημα DBMS που διαβάζει αυτά τα αρχεία μπορεί να τα δεί, όπως:
Borland dBase IV
Microsoft Access
Borland Paradox,
name::
* McsElln.αβκ'ognCompany@cptIt,
ANTINOOS ΕΦΑΡΜΟΓΕΣ ΠΛΗΡΟΦΟΡΙΚΗΣ ΕΠΕ
ΑΒΕΡΩΦ 34Α
Ν. ΙΩΝΙΑ
ΤΗΛ 2533213
ΦΑΞ 2518976
name::
* McsElln.αβκ'ΒΑΣΗ'ΔΕΔΟΜΕΝΩΝ (DATABASE)@cptIt,
_DEFINITION:
Βάση Δεδομένων είναι μια ΣΥΛΛΟΓΗ-ΠΛΗΡΟΦΟΡΙΩΝ που σχετίζονται μεταξύ τους.
Κάθε σχολικό έτος, φυλάσσεται σε ΜΙΑ βάση δεδομένων που αποθηκέυται σε ΦΑΚΕΛΟ με επέκταση .SYR.
name::
* McsElln.αβκ'ΕΝΤΥΠΟ (FORM) (F5)@cptIt,
_DEFINITION:
ΕΝΤΥΠΑ είναι ΠΑΡΑΘΥΡΑ που χρησιμοποιούνται για την ΕΜΦΑΝΙΣΗ και ΤΡΟΠΟΠΟΙΗΣΗ των δεδομένων που είναι αποθηκευμένα στους Πίνακες της βάσης δεδομένων.
name::
* McsElln.αβκ'ΠΑΡΑΜΕΤΡΟΙ (F3)@cptIt,
STRUCTURE:
ΕΝΤΥΠΑ
ΦΑΚΕΛΟΙ
ΠΙΝΑΚΕΣ
ΕΚΘΕΣΕΙΣ
ΔΙΑΦΟΡΑ
ΕΝΤΥΠΑ:
Καθορίζουν αρχικές τιμές σε πεδία ΜΑΘΗΤΩΝ
ΔΙΑΦΟΡΑ:
Καθορίζουν την ονομασία ΕΛΕΥΘΕΡΩΝ-ΠΕΔΙΩΝ για τους μαθητές.
name::
* McsElln.αβκ'ΠΙΝΑΚΑΣ (TABLE) (F7)@cptIt,
_DEFINITION:
Στους ΠΙΝΑΚΕΣ αποθηκεύονται τα δεδεμένα με μορφή γραμμών και στηλών (εγγραφών/πεδίων).
STORAGE:
Κάθε πίνακας είναι ένα ξεχωριστό φυσικό αρχείο με επέκταση .DB
ΠΙΝΑΚΕΣ ΤΟΥ ΑΒΑΚΙΟ:
Προσφέρει στο χρήστη την διαχείριση των πινάκων που έχουν δημιουργηθεί σαν απαντήσεις Ερωτημάτων.
name::
* McsElln.αβκ'ΦΑΚΕΛΟΙ (F4)@cptIt,
Κάθε φάκελος αποτελεί μια αυτόνομη βάση δεδομένων, με όλα τα αρχεία Πινάκων που την αποτελούν.
Για κάθε ΦΑΚΕΛΟ υπάρχουν ΟΜΑΔΕΣ χρηστών με διαφορετικά δικαιώματα:
όλοι χρησιμοποιούν ΨΕΥΔΩΝΥΜΑ και ΣΥΝΘΗΜΑ.
MASTER (ΕΠΙΚΕΦΑΛΗΣ): έχει όλα τα δικαιώματα
ADMIN (ΔΙΑΧΕΙΡΙΣΤΗΣ): ΔΕΝ μπορεί να αλλάξει τους κωδικούς του και να δημιουργήσει άλλους διαχειριστές. ΜΠΟΡΕΙ να δημιουργήσει χρήστες και φιλοξενούμενους
USER: ΔΕΝ μπορεί να διαγράψει φάκελλο.
GUEST: Απλως μπορεί να δεί τα δεδομένα.
Ο εφεδρικός φάκελος πρέπει να βρίσκεται όσο το δυνατόν πλησιέστερα χρονικά με τον κυρίως φάκελο.
INTRASOFT PROJECT:
ΙΟΥΝΙΟ 1994: ολοκληρώθηκε το έργο μηχανογραφησης 780 γυμνασίων, 130 ΤΕΛ, 20 ΠΕΚ.
ΚΟΣΤΟΣ: 3,15 δισ. δρχ.
[COMPUTER GO, OCT. 1994]
name::
* McsEngl.conceptItsoft1049,
* McsEngl.school-management-program@cptIt,
* McsEngl.program.school'management@cptItsoft1049,
* McsElln.ΠΡΟΓΡΑΜΜΑ-ΔΙΑΧΕΙΡΙΣΗΣ-ΣΧΟΛΕΙΩΝ@cptIt,
_GENERIC:
ORGANIZATION-MANAGEMENT-PROGRAM#ql:[Level CONCEPT:rl? conceptIt427]##cptIt427#
_SPECIFIC#ql:_GENERIC cptItsoft1049#:
ΑΒΑΚΙΟ#cptItsoft1067: attSpe#
ΣΩΚΡΑΤΗΣ#cptItsoft1050: attSpe#
name::
* McsEngl.conceptItsoft1050,
* McsElln.ΣΩΚΡΑΤΗΣ@cptItsoft1050,
ΣΥΣΤΗΜΑ ΔΙΑΧΕΙΡΙΣΗΣ ΛΕΙΤΟΥΡΓΙΩΝ ΣΧΟΛΕΙΟΥ
[ΕΓΧΕΙΡΙΔΙΟ]
MODUS CONSULTING Ltd
ΤΜΗΜΑ ΕΡΕΥΝΑΣ & ΑΝΑΠΤΥΞΗΣ ΛΟΓΙΣΜΙΚΟΥ
ΚΗΦΙΣΙΑΣ 108
11526 ΑΘΗΝΑ
01-6914339, 6498892
Καθορισμός μαθημάτων τάξης ΚΑΙ δημιουργία ομάδων μαθημάτων με κοινό τίτλο.
ΣΕ ΠΡΟΣΦΑΤΟ ΔΙΑΓΩΝΙΣΜΟ Η INMIS ΑΝΕΛΑΒΕ ΤΗΝ ΠΡΟΜΗΘΕΙΑ ΣΕ 100 ΤΕΛ ΤΗΝ ΠΡΟΜΗΘΕΙΑ RDBMS UNIFY 2000, ΚΑΙ ΤΗΝ 4GL ACCELL.
[RAM, SEP 1993, 18]
name::
* McsEngl.stmIthCpn.FINANCIAL@cptIt,
* McsEngl.conceptIt186,
* McsEngl.bank-its@cptIt,
* McsEngl.electronic-banking@cptIt,
* McsEngl.Financial-organization-information-technology-system@cptIt,
* McsEngl.its.financialorganization@cptIt186,
* McsElln.ΟΙΚΟΝΟΜΙΚΟΥ-ΟΡΓΑΝΙΣΜΟΥ-ΣΠΤ@cptIt,
_GENERIC:
* stmIth#cptItsoft180#
ETERIES#ql:IT-COMP.NFO# illp# {ΤΡΑΠΕΖΙΚΟ.ΣΥΣΤΗΜΑ}
ADVANTAGES
BANKS SMALL
DATA INPUT
EVOLUTION
EXPERT.SYSTEM
IMPACT
INTEGRATION
LIFE CYCLE
REGULATION
SPREAD
USE
ΚΥΠΡΟΣ
ΠΟΡΤΟΓΑΛΙΑ
The obvious advantage of any kind of EFT system results from the
reduced labor cost and
the increased speed.
[Bowden-et-al, 1984, 176#cptResource436]
electronic and computerized services, however, are not a panacea for banking problems.
[Austin-et-all, 1989, 271#cptResource435]
The cost required to process a check is considerably higher than the cost associated with an EFT...So the customer has a real incentive to use fewer checks and more EFT transfers.
[Bowden-et-al, 1984, 188#cptResource436]
COST CUTS:
Bank executive view MIS (departments) as a source for implementing cost cuts.
[Bank-Management, Jan 1991, 31#cptResource446]
1970:
Are we finally approaching the "cashless and checkless society" that so many people were talking about following the introduction of the first ATM in Valdosta, Georgia, in 1970? Don't count on it.
[Bowden-et-al, 1984, 206#cptResource436]
The "cashless and checkless society" did not come as rapidly as many had expected.
[Bowden-et-al, 1984, 173#cptResource436]
1980s:
it was not until the early 1980s that EFT began to be widely accepted and to spread rapidly... that's when the revolutionary effects that had been predicted as far as the 1960s began to materialize.
[Bowden-et-al, 1984, 175#cptResource436]
PREDICTION:
Ten years down the road is too far. Technology changes so rapidly that nobody, not even experts, can foresee all oportunities.
[Chorafas, 1982, 214#cptResource440]
Απο τα ΛΟΓΙΣΤΙΚΟΚΕΝΤΡΙΚΑ ΣΥΣΤΗΜΑΤΑ περνάμε στην εποχή των ΠΕΛΑΤΟΚΕΝΤΡΙΚΩΝ ΣΥΣΤΗΜΑΤΩΝ, δηλ. συστηματα και εφαρμογές καταναλωτή και την εξυπηρέτηση αυτού σε πρώτη ζήτηση.
[ΚΑΘΗΜΕΡΙΝΗ, 11 ΔΕΚ. 1994, 57]
Artificial intelligence software, which ismulates the reasoning of experts, will monitor borrowers' activities, compute credit ratings, and decide whether to apply a line of credit against a corporate overdraft.
[Bank Management, Jan 1990, 28]
ANION SYSTEM:
Among banking implementations in the United States written in Aion are
those for credit analysis (consumer, corporate) and
legal requirements connected with loan processing.
Other expert systems applications using the Aion shell have been developed by the insurance industry for
claims processing and
risk analysis.
[Chorafas, 1990, 125#cptResource444]
FORCAST (1982):
Before 1985, key-to-tape disc and stand-alone data entry will be replaced by multi-function terminals and POS.
More than 95% of data will be captured at point of sales and point of transaction.
[Chorafas, 1982, 151#cptResource440]
CREDIT'CARD#cptEconomy265: attSpe#
HOME.BANKING#cptIt322: attSpe#
IMAGE.TECHNOLOGY#cptIt323: attSpe#
With integration to
the mainframe and
development of local area networks,
banks will see an important increase in productivity.
[Bank-Management, Jan 1990, 52#cptResource446]
The increased use of electronic funds transfer systems is sure to have an impact
on the relations among banks, large and small,
on the relationships between banks and other financial institutions,
on the relationships between the commercial banks and the Fed,
on competition among teh banks and other financial services institutions,
on the issue of interstate bank structure as well as interstate banking relationships, and
on so many other aspects of the financial services industry.
[Bowden-et-al, 1984, 17#cptResource436]
Time of systems life-cycle:
9.5 months for feasibility study and requirements analysis
7.5 months for evaluation and choice of HW and SW
12 months to complete installation process at each site.
29 months process all together
[David, EMGT 321 project, 1991]
USA:
In early 1980, the federal reserve board was just working out the final rules of their "Regulation E" (concerning EFT) to implement the EFT Act of 1978. ... the first rules had become effective in February 1979.
[Bowden-et-al, 1984, 188#cptResource436]
1981:
There were about 2 billion electronic payment transactions nationwide during the year.
[Bowden-et-al, 1984, 206#cptResource436]
CAUSE:
The cost of handling this mountain of paper (for checks is the number one force that will speed the expanded use of EFT in the comming years.
[Bowden-et-al, 1984, 17#cptResource436]
IMPEDIMENTS:
1. consumers like the record keeping that their cancelled checks provide them.
2. legal problems.
3. the cost of the new tech.
[Bowden-et-al, 1984, 174#cptResource436]
but in general, technology has not been one of the impediments. The basic technology needed for a nationwide EFT network has existed for some time, and the unit cost of performing many basic functions has fallen sharply over the last few decades. The technology and the incentive to introduce it have existed, but
customer resistance and
legal obstacles
have been the major problems. These problems are being overcome only slowly.
[Bowden-et-al, 1984, 174#cptResource436]
one of the greatest impediments to the introduction of EFT systems for customer use has to do with location restrictions. The McFadden Act prevent banks from establishing branches in other states, and it requires them to abide by their own state's branching laws. More than half of the states now limit or entirely prohibit bank branching.
[Bowden-et-al, 1984, 183#cptResource436]
legal restrictions:
legal system of states
national laws prohibiting interstate banking
antitrust laws.
[Bowden-et-al, 1984, 185#cptResource436]
Bank to bank. Clearing operation.
Bank to organizations. Payrols.
Bank to customers. ATMs.
bank to buyer-seller.
[Martin, 1990, 4#cptResource134]
The small banks are not able to set up the systems themselves, but need to depend on larger banks to help them in providing these electronic services.
[Bowden-et-al, 1984, 17#cptResource436]
JCC. JOIN COMPUTER COMPANY
H ΑΝΑΠΤΥΞΗ ΞΕΚΙΝΗΣΕ ΠΑΡΑΛΛΗΛΑ ΜΕ ΤΟ ΔΙΑΣ, ΙΔΙΑ ΕΤΑΙΡΕΙΑ.
ΠΑΡΕΧΕΙ ΥΠΗΡΕΣΙΕΣ ΑΠΟ 18 ΙΑΝΟΥΑΡΙΟΥ 1993.
name::
* McsEngl.stmIthCpn.HOSPITAL@cptIt,
* McsEngl.conceptIt192,
* McsEngl.HOSPITAL-its@cptIt,
* McsEngl.its.hospital@cptIt192,
* McsElln.ΝΟΣΟΚΟΜΕΙΑΚΟ-ΣΥΣΤΗΜΑ@cptIt,
* McsElln.ΝΟΣΟΚΟΜΕΙΟΥ-ΣΠΤ@cptIt,
ΠΡΩΤΟΒΟΥΛΙΑ. ΤΟΥ ΕΡΓΑΣΤΗΡΙΟΥ ΙΑΤΡΙΚΗΣ ΦΥΣΙΚΗΣ ΤΗΣ ΙΑΤΡΙΚΗΣ ΣΧΟΛΗΣ ΤΟΥ ΠΑΝΕΠΙΣΤΗΜΙΟΥ ΑΘΗΝΩΝ.
ΞΕΚΙΝΗΣΕ. ΠΕΙΡΑΜΑΤΙΚΑ ΤΟ 1988.
ΑΠΟΤΕΛΕΙΤΑΙ. 16 ΤΕΡΜΑΤΙΚΑ, ΤΑ 13 ΒΡΙΣΚΟΝΤΑΙ ΣΕ 13 ΚΕΝΤΡΑ ΥΓΕΙΑΣ ΑΠΟΜΑΚΡΥΣΜΕΝΩΝ ΠΕΡΙΟΧΩΝ, ΑΜΥΝΤΑΙΟΥ, ΙΑΣΜΟΥ, ΦΙΛΙΑΤΩΝ, ΛΗΜΝΟΥ, ΣΟΥΦΛΙΟΥ, ΓΥΘΕΙΟΥ, ΟΡΕΣΤΙΑΔΟΣ, ΣΙΔΗΡΟΚΑΣΤΡΟΥ, ΣΚΟΠΕΛΟΥ, ΘΕΣΠΡΩΤΙΚΟΥ, ΤΣΟΤΥΛΙΟΥ, ΣΑΝΤΟΡΙΝΗΣ.
ΕΞΟΔΑ. 300 ΕΚΑΤΟΜΥΡΙΑ ΜΕΧΡΙ ΦΕΒΡ 1993
name::
* McsEngl.stmIthCpn.LAWYER-OFFICE@cptIt,
* McsEngl.conceptIt193,
* McsEngl.LAWYER-OFFICE-its@cptIt,
* McsEngl.its.lawyeroffice@cptIt193,
* McsElln.ΔΙΚΗΓΟΡΙΚΟ-ΓΡΑΦΕΙΟ@cptIt,
* McsElln.ΔΙΚΗΓΟΡΙΚΟΥ-ΓΡΑΦΕΙΟΥ-ΣΠΤ@cptIt,
_GENERIC:
* entity.whole.system.it_human#cptItsoft180#
ΑΥΤΟΜΑΤΟΠΟΙΗΜΕΝΕΣ ΔΙΑΔΙΚΑΣΙΕΣ
ΔΙΑΧΕΙΡΙΣΗ ΥΠΟΘΕΣΕΩΝ
ΗΛΕΚΤΡΟΝΙΚΗ ΧΡΟΝΟΧΡΕΩΣΗ
ΒΑΣΗ ΝΟΜΙΚΩΝ ΔΕΔΟΜΕΝΩΝ
ΤΡΑΠΕΖΕΣ ΝΟΜΙΚΩΝ ΠΛΗΡΟΦΟΡΙΩΝ, ΕΛΛΑΣLEX
ΝΟΜΙΚΑ ΣΥΜΒΟΥΛΕΥΤΙΚΑ ΣΥΣΤΗΜΑΤΑ, JURICAS AT HOLLAND
name::
* McsEngl.stmIthCpn.LIBRARY@cptIt,
* McsEngl.conceptIt237,
* McsEngl.library-its@cptIt,
* McsEngl.its.library@cptIt237,
* McsEngl.library-information-technology-system@cptIt,
* McsElln.ΒΙΒΛΙΟΘΗΚΗΣ-ΣΠΤ@cptIt,
"Ο ΡΟΜΠΕΡΤ Α. ΝΤΙΚΕΡ, ΣΥΜΒΟΥΛΟΣ ΤΗΣ ΒΙΒΛΙΟΘΗΚΗΣ [ΤΟΥ ΚΟΓΚΡΕΣΟΥ] ΣΕ ΘΕΜΑΤΑ ΣΧΕΤΙΚΑ ΜΕ ΤΑ "ΠΟΛΥΜΕΣΑ" ΠΡΟΒΛΕΠΕΙ ΟΤΙ ΔΕΝ ΘΑ ΑΡΓΗΣΕΙ ΝΑ ΕΡΘΕΙ Η ΜΕΡΑ ΟΤΑΝ ΣΥΝΟΛΗ Η ΑΝΘΡΩΠΙΝΗ ΓΝΩΣΗ -ΤΟ ΠΕΡΙΕΧΟΜΕΝΟ ΤΩΝ ΜΕΓΑΛΥΤΕΡΩΝ ΒΙΒΛΙΟΘΗΚΩΝ ΤΟΥ ΚΟΣΜΟΥ- ΘΑ ΒΡΙΣΚΕΤΑΙ ΣΤΗ ΔΙΑΘΕΣΗ ΤΟΥ ΚΑΘ' ΕΝΟΣ ΜΕ ΤΟ ΚΑΤΑΛΛΗΛΟ ΚΟΜΠΙΟΥΤΕΡ, Σ'ΟΠΟΙΔΗΠΟΤΕ ΜΕΡΟΣ ΤΟΥ ΚΟΣΜΟΥ"
[ΚΑΘΗΜΕΡΙΝΗ, 16 ΜΑΙΟ 1993, 7ΜΕΡΕΣ 32]
ΤΟ CNN ΕΙΠΕ ΟΤΙ ΑΝΕΠΤΥΞΕ ΕΝΑ ΣΥΣΤΗΜΑ ΠΟΥ ΜΠΟΡΕΙΣ ΝΑ ΕΧΕΙΣ ΠΡΟΣΒΑΣΗ ΣΕ ΟΛΟΚΛΗΡΑ ΚΕΙΜΕΝΑ, ΚΑΙ ΟΧΙ ΑΠΛΩΣ ΣΕ ΚΑΤΑΛΟΓΟΥΣ ΜΕ ΠΕΡΙΕΧΟΜΕΝΑ.
[CNN FEB 1993]
ΤΑ ΠΕΡΙΧΟΜΕΝΑ ΕΙΝΑΙ 100 ΕΚΑΤ. ΒΙΒΛΙΑ, ΧΑΡΤΕΣ ΚΛΠ ΠΕΡΙΠΟΥ, Η ΜΕΓΑΛΥΤΕΡΗ ΣΤΟΝ ΚΟΣΜΟ.
[ΚΑΘΗΜΕΡΙΝΗ, 16 ΜΑΙΟ 1993, 7ΜΕΡΕΣ 32]
1990, ΞΕΚΙΝΗΣΕ Η ΔΗΜΙΟΥΡΓΙΑ ΜΙΑΣ ΕΜΒΡΥΑΚΗΣ ΗΛΕΚΤΡΟΝΙΚΗΣ ΒΙΒΛΙΟΘΗΚΗΣ ΜΕ ΘΕΜΑ ΤΗΝ ΑΜΕΡΙΚΑΝΙΚΗ ΙΣΤΟΡΙΑ ΚΑΙ ΤΟΝ ΠΟΛΙΤΙΣΜΟ, ΚΑΙ ΟΡΙΣΜΕΝΑ ΑΠΟ ΤΑ ΠΕΡΙΕΧΟΜΕΝΑ ΕΙΝΑΙ ΗΔΗ ΔΙΑΘΕΣΙΜΑ ΣΕ ΕΜΠΟΡΙΚΕΣ ΓΡΑΜΜΕΣ.
[ΚΑΘΗΜΕΡΙΝΗ, 16 ΜΑΙΟ 1993, 7ΜΕΡΕΣ 32]
ΕΙΝΑΙ ΣΤΟΧΟΣ ΝΑ ΜΕΤΑΤΡΑΠΕΙ ΣΕ ΗΛΕΚΤΡΟΝΙΚΗ ΜΟΡΦΗ Ο ΚΟΡΜΟΣ ΤΗΣ ΒΙΒΛΙΟΘΗΚΗΣ ΜΕΧΡΙ ΤΟ 2000
[ΚΑΘΗΜΕΡΙΝΗ, 16 ΜΑΙΟ 1993, 7ΜΕΡΕΣ 32]
ΠΡΟΣΠΑΘΕΙ ΝΑ ΜΕΤΑΤΡΕΨΕΙ ΤΟ ΠΕΡΙΕΧΟΜΕΝΟ-ΤΗΣ ΣΕ ΗΛΕΚΤΡΟΝΙΚΗ ΜΟΡΦΗ.
[ΚΑΘΗΜΕΡΙΝΗ, 16 ΜΑΙΟ 1993, 7ΜΕΡΕΣ 32]
NALIG: ΠΡΟΣΑΡΜΟΓΗ ΤΟΥ ΛΟΓΙΣΜΙΚΟΥ ΤΗΣ ΕΘΝΙΚΗΣ ΒΙΒΛΙΟΘΗΚΗΣ ΣΤΟ UNIMARC.
ELISE:
EDILIBE II:
HYPERLIB:
EBP:
EXLIB:
RIDDLE:
HELEN:
EDIL:
EPFORC:
MORE:
JUKE-BOX:
SOCKER:
VAN EYCK:
MIRS:
name::
* McsEngl.conceptIt397,
* McsEngl.ITS.TOLL@cptIt397,
* McsEngl.toll its@cptIt,
* McsEngl.TOLL INFORMATION TECHNOLOGY SYSTEM@cptIt,
* McsElln.ΔΙΟΔΙΩΝ ΣΠΤ@cptIt,
* McsElln.ΠΛΗΡΟΦΟΡΙΑΚΟ ΣΥΣΤΗΜΑ ΔΙΟΔΙΩΝ@cptIt,
H ΑΥΣΤΡΙΑ ΕΦΑΡΜΟΖΕΙ ΠΙΛΟΤΙΚΑ ΕΝΑ ΕΝΤΕΛΩΣ ΑΥΤΟΜΑΤΟ ΣΥΣΤΗΜΑ ΠΟΥ ΑΠΟ ΜΙΑ ΚΑΡΤΑ, ΣΑΝ ΑΥΤΕΣ ΤΗΛΕΦΩΝΟΥ, ΑΦΑΙΡΟΥΝΤΑΙ ΤΑ ΔΙΟΔΙΑ ΧΩΡΙΣ ΝΑ ΣΤΑΜΑΤΗΣΕΙ ΤΟ ΑΥΤΟΚΙΝΗΤΟ.
[ΚΑΘΗΜΕΡΙΝΗ, 9 ΙΑΝΟ 1994, 40]
name::
* McsEngl.conceptIt305,
* McsEngl.its.tvstation@cptIt305,
* McsEngl.TV STATION its@cptIt,
* McsElln.ΠΛΗΡΟΡΙΑΚΟ ΣΥΣΤΗΜΑ ΤΗΛΕΟΠΤΙΚΟΥ ΣΤΑΘΜΟΥ@cptIt,
* McsElln.ΤΗΛΕΟΠΤΙΚΟΥ ΣΤΑΘΜΟΥ ΣΠΤ@cptIt,
ΔΗΜΙΟΥΡΓΙΑ: 1988 ΞΕΚΙΝΗΣΕ.
MANAGEMENT: Σ. ΚΥΡΟΣ
HARDWARE: 80486, ΟΠΤΙΚΕΣ ΙΝΕΣ ΣΤΟ ΔΙΚΤΥΟ, LIBRARY MANAGEMENT SYSTEM SONY,
SOFTWARE: UNIX, NOVELL, MS-DOS, DR-DOS, WINDOWS, ORACLE, ΠΕΡΓΑΜΟΣ MULTIMEDIA, FREE TEXT-RETRIEVAL,
name::
* McsEngl.conceptIt283,
* McsEngl.exchange-human-it-system@cptIt283, {2012-05-08}
* McsEngl.sysItHmn.exchange@cptIt283, {2012-05-08}
* McsEngl.its.stockexchange@cptIt283,
* McsEngl.stock-exchange-its@cptIt,
* McsEngl.sysIthExch@cptIt283, {2012-05-08}
* McsElln.ανταλλαγης συστημα τεχνολογιων πληροφοριας και ανθρωπου@cptIt, {2012-05-08}
* McsElln.ΧΡΗΜΑΤΙΣΤΗΡΙΟΥ ΣΠΤ@cptIt,
name::
* McsEngl.conceptIt283.1,
* McsEngl.system.it.human.stock-exhange@cptIt283.1, {2012-05-08}
ΧΡΗΜΑΤΙΣΤΗΡΙΟ.ΛΟΝΔΙΝΟΥ
* 1986 OKT 20: TECHNOLOGY.G; UK.G;
INFORMATION.G; ΤΟ ΧΡΗΜΑΤΙΣΤΗΡΙΟ ΛΕΙΤΟΥΡΓΕΙ ΑΠΟ ΤΩΡΑ ΜΕ ΚΟΜΠΟΥΤΕΡΣ.
[ΤΗΛΕΟΡΑΣΗ]
* 1993 ΕΓΚΑΤΑΛΕΙΨΗ
ΧΙΛΙΟI ΕΡΓΑΖΟΜΕΝΟΙ ΚΙΝΔΥΝΕΥΟΥΝ ΝΑ ΜΕΙΝΟΥΝ ΑΝΕΡΓΟΙ ΚΑΙ ΓΥΡΩ ΣΤΑ 270 ΕΚΑΤΟΜΜΥΡΙΑ ΛΙΡΕΣ ΑΓΓΛΙΑΣ ΥΠΟΛΟΓΙΖΕΤΑΙ Η ΖΗΜΙΑ ΠΟΥ ΣΥΝΕΠΑΓΕΤΑΙ Η ΕΓΚΑΤΑΛΕΙΨΗ ΤΟΥ ΠΡΟΓΡΑΜΜΑΤΟΣ ΕΙΣΑΓΩΓΗΣ ΤΩΝ ΗΛΕΚΤΡΟΝΙΚΩΝ ΥΠΟΛΟΓΙΣΤΩΝ ΣΕ ΟΛΟΚΛΗΡΟ ΤΟ ΣΥΣΤΗΜΑ ΤΟΥ ΧΡΗΜΑΤΙΣΤΗΡΙΟΥ.... ΤΟ ΣΥΣΤΗΜΑ TAURUS ΜΕΛΕΤΑΤΑΙ ΑΠΟ ΤΟ 1979
[ΒΗΜΑ, 21 ΜΑΡΤ 1993, Δ41]
name::
* McsEngl.conceptIt283.2,
* McsEngl.XETRA@cptIt283.2, {2012-05-08}
Xetra ("Exchange Electronic Trading") is a worldwide electronic securities trading system based in Frankfurt, Germany. It was created for the Frankfurt Stock Exchange and launched in November, 1997.[1] It is operated by Deutsche Bφrse.
More than 14 stock exchanges around the world have licensed the Frankfurt Stock Exchange Xetra electronic trading platform. Xetra’s electronic trading technology has an outstanding record of high scalability, speed, reliability, quality of core technology and the ease with which it can be adapted in other markets.
The conception and the implementation of the Xetra System was carried out by Accenture and Deutsche Bφrse Systems, the technology division of Deutsche Bφrse. It is based on the Eurex system designed and built by Deutsche Bφrse Systems.
The Xetra system has been successfully implemented on the Irish Stock Exchange (operating as ISE Xetra),[2] the Vienna Stock Exchange,[3] the Bulgarian Stock Exchange, the European Energy Exchange,[4] the Budapest Stock Exchange,[5] and a number of other exchanges. It will also be installed on the Shanghai Stock Exchange.[6]
In September, 2011, disagreement over "the introduction of the Xetra" system was given as the reason for the resignation of Budapest exchange head Mihaly Patai. "Patai, who is also chairman-chief executive of the Hungarian arm of Italy-based UniCredit S.p.A. (UNG.MI) and chairman of the Hungarian Banking Association, has been in charge of the bourse since December, 2008," according to the report.[7]
[http://en.wikipedia.org/wiki/Xetra_(trading_system)]
name::
* McsEngl.conceptIt287,
* McsEngl.its.judicialorganization@cptIt287,
* McsEngl.JUDICIAL ORGANIZATION its@cptIt,
* McsElln.ΔΙΚΑΣΤΙΚΟΥ ΟΡΓΑΝΙΣΜΟΥ ΣΠΤ@cptIt,
ICL, ΥΠΕΓΡΑΨΕ ΣΥΜΒΑΣΗ ΓΙΑ ΤΗΝ ΕΙΣΑΓΓΕΛΙΑ ΤΟΥ ΑΡΕΙΟΥ ΠΑΓΟΥ.
ΤΟ ΣΥΣΤΗΜΑ ΑΠΟΤΕΛΕΙΤΑΙ ΑΠΟ ΕΝΑ DRS 6000, ΕΝΑΝ ΑΡΙΘΜΟ ΘΕΣΕΩΝ ΕΡΓΑΣΙΑΣ ΚΑΙ ΠΡΟΣΩΠΙΚΟΥΣ ΥΠΟΛΟΓΙΣΤΕΣ ON-LINE ΣΥΝΔΕΔΕΜΕΝΟΥΣ ΜΕ ΤΟ ΚΕΝΤΡΙΚΟ ΣΥΣΤΗΜΑ.
[ΚΟΜΠΟΥΤΕΡ ΓΙΑ ΟΛΟΥΣ, ΑΠΡΙ 1993, 91]
name::
* McsEngl.conceptIt956,
* McsEngl.its ministry@cptIt,
* McsEngl.its.ministry@cptIt956,
* McsElln.ΥΠΟΥΡΓΕΙΟΥ ΣΠΤ@cptIt,
name::
* McsEngl.conceptIt330,
* McsEngl.greek economic-ministry its@cptIt,
* McsEngl.ITS ΥΠΟΥΡΓΕΙΟΥ ΟΙΚΟΝΟΜΙΚΩΝ@cptIt,
* McsEngl.its.GreekEconomicMinistry@cptIt330,
* McsElln.ΠΛΗΡΟΦΟΡΙΑΚΟ ΣΥΣΤΗΜΑ ΥΠΟΥΡΓΕΙΟΥ ΟΙΚΟΝΟΜΙΚΩΝ@cptIt,
* McsElln.ΥΠΟΥΡΓΕΙΟΥ ΟΙΚΟΝΟΜΙΚΩΝ ΣΠΤ@cptIt,
name::
* McsElln.ΚΕΠΥΟ@cptIt,
* McsElln.ΚΕΝΤΡΟ ΠΛΗΡΟΦΟΡΙΚΗΣ ΥΠΟΥΡΓΕΙΟΥ ΟΙΚΟΝΟΜΙΚΩΝ@cptIt,
VIES: VAT (ΦΠΑ) information exchange system: DATABASE ΜΕ ΕΠΙΧΕΙΡΗΜΑΤΙΕΣ, 30000 ΕΛΛΗΝΕΣ ΚΑΙ 1.300.000 ΚΟΙΝΟΤΗΤΑΣ [ΒΗΜΑ 17 ΙΑΝ 1993]
710.000 ΕΛΛΗΝΕΣ ΙΔΙΩΤΕΣ ΚΑΙ ΕΠΙΧΕΙΡΗΣΕΙΣ ΕΧΟΥΝ ΥΠΟΒΑΛΕΙ ΔΗΛΩΣΗ ΦΠΑ ΣΤΟ ΕΛΛΗΝΙΚΟ ΣΥΣΤΗΜΑ. ΤΣΕΚΑΡΟΝΤΑΙ ΑΦΜ.
* ΑΠΟΣΤΟΛΗ ΤΟΥ ΕΙΝΑΙ Η ΣΥΓΚΕΝΤΡΩΣΗ ΣΤΟΙΧΕΙΩΝ ΓΙΑ ΤΟ ΦΠΑ, ΑΛΛΑ ΚΑΙ ΓΕΝΙΚΟΤΕΡΑ ΓΙΑ ΟΛΕΣ ΤΙΣ ΣΥΝΑΛΛΑΓΕΣ ΣΤΑ ΚΡΑΤΗ-ΜΕΛΗ ΤΗΣ ΚΟΙΝΟΤΗΤΑΣ.
- ΟΙ ΕΠΙΧΕΡΗΣΕΙΣ ΠΡΕΠΕΙ ΚΑΘΕ 3 ΜΗΝΕΣ ΝΑ ΥΠΟΒΑΛΛΟΥΝ ΣΤΙΣ ΕΦΟΡΙΕΣ "ΑΝΑΚΕΦΑΛΑΙΩΤΙΚΟ ΠΙΝΑΚΑ ΕΝΔΟΚΟΙΝΟΤΙΚΩΝ ΠΑΡΑΔΟΣΕΩΝ". ΑΛΛΙΩΣ ΠΡΟΣΤΙΜΟ ΜΕΧΡΙ 400.000 ΔΡΧ.
- ΠΑΡΑΛΛΗΛΑ ΑΡΧΙΣΕ ΝΑ ΛΕΙΤΟΥΡΓΕΙ ΚΑΙ ΤΟ intrastat ΠΟΥ ΘΑ ΠΑΡΑΚΟΛΟΥΘΕΙ ΣΤΑΤΙΣΤΙΚΑ ΤΟ ΕΝΔΟΚΟΙΝΟΤΙΚΟ ΕΜΠΟΡΙΟ.
name::
* McsEngl.conceptIt312,
* McsEngl.its.municipal@cptIt312,
* McsEngl.municipal its@cptIt,
* McsElln.ΔΗΜΩΝ ΚΑΙ ΚΟΙΝΟΤΗΤΩΝ ΠΤΣ@cptIt,
* McsElln.ΔΗΜΟΥ/ΚΟΙΝΟΤΗΤΑΣ ΣΠΤ@cptIt,
1το ΕΠΙΠΕΔΟ ΤΟΠΙΚΗΣ ΑΥΤΟΔΙΟΙΚΗΣΗΣ.
ΔΗΜΟΙ (MUNICIPALITIES); ΟΛΕΣ ΟΙ ΠΡΩΤΕΥΟΥΣΕΣ ΝΟΜΩΝ ΚΑΙ ΟΙ ΠΟΛΕΙΣ ΜΕ ΠΛΗΘΥΣΜΟ ΠΑΝΩ ΑΠΟ 10.000 ΑΤΟΜΑ.
ΚΟΙΝΟΤΗΤΕΣ (COMMUNITIES)
ΠΟΣΟΤΗΤΑ: 276 ΔΗΜΟΙ (1-10000 153, 10000-50000 98, ΑΝΩ 25), 5760 ΚΟΙΝΟΤΗΤΕΣ (1-500 3377, 500-1000 1442, 1000-3000 842, 3000-10-000 99)
[Pangalos, 1988, 95#cptResource225]
ΝΕΑ ΔΟΜΗ:
ΚΕΝΤΡΙΚΟ ΕΠΙΠΕΔΟ : ΠΡΟΓΡΑΜΜΑΤΙΣΜΟΣ, ΣΥΝΤΟΝΙΣΜΟΣ.
ΠΕΡΙΦΕΡΕΙΑΚΟ ΕΠΙΠΕΔΟ: ΠΡΟΓΡΑΜΜΑΤΙΣΜΟΣ ΚΑΙ ΤΕΧΝΙΚΗ ΥΠΟΣΤΗΡΙΞΗ
ΝΟΜΟΥ ΕΠΙΠΕΔΟ : ΥΠΟΛΟΙΠΕΣ ΕΘΥΝΕΣ.
ΠΟΥ ΜΠΟΡΟΥΝ ΝΑ ΜΗΧΑΝΟΓΡΑΦΗΘΟΥΝ.
-ΜΗΤΡΩΟ ΑΡΡΕΝΩΝ
-ΜΗΤΡΩΟ ΓΕΝΙΚΟ
-ΛΗΞΙΑΡΧΕΙΟ
-ΥΔΡΕΥΣΗ
-ΔΙΑΧΕΙΡΙΣΗ ΝΕΚΡΟΤΑΦΕΙΟΥ
-ΛΟΓΙΣΤΙΚΑ (GENERAL LEDGER-PAYROLL)
-ACCOUNTS RECEIVABLE-PAYABLE
-STOCK CONTROL
-PERSONNEL MANAGEMENT
-TECHNICAL SERVICES-PROJECT MANAGEMENT
Β. ΣΑΛΟΥΣΤΡΟΣ ΑΒΕΤΕ D, 200.000
ΜΑΡΚΟΣ ΨΑΡΡΟΣ & ΣΥΝ. D, 48.000
ΠΡΩΤΟΠΟΡΙΑ N,D,U, 100.000
ΔΗΜΟΤΟΛΟΓΙΟ 150.000
ΜΗΤΡΩΟ ΑΡΡΕΝΩΝ 100.000
ΛΗΞΙΑΡΧΕΙΑ 150.000
ΠΡΩΤΟΚΟΛΛΟ 150.000
COMSYS N,D, 225.000
GENESIS N,D,U, 100.000
INTELLTECH N,D, 150.000
ΔΗΜΟΤΗΣ/ΔΗΜΟΤΟΛΟΓΙΟ 200.000
ΔΗΜΟΤΗΣ/ΥΔΡΕΥΣΗ 200.000
ΔΗΜΟΤΗΣ/ΠΡΩΤΟΚΟΛΛΟ 200.000
ΔΗΜΟΤΗΣ/ΛΟΓΙΣΤΙΚΗ 200.000
ON LINE SYSTEM D,U, 500.000
SIGNON N,D, 90.000
UNISOFT N,D, 100.000
ΔΗΜΟΤΟΛΟΓΙΟ 250.000
ΠΡΩΤΟΚΟΛΛΟ/ΓΡΑΜΜΑΤΕΙΑ 120.000
name::
* McsEngl.PARLIAMENT its@cptIt,
* McsEngl.its.parliament@cptIt163,
* McsElln.ΒΟΥΛΗΣ ΣΠΤ@cptIt,
* McsElln.ΠΛΗΡΟΦΟΡΙΑΚΟ ΣΥΣΤΗΜΑ ΒΟΥΛΗΣ@cptIt,
1983 ΜΕΛΕΤΗ ΣΚΟΠΙΜΟΤΗΤΑΣ
1987 ΑΓΟΡΑ ΕΞΟΠΛΙΣΜΟΥ
1988 ΣΤΕΛΕΧΩΣΗ
HARDWARE:
VAX 8350 super mini, 2,
ΤΕΡΜΑΤΙΚΑ, VT 220/320, 32
ΔΙΚΤΥΟ, Ethernet Novell, 2 starlan olivetti, Hellaspac
MANAGEMENT:
ΔΡ. Γ. ΑΓΓΕΛΟΠΟΥΛΟΣ, ΥΠΕΥΘΥΝΟΣ.
24 ΥΠΑΛΛΗΛΟΙ 1992.
SERVICES:
ΠΡΟΣΒΑΣΗ ΣΤΙΣ ΒΑΣΕΙΣ ΔΕΔΟΜΕΝΩΝ CELEX AND EPOQUE ΕΛΛΑΣLEX
name::
* McsEngl.conceptIt235,
* McsEngl.PERFECTURE its@cptIt,
* McsEngl.its.perfecture@cptIt235,
* McsElln.ΝΟΜΑΡΧΙΑΣ ΣΠΤ@cptIt,
* McsElln.ΠΛΗΡΟΦΟΡΙΑΚΟ ΣΥΣΤΗΜΑ ΝΟΜΑΡΧΙΩΝ@cptIt,
ΔΙΚΤΥΑ
ΟΛΟΚΛΗΡΩΘΗΚΕ Η ΕΓΚΑΤΑΣΤΑΣΗ ΔΙΚΤΥΟΥ ΥΠΟΛΟΓΙΣΤΩΝ ΜΕ 373 QUEST 286 ΣΤΙΣ 56 ΝΟΜΑΡΧΙΕΣ ΟΛΗΣ ΤΗΣ ΧΩΡΑΣ. ΟΛΟΚΛΗΡΩΘΗΚΕ ΣΕ ΕΝΑ ΔΙΜΗΝΟ.
[ΝΕΑ 8 ΦΕΒΡ 1993]
name::
* McsEngl.conceptIt306,
* McsEngl.PUBLIC ORGANIZATION its@cptIt,
* McsEngl.its.publicorganization@cptIt306,
* McsElln.ΠΛΗΡΟΦΟΡΙΑΚΟ ΣΥΣΤΗΜΑ ΔΗΜΟΣΙΩΝ ΟΡΓΑΝΙΣΜΩΝ@cptIt,
* McsElln.ΔΗΜΟΣΙΟΥ ΟΡΓΑΝΙΣΜΟΥ ΣΠΤ@cptIt,
_SPECIFIC:
GOVERNMENT#cptIt219#
JUDICIAL-ORGANIZATION#cptIt287#
MINISTRY/ΥΠΟΥΡΓΕΙΟ
MUNICIPAL#cptIt312#
PARLIAMENT#cptIt163#
PERFECTURE#cptIt235#
PUBLIC BUSINESS
ΚΑΤΑΚΥΡΩΣΕ ΔΙΕΘΝΗ ΔΙΑΓΩΝΙΣΜΟ ΓΙΑ ΤΗ ΜΗΧΑΝΟΡΓΑΝΩΣΗ ΤΟΥ, ΥΨΟΥΣ 600 ΕΚ. ΔΡΧ ΣΤΗΝ ΕΤΑΙΡΙΑ INFORMER AE. Η ΑΝΑΘΕΣΗ ΠΕΡΙΛΑΜΒΑΝΕΙ ΕΞΟΠΛΙΣΜΟ ΠΟΥ ΑΠΟΤΕΛΕΙΤΑΙ ΑΠΟ 10 ΣΥΣΤΗΜΑΤΑ RISC/IBM, ORACLE, ΕΚΠΑΙΔΕΥΣΗ ΚΑΙ ΥΠΟΣΤΗΡΙΞΗ. Ο ΕΞΩΠΛΙΣΜΟΣ ΘΑ ΕΓΚΑΤΑΣΤΑΘΕΙ ΣΕ ΙΣΑΡΙΘΜΕΣ ΠΟΛΕΙΣ ΤΗΣ ΕΛΛΑΔΑΣ, ΕΝΤΟΣ 3 ΜΗΝΩΝ ΑΠΟ ΤΗΝ ΗΜΕΡΟΜΗΝΙΑ ΚΑΤΑΚΥΡΩΣΗΣ.
[COMPUTER GO, JUN 1993, 81]
name::
* McsEngl.conceptIt450,
* McsEngl.system.it.economy@cptIt450, {2012-05-05}
* McsEngl.stmIthEcm@cptIt450, {2015-08-29}
* McsEngl.sysItEcn@cptIt450, {2012-05-05}
_DESCRIPTION:
The-state administering the economy-stmIth.
[hmnSngo.2015-08-29]
name::
* McsEngl.stmIthEcm'sector.HEALTH@cptIt,
* McsEngl.conceptIt454,
* McsEngl.HEALTH-SECTOR-its@cptIt,
* McsEngl.its.healthsector@cptIt454,
* McsElln.ΥΓΕΙΑΣ-ΠΤΣ@cptIt,
_DESCRIPTION:
ΠΡΟΤΕΙΝΕΤΑΙ:
--ΝΑ ΕΧΕΙ ΜΙΑ ΠΛΑΣΤΙΚΗ ΚΑΡΤΑ ΜΕ ΒΑΣΙΚΗ ΠΛΗΡΟΦΟΡΙΑ.
--ΚΑΘΕ ΑΣΘΕΝΗΣ ΝΑ ΕΧΕΙ ΙΑΤΡΙΚΟ ΡΕΚΟΡΝΤ ΣΕ ΜΙΑ LOCAL DATABASE.
ΠΛΗΡΟΦΟΡΙΚΑ ΣΥΣΤΗΜΑΤΑ ΝΟΣΟΚΟΜΕΙΩΝ:
ΠΕΡΙΛΑΜΒΑΝΕΙ ΤΗ ΜΗΧΑΝΟΓΡΑΦΗΣΗ 15 ΝΟΣΟΚΟΜΕΙΩΝ ΑΠΟ ΤΑ ΟΠΟΙΑ 10 ΒΡΙΣΚΟΝΤΑΙ ΣΤΗΝ ΑΘΗΝΑ..
ΤΟ ΑΝΕΛΑΒΑΝ ΟΙ ΕΤΑΙΡΕΙΕΣ DEC, INTRACOM, ICL (UNIX )
{time.1993}:
ΣΗΜΕΡΑ ΛΕΙΤΟΥΡΓΟΥΝ ΕΛΑΧΙΣΤΕΣ ΕΦΑΡΜΟΓΕΣ ΣΕ ΚΑΠΟΙΑ ΑΠΟ ΤΑ 15 ΝΟΣΟΚΟΜΕΙΑ ΠΟΥ ΕΧΟΥΝ ΕΝΤΑΧΘΕΙ ΣΤΟ ΠΡΟΓΡΑΜΜΑ.
[ΒΗΜΑ, 26 ΣΕΠΤ 1993, Ε5]
{time.1985}:
ΞΕΚΙΝΗΣΕ.
[ΒΗΜΑ, 26 ΣΕΠΤ 1993, Ε5]
{time.1983}:
ΨΗΦΙΖΕΤΑΙ ΝΟΜΟΣ ΓΙΑ ΤΟ ΕΘΝΙΚΟ ΣΥΣΤΗΜΑ ΥΓΕΙΑΣ. ΧΩΡΙΣ ΠΛΗΡΩΜΗ ΓΙΑ ΟΛΟΥΣ. 3 ΕΠΙΠΕΔΑ ΟΡΓΑΝΩΣΗΣ.
[Makris-et-all, 1987, 36#cptResource226]
name::
* McsEngl.stmIthEcm'sector.PUBLIC@cptIt,
* McsEngl.conceptIt270,
* McsEngl.public-sector-ITS@cptIt,
* McsEngl.its.public'sector@cptIt270,
* McsElln.ΠΛΗΡΟΦΟΡΙΑΚΟ-ΣΥΣΤΗΜΑ-ΔΗΜΟΣΙΟΥ-ΤΟΜΕΑ-ΚΟΙΝΩΝΙΑΣ@cptIt,
* McsElln.ΔΗΜΟΣΙΟΥ-ΤΟΜΕΑ-ΣΠΤ@cptIt,
name::
* McsEngl.conceptIt199,
* McsEngl.GREEK-PUBLIC-SECTOR-its@cptIt,
* McsEngl.its.greek'public'sector@cptIt,
* McsElln.ΕΛΛΗΝΙΚΟΥ-ΔΗΜΟΣΙΟΥ-ΣΠΤ@cptIt,
* αναμορφωση του ΤΕΧΝΙΚΟΥ ΣΥΜΒΟΥΛΙΟΥ ΠΛΗΡΟΦΟΡΙΚΗΣ (ΤΕΣΥΠ)
* Η ΠΡΟΣΑΡΜΟΓΗ ΤΩΝ ΠΡΟΜΗΘΕΙΩΝ ΠΛΗΡΟΦΟΡΙΚΗΣ ΤΕΧΝΟΛΟΓΙΑΣ ΣΤΟ ΚΑΘΕΣΤΩΣ ΤΗΣ ΕΟΚ
* ΠΡΟΣΤΑΣΙΑ ΑΠΟ ΤΗΝ ΑΥΤΟΠΟΙΗΜΕΝΗ ΕΠΕΞΕΡΓΑΣΙΑ ΠΛΗΡΟΦΟΡΙΩΝ
* η θέσπιση ΚΥΒΕΡΝΗΤΙΚΩΝ ΣΥΣΤΗΜΑΤΩΝ ΠΛΗΡΟΦΟΡΙΚΗΣ
* Η ΟΛΟΚΛΗΡΩΣΗ ΤΟΥ ΕΡΓΟΥ ΤΗΣ ΜΗΧΑΝΟΡΓΑΝΩΣΗΣ ΤΗΣ ΜΙΣΘΟΔΩΣΙΑΣ ΤΟΥ ΠΡΟΣΩΠΙΚΟΥ ΤΗΣ ΔΗΜΟΣΙΑΣ ΔΙΟΙΚΗΣΗΣ
ΑΘΗΝΑ#cptIt20, ΜΗΧΑΝΟΡΓΑΝΩΣΗ ΜΙΚΡΩΝ ΑΣΦΑΛΙΣΤΙΚΩΝ ΤΑΜΕΙΩΝ: attPar#
ΘΑΛΗΣ#cptIt143, ΠΑΡΑΚΟΛΟΥΘΗΣΗ ΔΑΠΑΝΩΝ ΠΡΟΥΠΟΛΟΓΙΣΜΟΥ: attPar#
ΣΟΛΩΝ#cptIt206, ΔΙΟΙΚΗΣΗ ΜΙΣΘΟΔΟΣΙΑ ΠΡΟΣΩΠΙΚΟΥ: attPar#
ΧΡΟΝΟΔΙΑΓΡΑΜΜΑ:
ΑΡΧΕΣ 1994: Θα τεθούν σε εφαρμογή.
[ΒΗΜΑ, 4 ΙΟΥΝ 1994, Α47]-
ΑΣΤΥΝΟΜΙΑ ΚΑΙ ΕΓΚΛΗΜΑΤΙΚΟΤΗΤΑ
ΒΙΟΜΗΧΑΝΙΑ ΚΑΙ ΕΜΠΟΡΙΟ
ΓΕΩΡΓΙΑ
ΕΚΔΟΣΗ ΤΑΥΤΟΤΗΤΩΝ
ΕΛΕΓΧΟΣ ΠΑΡΟΥΣΙΑΣ ΠΡΟΣΩΠΙΚΟΥ
ΚΕΝΤΡΙΚΟ ΣΥΣΤΗΜΑ ΜΙΣΘΟΔΩΣΙΑΣ
ΚΟΙΝΩΝΙΚΗ ΑΣΦΑΛΙΣΗ ΚΑΙ ΥΓΕΙΑ
ΜΗΧΑΝΕΣ ΠΡΟΠΟ
ΜΗΧΑΝΟΡΓΑΝΩΣΗ ΝΟΣΟΚΟΜΕΙΩΝ
ΠΕΡΙΒΑΛΛΟΝ ΚΑΙ ΜΟΛΥΝΣΗ
ΣΥΣΤΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΟΛΠ & ΟΛΘ
ΤΟΥΡΙΣΜΟΣ
ΦΟΡΟΛΟΓΙΚΟ ΣΥΣΤΗΜΑ
HELLAS-NET:
ΚΡΑΤΙΚΟ ΔΙΚΤΥΟ ΠΛΗΡΟΦΟΡΙΩΝ
ΔΙΚΤΥΟ ΣΥΣΤΗΜΑΤΩΝ ΠΛΗΡΟΦΟΡΙΚΗΣ ΔΗΜΟΣΙΑΣ ΔΙΟΙΚΗΣΗΣ
-ΗΡΘΑΝ ΕΜΠΕΙΡΟΓΝΩΜΟΝΕΣ ΑΠΟ ΔΝΤ ΓΙΑ ΝΑ ΠΡΟΤΕΙΝΟΥΝ ΗΛΕΚΤΡΟΝΙΚΗ ΛΥΣΗ ΔΙΑΧΕΙΡΙΣΗΣ ΤΩΝ ΡΕΥΣΤΩΝ ΔΙΑΘΕΣΙΜΩΝ ΤΟΥ ΚΡΑΤΟΥΣ.
ΤΟ ΣΥΣΤΗΜΑ ΘΑ ΕΙΝΑΙ ΚΛΕΙΣΤΟ ΩΣΤΕ ΝΑ ΣΥΝΔΕΕΙ ΜΕΤΑΞΥ ΤΟΥΣ ΤΙΣ ΕΦΟΡΙΕΣ ΚΑΙ ΤΑ ΑΛΛΑ ΔΗΜΟΣΙΑ ΤΑΜΕΙΑ, ΕΤΣΙ ΩΣΤΕ ΝΑ ΕΙΝΑΙ ΓΝΩΣΤΟ ΣΕ ΚΑΘΗΜΕΡΙΝΗ ΒΑΣΗ ΤΟ ΥΨΟΣ ΤΩΝ ΕΙΣΠΡΑΞΕΩΝ ΤΟΥ ΚΡΑΤΟΥΣ. ΚΑΤΑ ΤΟΝ ΙΔΙΟ ΤΡΟΠΟ ΘΑ ΚΑΤΑΓΡΑΦΕΙ ΟΠΟΙΑΔΗΠΟΤΕ ΔΑΠΑΝΗ ΟΠΟΙΟΥΔΗΠΟΤΕ ΥΠΟΥΡΓΕΙΟΥ. μελλοντικο.
[ΒΗΜΑ, 27 ΙΟΥΝ 1993, Δ2]
* ΥΠΟΥΡΓΕΙΑ: ΟΙΚΟΝΟΜΙΚΩΝ-ΓΕΩΡΓΙΑΣ-ΠΑΙΔΕΙΑΣ-ΜΕΤΑΦΟΡΩΝ
* ΓΕΝΙΚΕΣ ΓΡΑΜΜΑΤΕΙΕΣ: ΣΤΑΤΙΣΤΙΚΗΣ ΥΠΗΡΕΣΙΑΣ-ΚΟΙΝΩΝΙΚΩΝ ΑΣΦΑΛΕΙΣΕΩΝ-ΕΡΕΥΝΑΣ ΚΑΙ ΤΕΧΝΟΛΟΓΙΑΣ.
* ΥΠΟΛΕΙΠΕΤΑΙ ΤΩΝ ΑΛΛΩΝ ΧΩΡΩΝ ΤΗΣ ΚΟΙΝΟΤΗΤΑΣ (ΕΠΙΤΡΟΠΗ ΔΕΚΛΕΡΗ 60/1, 10/1 ΟΘΟΝΕΣ ΠΟΥ ΑΝΤΙΣΤΟΙΧΟΥΝ ΣΕ ΔΗΜΟΣΙΟΥΣ ΥΠΑΛΛΗΛΟΥΣ)
_Price:
* 1,3 ΔΙΣ ΔΡΧ ΤΟ 1993.
===
ΣΥΝΟΛΙΚΟ ΚΟΣΤΟΣ:
6 δισ. δρχ.
[ΒΗΜΑ, 4 ΙΟΥΝ 1994, Α47]
* ΚΥΒΕΡΝΗΤΙΚΟ ΣΥΜΒΟΥΛΙΟ ΠΛΗΡΟΦΟΡΙΚΗΣ (ΚΥΣΥΠ)
* ΣΥΝΤΟΝΙΣΤΙΚΕΣ ΟΜΑΔΕΣ ΠΛΗΡΟΦΟΡΙΚΗΣ, ΘΕΣΠΙΣΤΗΚΑΝ ΜΕ ΤΟ ΝΟΜΟ Ν-1943-1991
name::
* McsEngl.stmIthEcm'sector.TURIST@cptIt,
* McsEngl.conceptIt201,
* McsEngl.TURIST-SECTOR-its@cptIt,
* McsEngl.its.turistsector@cptIt201,
* McsElln.ΤΟΜΕΑ-ΤΟΥΡΙΣΜΟΥ-ΣΠΤ@cptIt,
ΤΟΥΡΙΣΜΟΣ: Αυτοματοποιηση της διαθεσης του ΕΛΛΗΝΙΚΟΥ ΤΟΥΡΙΣΤΙΚΟΥ ΠΡΟΙΟΝΤΟΣ.
Θα συνδεσει τις κυριοτερες ελλ. τουριστικες επιχειρησεις ΜΕ ενα ευρυτατο δικτυο τουριστικων πρακτορων στο εξωτερικο και στην ελλαδα. Χρηματοδοτηθηκε απο το κοινοτικο προγραμμα STAR. Το ανελαβε η databank.
[ΤΟ ΒΗΜΑ, 1992-07-03]
name::
* McsEngl.stmIthEcm.time.EVOLUTING@cptIt,
{time.1971}:
=== CyberCyn:
In 1971, an innovative system of cybernetic information management and transfer began developing in Chile during the government of President Salvador Allende; the CYBERSYN project, cybernetic synergy or SYNCO, information and control system. In Chilean State owned companies a system for capturing, processing and presenting economic information to be managed in “quasi” real time, becoming an absolute pioneer in the application of a cybernetic model in mass socio-economic contexts, and based on a convergence of science, technology, politics and cybernetics. The economic system of the Allende Government, after annexing and nationalising diverse State companies, was faced with the necessity to coordinate information regarding state companies and those that had been recently nationalised, so it required the creation of a dynamic and flexible system for a proper management of the companies. In 1970 Fernando Flores was appointed Technical Director General of CORFO (Production Development Corporation of Chile), and was responsible for the management and coordination between nationalised companies and the State. He had known the theories and solutions proposed by Britain’s Stafford Beer since he was an engineering student, and subsequently in the course of his professional relationship with SIGMA, the Beer consultancy firm. He and Raϊl Espejo, who also worked at CORFO, wrote to Stafford Beer inviting him to implement VSM (the Viable System Model) in Chile, which had been developed in Beer’s “THE BRAIN OF THE FIRM” (1967 – PP). Beer accepted immediately, and the project entered its development stage in 1971.
[http://www.cybersyn.cl/ingles/cybersyn/index.html]
name::
* McsEngl.conceptIt219,
* McsEngl.stmIth.system.STATE@cptIt,
* McsEngl.FvMcs.stmIth.system.STATE@cptIt,
* McsEngl.government-it-system@cptIt,
* McsEngl.its.government@cptIt219,
* McsEngl.e-government@cptIt219, {2011-09-07}
* McsElln.ΚΥΒΕΡΝΗΣΗΣ-ΣΠΤ@cptIt,
_GENERIC:
* stmIth#cptItsoft180#
* entity.whole.system.it_human#cptItsoft180#
{time.2011}:
Απογοητευτικά είναι τα στοιχεία που έδωσε η Ευρωπαϊκή Επιτροπή για την προώθηση της ηλεκτρονικής διακυβέρνησης στην Ελλάδα. Συγκεκριμένα η χώρα μας βρίσκεται στην τελευταία θέση της λίστας των 27 με 37,5% την ώρα που ο ευρωπαϊκός μέσος όρος είναι στο 84%.
Όπως αναφέρει η απάντηση της αντιπροέδρου της Επιτροπής κ. Νέλι Κρουζ στην ερώτηση του ευρωβουλευτή της ΝΔ κ. Γιώργου Παπανικολάου «μόλις το 13,4% των Ελλήνων χρησιμοποιούν το διαδίκτυο για συναλλαγές με τις δημόσιες αρχές, όταν ο ευρωπαϊκός μέσος όρος ανέρχεται στο 41%».
Από την πλευρά του, ο κ. Παπανικολάου σημείωσε πως όλα αυτά γίνονται την ώρα που σύμφωνα με τα στοιχεία για την αξιοποίηση των πόρων των διαρθρωτικών ταμείων η Ελλάδα εμφανίζεται ως η δεύτερη χώρα στην Ε.Ε. -μετά την Σλοβακία- με τις μεγαλύτερες επενδύσεις σε υπηρεσίες και εφαρμογές για τους πολίτες.
Συγκεκριμένα, η Ελλάδα παρουσιάζεται να επενδύει το 3,7% (780 εκ. ευρώ) των συνολικών διαθέσιμων πόρων των διαρθρωτικών ταμείων για την χώρα για αυτό τον σκοπό.
[http://www.kathimerini.gr/4dcgi/_w_articles_kathremote_1_07/09/2011_405215]
ΤΟ Informatics Research Institute ΑΣΧΟΛΕΙΤΑΙ ΜΕ ΤΗΝ ΑΝΑΠΤΥΞΗ ΚΑΙ ΕΦΑΡΜΟΓΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΗΝ ΠΡΟΕΔΡΙΑ ΚΑΙ ΤΗΝ ΚΕΝΤΡΙΚΗ ΚΥΒΕΡΝΗΣΗ ΤΗΣ ΧΩΡΑΣ.
name::
* McsEngl.conceptIt20,
* McsElln.ΑΘΗΝΑ@cptIt20,
* McsElln.ΑΘΗΝΆ@cptIt,
* McsElln.αθηνά@cptIt,
* McsEngl.its.αθηνα@cptIt20,
ΑΘΗΝΆ είναι πληροφοριακό σύστημα για την οργάνωση και βελτίωση των υπηρεσιών που παρέχει το ασφαλιστικό σύστημα, περιορίζοντας εκ παραλλήλου και το κόστος λειτουργίας του.
[ΒΗΜΑ, 4 ΙΟΥΝ 1994, Α47]
Σε πλήρη ανάπτυξη θα εξυπηρετεί 250, ΑΛΛΑ σε πρώτη φάση δοκιμαστικά σε 7:
- ΤΑΠ/ΟΤΕ,
- Εμποροϋπαλλήλων,
- Ξενοδοχοϋπαλλήλων,
- Συμβολαιογράφων,
- ΤΣΜΕΔΕ,
- ΤΑΥΣΥΤ,
- Δικηγόρων Ηρακλείου.
[ΒΗΜΑ, 4 ΙΟΥΝ 1994, Α47]
name::
* McsEngl.conceptIt253,
* McsEngl.its.ΔΗΜΟΚΤΡΙΤΟΥ@cptIt253,
* McsElln.ΔΗΜΟΚΡΙΤΟΥ ΣΠΤ@cptIt,
* McsElln.ΠΛΗΡΟΦΟΡΙΑΚΟ ΣΥΣΤΗΜΑ ΔΗΜΟΚΡΙΤΟΥ its@cptIt,
ΔΙΚΤΥΑ:
Vines.
ΣΥΝΔΕΣΗ ΜΕ ΤΟ ΔΙΚΤΥ ΑΡΙΑΔΝΗ.
ΜΕΣΩ TCP/IP ME ΚΕΝΤΡΙΚΟ ΥΠΟΛΟΓΙΣΤΗ convex.
ΙΣΤΟΡΙΚΟ:
1993
ΕΠΕΚΤΑΣΗ ΤΟΥ ΔΙΚΤΥΟΥ VINES ΣΕ ΔΥΟ ΑΛΛΑ ΣΗΜΕΙΑ α) ΙΝΣΤΙΤΟΥΤΟ ΡΑΔΙΟΙΣΟΤΟΠΩΝ ΚΑΙ β) ΣΤΟ ΚΤΙΡΙΟ ΤΗΣ ΣΧΟΛΗΣ. ΥΠΗΡΑΧΑΝ ΕΙΔΗ γ) Η ΔΙΕΥΘΥΝΣΗ ΔΙΟΙΚΗΤΙΚΟΥ ΚΑΙ δ) ΤΟ ΚΕΝΤΡΟ ΠΛΗΡΟΦΟΡΙΚΗΣ.
ΕΤΑΙΡΕΙΑ: COMPUTER BANK AE.
[COMPUTER ΓΙΑ ΟΛΟΥΣ, ΦΕΒ 1993, 87]
name::
* McsEngl.conceptIt143,
* McsElln.ΘΑΛΗΣ@cptIt143,
Ο ΘΑΛΗΣ είναι ένα πληροφοριακό σύστημα παρακολούθησης των δαπανών του προϋπολογισμού του κράτους. Με την εφαρμογή του το υπουργείο Οικονομικών θα γνωρίζει ανά πάσα στιγμή τη ροή των δαπανών του και θα μπορεί να μεταφέρει κονδύλια από τον ένα κωδικό στον άλλο.
[ΒΗΜΑ, 4 ΙΟΥΝ 1994, Α47]
Η μελέτη έγινε απο το οικονομικό πανεπιστήμιο.
[ΒΗΜΑ, 4 ΙΟΥΝ 1994, Α47]
Με το
- υπουργείο υγείας και
- γενικό λογιστήριο.
[ΒΗΜΑ, 4 ΙΟΥΝ 1994, Α47]
name::
* McsEngl.conceptIt206,
* McsElln.ΣΟΛΩΝ its@cptIt,
* McsEngl.its.ΣΟΛΩΝ@cptIt206,
* McsElln.ΣΟΛΩΝ@cptIt206,
ΣΟΛΩΝ είναι το ηλεκτρονικό πληροφοριακό σύστημα οργάνωσης της διοίκησης και της μισθοδοσίας του συνόλου των δημοσίων υπαλλήλων, που θα αυτοματοποιηθούν, παρέχοντας στη διοίκηση την ευχέρεια να γνωρίζει την κίνηση του προσωπικού, το δυναμικό των υπηρεσιών και την εξέλιξη των υποθέσεων που χειρίζονται υπάλληλοι και υπηρεσίες.
[ΒΗΜΑ, 4 ΙΟΥΝ 1994, Α47]
name::
* McsEngl.conceptIt242,
* McsEngl.binary-data@cptIt242, {2014-11-28}
* McsEngl.binary-document@cptIt242, {2014-11-28}
* McsEngl.computer-data@cptIt242,
* McsEngl.computer-document@cptIt242, {2014-11-28}
* McsEngl.data@cptIt242,
* McsEngl.data.computer@cptIt242,
* McsEngl.data.digital@cptIt242, {2012-04-12}
* McsEngl.data software@cptIt,
* McsEngl.data.software@cptIt242,
* McsEngl.data-structure-of-computer-langauge@cptIt242,
* McsEngl.data-type-of-computer-language@cptIt242,
* McsEngl.dataInfotech@cptIt242, {2014-02-08}
* McsEngl.dataSoft@cptIt242, {2014-02-08}
* McsEngl.digital-data@cptIt242,
* McsEngl.digital-document@cptIt242, {2014-12-06}
* McsEngl.digital-information@cptIt242, {2013-12-24}
* McsEngl.datatype-of-pcl@cptIt248,
* McsEngl.document.digital@cptIt242, {2014-12-06}
* McsEngl.document.electronic@cptIt242, {2014-12-06}
* McsEngl.elcectronic-document@cptIt242, {2014-12-06}
* McsEngl.software-data@cptIt242,
* McsEngl.software.information@cptIt242, {2013-12-24}
* McsEngl.software.instructionNo@cptIt242, {2013-12-25}
* McsEngl.software.processingNo@cptIt242, {2013-12-24}
* McsEngl.type-of-computer-language@cptIt242,
* McsEngl.dataIt@cptIt242, {2014-02-08}
* McsEngl.dataDgl@cptIt242, {2014-02-01}
* McsEngl.dgldat@cptIt242, {2013-12-24}
* ΔΕΔΟΜΕΝΑ-ΠΡΟΓΡΑΜΜΑΤΟΣ, {2013-12-24}
* McsElln.ΨΗΦΙΑΚΑ-ΔΕΔΟΜΕΝΑ@cptIt242, {2012-04-12}
DataSoftware is information REPRESENTED in information-technology.
[hmnSngo.2014-02-08]
Software-Data is any sensorial-information by organisms or machines, such as sign, speech, text, photo, audio, video, etc, managed with computers.
[hmnSngo.2012-03-04]
Data is any sensorial-information by organisms or machines, such as sign, speech, text, photo, audio, video, etc, stored
[hmnSngo.2010-06-06]
_DEFINITION:
* In computer programming, a data type or datatype is a defined kind of data, that is, a set of possible values and basic operations on those values.
[http://en.wikipedia.org/wiki/Category:Data_types]
** Every CL uses internal constructs that represent information, for example the "integer numbers" we know from math, it has diferent construct to represent eg 1-byte-integer, 2-byte-integer, signed-integer, unsigned-integer etc. These constructs we call DATA-TYPES.
[hmnSngo.2002-05-08]
** DATA-TYPE OF A COMPUTER-LANGUAGE is any construct that holds 'data' **or** data and 'operations' on them (as oop).
[hmnSngo.2002-04-28]
** DATA-STRUCTURE I call the construction a language uses to store information-representations (data).
[hmnSngo.2002-04-24]
Ουσιαστικά τα ΔΕΔΟΜΕΝΑ (data) αναπαριστούν τις ΠΛΗΡΟΦΟΡΙΕΣ που πρέπει να πάρει ένα πρόγραμμα, ώστε να φέρει σε πέρας επιτυχώς την αποστολή του.
[Αντωνάκος κα, "Ανάπτυξη εφαρμογών..." Γ' Λυκείου, 1999 α' έκδοση, 173]
ΔΕΔΟΜΕΝΑ είναι ΑΠΛΕΣ-ΠΛΗΡΟΦΟΡΙΕΣ, πχ μετρήσεις οργάνων, παρατηρήσεις απο τις οποίες ύστερα απο επεξεργασία βγάζουμε γενικότερα συμπεράσματα.
[ΝΙΚΟΣ, ΟΚΤ. 1995]
ΔΕΔΟΜΕΝΑ ονομάζω 'ΛΟΓΙΣΜΙΚΟ' που δεν είναι οδηγίες εκτέλεσης διαδικασίας.
[ΝΙΚΟΣ, ΝΟΕΜ. 1994]
Τα ΔΕΔΟΜΕΝΑ είναι ΕΦΑΡΜΟΓΗ κάποιου προγράμματος βάσει του οποίου έχουν δημιουργηθει.
[ΝΙΚΟΣ, ΟΚΤ. 1994]
Η διαφορα προγραμα-δεδομένα ΔΕΝ ΕΙΝΑΙ παντα ξεκάθαρη.
The term data refers to qualitative or quantitative attributes of a variable or set of variables. Data (plural of "datum") are typically the results of measurements and can be the basis of graphs, images, or observations of a set of variables. Data are often viewed as the lowest level of abstraction from which information and then knowledge are derived. Raw data, i.e. unprocessed data, refers to a collection of numbers, characters, images or other outputs from devices that collect information to convert physical quantities into symbols.
[http://en.wikipedia.org/wiki/Data]
1. not-program: not processing code.
2. not-knowledge: data, information, knowledge.
An electronic document is any electronic media content (other than computer programs or system files) that are intended to be used in either an electronic form or as printed output. Originally, any computer data were considered as something internal — the final data output was always on paper. However, the development of computer networks has made it so that in most cases it is much more convenient to distribute electronic documents than printed ones. And the improvements in electronic display technologies mean that in most cases it is possible to view documents on screen instead of printing them (thus saving paper and the space required to store the printed copies).
However, using electronic documents for final presentation instead of paper has created the problem of multiple incompatible file formats. Even plain text computer files are not free from this problem — e.g. under MS-DOS, most programs could not work correctly with UNIX-style text files (see newline), and for non-English speakers, the different code pages always have been a source of trouble.
Even more problems are connected with complex file formats of various word processors, spreadsheets and graphics software. To alleviate the problem, many software companies distribute free file viewers for their proprietary file formats (one example is Adobe's Acrobat Reader). The other solution is the development of standardized non-proprietary file formats (such as HTML and OpenDocument), and electronic documents for specialized uses have specialized formats – the specialized electronic articles in physics use TeX or PostScript.
[http://en.wikipedia.org/wiki/Electronic_document] {2014-12-06}
name::
* McsEngl.dataIt'ENVIRONMENT@cptIt,
name::
* McsEngl.dataIt'DATA-and-KNWOLEDGE@cptIt,
By knowledge, I mean the kind of information expressed by language. On the other hand data, i.e. highly structured information, is what database systems are good at managing, and databases are well understood and used. But most online knowledge is currently kept in files that are hard to structure, classify, browse, and find. Usually they are collections of documents created by word processors and found only by where they are kept.
[IKARUS ...ikarus4.html 1996oct]
name::
* McsEngl.dataIt'archetype@cptIt,
_DESCRIPTION:
Digital-data REPRESENT information, the archetype.
[hmnSngo.2014-02-06]
name::
* McsEngl.dataIt'doing@cptIt,
* McsEngl.data'function@cptIt,
* McsEngl.data'operation@cptIt,
* McsEngl.operation-of-datatype@cptIt248i,
_DESCRIPTION:
On every datatype are allowed specific processes (functions).
[KasNik, 2007-12-23]
===
OPERATOR is the symbol used for the operation.
[KasNik, 2007-12-23]
name::
* McsEngl.dataIt'endian@cptIt,
_DESCRIPTION:
If all data items are of byte type,then there is no question of Byte order.While storing multiple byte data items(or writing to some output stream),the sequence in which each byte is written/Read should be defined.There are two conventions followed.
In little endian the low byte( I mean the least significant byte ) is stored first(low memory addresss) and is followed by the next lower byte upto the high byte( most significant byte).(e.g Intel chips).
In big endian, the order is reverse.i.e High byte is stored first(low memory addresss) followed by next higher byte till the lower byte.(e.g Motorolo chips)
Network notation is big endian
[internet {1998-04-29}]
name::
* McsEngl.dataIt'entry@cptIt,
* McsEngl.conceptIt204,
* McsEngl.data-acquisition@cptIt,
* McsEngl.data'entry@cptIt204,
* McsEngl.IT-data-entry@cptIt,
* McsElln.ΕΙΣΑΓΩΓΗ-ΔΕΔΟΜΕΝΩΝ@cptIt,
_SPECIFIC:
KEYBOARDING
MANUAL DATA ENTRY
OPTICAL CHARACTER RECOGNITION
VOICE INPUT
Στην περιοχή της ΟΥΑΣΙΓΚΤΟΝ λειτουργει μια εταιρια που χρησιμοποιεί τους μοναχούς απο τα γύρω μοναστήρια για την εισαγωγή δεδομένων στον υπολογιστη.
[ΚΑΘΗΜΕΡΙΝΗ, 15 ΙΑΝ. 1995, 50]
name::
* McsEngl.dataIt.specific@cptIt,
* McsEngl.data.specific@cptIt,
* McsEngl.dataDgl.specific@cptIt,
* McsEngl.dgldat.specific@cptIt,
_SPECIFIC: dataIt.Alphabetically:
* abstract,
* algebraic,
* audio#cptItsoft986#
* boolean,
* character,
* collection,
* composite,
* compound,
* concept,
* concurrent#ql:data.concurrent#,
* date,
* endUser-data,
* graph
* image#cptItsoft989#
* instance,
* input,
* knowledge#cptItsoft458.1#
* linear,
* linerar_no,
* list,
* number,
* output,
* primitive,
* programming-language--data#ql:data_of_programming_language@cptIt242i#
* pointer and reference,
* primitive,
* string,
* text,
* tree,
* type,
* URL,
* value,
* video#cptItsoft987#
ΔΟΜΗ ΔΕΔΟΜΕΝΩΝ ονομάζουν τα είδη των data ένα πρόγραμμα παίρνει σαν είσοδο για να επεξεργαστεί αλλά και τα ᾳποτελέσματα' της επεξεργασίας.
Άρα η ελληνική μετάφραση 'δεδομένα' ΔΕΝ ανταποκρίνεται στην πραγματικότητα γιατί με τη λέξη αυτή στα ελληνικά εννοούμε πληροφορίες εισόδου.
[nikkas 1999oct29]
Classification of data structure
Primitive / Non-primitive: Primitive data structures are basic data structure and are directly operated upon machine instructions, e.g., integer, character. Non-primitive data structures are derived from primitive data structures, e.g., structure, union, array.
Homogeneous / Heterogeneous: In homogeneous data structures all elements are of the same type, e.g., array. In heterogeneous data structures elements are of different types, e.g. structure.
Static / Dynamic: In static data structures memory is allocated at the time of compilation. In dynamic data structures memory is allocated at run-time, throught functions such as malloc, calloc, etc.
Linear / Non-linear: Linear data structures maintain a linear relationship between their elements, e.g., array. Non-linear data structures do not maintain any linear relationship between their elements, e.g., in a tree.
[http://en.wikipedia.org/wiki/Data_structure]
name::
* McsEngl.dataIt.SPECIFIC-DIVISION.sensor@cptIt,
_SPECIFIC:
* audio-data#ql:dgldat.audio#
* image-data#ql:dgldat.image#
* linguistic-data#linkL#
* video-data#linkL#
name::
* McsEngl.dataIt.SPECIFIC-DIVISION.structure@cptIt,
_SPECIFIC:
* primitive-data#ql:dgldat.primitive#
* primitiveNo-data#ql:data.primitive.no#
name::
* McsEngl.dataIt.SPECIFIC-DIVISION.implementation@cptIt,
name::
* McsEngl.dataIt.ABSTRACT (unimplemented)@cptIt,
* McsEngl.abstract-datatype@cptIt242i,
* McsEngl.data.unimplemented@cptIt,
_DEFINITION:
In computing, an abstract data type (ADT) is a specification of a set of data and the set of operations that can be performed on the data. Such a data type is abstract in the sense that it is independent of various concrete implementations. The definition can be mathematical, or it can be programmed as an interface. A first class ADT supports the creation of multiple instances of the ADT, and the interface normally provides a constructor, which returns an abstract handle to new data, and several operations, which are functions accepting the abstract handle as an argument.[1]
[http://en.wikipedia.org/wiki/Abstract_data_type]
name::
* McsEngl.dataIt.ABSTRACT.NO (implemented)@cptIt,
* McsEngl.non-abstract-datatype@cptIt242i,
* McsEngl.data.implemented@cptIt,
name::
* McsEngl.dataIt.PRIMITIVE (unit)@cptIt,
* McsEngl.atom-datatype@cptIt,
* McsEngl.basic-type@cptIt248i,
* McsEngl.built-in-type@cptIt248i,
* McsEngl.data.primitive@cptIt,
* McsEngl.dgldat.atom@cptIt, {2014-02-01}
* McsEngl.dgldat.compositeNo@cptIt, {2014-02-01}
* McsEngl.dgldat.primitive@cptIt, {2014-02-01}
* McsEngl.dgldat.structureNo@cptIt, {2014-02-01}
* McsEngl.primitive-datatype@cptIt248i,
* McsEngl.primitive-type@cptIt248i,
* McsEngl.primitive-data-type-(java)@cptIt,
* McsEngl.value-type-(c#)@cptIt,
_GENERIC:
* data-language-programming
_DEFINITION:
In computer science, primitive types — as distinct from composite types — are data types provided by a programming language as basic building blocks. Primitive types are also known as built-in types or basic types.
Depending on the language and its implementation, primitive types may or may not have a one-to-one correspondence with objects in the computer's memory. However, one usually expects operations on primitive types to be the fastest language constructs there are. Integer addition, for example, can be performed as a single machine instruction, and some processors offer specific instructions to process sequences of characters with a single instruction. In particular, the C standard mentions that "a 'plain' int object has the natural size suggested by the architecture of the execution environment". This means that int is likely to be 32 bits long on a 32-bit architecture.
Most languages do not allow the behaviour or capabilities of primitive types to be modified by programs. Exceptions include Smalltalk, which permits primitive datatypes to be extended within a program, adding to the operations that can be performed on them or even redefining the built-in operations.
[http://en.wikipedia.org/wiki/Primitive_type]
_SPECIFIC:
* boolean#ql:data.boolean#
* number#ql:data.number#
* string#ql:data.string#
===
* null##
* undefined##
===
The actual range of primitive types that is available is dependent upon the specific programming language that is being used. For example, in C, strings, are a composite data type, whereas in modern dialects of Basic and in JavaScript, they are a primitive data type.
Typical primitive types may include:
* Character (character, char);
* Integer (integer, int, short, long, byte) with a variety of precisions;
* Floating-point number (float, double, real, double precision);
* Fixed-point number (fixed) with a variety of precisions and a programmer-selected scale.
* Boolean having the values true and false.
* Reference (also called a pointer or handle), a small value referring to another object's address in memory, possibly a much larger one.
More sophisticated types which can be primitive include:
* Tuples in ML, Python
* Linked lists in Lisp
* Complex numbers in Fortran, C (C99), Lisp, Python
* Rational numbers in Lisp
* Hash tables in various guises, in Lisp, Python, Lua
* First class functions, closures, continuations in Functional programming languages such as Lisp and ML
[http://en.wikipedia.org/wiki/Primitive_type]
name::
* McsEngl.dataIt.atom.BOOLEAN@cptIt,
* McsEngl.boolean-datatype@cptIt248i,
* McsEngl.data.boolean@cptIt,
* McsEngl.logical-datatype@cptIt,
* McsEngl.bln@cptIt,
_GENERIC:
* data-primitive#ql:data.primitive#
name::
* McsEngl.dataIt.atom.NUMBER@cptIt,
* McsEngl.number-datatype@cptIt,
* McsEngl.dglnbr@cptIt, {2013-12-24}
* McsEngl.nbr-datatype@cptIt,
_GENERIC:
* data-primitive#ql:dgldat.primitive#
_SPECIFIC:
# Integer (integer, int, short, long, byte) with a variety of precisions;
# Floating-point number (float, double, real, double precision);
# Fixed-point number (fixed) with a variety of precisions and a programmer-selected scale
name::
* McsEngl.dataIt.number.INTEGER@cptIt,
* McsEngl.integer-datatype@cptIt248i,
* McsEngl.int-datatype@cptIt248i,
* McsEngl.short-datatype@cptIt248i,
* McsEngl.long-datatype@cptIt248i,
* McsEngl.byte-datatype@cptIt248i,
_GENERIC:
* data-primitive#ql:data.primitive#
_DESCRIPTION:
# Integer (integer, int, short, long, byte) with a variety of precisions (number of bits);
Integer Numbers:
*** decimal, radix-10: 74, 82, 1002,...
*** octal (base 8): 0113,
*** hexadecimal (base 16): 0x4b,
name::
* McsEngl.dataIt.number.FLOATING-POINT@cptIt,
* McsEngl.floating-point-datatype@cptIt248i,
* McsEngl.float-datatype@cptIt248i,
* McsEngl.double-datatype@cptIt248i,
* McsEngl.real-datatype@cptIt248i,
* McsEngl.double-precision-datatype@cptIt248i,
_GENERIC:
* data-primitive#ql:data.primitive#
_DESCRIPTION:
# Floating-point number (float, double, real, double precision);
Floating-Point Numbers:
3.14159 // 3.14159
6.02e23 // 6.02 x 10^23
1.6e-19 // 1.6 x 10^-19
3.0 // 3.0
name::
* McsEngl.dataIt.number.FIXED-POINT@cptIt,
* McsEngl.fixed-point-datatype@cptIt248i,
* McsEngl.fixed-datatype@cptIt248i,
_GENERIC:
* data-primitive#ql:data.primitive#
# Fixed-point number (fixed) with a variety of precisions and a programmer-selected scale
name::
* McsEngl.dataIt.PRIMITIVE.NO (unitNo)@cptIt,
* McsEngl.construction-of-units@cptIt, {2015-10-24}
* McsEngl.compound-datatype@cptIt248i,
* McsEngl.composite-datatype@cptIt248i,
* McsEngl.data.composite@cptIt,
* McsEngl.data.compound@cptIt,
* McsEngl.datastructure@cptIt,
* McsEngl.data-structure@cptIt, {2014-02-01}
* McsEngl.dgldat.atomNo@cptIt, {2014-02-01}
* McsEngl.dgldat.composite@cptIt, {2014-02-01}
* McsEngl.dgldat.primitiveNo@cptIt, {2014-02-01}
* McsEngl.dgldat.structure@cptIt, {2014-02-01}
* McsEngl.non-primitive-datatype@cptIt,
_DEFINITION:
In computer science, composite types are datatypes which can be constructed in a programming language out of that language's primitive types and other composite types. The act of constructing a composite type is known as composition.
[http://en.wikipedia.org/wiki/Composite_type]
_SPECIFIC:
* collection##
* tree##
_CREATED: {2013-12-20} {2008-01-06}
name::
* McsEngl.datastructure@cptCore552i,
* McsEngl.data-model@cptCore478.2, {2012-04-26}
* McsEngl.data-structure@cptCore552i,
* McsEngl.datastructure@cptIt242i,
_DESCRIPTION:
* Type is generic-data with specific only one "kind" of data, eg numbers, dates, strings, etc.
[hmnSngo.2011-12-13]
===
* DATA TYPE is the 'ABSTRACT' data a language supports.
LITTERAL is the 'CONCRETE' data a language supports.
[nikkas 1999oct29]
_DEFINITION:
In computer science, a data structure is a way of storing data in a computer so that it can be used efficiently. Often a carefully chosen data structure will allow the most efficient algorithm to be used. The choice of the data structure often begins from the choice of an abstract data type. A well-designed data structure allows a variety of critical operations to be performed, using as few resources, both execution time and memory space, as possible. Data structures are implemented using the data types, references and operations on them provided by a programming language.
[http://en.wikipedia.org/wiki/Data_structure]
IMPLEMENTATION:
* DATA_TYPE#ql:data'type'of'computer'language-*##cptIt248i#
FUNDAMENTAL:
The fundamental building blocks of most data structures are
- arrays,
- records,
- discriminated unions, and
- references.
[http://en.wikipedia.org/wiki/Data_structure]
References (like the address of of house) are NOT data_structures.
[hmnSngo.2008-01-06_KasNik]
_SPECIFIC_DIVISION.LINE:
* LINEAR_DATASTRUCTURE:
LIST (or vector or sequence)
ASSOCIATIVE_ARRAY (a.k.a. dictionary or map)
* NON_LINEAR_DATASTRUCTURE:
GRAPH
TREE
name::
* McsEngl.dataIt.atomNo.STRUCTURED.NO@cptIt,
* McsEngl.conceptIt242.1,
* McsEngl.collection-datatype@cptIt242i,
* McsEngl.data.list@cptIt242.1, {2011-12-18}
* McsEngl.list-data@cptIt, {2011-12-18}
* McsEngl.list-datatype@cptIt242i,
_DESCRIPTION:
Collection is a-construction-of-units without any structure in its members.
[hmnSngo.2015-10-24]
_SPECIFIC_DIVISION.duplicates:
* duplicate-collection,
* non-duplicate-collection,
_SPECIFIC_DIVISION.order:
* ordered-collection,
* non-ordered-collection,
_SPECIFIC_DIVISION.quantity_of_elements:
* single,
* pair,
* triple,
* quad | quadruplets |
_SPECIFIC_DIVISION.Expansion:
* expandable-collection,
* non-expandable-collection,
_SPECIFIC:
* array,
* duplicate-collection,
* duplicateNo-collection,
* expandable-collection,
* expandableNo-collection,
* FIFO,
* key-value--collection,
* LIFO,
* ordered-collection,
* orderedNo-collection,
* pair,
* quad,
* set,
* single,
* triple,
* vector,
name::
* McsEngl.dataIt.datastructure.SPECIFIC.DIVISION.Quantity-of-elements (pair; triple...)@cptIt,
single, double, triple, quadruple, quintuple, sextuple, septuple, octuple, ..., n-tuple,
[http://en.wikipedia.org/wiki/Tuple]
name::
* McsEngl.dataIt.datastructure.DEQUE@cptIt,
* McsEngl.data.deque@cptIt,
* McsEngl.datstr.DEQUE@cptIt,
* McsEngl.deque-DataStructure@cptCore552i,
_DESCRIPTION:
In computer science, a deque (short for double-ended queue) is an abstract data structure for which elements can be added to or removed from the front or back. This differs from a normal queue, where elements can only be added to one end and removed from the other. An input-restricted deque is one where deletion can be made from both ends, but input can only be made at one end. An output-restricted deque is one where input can be made at both ends, but output can be made from one end only. Both queues and stacks can be considered specializations of deques, and can be implemented using deques.
Deque is usually pronounced deck.
[http://en.wikipedia.org/wiki/Deque]
name::
* McsEngl.dataIt.datastructure.FIFO (queue)@cptIt,
* McsEngl.data.fifo@cptIt,
* McsEngl.data.queue@cptIt,
* McsEngl.datstr.QUEUE@cptIt,
* McsEngl.queue-DataStructure@cptCore552i,
* McsEngl.FIFO-datatype@cptIt242i,
* McsEngl.queue-datatype@cptIt242i,
_GENERIC:
* data-list#ql:data.list#
_DESCRIPTION:
A queue (pronounced /kju?/) is a particular kind of collection in which the entities in the collection are kept in order and the principal (or only) operations on the collection are the addition of entities to the rear terminal position and removal of entities from the front terminal position. This makes the queue a First-In-First-Out (FIFO) data structure. In a FIFO data structure, the first element added to the queue will be the first one to be removed. This is equivalent to the requirement that whenever an element is added, all elements that were added before have to be removed before the new element can be invoked. A queue is an example of a linear data structure.
[http://en.wikipedia.org/wiki/Queue_%28data_structure%29]
name::
* McsEngl.dataIt.datastructure.LIFO (stack)@cptIt,
* McsEngl.data.lifo@cptIt,
* McsEngl.data.stack@cptIt,
* McsEngl.datstr.STACK@cptIt,
* McsEngl.LIFO-datatype@cptIt242i,
* McsEngl.stack-DataStructure@cptCore552i,
* McsEngl.stack-datatype@cptIt242i,
_GENERIC:
* data-list#ql:data.list#
_DESCRIPTION:
In computer science, a stack is an abstract data type and data structure based on the principle of Last In First Out (LIFO). Stacks are used extensively at every level of a modern computer system. For example, a modern PC uses stacks at the architecture level, which are used in the basic design of an operating system for interrupt handling and operating system function calls. Among other uses, stacks are used to run a Java Virtual Machine, and the Java language itself has a class called "Stack", which can be used by the programmer. The stack is ubiquitous.
A stack-based computer system is one that stores temporary information primarily in stacks, rather than hardware CPU registers (a register-based computer system).
[http://en.wikipedia.org/wiki/Stack_%28data_structure%29]
_DEFINITION:
In computer science, a stack is an abstract data type and data structure based on the principle of Last In First Out (LIFO). Stacks are used extensively at every level of a modern computer system. For example, a modern PC uses stacks at the architecture level, which are used in the basic design of an operating system for interrupt handling and operating system function calls. Among other uses, stacks are used to run a Java Virtual Machine, and the Java language itself has a class called "Stack", which can be used by the programmer. The stack is ubiquitous.
A stack-based computer system is one that stores temporary information primarily in stacks, rather than hardware CPU registers (a register-based computer system).
[http://en.wikipedia.org/wiki/Stack_%28data_structure%29]
name::
* McsEngl.dataIt.datastructure.NAME-VALUE-PAIR@cptIt,
* McsEngl.conceptIt242.2,
* McsEngl.attribute-value-pair@cptIt, {2013-08-26}
* McsEngl.data.key-value@cptIt, {2012-01-29}
* McsEngl.data.map-collection@cptIt,
* McsEngl.data.name-value@cptIt, {2012-01-29}
* McsEngl.field-value-pair@cptIt, {2013-08-26}
* McsEngl.key-value-data-collection@cptIt242.2, {2011-08-31}
* McsEngl.name-value-data-collection@cptIt242.2, {2011-08-31}
* McsEngl.name-value-pair@cptIt, {2013-08-26}
* McsEngl.key-value-pair-datatype@cptIt242i,
* McsEngl.map-datatype@cptIt242i,
* McsEngl.property-value-datatype@cptIt242i, {2011-09-31}
* McsEngl.relation-entity-datatype@cptIt242i, {2011-09-31}
_Desctiption:
A name–value pair, key–value pair, field–value pair or attribute–value pair is a fundamental data representation in computing systems and applications. Designers often desire an open-ended data structure that allows for future extension without modifying existing code or data. In such situations, all or part of the data model may be expressed as a collection of tuples <attribute name, value>; each element is an attribute–value pair. Depending on the particular application and the implementation chosen by programmers, attribute names may or may not be unique.
Some of the applications where information is represented as attribute-value pairs are:
E-mail, in RFC 2822 headers
Query strings, in URLs
Optional elements in network protocols, such as IP, where they often appear as TLV (type-length-value) triples
Bibliographic information, as in BibTeX and Dublin Core metadata
Element attributes in SGML and XML
General metadata in RDF
Some kinds of database systems
OpenStreetMap map data
Some computer languages implement attribute-value pairs, or more frequently collections of attribute-value pairs, as standard language features. Most of these implement the general model of an associative array: an unordered list of unique attributes with associated values. As a result, they are not fully general; they cannot be used, for example, to implement electronic mail headers (which are ordered and non-unique).
[http://en.wikipedia.org/wiki/Attribute%E2%80%93value_pair] 2013-08-26,
===
* A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.
...
These are universal data structures. Virtually all modern programming languages support them in one form or another. It makes sense that a data format that is interchangable with programming languages also be based on these structures.
[http://www.json.org//]
_JSON:
{
"name": "xxx",
"quantity": 23,
}
java_array2:
int ar[][] =
{ {1, 0},
{0, 1},
{0, 0} };
name::
* McsEngl.dataIt.datastructure.Name-Value.Ordered@cptIt,
name::
* McsEngl.dataIt.datastructure.Name-Value.OrderedNo@cptIt,
* McsEngl.hashtable-java@cptIt,
* McsEngl.object-JSON@cptIt,
name::
* McsEngl.dataIt.Record@cptIt,
* McsEngl.record-datatype@cptIt242i,
name::
* McsEngl.dataIt.datastructure.OPTION@cptIt,
* McsEngl.data.option@cptIt242i,
_DESCRIPTION:
A list of predefined values for an attribute.
[hmnSngo.2011-12-26]
name::
* McsEngl.dataIt.datastructure.ORDERED@cptIt,
* McsEngl.ordered-collection-of-data@cptIt242i,
* McsEngl.tuple-dataStructure@cptIt242i,
_GENERIC:
* data-list#ql:data.list#
_DEFINITION:
* An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.
[http://www.json.org//]
===
In mathematics and computer science, a tuple is an ordered list of elements. In set theory, an (ordered) n-tuple is a sequence (or ordered list) of n elements, where n is a positive integer.
[http://en.wikipedia.org/wiki/Tuple]
java_array2:
int ar[][] =
{ {1, 0 , 0},
{0, 1, 0},
{0, 0, 1} };
name::
* McsEngl.dataIt.Array@cptIt,
* McsEngl.array-DataStructure@cptCore552i,
* McsEngl.array-datatype@cptIt242i,
* McsEngl.datstr.ARRAY@cptIt,
_DEFINITION:
In computer science an array is a data structure consisting of a group of elements that are accessed by indexing. In most programming languages each element has the same data type and the array occupies a continuous area of storage. Most programming languages have a built-in array data type.
[http://en.wikipedia.org/wiki/Array]
_DEFINITION:
Holds same-type data, in known LENGTH.
name::
* McsEngl.dataIt.Vector@cptIt,
* McsEngl.vector-datatype@cptIt242i,
name::
* McsEngl.dataIt.datastructure.SET@cptIt,
* McsEngl.set-datastructure@cptIt242i,
_DEFINITION:
Set is an ordered, non-duplicate collection.
[hmnSngo.2011-12-18]
name::
* McsEngl.dataIt.datastructure.TABLE@cptIt,
* McsEngl.data.table@cptIt,
* McsEngl.table-datastructure@cptIt,
name::
* McsEngl.dataIt.CONCEPT@cptIt,
* McsEngl.conceptIt242.3,
* McsEngl.digital-concept@cptIt242.3, {2013-12-24}
* McsEngl.dglcpt@cptIt242.3, {2013-12-24}
name::
* McsEngl.dataIt.Concurrent@cptIt,
_DESCRIPTION:
In computer science, a concurrent data structure is a particular way of storing and organizing data for access by multiple computing threads (or processes) on a computer.
[http://en.wikipedia.org/wiki/Concurrent_data_structure]
name::
* McsEngl.dataIt.DISCRIMINATED-UNION@cptIt,
* McsEngl.datstr.DISCRIMINATED-UNION@cptIt,
* McsEngl.discriminated-union-DataStructure@cptCore552i,
* McsEngl.variant-DataStructure@cptCore552i,
* McsEngl.variant-record-DataStructure@cptCore552i,
* McsEngl.disjoint-union-DataStructure@cptCore552i,
_DEFINITION:
In computer science, a tagged union, also called a variant, variant record, discriminated union, or disjoint union, is a data structure used to hold a value that could take on several different, but fixed types. Only one of the types can be in use at any one time, and a tag field explicitly indicates which one is in use. It can be thought of as a type which has several "cases," each of which should be handled correctly when that type is manipulated. Like ordinary unions, tagged unions can save storage by overlapping storage areas for each type, since only one is in use at a time.
Tagged unions are most important in functional languages such as ML and Haskell, where they are called datatypes (see algebraic data type) and the compiler is able to verify that all cases of a tagged union are always handled, avoiding many types of errors. They can, however, be constructed in nearly any language, and are much safer than untagged unions, often simply called unions, which are similar but do not explicitly keep track of which member of the union is currently in use.
[http://en.wikipedia.org/wiki/Tagged_union]
name::
* McsEngl.dataIt.GRAPH@cptIt,
* McsEngl.graph-datastructure@cptIt248i,
_DEFINITION:
In computer science, a graph is a kind of data structure, specifically an abstract data type (ADT), that consists of a set of nodes (also called vertices) and a set of edges that establish relationships (connections) between the nodes. The graph ADT follows directly from the graph concept from mathematics.
Informally, G=(V,E) consists of vertices, the elements of V, which are connected by edges, the elements of E. Formally, a graph, G, is defined as an ordered pair, G=(V,E), where V is a finite set and E is a set consisting of two element subsets of V.
[http://en.wikipedia.org/wiki/Graph_%28data_structure%29]
_SPECIFIC:
* Adjacency list
* Adjacency matrix
* Disjoint-set data structure
* Graph-structured stack
* Scene graph
* Frame
* Database
[http://en.wikipedia.org/wiki/List_of_data_structures]
name::
* McsEngl.dataIt.CHAIN@cptIt,
* McsEngl.chain-datastructure@cptIt,
_DESCRIPTION:
· chain is an ordered linear graph.
· a-Dchain is a crypto unmodified chain.
name::
* McsEngl.dataIt.INPUT@cptIt,
* McsEngl.conceptIt242.6,
* McsEngl.data-in@cptIt242.6, {2012-03-05}
* McsEngl.dataIn@cptIt242.6, {2012-03-05}
* McsElln.ΔΕΔΟΜΕΝΑ-ΕΙΣΟΔΟΥ@cptIt,
ΟΡΙΣΜΟΣ:
είναι δεδομένα που εισάγονται για επεξεργασία στον υπολογιστή κατά την εκτέλεση ενός προγράμματος.
[Παπακωνσταντίνου κα, Τεχνολογία Υπολογιστικών... Γ' Ε. Λυκείου, 1999 α' έκδοση, 275]
name::
* McsEngl.dataIt.LANGUAGE.COMPUTER@cptIt,
* McsEngl.dataIt.computer-language@cptIt,
_DESCRIPTION:
Data REPRESENTED by a computer-language#ql:lngcmr@cptIt204#.
[2014-02-08]
name::
* McsEngl.dataIt.LANGUAGE.PROGRAMING@cptIt,
* McsEngl.data.programing-language@cptIt,
* McsEngl.data-lngPrg@cptIt248i,
* McsEngl.data-pl@cptIt248.7,
* McsEngl.lngPrg'data@cptIt,
* McsEngl.pgmlng'code.DATA@cptIt,
* McsEngl.pgmlng'Data-code@cptIt,
* McsEngl.mdp'data@cptIt,
_GENERIC:
* data#cptItsoft242#
_DEFINITION:
DATA of a computer-language are the information-representing-entities that a program written with a computer-langaure process.
[hmnSngo.2002-04-23]
===
A computer-language creates internal constructs (we call them data-types) to hold the real-life's data in order to process them.
[hmnSngo.2002-04-30]
===
In computer science, a value is an interpretation of a sequence of bits according to some data type. It is possible for the same sequence of bits to have different values, depending on the type used to interpret its meaning. For instance, the value could be an integer or floating point value, or a string.
[http://en.wikipedia.org/wiki/Value_(computer_science)]
name::
* McsEngl.lcp'data'Constant@cptIt,
* McsEngl.constant-data-container@cptIt248i,
* McsEngl.constant-lngPrg@cptIt248i,
* McsEngl.constant-of-computer-language@cptIt248i,
* McsEngl.constant-pl@cptIt248,
* McsEngl.mdp'constant@cptIt,
_DEFINITION:
CONSTANT is a REGISTER (a memory position) that holds a simple-data-value.
[hmnSngo.2002-03-14]
CONSTAT is a NAME that always denotes a unique data.
[nikkas 1999oct30]
name::
* McsEngl.pgmlng'data.specific@cptIt,
* McsEngl.pl'datatype@cptIt,
* McsEngl.pl'data-type@cptIt,
name::
* McsEngl.lcp'data.TYPE@cptIt,
* McsEngl.pgmlng'data.generic@cptIt,
name::
* McsEngl.dataIt.Linear@cptIt,
* McsEngl.linear-datatype@cptIt248i,
* McsEngl.linear-data-structure@cptIt248i,
* McsEngl.line-datatype@cptIt248i,
* McsEngl.line-data-structure@cptIt248i,
_SPECIFIC:
Array
Deque
Linked_list
Queue
Stack
name::
* McsEngl.dataIt.LINKED-LIST@cptIt,
* McsEngl.datstr.linked-list@cptIt,
* McsEngl.linked-list-DataStructure@cptCore552i,
_DESCRIPTION:
In computer science, a linked list is one of the fundamental data structures, and can be used to implement other data structures. It consists of a sequence of nodes, each containing arbitrary data fields and one or two references ("links") pointing to the next and/or previous nodes. The principal benefit of a linked list over a conventional array is that the order of the linked items may be different from the order that the data items are stored in memory or on disk, allowing the list of items to be traversed in a different order. A linked list is a self-referential datatype because it contains a pointer or link to another datum of the same type. Linked lists permit insertion and removal of nodes at any point in the list in constant time,[1] but do not allow random access. Several different types of linked list exist: singly-linked lists, doubly-linked lists, and circularly-linked lists.
Linked lists can be implemented in most languages. Languages such as Lisp and Scheme have the data structure built in, along with operations to access the linked list. Procedural or object-oriented languages such as C, C++, and Java typically rely on mutable references to create linked lists.
[http://en.wikipedia.org/wiki/Linked_list]
name::
* McsEngl.dataIt.LinearNo@cptIt,
* McsEngl.non-linear-datatype@cptIt248i,
name::
* McsEngl.dataIt.OUTPUT@cptIt,
* McsEngl.conceptIt242.7,
* McsEngl.data-out@cptIt242.7, {2012-03-05}
* McsEngl.dataOut@cptIt242.7, {2012-03-05}
* McsElln.ΑΠΟΤΕΛΕΣΜΑΤΑ-ΕΞΟΔΟΥ@cptIt, [Παπακωνσταντίνου κα; Τεχνολογία Υπολογιστικών... Γ'Ε. Λυκείου, 1999 α'έκδοση, 274]
ΟΡΙΣΜΟΣ:
Είναι τα αποτελέσματα που παράγονται από έναν υπολογιστή, ως συνέπεια της εκτέλεσης ενός ή πολλαπλών προγραμμάτων.
[Παπακωνσταντίνου κα, Τεχνολογία Υπολογιστικών... Γ' Ε. Λυκείου, 1999 α' έκδοση, 274]
name::
* McsEngl.dataIt.sensor.AUDIO (ds)@cptIt,
* McsEngl.conceptIt550,
* McsEngl.dgldat.audio@cptIt,
* McsEngl.digital-audio-data@cptIt,
* McsEngl.digital-sound@cptIt550,
* McsEngl.digitised-sound@cptIt,
* McsEngl.digitised'sound@cptIt550,
* McsEngl.sampled-audio-signal@cptIt,
* McsEngl.sampled'audio@cptIt550,
The term "sampled audio" is used here slightly loosely. A sound wave could be sampled at discrete intervals while being left in an analog form. For purposes of the Java Sound API, however, "sampled audio" is equivalent to "digital audio."
Typically, sampled audio on a computer comes from a sound recording, but the sound could instead be synthetically generated (for example, to create the sounds of a touch-tone telephone). The term "sampled audio" refers to the type of data, not its origin.
[jdk 140]
The javax.sound.sampled package handles digital audio data, which the Java Sound API refers to as sampled audio. Samples are successive snapshots of a signal. In the case of audio, the signal is a sound wave. A microphone converts the acoustic signal into a corresponding analog electrical signal, and an analog-to-digital converter transforms that analog signal into a sampled digital form.
name::
* McsEngl.ds'BITRATE@cptIt,
* McsEngl.audio'stream@cptIt550i,
* McsEngl.bitstream@cptIt550i,
_DEFINITION:
The sampling frequency is basically the number of times per second audio is sampled and stored as a number - CD audio is sampled at 44.1 KHz, which means 44,100 samples per second. CD audio uses 16 bit samples, so the bitrate of uncompressed CD audio = 44,100 x 16 bits per second (well x 2 actually, because it's stereo).
The "bitrate" on the other hand, when talking about MP3 files, refers to the transfer bitrate for which the files are encoded - i.e. an MP3 file encoded "at a bitrate of 128 Kbps" is compressed such that it could be streamed continuously through a link providing a transfer rate of 128 thousand bits per second. But most of us don't really use MP3 as a streaming medium (except for shoutcast, etc.) so really what the MP3 "bitrate" is a measure of is how severely the files is being compressed - the lower the bitrate, the more the file has been compressed... and the more you compress a file, the more of the original data is lost, and so the worse the playback sound quality will be. It's almost exactly analogous to compressing a JPG image with a higher compression ratio - you get a smaller file, but when you view it, it doesn't look as good.
What bitrate for MP3 files will give "CD quality"?
Aw heck... this is another of those questions that people debate *endlessly*. There really is no one answer - it depends on your ears, your equipment, etc. I think it's probably fair to say that 128 Kbps is a bit on the low side, although it may sound fine from some encoders for some songs under some circumstances, whilst 160 Kbps done by a good encoder should sound pretty good to most people under most circumstances.... *but* I know some people will insist on higher standards. Different encoding software really does make a difference - some encoding software produces results that sound pretty awful to me at 128 Kbps, whereas other software produces ok results... e.g. speaking strictly from my own experience, 128 Kbps files from the older versions of Musicmatch Jukebox which used the Xing encoder or from Audiocatalyst often sound *really* poor, whereas BladeEnc (which is free) produces files at 128 Kbps which are often quite acceptable. The LAME encoder, an open source project, is another good free alternative, probably slightly superior to BladeEnc. And the free download of Musicmatch Jukebox now lets you encode at all bitrates using a version of the Fraunhofer encoder. I mostly rip to WAV files, and then encode using either the LAME or Fraunhofer encoder at 160 Kbps at the moment. If I'm not happy listening to the results on earphones, then I'll try 192 Kbps...
OTOH kbps is actually a measure of data transfer rate - it means kilo bits per second, i.e. the number of thousands of bits transferred per second. When applied to MP3 files it refers to the rate at which the file would have to transferred for the audio data to be transferred in real time (i.e. for 1 seconds worth of audio to be transferred in 1 second of elapsed time). Essentially this means it is a measure of how much the audio data has been compressed in creating the MP3 files. Uncompressed CD audio data requires a transfer rate of 1,411.2 kpbs (16 x 2 x 44,100), so MP3 data encoded for 128 kbps is compressed by a factor of 11.025.
name::
* McsEngl.ds'CAPTURE@cptIt,
* McsEngl.recording@cptIt,
name::
* McsEngl.ds'FORMAT@cptIt,
* McsEngl.audio'encoding@cptIt550i,
* McsEngl.audio-type@cptIt,
* McsEngl.coding'scheme@cptIt550i,
* McsEngl.compression'audio'format@cptIt550i,
* McsEngl.digital-audio-format@cptIt550i,
ds'FRAME:
A frame contains the data for all channels at a particular time. For PCM-encoded data, the frame is simply the set of simultaneous samples in all channels, for a given instant in time, without any additional information. In this case, the frame rate is equal to the sample rate, and the frame size in bytes is the number of channels multiplied by the sample size in bits, divided by the number of bits in a byte.
For other kinds of encodings, a frame might contain additional information besides the samples, and the frame rate might be completely different from the sample rate. For example, consider the MP3 (MPEG-1 Audio Layer 3) encoding, which is not explicitly mentioned in the current version of the Java Sound API, but which could be supported by an implementation of the Java Sound API or by a third-party service provider. In MP3, each frame contains a bundle of compressed data for a series of samples, not just one sample per channel. Because each frame encapsulates a whole series of samples, the frame rate is slower than the sample rate. The frame also contains a header. Despite the header, the frame size in bytes is less than the size in bytes of the equivalent number of PCM frames. (After all, the purpose of MP3 is to be more compact than PCM data.) For such an encoding, the sample rate and sample size refer to the PCM data that the encoded sound will eventually be converted into before being delivered to a digital-to-analog converter (DAC).
[jdk 140]
name::
* McsEngl.ds'format.SPEECH@cptIt,
* McsEngl.speech'coding@cptIt550,
DEFINETRO:
Speech coding is the compression of speech (into a code) for transmission with speech codecs that use audio signal processing and speech processing techniques.
The two most important applications using speech coding are mobile phones and internet phones.
The techniques used in speech coding are similar to that in audio data compression and audio coding where knowledge in psychoacoustics is used to transmit only data that is relevant to the human auditory system. For example, in narrowband speech coding, only information in the frequency band 400 Hz to 3500 Hz is transmitted but the reconstructed signal is still adequate for intelligibility.
However, speech coding differs from audio coding in that there is a lot more statistical information available about the properties of speech. In addition, some auditory information which is relevant in audio coding can be unnecessary in the speech coding context. In speech coding, the most important criterion is preservation of intelligibility and "pleasantness" of speech, with a constrained amount of transmitted data.
[http://en.wikipedia.org/wiki/Speech_coding]
_SPESIFEPTO:
* A-law
* Mu-law
* LPC:
* CELP#ql:celp-*#:
* RELP#ql:relp-*#:
* In speech analysis and in speech synthesis, Linear Predictive Coding (LPC) is one of the most powerful techniques and one of the most useful methods for voice coder (vocoder) systems.
The A-law algorithm and the Mu-law algorithm are used in nearly all land-line long distance telephone communications. They can be seen as a kind of speech encoding, requiring only 8 bits per sample but giving effectively 12 bits of resolution.
The most common speech coding scheme is Code-Excited Linear Predictive (CELP) coding, which is used for example in the GSM standard.
isrc.speech.CODING:
* http://library2.usask.ca/theses/available/etd-12202003-142739/unrestricted/0105Thesis.pdf:
name::
* McsEngl.ds'format.LINEAR'ENCONDING@cptIt,
* McsEngl.LINEAR'ENCONDING@cptIt550i,
PCM is one kind of encoding of the sound waveform. The Java Sound API includes two PCM encodings that use linear quantization of amplitude, and signed or unsigned integer values. Linear quantization means that the number stored in each sample is directly proportional (except for any distortion) to the original sound pressure at that instant—and similarly proportional to the displacement of a loudspeaker or eardrum that is vibrating with the sound at that instant. Compact discs, for example, use linear PCM-encoded sound.
[jdk 140]
name::
* McsEngl.ds'format.NON'LINEAR'ENCODING@cptIt,
* McsEngl.NON'LINEAR'ENCODING@cptIt550i,
Mu-law#ql:ds'mlaw'coding# encoding and a-law encoding are common nonlinear encodings that provide a more compressed version of the audio data; these encodings are typically used for telephony or recordings of speech. A nonlinear encoding maps the original sound's amplitude to the stored value using a nonlinear function, which can be designed to give more amplitude resolution to quiet sounds than to loud sounds.
[jdk 140]
name::
* McsEngl.ds'format.ALAW'CODING@cptIt,
* McsEngl.A'LAW'CODING@cptIt550i,
_DEFINITION:
It is used in EUROPE. It does quantization with 13 bits and then compress them to 8 bit logarithmically.
name::
* McsEngl.ds'format.CELP@cptIt,
* McsEngl.CELP@cptIt550i,
DEFINETRO:
* CELP stands for Code Excited Linear Prediction and is a speech coding algorithm originally proposed by M.R. Schroeder and B.S. Atal in 1985. At the time, it provided significantly better quality than existing low bit-rate algorithms, such as RELP and LPC vocoders (e.g. FS-1015). Along with its variants, such as ACELP, RCELP, LD-CELP and VSELP, it is currently the most widely used speech coding algorithm. CELP is now used as a generic term for a class of algorithms and not for a particular codec.
[http://en.wikipedia.org/wiki/CELP]
* Various attempts have been made to encode the residue signal in an efficient way, providing better quality speech than LPC-10e without increasing the bit rate too much. The most successful methods use a codebook, a table of typical residue signals, which is set up by the system designers. In operation, the analyzer compares the residue to all the entries in the codebook, chooses the entry which is the closest match, and just sends the code for that entry. The synthesizer receives this code, retrieves the corresponding residue from the codebook, and uses that to excite the formant filter. Schemes of this kind are called Code Excited Linear Prediction (CELP).
* The CELP family of coders compensates for the lack of quality of the simple LPC model by using more information in the excitation. Each of a set of codebook of excitation vectors is tried and the index of the one that best matches the original speech is transmitted. This results in an increase in the bit rate to typically 4800-9600bps. Most speech coding research is currently directed towards CELP coders. (See, for example, CELP 3.2a, a TMS implementation, a G.728 LD-CELP vocoder, and the L&H implementation.
name::
* McsEngl.ds'format.LPC@cptIt,
* McsEngl.LPC@cptIt550i,
* McsEngl.Linear'Predictive'Coding@cptIt550i,
_DEFINITION:
Linear Predictive Coding (LPC) is one of the most powerful speech analysis techniques, and one of the most useful methods for encoding good quality speech at a low bit rate. It provides extremely accurate estimates of speech parameters, and is relatively efficient for computation.
Linear Predictive Coding (LPC) is a frequency domain coder. Speech is broken up to short frames, where it is assumed that the speech signal is stationary. Then the LPC model is applied and a set of parameters (usually somewhere between 8 and 14) is derived, the LP coefficients. The Speech synthesizer uses the LP coefficients along with extra parameters such as excitation, voicing etc., to predict a series of samples whose frequency distribution approximates the one of the original frame.
[George_Gagaudakis]
LPC analyzes the speech signal by estimating the formants, removing their effects from the speech signal, and estimating the intensity and frequency of the remaining buzz. The process of removing the formants#ql:lpc'formant# is called inverse filtering, and the remaining signal is called the residue.
The numbers which describe the formants and the residue can be stored or transmitted somewhere else. LPC synthesizes the speech signal by reversing the process: use the residue to create a source signal, use the formants to create a filter (which represents the tube), and run the source through the filter, resulting in speech.
Because speech signals vary with time, this process is done on short chunks of the speech signal, which are called frames. Usually 30 to 50 frames per second give intelligible speech with good compression.
[Otolith]
- Speech is generated by the human vocal tract.
- We can model speech as a source (voicing or fricative excitation) passing through a filter - the human vocal tract.
- LPC decides
* what coefficients the filter needs,
* What sort of excitation is needed
* What the energy of excitation should be
* What pitch is required if the excitation is voiced.
- Typically encodes speech at 1200-2400 bps, although it does sound robotic
LPC analysis, which originally was used for statistical analysis, proved useful in computer music because of its ability to extract and store time-varying formant information. Time varying means that the information changes over time, like the amplitude of a waveform does. Formants are points in a sound's spectrum where frequencies are boosted. In the real world this is often due to natural resonance in the object that is vibrating. The difference in the sounds of spoken vowels such as 'a' and 'e' are due to differences in the formant peaks caused by the difference in the shape of your mouth when you produce the sounds. The data generated by an LPC analysis of a sound consists primarily of filter coefficients which, if used to control a specific type of filter, will alter an input sound's spectrum to match the formant peaks of the original sound. If this input sound is a raw pulse waveform (which contains all harmonics at equal amplitudes), the resultant filtered sound timbre will be very close to the original. This is the basic procedure for the LPC Resynthesis command. Typically, the original sound to be analyzed is a vocal sound, which can then be resynthesized with various parameters (such as pitch or duration) changed. The Formant Filter command allows for the filtering of any arbitrary input sound, which "maps" the formant peaks onto that sound.
An additional 'warping' parameter is also available, with values between -1 and 1, with 0 being no warping. This factor has the effect of shifting the formant peaks down or up in frequency, thereby radically altering the timbre. The best values are in the range +-.01 to +-.5.
In the LPC analysis command, the number of poles specifies the accuracy of the analysis: the greater the number of poles, the more precisely the format regions will be captured. Typical values range from about 24 for 22khz sounds up to 64 for 44khz and 48khz sounds.
lpc'FORMANT:
LPC starts with the assumption that the speech signal is produced by a buzzer at the end of a tube. The glottis (the space between the vocal cords) produces the buzz, which is characterized by its intensity (loudness) and frequency (pitch). The vocal tract (the throat and mouth) forms the tube, which is characterized by its resonances, which are called formants.
[Otolith]
In other words the air passes from the lungs into the vocal tract, which is a series of cavities acting as resonators, emphasizing some frequencies and attenuating others. These resonances are called formants.
The formants are the main "timbrical print", which allows us to distinguish between a male, a female and a child voice as well as between different voices of the same sex and age.
Pitch/Speed Shifting:
Another aspect of LPC is its ability to alter the pitch or speed of a sound independently from another. If a entire sample of a voice is transposed up or down to either change the pitch or the speed, the voice begans to sound like Mickey Mouse. This effect, known as munchkinization, occurs because certain characteristics of voice, instruments, etc. known as formants, must remain in place for the sound to retain its identity. LPC corrects this problem by maintaining the correct amplitudes over their associated frequencies, which holds the formants in their correct positions. Sounds can be speed up, slowed down, and even have the pitched raised/lowered with the sound remaining completely natural.
Estimating the Formants:
The basic problem of the LPC system is to determine the formants from the speech signal. The basic solution is a difference equation, which expresses each sample of the signal as a linear combination of previous samples. Such an equation is called a linear predictor, which is why this is called Linear Predictive Coding. The coefficients of the difference-equation (the prediction coefficients) characterize the formants, so the LPC system needs to estimate these coefficients. The estimate is done by minimizing the mean-square error between the predicted signal and the actual signal.
This is a straightforward problem, in principle. In practice, it involves
(1) the computation of a matrix of coefficient values, and
(2) the solution of a set of linear equations.
Several methods (autocorrelation, covariance, recursive lattice formulation) may be used to assure convergence to a unique solution with efficient computation.
lpc'INVERSE-FILTERING:
LPC analyzes the speech signal by estimating the formants, removing their effects from the speech signal, and estimating the intensity and frequency of the remaining buzz.
The process of removing the formants#ql:lpc'formant# is called inverse-filtering, and the remaining signal is called the residue.
[Otolith]
lpc'RESIDUE:
LPC analyzes the speech-signal by estimating the formants, removing their effects from the speech signal, and estimating the intensity and frequency of the remaining buzz. The process of removing the formants#ql:lpc'formant# is called inverse-filtering, and the remaining signal is called the residue.
[Otolith]
lpc'SYNTHESIS:
The most exciting ability of LPC is that of Cross-Synthesis. When a sound is analyzed using LPC other things must be measured to recreate the actual sound. One of these is pitch. If a voice is re-synthesized using its LPC analysis without the pitch information, the voice will sound very robotic. That in itself would be a great tool...but, there's more! A specific excitation-sound is needed to recreate the original sound using LPC. However, by replacing the excitation sound with another sound you can create a completely new sound. One classic example is cross-synthesizing an orchestra with a person's voice.
name::
* McsEngl.ds'format.MLAW'CODING (μ-Law |u-law | mu-law)@cptIt,
* McsEngl.M'LAW'CODING@cptIt550i,
_DEFINITION:
It is used in US and JAPAN. It does quantization with 14 bits and then compress them to 8 bit logarithmically.
name::
* McsEngl.ds'format.MP3@cptIt,
* McsEngl.MP3@cptIt550i,
* McsEngl.MPEG@cptIt1-Audio-Layer-3,
MP3 is short for MPeg3, or more fully MPeg - Level 3. MP3, an industry standard developed in 1992 by the German Frauenhofer Research Institute, achieves a spectacular compression ratio of a sampled audio wave, ranging from a factor of eight to a factor of 12, depending on the source. This means that the 10MB of storage capacity needed to encode one minute of hi-fi music on a compact disc is reduced to a 1 MB MP3 file on a computer hard drive.
MP3 divides the frequency range into 32 bands, each of which the human ear hears separately. The component of the input signal (sampled wave) in each of those ranges is then subjected to a Fourier-like mathematical transformation that separates it into a further 18 constituents, generating a total of 576 individual frequency bands. Within each of those bands, components undetectable to the human ear are removed.
The resulting signal is then compressed further by Huffmann coding, a technique familiar to computer scientists, which represents frequently occurring values by shorter codes than used for less frequently occurring values. (For instance, it would be highly wasteful to use the default 141,120 bits of the sampled wave to encode a 1/10 second silence in a song.) The result of all this maths?
Free music at the stroke of a few keys on the keyboard for any teenager with a computer. (Discounting the internet connection charges their parents pay at the end of the month.) With consumer electronics stores offering new MP3 players every few months, and with millions of PC owners swapping music files illegally (as well as occasionally downloading them legitimately), the modern music industry is built on mathematics as much as anything else. What Joseph Fourier would have made of today's applications of his original mathematical analysis of heat waves is anybody's guess.
For other kinds of encodings, a frame might contain additional information besides the samples, and the frame rate might be completely different from the sample rate. For example, consider the MP3 (MPEG-1 Audio Layer 3) encoding, which is not explicitly mentioned in the current version of the Java Sound API, but which could be supported by an implementation of the Java Sound API or by a third-party service provider. In MP3, each frame contains a bundle of compressed data for a series of samples, not just one sample per channel. Because each frame encapsulates a whole series of samples, the frame rate is slower than the sample rate. The frame also contains a header. Despite the header, the frame size in bytes is less than the size in bytes of the equivalent number of PCM frames. (After all, the purpose of MP3 is to be more compact than PCM data.) For such an encoding, the sample rate and sample size refer to the PCM data that the encoded sound will eventually be converted into before being delivered to a digital-to-analog converter (DAC).
mp3'layer:
Q: O.K., let us concentrate on one or two audio channels. Which Layer shall I use for my application? A: Good Question. Of course, it depends on all your requirements. But as a first approach, you should consider the available bitrate of your application as the Layers have been designed to support certain areas of bitrates most effectively. Roughly, today you can achieve a data reduction of around
** 1:4 with Layer-1 (or 192 kbps per audio channel),
** 1:6..8 with Layer-2 (or 128..96 kbps per audio channel), and
** 1:10..12 with Layer-3, (or 64..56 kbps per audio channel),
and still the reconstructed audio signal will maintain a "CD-like" sound quality. This may be used as a first "thumb rule" - let's talk about details later on.
name::
* McsEngl.ds'format.PAC@cptIt,
Current state-of-the-art coding algorithms, such as the Perceptual Audio Coder or PAC developed at AT&T Bell Labs, are capable of coding 2 channels of digital audio at a total bit rate of 128 kbps with essentially no loss in quality from that of the original CD coding
name::
* McsEngl.ds'format.PCM'CODING@cptIt,
* McsEngl.PCM@cptIt550i,
_DEFINITION:
64 kbits/s PCM Codecs:
Pulse Code Modulation (PCM) codecs are the simplest form of waveform codecs. Narrowband speech is typically sampled 8000 times per second, and then each speech sample must be quantized. If linear quantization is used then about 12 bits per sample are needed, giving a bit rate of about 96 kbits/s. However this can be easily reduced by using non-linear quantization. For coding speech it was found that with non-linear quantization 8 bits per sample was sufficient for speech quality which is almost indistinguishable from the original. This gives a bit rate of 64 kbits/s, and two such non-linear PCM codecs were standardised in the 1960s. In America u-law coding is the standard, while in Europe the slightly different A-law compression is used. Because of their simplicity, excellent quality and low delay both these codecs are still widely used today. For example the .au audio files that are often used to convey sounds over the Web are in fact just PCM files. For information on how to listen to au and other sound format files under various operating systems see here. Code to implement the G711 A-law and u-law codes has been released into the public domain by Sun Microsystems Inc, and modified by Borge Lindberg. To FTP this code click here. For more information about PCM, and other waveform codecs, a good place to look is the book "Digital Coding of Waveforms" by N.S Jayant and Peter Noll. It was published by Prentice Hall in 1984, and although its too expensive really to be worth buying, you might find a copy in your library.
name::
* McsEngl.ds'format.RELP@cptIt,
* McsEngl.relp@cptIt550i,
DEFINETRO:
* RELP stands for Residual Excited Linear Prediction and is an old (no longer used) speech coding algorithm.
[http://en.wikipedia.org/wiki/RELP]
* The Residual Excited Linear Predictive (RELP) vocoder is one of the LPC-based vocoders. Although the compression rate is moderate, because a sequence of residual signals is needed to excite speech signals, the quality of the synthesized speech is far better than the basic LPC, CELP and MELP vocoders. The system is robust [26], since there is no need to analyze whether the sound is voiced or unvoiced nor to analyze the pitch period
[http://library2.usask.ca/theses/available/etd-12202003-142739/unrestricted/0105Thesis.pdf]
_CREATION:
* The Residual-Excited Linear Predictive (RELP) vocoder, which is the focus of this research, was proposed by Un et al. in 1974 [8].
[http://library2.usask.ca/theses/available/etd-12202003-142739/unrestricted/0105Thesis.pdf]
BIT RATE:
The RELP vocoder, which Un et al. proposed, encodes speech between 6 and 9.6 kbps [26], depending on the quality of the synthesized speech desired.
[http://library2.usask.ca/theses/available/etd-12202003-142739/unrestricted/0105Thesis.pdf]
RESIDUAL:
Linear prediction error (residual) signals are used for the excitation. There
is no voiced/unvoiced detection or pitch detection required.
[http://library2.usask.ca/theses/available/etd-12202003-142739/unrestricted/0105Thesis.pdf]
name::
* McsEngl.ds'format'CODEC@cptIt,
* McsEngl.audio'codec@cptIt550i,
* McsEngl.audio'encoding@cptIt550i,
name::
* McsEngl.ds'encoder@cptIt,
the encoder needs much more computation power than the decoder.
name::
* McsEngl.ds'RESOLUTION'IN'AMPLITUDE (sample-size)@cptIt,
* McsEngl.ds'bit'depth@cptIt550i,
* McsEngl.ds'quantization@cptIt550i,
* McsEngl.quantization@cptIt550i,
* McsElln.ΑΝΑΛΥΣΗ@cptIt,
* McsEngl.sample'size@cptIt550i,
* McsElln.ΜΕΓΕΘΟΣ-ΔΕΙΓΜΑΤΟΛΕΙΨΙΑΣ@cptIt,
_DEFINITION:
quantization, or resolution in amplitude (the number of bits used to represent each sample).
[jdk 140]
The sample size indicates how many bits are used to store each snapshot; 8 and 16 are typical values.
This describes the number of bits to use for each sample on each channel. Choosing 8-bit resolution will provide 256 unique "volumes". The PC-Speaker, for example, provides only 4-bits of resolution because it can support 16 unique volume levels. Choosing a 16-bit resolution will provide 65,536 unique "volumes", for a 96 dB signal-to-noise ratio. Much quieter sounds can be reproduced at 16-bit resolution than at 8-bit resolution, which only has a 48 dB signal-to-noise ratio. Compact disk players have a 16-bit resolution.
[CoolEdit 96]
ΑΝΑΛΥΣΗ:
Μετριέται από τον ΑΡΙΘΜΟ των διαφορετικών τιμών voltage που μπορεί να ορίσει μία συσκευή.
8, 12, 16 BIT. Με 8 μπιτ έχουμε 256 διαφορετικους τυπους αναπαράστασης καθε δείγματος, πράγμα που σημαινει φτωχή στρογγυλοποίηση. Χρησιμοποιείται κυρίως στά τηλέφωνα.
ΜΕ 16BIT ΕΧΟΥΜΕ 65.536 ΔΥΝΑΤΕΣ ΤΙΜΕΣ, ΓΙΑ ΝΑ ΑΝΤΙΣΤΟΙΧΙΣΟΥΜΕ ΤΟ ΕΥΡΟΣ ΔΙΑΚΥΜΑΝΣΗΣ ΤΗΣ ΗΛΕΚΤΡΙΚΗΣ ΤΑΣΗΣ. ΕΤΣΙ Η ΑΝΑΠΑΡΑΣΤΑΣΗ ΕΙΝΑΙ ΤΕΛΕΙΑ.
name::
* McsEngl.ds'RESOLUTION'IN'TIME (sample-rate)@cptIt,
* McsEngl.sampling'frequency@cptIt,
* McsEngl.sample'rate@cptIt550i,
* McsEngl.sampling'rate@cptIt550i,
* McsElln.ΣΥΧΝΟΤΗΤΑ-ΔΕΙΓΜΑΤΟΛΕΙΨΙΑΣ@cptIt,
_DEFINITION:
The sample rate describes how many times per second to take a snapshot of the audio. The human ear can perceive sounds up to about 17,000 cycles per second, or 17 Khz. When choosing a sample rate, frequencies of up to 1/2 the sample rate can be produced effectively. To reproduce frequencies up to 10Khz, a sample rate of at least 20Khz must be chosen. You may enterany sample rate directly, or choose a common sample rate from the list.
8,000 Hz Telephone Quality
11,025 Hz Poor AM Radio Quality
16,000 Hz Reasonable compromise between 11 KHz and 22 KHz
22,050 Hz Near FM Radio Quality
32,075 Hz Better than FM Radio Quality (Some boards support 32,000 instead)
44,100 Hz CD Quality
48,000 Hz DAT Quality
[CoolEdit 96]
In a digitised sound system, the sound wave is measeured -sampled- at between 5,000 and 44,000 times a second - the sampling rate. The result is stored as a digital number in a file on disk. The more samples per second, the more accurate the sound, but the larger the resulting file; CD-quality sound is sampled at 44,100 times per second- one second of sound takes up a 44K file.
ΣΥΧΝΟΤΗΤΕΣ: 11.025, 22.05, 44.1 ΚΗz. Πόσα δείγματα συχνοτήτων παίρνουμε το δευτερόλεπτο.
ΟΣΟ ΠΙΟ ΜΕΓΑΛΗ ΕΙΝΑΙ Η ΣΥΧΝΟΤΗΤΑ, ΤΟΣΟ ΠΙΟ ΠΟΛΕΣ ΤΙΜΕΣ ΕΧΟΥΜΕ ΣΤΟ ΔΕΥΤΕΡΟΛΕΠΤΟ ΓΙΑ ΤΟΝ ΑΝΑΛΟΓΙΚΟ ΗΧΟ, ΑΡΑ ΤΟΣΟ ΠΙΟ ΠΙΣΤΟΣ ΕΙΝΑΙ Ο ΨΗΦΙΑΚΟΣ ΣΤΟΝ ΑΝΑΛΟΓΙΚΟ.
ΠΡΑΚΤΙΚΑ, Η ΣΥΧΝΟΤΗΤΑ ΔΕΙΓΜΑΤΟΛΕΙΨΙΑΣ ΠΡΕΠΕΙ ΝΑ ΕΙΝΑΙ ΔΙΠΛΑΣΙΑ ΑΠΟ ΤΗ ΜΕΓΙΣΤΗ ΣΥΧΝΟΤΗΤΑ ΤΟΥ ΑΝΑΛΟΓΙΚΟΥ ΗΧΟΥ.
NYQUIST'THEOREM:
The sampling rate must be greater than twice the frequency measured for accurate results. (The mathematical statement of this is the Nyquist Theorem.)
The Nyquist rate (twice the frequency of interest) is the lowest allowable sampling rate. For best results, sampling rates twice or four times this should be used.
name::
* McsEngl.ds'SAMPLE@cptIt,
_DEFINITION:
sample is ONE snapshot of a sound wave. It has a value, a number that represents a voltage that represents an AMPLITUDE in the sound wave.
name::
* McsEngl.ds'STORAGE@cptIt,
CD-QUALITY:
44100 sample X 16x2 bit (4 Bytes) = 170.000 Bytes per second.
x 60 seconds
= 10.000.000 Bytes per minite.
name::
* McsEngl.ds'ENVIRONMENT@cptIt,
The Benefits of Being Digital:
You may be wondering about the point of all of this, if it turns out that a digital system is more complex than the equivalent analog circuit. Digital circuits are complex, but very few of the components must be precise; most of the circuitry merely responds to the presence or absence of current. Improving performance is usually only a matter of increasing the word size or the sample rate, which is achieved by duplicating elements of the circuit. It is possible to build analog circuits that match digital performance levels, but they are very expensive and require constant maintenance. The bottom line is that good digital systems are cheaper than good analog systems.
Digital devices usually require less maintenance than analog equipment. The electrical characteristics of most circuit elements change with time and temperature, and minor changes slowly degrade the performance of analog circuits. Digital components either work or don't, and it is much easier to find a chip that has failed entirely than one that is merely 10% off spec. Many analog systems are mechanical in nature, and simple wear can soon cause problems. Digital systems have few moving parts, and such parts are usually designed so that a little vibration or speed variation is not important.
In addition, digitally encoded information is more durable than analog information, again because circuits are responding only to the presence or absence of something rather than to the precise characteristics of anything. As you have seen, it is possible to design digital systems so that they can actually reconstruct missing or incorrect data. You can hear every little imperfection on an LP, but minor damage is not audible with a CD.
The aspect of digital sound that is most exciting to the electronic musician is that any numbers can be converted into sound, whether they originated at a microphone or not. This opens up the possibility of creating sounds that have never existed before, and of controlling those sounds with a precision that is simply not possible with any other technique.
For further study, I recommend Principles of Digital Audio by Ken C Pohlmann, published by McGraw-Hill inc ISBN number0-07-050469-5.
name::
* McsEngl.ds.SPECIFIC@cptIt,
_SPECIFIC:#ql:_GENERIC cptIt550#
JAVA-SOUND#ql:jv'sound-*##digital-sound handling by java programming language#
name::
* McsEngl.ds.SPEECH@cptIt,
However, speech coding differs from audio coding in that there is a lot more statistical information available about the properties of speech. In addition, some auditory information which is relevant in audio coding can be unnecessary in the speech coding context. In speech coding, the most important criterion is preservation of intelligibility and "pleasantness" of speech, with a constrained amount of transmitted data.
[http://en.wikipedia.org/wiki/Speech_coding]
name::
* McsEngl.ds.HDCD@cptIt,
High Definition Compatible Digital® (HDCD®) is a patented encode/decode process for delivering the full richness and detail of the original microphone feed on Compact Discs and DVD-Audio. HDCD has been used in the recording of more than 5,000 CD titles, which include more than 250 Billboard Top 200 recordings and more than 175 GRAMMY® nominations, (View a list of the HDCD Grammy nominees in 1998, 1999, 2000, and 2001) and account for more than 300 million CDs sold.
HDCD-encoded CDs sound better because they are encoded with 20 bits of real musical information, as compared with 16 bits for all other CDs. HDCD overcomes the limitation of the 16-bit CD format by using a sophisticated system to encode the additional 4 bits onto the CD while remaining completely compatible with the existing CD format. HDCD provides more dynamic range, a more focused 3-D soundstage, and extremely natural vocal and musical timbre. With HDCD, you get the body, depth, and emotion of the original performance not a flat, digital imitation. Tell me more.
HDCD technology was originally developed by Keith Johnson and Pflash Pflaumer, two preeminent technologists in the audio arena. In 1996, they founded Pacific Microsonics, Inc. (PMI), a California-based audio technology licensing company, in order to improve the quality of digital audio recordings and playback while remaining compatible with established digital formats.
In September 2000, Microsoft Corporation acquired PMI. Microsoft continues to incorporate PMI's pioneering technology into offerings for the PC. This technology brings to Microsoft unique strengths in digital audio signal processing that are increasingly important as digital media becomes a primary source of entertainment.
[http://www.hdcd.com/about/index.html]
_CREATED: {2013-12-24} {2013-10-09} ?
name::
* McsEngl.conceptIt989,
* McsEngl.dgldat.image,
* McsEngl.digital picture,
* McsEngl.digital-image, cptResouce,
* McsEngl.digital-picture@cptIt989,
* McsEngl.image.digital@cptIt989,
* McsEngl.img.DIGITAL,
* McsEngl.picture.digital@cptIt989,
* McsEngl.dglimg, cptIt989
* McsElln.ΨΗΦΙΑΚΗ ΕΙΚΟΝΑ,
* McsElln.ΨΗΦΙΟΠΟΙΗΜΕΝΗ ΕΙΚΟΝΑ,
name::
* McsEngl.dglimg'SIZE@cptIt,
Το μέγεθος μιας εικόνας και στην οθόνη αλλά και στην εκτύπωση εξερτάται
- από τα εικονοστοιχεία που την αποτελούν (800x600)
- και τα εικονοστοιχεία ανά μονάδα μήκους που την αποτελούν (dpi)
[RAM, 1997may, 156]
name::
* McsEngl.dglimg'STANDARD@cptIt,
BMP bitmap (Windows Paint),
CDR (corel)
CGM (Computer Graphics Metafile),
CLP (DOS for Quattro),
CIS
DIB (windows)
DRW (Micrografx)
DXF (Audodesk)
EPS (Encapsulated PostScript Adobe-Illustrator),
GIF (Graphics Interchange Format), CompuServe.
GWM (Ambiente)
Jpeg: ΤΡΟΠΟΣ ΣΥΜΠΙΕΣΗΣ true color
MIC (MS Image Composer)
PCD (Photo CD)
PCX (Paintbrush)
PIC (Lotus for DOS)
PSD (Adobe Photoshop)
R LE (windows)
SYM (Symbol Manager)
TGA Targa
TIF (Tag Image File Format)
WMF (windows)
name::
* McsEngl.dglimg.specific@cptIt,
_SPECIFIC:
Smalltalk/V supports both bit-mapped (also known as raster) and vector graphics.
A character stored as a bitmap is formed from a collection of dots or pixels, in raster graphics.
A character in vector graphics is represented by a mathematical formula describing direction and length of the path along its edges. Any graphical shape can be represented and transformed by abstract geometrical description, without regard for the dot resolution of the eventual display or output hardware. This feature of vector graphics promotes the goal of device independent graphics.
[Smalltalk Express Tutorial, 1996]
name::
* McsEngl.dglimg.DATA-URI@cptIt,
* McsEngl.data-uri@cptIt,
* McsEngl.datauri@cptIt,
* McsEngl.data-uri@cptIt,
* McsEngl.img.data-uri@cptIt,
_DESCRIPTION:
We can-see the-image of a-datauri, be putting in the-address-bar of a-browser, the-datauri.
[hmnSngo.2016-03-18]
===
* Did you know that you don't have to link to an external image file when using an <img> element in HTML, or declaring a background-image in CSS? You can embed the image data directly into the document with data URIs.
[http://css-tricks.com/data-uris/]
_ADDRESS.WPG:
* http://www.askapache.com/online-tools/base64-image-converter//
* http://www.abeautifulsite.net/convert-an-image-to-a-data-uri-with-your-browser/
* http://websemantics.co.uk/online_tools/image_to_data_uri_convertor//
===
* https://www.nczonline.net/blog/2009/10/27/data-uris-explained//
_FORMAT:
The format, to be specific:
data:[<mime type>][;charset=<charset>][;base64],<encoded data>
[http://css-tricks.com/data-uris/]
Why would you do this?
The biggest reason: it saves HTTP Requests. Other than pure document size, this is the#1 factor concerning how fast a page loads. Less = better.
[http://css-tricks.com/data-uris/]
Browser Compatibility
Data URI's don't work in IE 5-7, but are supported in IE 8. You could:
Use an IE-only stylesheet to put images in, or,
Use it only for progressive enhancement type stuff where having no image is perfectly acceptable, or,
Not care
Read this article about an alternate technique that does work.
[http://css-tricks.com/data-uris/]
_CODE.CSS:
content: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABUAAAAVAgMAAADUeU0FAAAAAXNSR0IArs4c6QAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB98MBQkeKt251O8AAAAJUExURQAAAAAAAP///4Pdz9IAAAABdFJOUwBA5thmAAAAAWJLR0QCZgt8ZAAAAD9JREFUCB1VwbENgDAQADFHOvqwUQpG4PdfhRqbn2tmXkIkkVvknGjZUYq2FR0e2laUomVHzoncIokQ18y8/j57ogUnBQYbRAAAAABJRU5ErkJggg==);
_CODE.HML:
<img width="21" height="21" title="" alt="" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABUAAAAVAgMAAADUeU0FAAAAAXNSR0IArs4c6QAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB98MBQkeKt251O8AAAAJUExURQAAAAAAAP///4Pdz9IAAAABdFJOUwBA5thmAAAAAWJLR0QCZgt8ZAAAAD9JREFUCB1VwbENgDAQADFHOvqwUQpG4PdfhRqbn2tmXkIkkVvknGjZUYq2FR0e2laUomVHzoncIokQ18y8/j57ogUnBQYbRAAAAABJRU5ErkJggg==" />
img.TOC.EXPAND:
imgToc1Exp15b.png
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA8AAAAPCAYAAAA71pVKAAAABmJLR0QA/wD/AP+gvaeTAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH4AEbDzYiN8jfoAAAAB1pVFh0Q29tbWVudAAAAAAAQ3JlYXRlZCB3aXRoIEdJTVBkLmUHAAAAK0lEQVQoz2NgGHmAEUr/p0AvSQb8J1mCWAv+k6sRl0KSw+Q/BYFJmcbhCgBsWAv3IVPBNwAAAABJRU5ErkJggg==
===
imgToc1Exp15wb.png
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA8AAAAPCAYAAAA71pVKAAAABmJLR0QA/wD/AP+gvaeTAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH4AEbDzcTfw3u2wAAAB1pVFh0Q29tbWVudAAAAAAAQ3JlYXRlZCB3aXRoIEdJTVBkLmUHAAAAOklEQVQoz2NgGHmAkYGBgeH/////SdbIyMgI5xBrAE51hAwgaAEuBUR7DV0hyWEC00BOYDJQpHEYAwDmly/WC/CfiAAAAABJRU5ErkJggg==
===
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABUAAAAVAgMAAADUeU0FAAAAAXNSR0IArs4c6QAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB98MBQkgNRF0wmcAAAAJUExURQAAAAAAAP///4Pdz9IAAAABdFJOUwBA5thmAAAAAWJLR0QCZgt8ZAAAADtJREFUCB1VwbENgDAQADFHOvqwUQpG4PdfhRqbn2tmXkKECBGiw0PbilK07Mg5kVskESJEiBDXzLz+PkuQBGjUC3cvAAAAAElFTkSuQmCC
img.TOC.COLLAPSE:
imgToc2Col15b.png
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA8AAAAPCAYAAAA71pVKAAAABmJLR0QA/wD/AP+gvaeTAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH4AEbDiw6lUvXGgAAAB1pVFh0Q29tbWVudAAAAAAAQ3JlYXRlZCB3aXRoIEdJTVBkLmUHAAAAKUlEQVQoz2NgGAXo4D+lGv9TauN/Sp36n1I//qc0cODqGCkIVcaRmPwAaXwL990+l5QAAAAASUVORK5CYII=
===
imgToc2Col15wb.png
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA8AAAAPCAYAAAA71pVKAAAABmJLR0QAAAAAAAD5Q7t/AAAACXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH4AEbDjMPDqIdpwAAAB1pVFh0Q29tbWVudAAAAAAAQ3JlYXRlZCB3aXRoIEdJTVBkLmUHAAAAQ0lEQVQoz+WQMRIAIAjDWs//f7kOnot6BVbNCCQDwHtIsvsWiHKB5kSSjAKHuF9rUhdTASfaQEa8BfqaofQZCADxIQOPwk++KQylWgAAAABJRU5ErkJggg==
===
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABUAAAAVAgMAAADUeU0FAAAAAXNSR0IArs4c6QAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB98MBQkjIrmKFGMAAAAJUExURQAAAAAAAP///4Pdz9IAAAABdFJOUwBA5thmAAAAAWJLR0QCZgt8ZAAAADhJREFUCNdjYEABrKGhoSEMDCwMYIyDYoFQghDKwQFEMTIIgCgWEGJgEWBgBFEODAwu+A2D2ocCAD3IBGhdG60ZAAAAAElFTkSuQmCC
img.TOC.LEAF:
imgToc3Lif15.png
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA8AAAAPCAYAAAA71pVKAAAABmJLR0QAAAAAAAD5Q7t/AAAACXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH4AEZCAYiR8g3XQAAAB1pVFh0Q29tbWVudAAAAAAAQ3JlYXRlZCB3aXRoIEdJTVBkLmUHAAAAL0lEQVQoz2NgGKzgP6Ua/1Nq439KnfqfUj/+pzRw/lPdZor9THFoUxzPFKcw2gIAggAT7YryXnIAAAAASUVORK5CYII=
===
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABUAAAAVAgMAAADUeU0FAAAAAXNSR0IArs4c6QAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB98MBQkeKt251O8AAAAJUExURQAAAAAAAP///4Pdz9IAAAABdFJOUwBA5thmAAAAAWJLR0QCZgt8ZAAAAD9JREFUCB1VwbENgDAQADFHOvqwUQpG4PdfhRqbn2tmXkIkkVvknGjZUYq2FR0e2laUomVHzoncIokQ18y8/j57ogUnBQYbRAAAAABJRU5ErkJggg==
img.ASTERISK:
data:image/gif;base64,R0lGODlhEAAQAMQAAORHHOVSKudfOulrSOp3WOyDZu6QdvCchPGolfO0o/XBs/fNwfjZ0frl3/zy7////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAkAABAALAAAAAAQABAAAAVVICSOZGlCQAosJ6mu7fiyZeKqNKToQGDsM8hBADgUXoGAiqhSvp5QAnQKGIgUhwFUYLCVDFCrKUE1lBavAViFIDlTImbKC5Gm2hB0SlBCBMQiB0UjIQA7
name::
* McsEngl.dglimg.MAP@cptIt,
* McsEngl.conceptIt242.4,
* McsEngl.map-datatype@cptIt242.4,
name::
* McsEngl.dglimg.PHOTO@cptIt,
* McsEngl.conceptIt989.1,
* McsEngl.conceptResource941,
* McsEngl.digital-photo@cptIt,
* McsEngl.digital-photograph@cptIt,
* McsEngl.img.digital.photo@cptIt,
* McsEngl.photograph.digital@cptResource941,
====== lagoGreek:
* McsElln.ΨΗΦΙΑΚΗ-ΦΩΤΟΓΡΑΦΙΑ@cptIt,
Η ανάλυση για την παρουσίαση στις οθόνες είναι 72dpi
[RAM 1997may, 102]
name::
* McsEngl.dglimg.RASTER@cptIt,
* McsEngl.bitmap-digital-image@cptResouce,
* McsEngl.img.digital.raster@cptIt,
* McsEngl.raster-image-format@cptIt,
====== lagoGreek:
* McsElln.ψηφιογραφική-εικόνα@cptResource, [Πληροφορική γυμανσίου]
name::
* McsEngl.dglimg.SVG@cptIt,
* McsEngl.conceptIt1011,
* McsEngl.SVG@cptIt,
* McsEngl.svg@cptIt1011,
* McsEngl.img.digital.svg@cptIt,
* McsEngl.scalable-vector-graphics@cptResource,
* McsEngl.svg@cptResource,
* McsEngl.imgSvg@cptIt, {2015-05-31}
_GENERIC:
* markup-language##
Type of format: vector image format
_DESCRIPTION:
Scalable Vector Graphics (SVG) is an XML-based vector image format for two-dimensional graphics that has support for interactivity and animation. The SVG specification is an open standard developed by the World Wide Web Consortium (W3C) since 1999.
SVG images and their behaviors are defined in XML text files. This means that they can be searched, indexed, scripted, and, if need be, compressed. As XML files, SVG images can be created and edited with any text editor, but it is often more convenient to create them with drawing programs such as Inkscape.
All major modern web browsers—including Mozilla Firefox, Internet Explorer 9 and 10, Google Chrome, Opera, and Safari—have at least some degree of support for SVG and can render the markup directly.
Scalable Vector Graphics
W3C SVG Logo
Filename extension .svg, .svgz
Internet media type image/svg+xml[1][2]
Uniform Type Identifier public.svg-image
UTI conforms to public.image
Developed by World Wide Web Consortium
Initial release 4 September 2001
Latest release 1.1 (Second Edition) / 16 August 2011; 2 years ago
Type of format Vector image format
Extended from XML
Open format? Yes
Website www.w3.org/Graphics/SVG
[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics]
===
Scalable Vector Graphics (SVG) is an XML specification and file format for describing two-dimensional vector graphics, both static and animated. SVG can be purely declarative or may include scripting. Images can contain hyperlinks using outbound simple XLinks.[2] It is an open standard created by the World Wide Web Consortium's SVG Working Group.
[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics]
name::
* McsEngl.imgSvg'editor@cptIt,
_GENERIC:
* computer-program##
_SVG_EDIT:
* SVG-edit is a fast, web-based, JavaScript-driven SVG drawing editor that works in any modern browser.
* https://code.google.com/p/svg-edit//
* http://svg-edit.googlecode.com/svn/branches/2.6/editor/svg-editor.html,
===
* http://editor.method.ac//
_SVGREAL:
* http://www.vectomatic.org/gwt/svgreal-latest/svgreal.html,
name::
* McsEngl.imgSvg'htmlelt@cptIt,
_DESCRIPTION:
In HTML5, you can embed SVG elements directly into your HTML pages.
[http://www.w3schools.com/svg/svg_inhtml.asp]
_CODE.HML:
<svg width="100" height="100">
<circle cx="50" cy="50" r="40" stroke="green" stroke-width="4" fill="yellow" />
</svg>
[http://www.w3schools.com/html/html5_svg.asp]
name::
* McsEngl.imgSvg'resource@cptIt,
_ADDRESS.WPG:
* http://www.w3schools.com/svg/default.asp,
* https://developers.google.com/web/fundamentals/media/images/use-icons?hl=en,
* http://www.kevlindev.com/geometry/2D/three_point_circle.svg,
name::
* McsEngl.imgSvg'shape@cptIt,
_SPECIFIC:
The complete list of predefined shapes is:
rect
circle
ellipse
line
polyline
polygone
[http://www.i-programmer.info/programming/graphics-and-imaging/2063-getting-started-with-svg-html5.html]
name::
* McsEngl.imgSvg'circle@cptIt,
_CODE.SVG:
<circle
cx="20" cy="50" r="20"
style="fill:red"
/>
name::
* McsEngl.imgSvg'circle@cptIt,
_CODE.SVG:
<rect
x="5" y="50"
width="150" height="30"
style="fill:yellow"
/>
name::
* McsEngl.imgSvg'Specification@cptIt,
svgspn.REC.2011-08-16.SVG11se:
* https://www.w3.org/TR/2011/REC-SVG11-20110816//
Scalable Vector Graphics (SVG) 1.1 (Second Edition)
W3C Recommendation 16 August 2011
SVG is a W3C Recommendation
SVG 1.0 became a W3C Recommendation on 4 September 2001.
SVG 1.1 became a W3C Recommendation on 14 January 2003.
SVG 1.1 (Second Edition) became a W3C Recommendation on 16 August 2011.
[http://www.w3schools.com/svg/default.asp]
name::
* McsEngl.imgSvg.CREDIT-CARD@cptIt,
_CODE.SVG:
//filename: credit.svg
<?xml version="1.0" encoding="utf-8"?>
<!-- Generated by IcoMoon.io -->
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="32" height="32" viewBox="0 0 32 32">
<g></g>
<path d="M29 4h-26c-1.65 0-3 1.35-3 3v18c0 1.65 1.35 3 3 3h26c1.65 0 3-1.35 3-3v-18c0-1.65-1.35-3-3-3zM3 6h26c0.542 0 1 0.458 1 1v3h-28v-3c0-0.542 0.458-1 1-1zM29 26h-26c-0.542 0-1-0.458-1-1v-9h28v9c0 0.542-0.458 1-1 1zM4 20h2v4h-2zM8 20h2v4h-2zM12 20h2v4h-2z" fill="#000000"></path>
</svg>
name::
* McsEngl.dglimg.VECTOR@cptIt,
* McsEngl.img.digital.vector@cptIt,
* McsEngl.vector-format@cptResource,
* McsEngl.vector-graphics@cptResource,
* McsEngl.vector-digital-image@cptResouce,
* McsEngl.vector-image-format@cptResource,
====== lagoGreek:
* McsElln.διανυσματικές-ψηφιακές-εικόνες@cptResource,
_DESCRIPTION:
Vector graphics is the use of geometrical primitives such as points, lines, curves, and shapes or polygon(s), which are all based on mathematical expressions, to represent images in computer graphics. Vector graphics are based on vectors (also called paths, or strokes) which lead through locations called control points. Each of these points has a definite position on the x and y axes of the work plan. Each point, as well, is a variety of database, including the location of the point in the work space and the direction of the vector (which is what defines the direction of the track). Each track can be assigned a color, a shape, a thickness and also a fill.
This does not affect the size of the files in a substantial way because all information resides in the structure; it describes how to draw the vector.
[http://en.wikipedia.org/wiki/Vector_image_format]
===
Adobe pitches graphics standard By Mike Ricciuti Staff Writer, CNET NEWS.COM April 13, 1998, 1:25 p.m. PT audio | update Adobe Systems (ADBE) said today that it has submitted a proposal to the World Wide Web Consortium that could result in better quality Web-based graphics that do not require specialized plug-ins or viewers.
The Precision Graphics Markup Language (PGML), created in conjunction with IBM, Netscape Communications, and Sun Microsystems, is used to define Web page-based images, graphics, and animation, according to Adobe.
More coverage on CNET Radio The PGML spec is being pitched to the W3C as a standard way for handling vector graphics, which differ from common bitmap graphics formats such as .GIF and .JPG. Vector graphics are defined as a series of objects, any piece of which can be manipulated individually. Bitmaps are larger blocks of code that cannot be segmented.
"The big challenge is getting images down to a reasonable size," said Ted Simonides, director of Web product marketing at Adobe. With vector graphics, instead of transmitting a large image, you transmit the description of the image to a Web browser or printer, which then draws the image. "You don't have the issue of transmitting the large image itself, " he said.
The specification builds on Adobe's PostScript and portable document format (PDF) standards, said the company, meaning that few changes will be necessary to make existing PostScript and PDF applications PGML compliant.
PGML is best suited to graphics such as bar charts, logos, and screen graphics, like push buttons. Simonides sees PGML coexisting with current image file formats. "The idea is to support PGML graphics as inline images, as .GIFs and .JPGs are currently supported in Web browsers."
Simonides said Adobe has worked with Netscape, which plans to support PGML in a future release of its Navigator Web browser. The company has also held discussions with Microsoft about adding support to Internet Explorer. "They are interested in participating, and they have some ideas of their own. That's why it seemed best to work with the W3C," he said.
Until browser support for PGML materializes, Adobe will most likely issue an ActiveX or Java component that would function as a browser add-on to support PGML graphics. No release date for the component has been set.
PGML is compatible with XML (extensible markup language), which was recently recommended as a standard by the W3C. XML, related to HTML, is a system for defining, validating, and sharing document formats on the Web. PGML also works with other specifications for building graphics-intensive Web pages, including CSS (cascading style sheets) and DOM (document object model).
According to Sun's JavaSoft division, PGML is based on the same imaging model as the Java 2D application programming interface due with Java Development Kit 1.2. That means PGML graphics will work on Java-based systems.
The PGML specification proposal is in initial draft format.
The W3C is forming a working group to hammer out the final PGML spec, Simonides said. If all goes well, the consortium will eventually vote on whether to recommend PGML as an approved standard.
related news stories • Spec to animate Web pages March 13, 1998 • W3C makes XML a standard February 10, 1998
Go to | Front Door | Intranets | Search Short takes | One Week View
Want a hard copy? Click for a printer-friendly version of this story.
Latest Headlines display on desktop The Net • Gore to unveil Internet2 • Macromedia to open Flash • JavaSoft soothes licensees • Spam king retires • Excite, Lycos get more personal Computing • Cyrix shoots for 300 MHz • Can SGI turn the corner? • SGI cozies up to Intel • Apple sues Exponential • E-stamps by printer tested • Servers use fastest Pentium II Intranets • ICat to host Net storefronts • Bay to support NT for access • Workflow software standard backed • Adobe pitches graphics standard Business • Playboy plays up stock quotes • Lightbridge to come up short • Microsoft foes cite Intuit case • Bank merger joins tech rivals • Net stocks take a breather Miss a day? • All the Headlines
FREE newsletter sample
Get computer bargains • at Cyberian Outpost • at Egghead.com Bid on other products • at Surplus Auction Win your dream machine • at COMPUTERS.COM
Specs and latest prices for 3D cards. Back to Top Copyright © 1995-98 CNET, Inc. All rights reserved. Privacy policy.
_SPECIFIC:
vector formats: SVG, AI and PDF.
[http://icomoon.io/#docs]
name::
* McsEngl.dataIt.sensor.LINGUISTIC@cptIt,
* McsEngl.dgldat.linguistic@cptIt,
_DESCRIPTION:
Text, misc symbols and concepts we communicate with a human-language stored and processed by a computer.
[hmnSngo.2013-12-24]
name::
* McsEngl.dataIt.TEXT@cptIt,
* McsEngl.data.text@cptIt,
* McsEngl.dgltxt@cptIt,
_SPECIFIC:
* string#ql:data.string#
name::
* McsEngl.dataIt.text.CHARACTER@cptIt,
* McsEngl.character-datatype@cptIt248i,
* McsEngl.char-datatype@cptIt248i,
* McsEngl.dgldat.character@cptIt,
_GENERIC:
* data-primitive#ql:data.primitive#
pcl'ESCAPE_CODE:
These are special characters that cannot be expressed otherwise in the sourcecode of a program, like newline (\n) or tab (\t).
name::
* McsEngl.data.string,
* McsEngl.dgldat.string,
* McsEngl.string-datatype@cptIt248i,
* McsEngl.str,
_GENERIC:
* data-primitive#ql:data.primitive#,
* data-text#ql:data.text#,
name::
* McsEngl.conceptIt242.5,
* McsEngl.caledar-datatype@cptIt242.5,
* McsEngl.data.calendar,
name::
* McsEngl.data.evolution,
* McsEngl.data.time-series,
* McsEngl.dgldat.process,
name::
* McsEngl.tree-datatype,
* McsEngl.tree-datastructure,
* cptIt248i,
_DEFINITION:
In computer science, a tree is a widely-used data structure that emulates a tree structure with a set of linked nodes.
[http://en.wikipedia.org/wiki/Tree_data_structure]
_ADDRESS.WPG:
* https://medium.freecodecamp.org/all-you-need-to-know-about-tree-data-structures-bceacb85490c,
_SPECIFIC:
* M-Way Tree
o B-tree
+ 2-3-4 tree
+ B+ tree
+ B*-tree
+ UB-tree
+ R-tree
# R+ tree
# R* tree
* Binary tree
o Binary heap
o Binary search trees (each tree node compares entire key values)
+ Self-balancing binary search trees
# AVL tree
# Red-black tree
* AA tree
# Scapegoat tree
# Splay tree
# Top Trees
+ Interval tree
+ Treap
* Trie family (each tree node compares a bitslice of key values)
o Radix tree
o van Emde Boas tree
o Suffix tree
+ Directed Acyclic Word Graph (DAWG)
* Heap
o Binary heap
o Binomial heap
o Fibonacci heap
o 2-3 heap
o Soft heap
o Pairing heap
o Leftist heap
o Treap
o Beap
o Skew heap
* Parse tree
* Space partitioning
o BSP tree
+ Kd-tree
# Kdb-tree
o Quadtree
o Octree
[http://en.wikipedia.org/wiki/List_of_data_structures]
name::
* McsEngl.data.generic,
* McsEngl.data-type@cptIt242i,
* McsEngl.datatype@cptIt242i,
name::
* McsEngl.data.instance,
_DEFINITION:
It is data without SPECIFIC ones.
[hmnSngo.2011-12-12]
name::
* McsEngl.conceptIt97,
* McsEngl.econtent,
* McsEngl.content@cptIt97, {2012-01-22}
* McsEngl.content.digital@cptIt97,
* McsEngl.data.content@cptIt242i,
* McsEngl.user-data@cptIt242i,
* McsEngl.dataUser@cptIt97, {2012-04-12}
* McsEngl.data.user@cptIt97, {2012-04-12}
* McsEngl.digital-content@cptIt97, 2013,09.24,
* McsEngl.endUser-code@cptIt97, {2012-01-27}
* McsEngl.econtent@cptIt97, {2016-03-20}
_NAME.OLD:
* data-collection-97, {2011-09-03}
* application-data-97, other, {2011-09-03}
* collectionData-97, {2011-09-03}
* user-data-97, {2012-01-22}
* application.InfoTech-97,
* technology application,
* technology use,
* ΕΦΑΡΜΟΓΗ/ΧΡΗΣΗ ΤΗΣ ΤΕΧΝΟΛΟΓΙΑΣ,
* ΕΦΑΡΜΟΓΗ-97,
content.definition.part:
EndUser-code is any code (data or processing) of an APPLICATION, added by endUser.
[hmnSngo.2012-01-27]
_DESCRIPTION:
Content is data that a user understands, in contrast to data that a program "understands".
[hmnSngo.2012-01-22]
===
Any collection of data used in programs or created by programs.
[hmnSngo.2011-09-03]
_DEFINITION:
DATA-APPLICATION is an APPLICATION with which we cann't write programs, but only manipulate data.
[NIKOS, DEC 1996]
ΕΦΑΡΜΟΓΗ ονομάζω ΚΑΘΕ δημιουργία με τη χρήση της τεχνολογίας#cptIt0.1#.
[ΝΙΚΟΣ, ΔΕΚ. 1994]
PROGRAM APPLICATIONS ονομάζω δημιουργήματα κάποιου προγράμματος#cptIt59.1#. Μπορεί να είναι κάποιο καινούργιο πρόγραμμα ή ένα αρχειο δεδομένων.
[ΝΙΚΟΣ, ΝΟΕΜ. 1994]
PROGRAM-APPLICATION I call an APPLICATION with which we write programms. A program is a 'program application' because it is written by another program.
name::
* McsEngl.econtent'DRM@cptIt,
* McsEngl.DRM-digital-rights-management@cptIt,
* McsEngl.digital-rights-management@cptIt,
_DESCRIPTION:
Digital rights management (DRM) is a class of controversial technologies[1] that are used by hardware manufacturers, publishers, copyright holders, and individuals with the intent to control the use of digital content and devices after sale;[1][2][3] there are, however, many competing definitions.[4] With First-generation DRM software, the intent is to control copying while Second-generation DRM schemes seek to control viewing, copying, printing, and altering of works or devices. The term is also sometimes referred to as copy protection, copy prevention, and copy control, although the correctness of doing so is disputed.[5] DRM is a set of access control technologies.[6][7] Companies such as Amazon, AT&T, AOL, Apple Inc., Google,[8] BBC, Microsoft, Electronic Arts, and Sony use digital rights management. In 1998, the Digital Millennium Copyright Act (DMCA) was passed in the United States to impose criminal penalties on those who make available technologies whose primary purpose and function are to circumvent content protection technologies.[9]
The use of digital rights management is not universally accepted. Some content providers claim that DRM is necessary to fight copyright infringement online and that it can help the copyright holder maintain artistic control[10] or ensure continued revenue streams.[11] Proponents argue that digital locks should be considered necessary to prevent "intellectual property" from being copied freely, just as physical locks are needed to prevent personal property from being stolen.[12] Those opposed to DRM contend there is no evidence that DRM helps prevent copyright infringement, arguing instead that it serves only to inconvenience legitimate customers, and that DRM helps big business stifle innovation and competition.[13] Furthermore, works can become permanently inaccessible if the DRM scheme changes or if the service is discontinued.[14]
Digital locks placed in accordance with DRM policies can also restrict users from doing something perfectly legal, such as making backup copies of CDs or DVDs, lending materials out through a library, accessing works in the public domain, or using copyrighted materials for research and education under fair use laws.[12] Some opponents, such as the Free Software Foundation (FSF) through its Defective by Design campaign, maintain that the use of the word "rights" is misleading and suggest that people instead use the term digital restrictions management.[15] Their position is that copyright holders are restricting the use of material in ways that are beyond the scope of existing copyright laws, and should not be covered by future laws.[16] The Electronic Frontier Foundation (EFF) and the FSF consider the use of DRM systems to be anti-competitive practice.[17][18]
[http://en.wikipedia.org/wiki/Digital_rights_management]
name::
* McsEngl.econtent'format@cptIt,
_ADDRESS.WPG:
* https://en.wikipedia.org/wiki/Comparison_of_e-book_formats,
name::
* McsEngl.econtent'program.EDITOR@cptIt,
* McsEngl.econtent.editor@cptIt,
* McsEngl.econtent.creator@cptIt,
name::
* McsEngl.econtent'program.MANAGER@cptIt,
* McsEngl.econtent.manager@cptIt,
name::
* McsEngl.econtent'program.READER@cptIt,
* McsEngl.econtent.reader@cptIt,
* McsEngl.econtent.viewer@cptIt,
name::
* McsEngl.econtent.SPECIFIC@cptIt,
_SPECIFIC: content.Alphabetically:
* book-econtent#cptItsoft266#
* database-econtent#cptIt851#
* dictionary-econtent#cptIt476.1#
* education-econtent#cptIt861.?#
* encyclopedia-econtent#cptIt486.?#
* geograph-econtent#cptIt443.?#
* knowledge-collectionData#cptItsoft497.1#
ELECTRONIC SCS APPLICATION:
FOLIO VIEWS 2.1 SCS#cptIt174: attSpe#
FOLIO VIEWS 3.01 SCS#cptIt417: attSpe#
SSS KB##
name::
* McsEngl.econtent.Text@cptIt,
* McsEngl.etext@cptIt, {2016-03-20}
name::
* McsEngl.dataIt.USER.NO@cptIt,
* McsEngl.data.LanguageProgramming@cptIt,
* McsEngl.data-of-programming-language@cptIt242i,
* McsEngl.dgldat.programer@cptIt,
* McsEngl.programer-data@cptIt242i,
name::
* McsEngl.dataIt.VALUE@deleted,
* McsEngl.value-data@cptIt242i,
* McsEngl.value-of-datatype@cptIt242i,
_DESCRIPTION:
CODE (data and processing) associated with a NAME is called VALUE in computers.
[hmnSngo.2014-02-01]
===
There is no 'value' type of 'data'. Data is a kinde of 'value'.
[hmnSngo.2013-12-24]
===
Value of a datatype is the DATA instances of this "generic" datatype.
[KasNik, 2007-12-23]
name::
* McsEngl.conceptIt59,
* McsEngl.software.PROGRAM (cmrpgm)@cptIt,
* McsEngl.FvMcs.software.PROGRAM (cmrpgm)@cptIt,
* McsEngl.Computer-Program@cptIt,
* McsEngl.program.computer@cptIt,
* McsEngl.pcr@cptIt, {2016-08-24}
* McsEngl.pgm@cptIt,
* McsEngl.code.program@cptIt,
* McsEngl.computer-program@cptIt,
* McsEngl.data-machine-program@cptIt, {2008-01-08}
* McsEngl.program.computer@cptIt,
* McsEngl.program-of-computer@cptIt,
* McsEngl.software.program@cptIt,
* McsEngl.software-program@cptIt,
* McsEngl.cmrpgm@cptIt, {2013-07-26}
* McsEngl.pgmCmr@cptIt, {2014-02-01}
* McsEngl.pgm@cptIt, {2013-07-19}
* McsEngl.prm@cptIt, {2013-07-17}
* McsEngl.prgm@cptIt, {2013-07-17}
* McsEngl.prg@deleted, {2013-07-17}
====== lagoGreek:
* McsElln.ενν.ΚΩΔΙΚΑΣ@cptIt,
* McsElln.ενν.ΠΡΟΓΡΑΜΑ-ΥΠΟΛΟΓΙΣΤΗ@cptIt,
* McsElln.ενν.ΠΡΟΓΡΑΜΜΑ@cptIt,
====== lagoEsperanto:
* McsEngl.programo@lagoEspo,
* McsEspo.programo@cptIt,
=== _OLD:
* McsEngl.software-system@old,
* McsEngl.software-system-59@old,
* While HTML allows us to visualize the information on the web, it doesn't provide much capability to describe the information in ways that facilitate the use of software programs to find or interpret it.
[http://www.daml.org/about.html]
cmrpgm'toc#ql:[Level CONCEPT:rl? conceptIt59]#
name::
* McsEngl.cmrpgm'overview@cptIt,
name::
* McsEngl.cmrpgm'Definition@cptIt,
· computer-program is a-programing-algorithm a-computer understands, ie the-source-code or the-binary-code of the-algorithm.
[hmnSngo.2019-01-07]
Computer-program is the-EXECUTABLE-document of a-programing-algorithm#ql:programing_algorithm#.
[hmnSngo.2017-11-11]
Computer-program is the-code of an-algorithm PLUS its documentation, licence and other attributes of this code.
[hknm.2016-08-24]
Computation_program is a REPRESENTATION of a data_processing METHOD a machine understands (= undertands what data_processing to do, not the meaning of this data_processing).
[hmnSngo.2008-01-08_KasNik]
COMPUTER-PROGRAM is a series of instructions, a computer uses to process data (textual, audio, visual).
[hmnSngo.2002-04-22]
ΠΡΟΓΡΑΜΜΑ ονομάζω ΛΟΓΙΣΜΙΚΟ#cptIt64.1# που, σε αντίθεση με τα ΔΕΔΟΜΕΝΑ, μπορεί να εκτελεί διαδικασίες.
[hmnSngo.1995-03]
Ενα πρόγραμμα ΔΕΝ εκτελεί διαδικασίες. Ενα κομπιούτερ εκτελεί διαδικασίες με βάση ένα πρόγραμμα.
[hmnSngo.2002-04-22]
ΠΡΟΓΡΑΜΑ ΥΠΟΛΟΓΙΣΤΗ είναι ένα σύνολο 'εντολών' γραμμένο βάση μιας 'γλώσας υπολογιστων', που εκτελει κάποιες λειτουργιες.
ΠΡΟΣΟΧΗ!!!! τις διαφορετικές ΕΚΔΟΣΕΙΣ, ΔΕΝ τις θεωρώ διαφορετικο προγραμα, γιατί δεν είναι καινούργιες οντότητες αλλά εξελίξεις της ίδιας οντοτητας.
[ΝΙΚΟΣ, 14 ΣΕΠΤ. 1994]
A program is a strategy for processing information.
[BONCZEK, 1979, 270#cptResource6]
name::
* McsEngl.cmrpgm'INSTALLING@cptIt,
* McsEngl.conceptIt162,
* McsEngl.cmrpgm'installing@cptIt,
* McsEngl.pgmCmr'doing.INSTALLATION@cptIt,
* McsEngl.pgm'doing.installation@cptIt,
* McsEngl.program-installation@cptIt,
* McsEngl.program'installation@cptIt162,
* McsEngl.programing.deploying@cptIt,
====== lagoGreek:
* McsElln.ΕΓΚΑΤΑΣΤΑΣΗ-ΠΡΟΓΡΑΜΜΑΤΟΣ@cptIt,
_DESCRIPTION:
[http://en.wikipedia.org/wiki/Software_development_process]
===
ΕΓΚΑΤΑΣΤΑΣΗ ΠΡΟΓΡΑΜΜΑΤΟΣ είναι η ΔΙΑΔΙΚΑΣΙΑ τοποθέτησης του προγράμματος σε καποιο ΠΛΗΡΟΦΟΡΙΑΚΟ-ΣΥΣΤΗΜΑ.
name::
* McsEngl.cmrpgm'Updating@cptIt,
* McsEngl.cmrpgm'updating@cptIt,
name::
* McsEngl.cmrpgm'USING@cptIt,
name::
* McsEngl.cmrpgm'Starting (synopsis)@cptIt,
* McsEngl.conceptIt59.4,
* McsEngl.conceptIt56,
* McsEngl.cmrpgm'executing@cptIt,
* McsEngl.cmrpgm'starting@cptIt,
* McsEngl.pcr'synopsis@cptIt,
* McsEngl.pcr'executing@cptIt,
* McsEngl.pgm'executing@cptIt,
* McsEngl.pgm'running@cptIt,
* McsEngl.pgm'starting@cptIt,
* McsEngl.program-execution@cptIt,
* McsEngl.executing-program@cptIt,
* McsEngl.pgm'doing.EXECUTING@cptIt,
* McsEngl.program-execution@cptIt59.4,
* McsEngl.program-executing@cptIt59.4, {2011-10-02}
* McsEngl.program-running@cptIt59.4, {2011-10-02}
* McsEngl.program-using@cptIt59.4, {2011-10-02}
* McsEngl.program-run@cptIt,
====== lagoGreek:
* McsElln.ΕΚΤΕΛΕΣΗ-ΠΡΟΓΡΑΜΜΑΤΟΣ@cptIt,
_DEFINITION:
ΕΚΤΕΛΕΣΗ ΠΡΟΓΡΑΜΜΑΤΟΣ είναι η ΔΙΑΔΙΚΑΣΙΑ με την οποία ένα πρόγραμμα ξεκινάει να δουλεύει.
[ΝΙΚΟΣ, 1997ιουλ07]
name::
* McsEngl.cmrpgm'Command-of-synopsis@cptIt,
* McsEngl.pgm'command@cptIt,
* McsEngl.osclicmd@cptIt,
_DESCRIPTION:
A command is an instruction given by a human to tell a computer to do something. Commands are generally issued by typing them in at the command line and then pressing the ENTER key, which passes them to the shell. A shell, also referred to as a command interpreter, is a program that reads commands that are typed on a keyboard and then executes (i.e., runs) them.
[http://www.linfo.org/command_line.html]
name::
* McsEngl.cmrpgm'Argument-of-command@cptIt,
_DESCRIPTION:
There is no consistency in naming the use of "option", "argument" and "flag", and there is no enforcing authority within the software development world to enforce usage. This happens for all wording: after 30+ years of using the word "directory", I now have to deal with people using the word "folder", having been confused with Microsoft's new-speak.
Things you put on the command-line after a command are often called arguments to the command, like arguments to a function call. But I have also seen them being called parameters. The fact that they are called arguments in the C manual (hence, argc and argv) probably contributed to this usage of the word.
Apart from programming language tutorials, the specific usage of wording in libraries (such as getopt for C, argparse for Python, etc.) handling these parameters has helped standardise some of the wording, but not always.
The word "option" comes from "optional", indicating they can be left out. Options are often preceded by a single (-) or double (--, long-option) dash. And then there are options that are not optional (look, for example, at the arparse manual and search for "required"). Some commands do not use or enforce usage of the - (e.g., tar, ps, and dd). An option can take an argument (e.g., -w80 and --color=always), sometimes more.
Flags are in my experience the same as options, but most often used for boolean values (i.e., not taking arguments themselves).
Since every programmer has the option to try and look up some standard way of doing things and naming things, but can also reinvent the wheel without much extra costs, naming is never going to be consistent. And once you document your code and it is clear what new meaning you you give to these words by giving examples, those names and meanings might just stick if there are enough people learning use of the words from there.
[http://unix.stackexchange.com/a/285588]
name::
* McsEngl.cmrpgm'Input-argument@cptIt,
* McsEngl.argument-of-command@cptIt,
_DESCRIPTION:
Options are distinct from arguments, which are input data provided to commands, most commonly the names of files and directories. Commands can also receive input data via pipes, which are a type of redirection that is designed to transfer the output of one command to be used as the input for another. Options can be used simultaneously with arguments and redirection.
[http://www.linfo.org/option.html]
name::
* McsEngl.cmrpgm'Option-argument@cptIt,
* McsEngl.flag-of-command@cptIt,
* McsEngl.option-of-command@cptIt,
* McsEngl.switch-of-command@cptIt,
_DESCRIPTION:
An option, also referred to as a flag or a switch, is a single-letter or full word that modifies the behavior of a command in some predetermined way.
[http://www.linfo.org/option.html]
name::
* McsEngl.cmrpgm'Configuring@cptIt,
* McsEngl.configuring-program@cptIt,
* McsEngl.customizing-program@cptIt,
* McsEngl.pgm'configuring@cptIt,
* McsEngl.pgm'setu-up@cptIt,
* McsEngl.program'configuring@cptIt,
* McsEngl.program'preferences@cptIt,
====== lagoGreek:
* McsElln.παραμετροποίηση-προγράμματος@cptIt,
name::
* McsEngl.cmrpgm'UI-COMMAND (pcrcmd)@cptIt,
* McsEngl.pcr'command@cptIt,
* McsEngl.pgm'command@cptIt,
* McsEngl.pcrcmd@cptIt,
name::
* McsEngl.pcrcmd'Shortcut (pcrshc)@cptIt,
* McsEngl.pcr'shortcut@cptIt,
* McsEngl.pgm'shortcut@cptIt,
* McsEngl.pcrshc@cptIt,
name::
* McsEngl.cmrpgm'Tip@cptIt,
* McsEngl.conceptIt470,
* McsEngl.cmrpgm'tip@cptIt,
* McsEngl.program'tip@cptIt,
* McsEngl.tip-of-program@cptIt,
_DESCRIPTION:
ΔΙΑΔΙΚΑΣΙΕΣ με τις οποίες γίνεται πιο εύκολη η χρήση του προγραματος.
name::
* McsEngl.cmrpgm'DEVELOPING@cptIt,
* McsEngl.cmrpgm'developing@cptIt,
* McsEngl.pgm'creating@cptIt,
* McsEngl.pgm'building@cptIt,
* McsEngl.pgm'compiling@cptIt,
* McsEngl.program'building@cptIt,
* McsEngl.program'creating@cptIt,
_DESCRIPTION:
From source-code to execution-code.
[hmnSngo.2013-12-16]
name::
* McsEngl.cmrpgm'doing.DEBUGING@cptIt,
_DESCRIPTION:
Debugging is a methodical process of finding and reducing the number of bugs, or defects, in a computer program or a piece of electronic hardware, thus making it behave as expected. Debugging tends to be harder when various subsystems are tightly coupled, as changes in one may cause bugs to emerge in another. Many books have been written about debugging (see below: Further reading), as it involves numerous aspects, including interactive debugging, control flow, integration testing, log files, monitoring (application, system), memory dumps, profiling, Statistical Process Control, and special design tactics to improve detection while simplifying changes.
[http://en.wikipedia.org/wiki/Debugging]
name::
* McsEngl.cmrpgm'doing.DONE@cptIt,
NCZOnline Newsletter - Defining Done
Hi everyone,
After a couple of years at Yahoo, my manager pulled me aside and said he really liked the way I went about my work. I gave good estimates, my work was typically done on time, and there were usually very few bugs once shipped. He asked me if I would help teach the rest of the team how to work like I do. I hadn't realized I was doing anything different than anyone else, but my manager had pointed out an important distinction: my definition of "done" was different from a lot of other people's.
Most will say that code is done when it has shipped. Most timing estimates focus on when something is pushed to production and users are able to interact with it. However, everything has bugs when first released, so can you really say the code is done if you're still fixing bugs week after week? That bug fixing prevents you from moving on to your next task and will push back all further tasks. Is that really done?
I believe that code is done when you no longer have to make changes to it (outside of enhancements). This might seem like a dream given today's agile methodologies, but it is possible. Keeping your files small and focused on specific tasks is a good way to create a bunch of code that doesn't need to be touched. Your goal in writing software is to move as much code as possible into this state of done. The less code that changes, the fewer bugs introduced.
So I'd encourage you to take more time up front for the development phase of your work. Adjust your estimates accordingly. Planning for one month of development but spending six months fixing bugs means it takes seven months for the code to be done; if you instead take some more upfront time and maybe use two months of planning and development, you might end up spending only two months fixing bugs (only four months for the code to be done). There are few managers who would argue with those results.
This is the software equivalent of the old addage, "measure twice, cut once." The more upfront planning you can do for your work, the fewer bugs you'll face when going to production, and the faster your code can reach "done."
Be well.
-N
[2015-12-08]
name::
* McsEngl.cmrpgm'archetype@cptIt,
* McsEngl.archetype-of-program@cptIt,
_DESCRIPTION:
· programing-archetype is a-document describing the-doing-of-a-program as done by a-human.
[hmnSngo.2019-01-06]
===
Archetype is an-info-processing method a-human does.
[hmnSngo.2016-08-24]
name::
* McsEngl.cmrpgm'ALGORITHM (Model)@cptIt,
* McsEngl.Algorithm-of-program@cptIt,
_DESCRIPTION:
Algorithm is the-archetype expressed in a-way a-computer can do.
[hmnSngo.2016-08-24]
===
A-program DESCRIBES an-algorithm in a-language that a-computer understands.
[hmnSngo.2015-10-09]
name::
* McsEngl.cmrpgm'structure@cptIt,
_DESCRIPTION:
Theoretically, you can divide any program into three parts: input, process, and output.
[Eckel, Thinking in Java 1998jan]
===
the structure and elements of computer programs
[http://en.wikipedia.org/wiki/Functional_programming]
name::
* McsEngl.pcr-algo'SPECIFICATION@cptIt,
* McsEngl.pcr'specification@cptIt,
_DESCRIPTION:
A program specification is the definition of what a computer program is expected to do. It can be informal, in which case it can be considered as a blueprint or user manual from a developer point of view, or formal, in which case it has a definite meaning defined in mathematical or programmatic terms. In practice, most successful specifications are written to understand and fine-tune applications that were already well-developed, although safety-critical software systems are often carefully specified prior to application development. Specifications are most important for external interfaces that must remain stable.
[http://en.wikipedia.org/wiki/Specification]
name::
* McsEngl.pcr-algo'Binary-code@cptIt,
* McsEngl.cmrpgm'binary-code@cptIt,
* McsEngl.cmrpgm'machine-code@cptIt,
* McsEngl.pcr'binary-code@cptIt,
name::
* McsEngl.pgmcode'bit-architecture@cptIt,
* McsEngl.conceptIt472,
* McsEngl.bit-architecture-of-program@cptIt,
* McsEngl.pgmCmr'bit-architecture@cptIt,
_DESCRIPTION:
Πόσα μπιτ επεξεργάζεται σε κάθε κτύπο του εσωτερικου ρολογιου.
name::
* McsEngl.cmrpgm'Relation-to-computer-system@cptIt,
_DESCRIPTION:
Every processor or processor family has its own machine code instruction set.
Instructions are patterns of bits that by physical design correspond to different commands to the machine.
Thus, the instruction set is specific to a class of processors using (much) the same architecture.
Successor or derivative processor designs often include all the instructions of a predecessor and may add additional instructions.
Occasionally, a successor design will discontinue or alter the meaning of some instruction code (typically because it is needed for new purposes), affecting code compatibility to some extent; even nearly completely compatible processors may show slightly different behavior for some instructions, but this is rarely a problem.
Systems may also differ in other details, such as memory arrangement, operating systems, or peripheral devices.
Because a program normally relies on such factors, different systems will typically not run the same machine code, even when the same type of processor is used.
[http://en.wikipedia.org/wiki/Machine_language]
name::
* McsEngl.cmrpgm'source-code@cptIt,
* McsEngl.cmrpgm'source-code@cptIt,
* McsEngl.pgmcode@cptIt, {2015-05-10}
* McsEngl.programmer-code@cptIt59,
_DESCRIPTION:
Source_code is the-algorithm of a-program written (= implemented) in a-programing-language.
[hmnSngo.2017-11-01]
===
Code is an-algorithm expressed in a-format a-computer understands.
[hmnSngo.2016-08-24]
===
A program it is not its code. It has documentation, licence, humans, etc.
[hknu_2013-07-31,]
_SiblingPartial:
* documentation#ql:program'doc#
name::
* McsEngl.pgmcode'readability@cptIt,
* McsEngl.cmrpgm'readability@cptIt,
name::
* McsEngl.pgmcode'reviewing@cptIt,
* McsEngl.code-review@cptIt, {2012-11-15}
_DESCRIPTION:
Code review is systematic examination (often known as peer review) of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers' skills. Reviews are done in various forms such as pair programming, informal walkthroughs, and formal inspections.[1]
[http://en.wikipedia.org/wiki/Code_review]
===
A of the work product, or by one or more colleagues of the author, to evaluate the technical content and/or quality of the work.[1]
Software management reviews are conducted by management representatives to evaluate the status of work done and to make decisions regarding downstream activities.
Software audit reviews are conducted by personnel external to the software project, to evaluate compliance with specifications, standards, contractual agreements, or other criteria.
[http://en.wikipedia.org/wiki/Software_review] 2012-11-15,
===
A software review is "A process or meeting during which a software product is examined by a project personnel, managers, users, customers, user representatives, or other interested parties for comment or approval".[1]
In this context, the term "software product" means "any technical document or partial document, produced as a deliverable of a software development activity", and may include documents such as contracts, project plans and budgets, requirements documents, specifications, designs, source code, user documentation, support and maintenance documentation, test plans, test specifications, standards, and any other type of specialist work product.
[http://en.wikipedia.org/w/index.php?title=Software_review&direction=prev&oldid=488781130]
name::
* McsEngl.pgm'code.specific@cptIt,
_SPECIFIC:
* data-code#ql:program'data_code#,
* processing-code#ql:program'processing_code#,
* mixed-code#ql:program'mixed_code#,
===
* container-code#ql:program'container_code#,
* non-container-code,
===
* codeType,
name::
* McsEngl.pgmcode.CONTAINER@cptIt,
* McsEngl.container-code-of-program@cptIt59,
* McsEngl.pgm'Container@cptIt,
* McsEngl.pgm'Container-code@cptIt,
* McsEngl.pgm'Group-of-code@cptIt,
_GENERIC:
* pgm's-code#ql:program'code#
_SPECIFIC:
* class,
* constant,
* data-container,
* function,
* mixed-container,
* processing-container,
* variable,
===
* data-container,
* mixed-container,
* processing-container,
name::
* McsEngl.pgmcode.CONTAINER.NO@cptIt,
* McsEngl.pgm'ContainerNo@cptIt,
* McsEngl.pgm'ContainerNo-code@cptIt,
* McsEngl.pgm'Non-container-code@cptIt,
name::
* McsEngl.pgmcode.DATA@cptIt,
* McsEngl.pgm'Data-application@cptIt,
_GENERIC:
* program's-code#ql:program'code#
* data#ql:data@cptIt242#
_SPECIFIC:
* endUser-data,
* programer-data,
name::
* McsEngl.cmrpgm'data.Audio@cptIt,
* McsEngl.pgm'audio-data@cptIt,
name::
* McsEngl.cmrpgm'data.Collection@cptIt,
* McsEngl.pgm'collection-data@cptIt,
name::
* McsEngl.cmrpgm'data.EndUser@cptIt,
* McsEngl.pgm'content-data@cptIt,
* McsEngl.pgm'enduser-data@cptIt, {2012-01-29}
name::
* McsEngl.cmrpgm'data.Image@cptIt,
* McsEngl.pgm'-imagedata@cptIt,
name::
* McsEngl.cmrpgm'data.Programer@cptIt,
* McsEngl.pgm'data-code@cptIt,
* McsEngl.pgm'programer-data-code@cptIt,
* McsEngl.pgm'programer-data@cptIt,
name::
* McsEngl.cmrpgm'data.Text@cptIt,
* McsEngl.pgm'text-data@cptIt,
name::
* McsEngl.cmrpgm'data.Time@cptIt,
* McsEngl.pgm'time-data@cptIt,
name::
* McsEngl.cmrpgm'data.Video@cptIt,
* McsEngl.pgm'video-data@cptIt,
name::
* McsEngl.pgmcode.DEVELOPER@cptIt,
* McsEngl.pgm'developer-code@cptIt,
* McsEngl.pgm'programer-code@cptIt,
name::
* McsEngl.pgmcode.FILE@cptIt,
* McsEngl.pgm'file@cptIt,
* McsEngl.pgmCmr'file@cptIt,
name::
* McsEngl.pgmfile'file.CONFIGURATION@cptIt,
_DESCRIPTION:
* config_file_cpt,
* configuration_file_cpt,
* file.configuration_cpt,
* pgmCmr'configuration_file,
_DESCRIPTION:
In computing, configuration files, or config files configure the initial settings for some computer programs. They are used for user applications, server processes and operating system settings. The files are often written in ASCII (rarely UTF-8) and line-oriented, with lines terminated by a newline or carriage return/line feed pair, depending on the operating system. They may be considered a simple database.
Some applications provide tools to create, modify, and verify the syntax of their configuration files; these sometimes have graphical interfaces. For other programs, system administrators may be expected to create and modify files by hand using a text editor. For server processes and operating-system settings, there is often no standard tool, but operating systems may provide their own graphical interfaces such as YaST or debconf.
Some computer programs only read their configuration files at startup. Others periodically check the configuration files for changes. Users can instruct some programs to re-read the configuration files and apply the changes to the current process, or indeed to read arbitrary files as a configuration file. There are no definitive standards or strong conventions.
[https://en.wikipedia.org/wiki/Configuration_file]
name::
* McsEngl.pgmcode.PREFERENCE@cptIt,
* McsEngl.configuration-variable@cptIt,
* McsEngl.pgmCmr'configuration-variable@cptIt,
* McsEngl.pgm'configuration-option@cptIt,
* McsEngl.pgm'preference@cptIt,
* McsEngl.pgm'option@cptIt,
* McsEngl.pgm'user-preference@cptIt,
====== lagoGreek:
* McsElln.παράμετρος-προγράμματος@cptIt,
_DESCRIPTION:
Configuration-variable is a-variable of the-program whose VALUE can-be-setted by the-user, usually through the-configuration-file.
[hmnSngo.2015-10-09]
name::
* McsEngl.pgmcode.MIXED@cptIt,
* McsEngl.pgm'Mixed-code@cptIt,
* McsEngl.pgm'programer-mixed-code@cptIt,
name::
* McsEngl.pgmcode.PROCESSING@cptIt,
* McsEngl.pgm'Processing-code@cptIt,
* McsEngl.pgm'programer-processing-code@cptIt,
name::
* McsEngl.pgmcode.TYPE@cptIt,
* McsEngl.conceptIt59.5,
* McsEngl.codeType@cptIt59.5,
_DEFINITION:
CodeType is SPECIFIC code identifiable because of some diferent attributes which has other specifics.
[hmnSngo.2012-01-29]
name::
* McsEngl.pcr-algo'code'issue@cptIt,
* McsEngl.pgm'issue@cptIt,
name::
* McsEngl.pcr-algo'code'issue.bug@cptIt,
* McsEngl.pgm'error@cptIt,
* McsEngl.pgm'issue@cptIt,
_ADDRESS.WPG:
* How to Report Bugs Effectively
- by Simon Tatham, professional and free-software programmer
- http://www.chiark.greenend.org.uk/~sgtatham/bugs.html,
name::
* McsEngl.cmrpgm'Bug-report@cptIt,
Summary
* The first aim of a bug report is to let the programmer see the failure with their own eyes. If you can't be with them to make it fail in front of them, give them detailed instructions so that they can make it fail for themselves.
* In case the first aim doesn't succeed, and the programmer can't see it failing themselves, the second aim of a bug report is to describe what went wrong. Describe everything in detail. State what you saw, and also state what you expected to see. Write down the error messages, especially if they have numbers in.
* When your computer does something unexpected, freeze. Do nothing until you're calm, and don't do anything that you think might be dangerous.
* By all means try to diagnose the fault yourself if you think you can, but if you do, you should still report the symptoms as well.
* Be ready to provide extra information if the programmer needs it. If they didn't need it, they wouldn't be asking for it. They aren't being deliberately awkward. Have version numbers at your fingertips, because they will probably be needed.
* Write clearly. Say what you mean, and make sure it can't be misinterpreted.
* Above all, be precise. Programmers like precision.
[http://www.chiark.greenend.org.uk/~sgtatham/bugs.html]
name::
* McsEngl.cmrpgm'user-interface@cptIt,
* McsEngl.conceptIt420,
* McsEngl.pui@cptIt,
* McsEngl.pcr'user-interface@cptIt,
* McsEngl.user-interface@cptIt420,
* McsEngl.pgm'ui@cptIt,
====== lagoGreek:
* McsElln.ΔΙΕΠΑΦΗ-ΧΡΗΣΤΗ@cptIt,
* McsElln.ΠΕΡΙΒΑΛΛΟΝ-ΔΙΕΠΑΦΗΣ@cptIt,
ΔΙΕΠΑΦΗ ΧΡΗΣΤΗ:
* Βακάλη κα, Ανάπτυξη Εφαρμογών γ' λυκείου, 1999 α' έκδοση, 241
ΠΕΡΙΒΑΛΛΟΝ ΔΙΕΠΑΦΗΣ:
* Αντωνάκος κα, "Ανάπτυξη εφαρμογών..." Γ' Λυκείου, 1999 α' έκδοση
(Language) User-Interface are the means a Computer-language uses to communicate with the user.
[nikkas 1999oct29]
User interface is any way with which a USER communicates with a program#cptIt59.1#.
[NIKOS, OKT. 1996]
name::
* McsEngl.pui'designing@cptIt,
_DESCRIPTION:
Best Practices for Designing an Interface
Everything stems from knowing your users, including understanding their goals, skills, preferences, and tendencies. Once you know about your user, make sure to consider the following when designing your interface:
Keep the interface simple. The best interfaces are almost invisible to the user. They avoid unnecessary elements and are clear in the language they use on labels and in messaging.
Create consistency and use common UI elements. By using common elements in your UI, users feel more comfortable and are able to get things done more quickly. It is also important to create patterns in language, layout and design throughout the site to help facilitate efficiency. Once a user learns how to do something, they should be able to transfer that skill to other parts of the site.
Be purposeful in page layout. Consider the spatial relationships between items on the page and structure the page based on importance. Careful placement of items can help draw attention to the most important pieces of information and can aid scanning and readability.
Strategically use color and texture. You can direct attention toward or redirect attention away from items using color, light, contrast, and texture to your advantage.
Use typography to create hierarchy and clarity. Carefully consider how you use typeface. Different sizes, fonts, and arrangement of the text to help increase scanability, legibility and readability.
Make sure that the system communicates what’s happening. Always inform your users of location, actions, changes in state, or errors. The use of various UI elements to communicate status and, if necessary, next steps can reduce frustration for your user.
Think about the defaults. By carefully thinking about and anticipating the goals people bring to your site, you can create defaults that reduce the burden on the user. This becomes particularly important when it comes to form design where you might have an opportunity to have some fields pre-chosen or filled out.
[http://www.usability.gov/what-and-why/user-interface-design.html]
name::
* McsEngl.pui'interface-language@cptIt,
* McsEngl.conceptIt469,
* McsEngl.interface-language-of-a-program@cptIt,
Είναι η ΦΥΣΙΚΗ ΓΛΩΣΑ με την οποία επικοινωνεί ο χρήστης του προγράμματος με το προγραμα.
[ΝΙΚΟΣ, ΝΟΕΜ. 1994]
name::
* McsEngl.pui'IO-system@cptIt,
Creating a good input/output (IO) system is one of the more difficult tasks for the language designer.
This is evidenced by the number of different approaches. The challenge seems to be in covering all eventualities. Not only are there different kinds of IO that you want to communicate with (files, the console, network connections), but you need to talk to them in a wide variety of ways (sequential, random-access, binary, character, by lines, by words, etc.).
[Eckel, Thinking in Java, 1998jan]
name::
* McsEngl.pui'resource@cptIt,
_ADDRESS.WPG:
* http://blog.teamtreehouse.com/10-user-interface-design-fundamentals,
name::
* McsEngl.ui.specific@cptIt,
_SPECIFIC:
* CHARACTER-UI#ql:ui.character_based@cptIt#
* GRAPHICAL-UI#cptItsoft366#
* VOICE-UI#linkL#
===
* os-ui##
name::
* McsEngl.pui.medium.CHARACTER (cli)@cptIt,
* McsEngl.cli@cptIt,
* McsEngl.ui'command-line-user-interface@cptIt,
* McsEngl.ui'console@cptIt,
* McsEngl.ui.character-based@cptIt,
* McsEngl.ui.CLI@cptIt,
_DESCRIPTION:
The-communication user-pgm is-done with characters, no graphics.
[hmnSngo.2016-12-21]
name::
* McsEngl.pui.medium.GRAPHICAL (gui)@cptIt,
* McsEngl.conceptIt366,
* McsEngl.gui@cptIt,
* McsEngl.GUI@cptIt,
* McsEngl.gui@cptIt,
* McsEngl.graphical-user-interface@cptIt,
* McsEngl.os'gui@cptIt,
* McsEngl.pgm'gui@cptIt,
====== lagoGreek:
* McsElln.γραφική-διεπαφή-του-χρήστη@cptIt,
* McsElln.ΓΡΑΦΙΚΟ-ΠΕΡΙΒΑΛΛΟΝ-ΕΠΙΚΟΙΝΩΝΙΑΣ@cptIt,
_DEFINITION:
a visual way of interacting with a computer using items such as windows, icons, and menus, used by most modern operating systems.
[Google dict]
===
* ΤΑ GUI ΣΥΝΟΔΕΥΟΥΝ ΤΑ ΛΕΙΤΟΥΡΓΙΚΑ ΣΥΣΤΗΜΑΤΑ ΚΑΙ ΤΟΥΣ ΠΡΟΣΔΙΔΟΥΝ ΤΗΝ ΠΟΛΥΧΡΩΜΗ ΕΙΚΟΝΑ ΤΟΥΣ ΠΡΟΣ ΤΟΝ ΕΞΩ ΚΟΣΜΟ ΚΑΙ ΚΥΡΙΩΣ ΠΡΟΣ ΤΟΝ ΧΡΗΣΤΗ.
===
* Είναι το αντίθετο του CHARACTER BASED INTERFACE.
name::
* McsEngl.gui'component (guic)@cptIt,
* McsEngl.gui'component@cptIt,
* McsEngl.gui'item@cptIt, {2015-05-27}
* McsEngl.control.gui@cptIt,
* McsEngl.GCE@cptIt,
* McsEngl.gce@cptIt,
* McsEngl.graphical-control-element@cptIt,
* McsEngl.graphical-user-interface-element@cptIt,
* McsEngl.gui'control@cptIt,
* McsEngl.gui'widget@cptIt,
* McsEngl.widget@cptIt,
* McsEngl.widget.gui@cptIt,
* McsEngl.window-gadget@cptIt,
* McsEngl.gui'element.control@cptIt,
* McsEngl.widget@cptIt,
* McsEngl.Graphical-Control-Element@cptIt,
* McsEngl.guic@cptIt, {2016-08-25}
_DESCRIPTION:
Graphical user interface elements are those elements used by graphical user interfaces (GUIs) to offer a consistent visual language to represent information stored in computers. These make it easier for people with few computer skills to work with and use computer software.
This article explains the most common elements of visual language interfaces found in the WIMP ("window, icon, menu, pointer") paradigm, although many are also used at other graphical post-WIMP interfaces. These elements are usually embodied in an interface using a widget toolkit or desktop environment.
[http://en.wikipedia.org/wiki/Graphical_user_interface_elements]
===
Interface elements known as graphical control elements, controls or widgets are software components that a computer user interacts with through direct manipulation to read or edit information about an application. Each widget facilitates a specific user-computer interaction. Structuring a user interface with Widget toolkits allow developers to reuse code for similar tasks, and provides users with a common language for interaction, maintaining consistency throughout the whole information system.
Common uses for widgets involve the display of collections of related items (such as with various list and canvas controls), initiation of actions and processes within the interface (buttons and menus), navigation within the space of the information system (links, tabs and scrollbars), and representing and manipulating data values (labels, check boxes, radio buttons, sliders, spinners...)
[http://en.wikipedia.org/wiki/Graphical_user_interface_elements#Controls_.28or_Widgets.29]
name::
* McsEngl.guic'structure@cptIt,
_DESCRIPTION:
User interfaces use visual conventions to represent the generic information shown. Some conventions are used to build the structure of the static elements on which the user can interact, and define the appearance of the interface.
[http://en.wikipedia.org/wiki/Graphical_user_interface_elements]
name::
* McsEngl.guic.specific@cptIt,
* McsEngl.guielt.specific@cptIt,
* McsEngl.gce.specific@cptIt,
_SPECIFIC:
Graphical control elements
Command input
* gce.Button
* gce.Context_menu
* gce.Menu
* gce.Pie_menu
* gce.Drop_down
* gce.Adjustment_handle
Data input-output
* gce.Checkbox
* gce.Combo_box
* gce.Cycle_button
* gce.Drop_down_list
* gce.Grid_view
* gce.List_box
* gce.List_builder
* gce.Radio_button
* gce.Scrollbar
* gce.Slider
* gce.Spinner
* gce.Search_box
* gce.Text_box
Informational
* gce.Balloon_help
* gce.Head_up_display_in_computing
* gce.Head_up_display_in_video_games
* gce.Icon
* gce.Infobar
* gce.Label
* gce.Loading_screen
* gce.Progress_indicator (* gce.Progress_bar * gce.Splash_screen * gce.Throbber)
* gce.Sidebar
* gce.Status_bar
* gce.Toast
* gce.Tooltip
Containers
* gce.Accordion
* gce.Disclosure_widget
* gce.Frame_Fieldset
* gce.Menu_bar
* gce.Panel
* gce.Popover
* gce.Ribbon
* gce.Tab
* gce.Toolbar
* gce.Window
Navigational
* gce.Address_bar
* gce.Breadcrumb
* gce.Hyperlink
* gce.Tree_view
* gce.Link_bar
Special windows
* gce.About_box
* gce.Alert_dialog_box
* gce.Dialog_box
* gce.File_dialog
* gce.Inspector_window
* gce.Modal_window
* gce.Palette_window
Related concepts
* Layout manager
* Look and feel
* Mouseover
* Widget toolkit
* WIMP
* File viewer
* Graphical user interface elements
[http://en.wikipedia.org/wiki/Spinner_(computing)]
_SPECIFIC:
* accordion#linkL#
* button#linkL
* container#linkL#
* cursor#linkL#
* icon#linkL#
* menu#linkL#
* menubar#linkL#
* pointer#linkL#
* ribbon#linkL#
* scrollbar#linkL#
* tab#linkL#
* textfield#linkL#
* toolbar#linkL#
* window#linkL#
*#linkL#
*#linkL#
name::
* McsEngl.guic.generic.CONTAINER@cptIt,
* McsEngl.guic.container@cptIt,
_SPECIFIC:
Containers
* Accordion
* Disclosure widget
* Frame/Fieldset
* Menu bar
* Panel#ql:guielt.panel#
* Popover
* Ribbon
* Tab
* Toolbar
* Window
[http://en.wikipedia.org/wiki/Spinner_(computing)]
name::
* McsEngl.guic.generic.INFORMATIONAL@cptIt,
_SPECIFIC:
Informational Components:
* tooltips,
* icons,
* progress bar,
* notifications,
* message boxes,
* modal windows
[http://www.usability.gov/what-and-why/user-interface-design.html]
name::
* McsEngl.guic.generic.INPUT@cptIt,
_SPECIFIC:
Input Controls:
* buttons,
* text fields,
* checkboxes,
* radio buttons,
* dropdown lists,
* list boxes,
* toggles,
* date field
[http://www.usability.gov/what-and-why/user-interface-design.html]
name::
* McsEngl.guic.generic.NAVIGATIONAL@cptIt,
_SPECIFIC:
Navigational Components:
* breadcrumb,
* slider,
* search field,
* pagination,
* tags,
* icons
[http://www.usability.gov/what-and-why/user-interface-design.html]
name::
* McsEngl.guic.bar.MENU@cptIt,
* McsEngl.guic.menubar@cptIt,
_GENERIC:
* container-gui-element#ql:guielt.container@cptIt#
name::
* McsEngl.guic.bar.TOOL@cptIt,
* McsEngl.guic.toolbar@cptIt,
_GENERIC:
* container-gui-element#ql:guielt.container@cptIt#
name::
* McsEngl.guic.bar.STATUS@cptIt,
* McsEngl.guic.statusbar@cptIt,
name::
* McsEngl.guic.CHECKBOX@cptIt,
* McsEngl.gui'checkbox@cptIt,
* McsEngl.checkbox.gui@cptIt,
_GENERIC:
* container-gui-element#ql:guielt.container@cptIt#
name::
* McsEngl.guic.CURSOR@cptIt,
* McsEngl.cursor.gui@cptIt,
* McsEngl.gui'cursor@cptIt,
* McsEngl.gui'element.cursor@cptIt,
_DESCRIPTION:
A cursor is an indicator used to show the position on a computer monitor or other display device that will respond to input from a text input or pointing device.
Pointer[edit]
Main article: Pointer (computing WIMP)
The pointer echoes movements of the pointing device, commonly a mouse or touchpad. The pointer is the place where actions take place that are initiated through direct manipulation gestures such as click, touch and drag.
Insertion point[edit]
The caret, text cursor or insertion point represents the point of the user interface where the focus is located. It represents the object that will be used as the default subject of user-initiated commands such as writing text, starting a selection or a copy-paste operation through the keyboard.
[http://en.wikipedia.org/wiki/Graphical_user_interface_elements]
name::
* McsEngl.guic.INTERACTION@cptIt,
* McsEngl.gui'interaction-element@cptIt,
name::
* McsEngl.guic.lag.XAML@cptIt,
* McsEngl.xaml'guic@cptIt,
Here is the list of controls which we will discuss one by one in this chapter.
Sr. No. Controls & Description
1 Button
A control that responds to user input.
2 Calendar
Represents a control that enables a user to select a date by using a visual calendar display.
3 CheckBox
A control that a user can select or clear.
4 ComboBox
A drop-down list of items a user can select from.
5 ContextMenu
Gets or sets the context menu element that should appear whenever the context menu is requested through a user interface (UI) from within this element.
6 DataGrid
Represents a control that displays data in a customizable grid.
7 DatePicker
A control that lets a user select a date.
8 Dialogs
An application may also display additional windows to the user to gather or display important information.
9 GridView
A control that presents a collection of items in rows and columns that can scroll horizontally.
10 Image
A control that presents an image.
11 ListBox
A control that presents an inline list of items that the user can select from.
12 Menus
Represents a Windows menu control that enables you to hierarchically organize elements associated with commands and event handlers.
13 PasswordBox
A control for entering passwords.
14 Popup
Displays content on top of existing content, within the bounds of the application window.
15 ProgressBar
A control that indicates progress by displaying a bar.
16 ProgressRing
A control that indicates indeterminate progress by displaying a ring.
17 RadioButton
A control that allows a user to select a single option from a group of options.
18 RichEditBox
A control that lets a user edit rich text documents with content like formatted text, hyperlinks, and images.
19 ScrollViewer
A container control that lets the user pan and zoom its content.
20 SearchBox
A control that lets a user enter search queries.
21 Slider
A control that lets the user select from a range of values by moving a Thumb control along a track.
22 TextBlock
A control that displays text.
23 TimePicker
A control that lets a user set a time value.
24 ToggleButton
A button that can be toggled between 2 states.
25 ToolTip
A pop-up window that displays information for an element.
26 Window
The root window which provides minimize/maximize option, Title bar, border and close button.
[http://www.tutorialspoint.com/xaml/xaml_controls.htm]
name::
* McsEngl.guic.LIST@cptIt,
* McsEngl.gui'list@cptIt,
* McsEngl.list.gui@cptIt,
name::
* McsEngl.guic.list.COMBOBOX@cptIt,
* McsEngl.gui'combo-box@cptIt,
* McsEngl.combo-box.gui@cptIt,
* McsEngl.combobox.gui@cptIt,
_DESCRIPTION:
A combo box is a commonly used graphical user interface widget (or control). Traditionally, it is a combination of a drop-down list or list box and a single-line editable textbox, allowing the user to either type a value direct The term "combo box" is sometimes used to mean "drop-down list".[1] In both Java and .NET, "combo box" is not a synonym for "drop-down list".[2][3] Definition of "drop down list" is sometimes clarified with terms such as "non-editable combo box" (or something similar) to distinguish it from "combo box".
[http://en.wikipedia.org/wiki/Combo_box]
name::
* McsEngl.guic.list.DROP-DOWN@cptIt,
* McsEngl.gui'drop-down-list@cptIt,
* McsEngl.drop-down-list.gui@cptIt,
* McsEngl.pull-down-list.gui@cptIt,
_DESCRIPTION:
A drop-down menu (also drop down menu or drop down list or drop menu or pull-down list) is a graphical control element, similar to a list box, that allows the user to choose one value from a list. When a drop-down list is inactive, it displays a single value. When activated, it displays (drops down) a list of values, from which the user may select one. When the user selects a new value, the control reverts to its inactive state, displaying the selected value. It is often used in the design of graphical user interfaces, including web design.
[https://en.wikipedia.org/wiki/Drop-down_list]
name::
* McsEngl.guic.MENU@cptIt,
* McsEngl.gui'menu@cptIt,
* McsEngl.menu.gui@cptIt,
_DESCRIPTION:
Menus allow the user to execute commands by selecting from a list of choices. Options are selected with a mouse or other pointing device within a GUI. A keyboard may also be used. Menus are convenient because they show what commands are available within the software. This limits the amount of documentation the user reads to understand the software.[2]
A menu bar is displayed horizontally across the top of the screen and/or along the tops of some or all windows. A pull-down menu is commonly associated with this menu type. When a user clicks on a menu option the pull-down menu will appear.[3][4]
A menu has a visible title within the menu bar. Its contents are only revealed when the user selects it with a pointer. The user is then able to select the items within the pull-down menu. When the user clicks elsewhere the content of the menu will disappear.[5]
A context menu is invisible until the user performs a specific mouse action, like pressing the right mouse button. When the software-specific mouse action occurs the menu will appear under the cursor.[3]
Menu extras are individual items within or at the side of a menu.
[http://en.wikipedia.org/wiki/Graphical_user_interface_elements]
name::
* McsEngl.guic.PANEL@cptIt,
* McsEngl.gui'panel@cptIt,
* McsEngl.panel.gui@cptIt,
_GENERIC:
* container-gui-element#ql:guielt.container@cptIt#
_DESCRIPTION:
Panels in widget toolkits (libraries that contain a collection of graphical control elements) often have no specific graphic characteristics, but are mainly used to group child widgets together. They provide better control on the layout of the graphical control elements.
[http://en.wikipedia.org/wiki/Panel_(computer_software)]
===
In computer program development, a panel is a representation of what information will be sent to a user's display screen in given circumstances. Typically, when designing a program, the user interface is specified by portraying what information (text and pictures) will be presented to the user at different stages of using the program. For example, each menu, help page, or other form of content constitutes a panel of information that is to be implemented by developers and tested by early users. Since most applications are developed against the context of an operating system graphical user interface ( GUI ), these elements can sometimes be assumed in describing specific panels. Generally, in a windowed user interface, a panel is designed for each window of information.
This was last updated in April 2005
Posted by: Margaret Rouse
[http://whatis.techtarget.com/definition/panel]
name::
* McsEngl.guic.POPOVER@cptIt,
* McsEngl.gui'popover@cptIt,
* McsEngl.popover.gui@cptIt,
_DESCRIPTION:
A Popover is a container-type graphical control element that hovers over its parent window and blocks any other interaction with until it is selected. It can contain various other graphical control element such as checkboxs, radio buttons or a List box. As any container-type graphical control element it is meant to group elements that belong together and is not meant to be extensive.
Popover graphical control element were introduced in GTK+ 3.12[1]
[http://en.wikipedia.org/wiki/Popover_(GUI)]
name::
* McsEngl.guic.RADIOBUTTON@cptIt,
* McsEngl.gui'radiobutton@cptIt,
* McsEngl.radiobutton.gui@cptIt,
name::
* McsEngl.guic.RIBBON@cptIt,
* McsEngl.gui'ribbon@cptIt,
* McsEngl.ribbon.gui@cptIt,
_DESCRIPTION:
In computer interface design, a ribbon is a graphical control element. It is a set of toolbars placed on several tabs. Microsoft products released since 2007 have introduced a form of modular ribbon as their main interface, where large tabbed toolbars, filled with graphical buttons and other graphical control elements, are grouped by functionality. Such ribbons use tabs to expose different sets of controls, eliminating the need for many parallel toolbars. Contextual tabs are tabs that appear only when the user needs them. For instance, in a word processor, an image-related tab may appear when the user selects an image in a document, allowing the user to interact with that image.
The usage of the term ribbon dates from the 1980s and was originally used as a synonym for what is now more commonly known as a (non-tabbed) toolbar. However, in 2007, Microsoft Office 2007 used the term to refer to its own implementation of tabbed toolbars bearing heterogeneous controls, which Microsoft calls "The Fluent UI". Thus, Microsoft popularized the term with a new meaning, although similar tabbed layouts of controls had existed in previous software from other vendors. The new design was intended to alleviate the problem of users not finding or knowing of the existence of available features in the Office suite.[1][2]
[http://en.wikipedia.org/wiki/Ribbon_(computing)]
name::
* McsEngl.guic.SLIDER@cptIt,
* McsEngl.gui'slider@cptIt,
* McsEngl.slider.gui@cptIt,
_DESCRIPTION:
A slider or track bar is a graphical control element with which a user may set a value by moving an indicator, usually in a horizontal fashion. In some cases the user may also click on a point on the slider to change the setting. It is different from a scrollbar in that it is not continuous but used to adjust a value without changing the format of the display or the other information on the screen.
[http://en.wikipedia.org/wiki/Slider_(computing)]
name::
* McsEngl.guic.SPINNER@cptIt,
* McsEngl.gui'spinner@cptIt, /spiner/
* McsEngl.spinner.gui@cptIt,
_DESCRIPTION:
A spinner or numeric updown is a graphical control element with which a user may adjust a value in an adjoining text box by either clicking on an up or down arrow, or by holding an arrow down, causing the value in the text box to increase (if the up arrow is held down) or decrease (if the down arrow is held down). A spinner is typically oriented vertically. In most cases holding a button down causes the speed at which the associated value changes to increase. Usually, the value of the spinner is displayed in a text box next to the spinner, allowing the user to use the spinner to adjust the value, or to type the value into the text box.
A spinner is different from a scrollbar or slider in that a spinner is typically used to adjust a value without changing the format of the display or the other information on the screen. Thus, the appearance of the spinner at a given time does not represent the quantity of the associated value.
[http://en.wikipedia.org/wiki/Spinner_(computing)]
name::
* McsEngl.guic.TEXTAREA@cptIt,
* McsEngl.gui'textarea@cptIt,
* McsEngl.textarea@cptIt,
_DESCRIPTION:
Textarea is a MULTILINE box to write, textbox is a SINGLE-LINE box.
[hmnSngo.2015-10-18]
name::
* McsEngl.guic.TEXTBOX@cptIt,
* McsEngl.gui'textbox@cptIt,
* McsEngl.text-field@cptIt,
* McsEngl.text-box@cptIt,
* McsEngl.text-entry-box@cptIt,
* McsEngl.text-input-box@cptIt,
* McsEngl.textbox.gui@cptIt,
_DESCRIPTION:
A text box, text field or text entry box is a graphical control element intended to enable the user to input text information to be used by the program. Human Interface Guidelines recommend a single-line text box when only one line of input is required, and a multi-line text box only if more than one line of input may be required. Non-editable text boxes can serve the purpose of simply displaying text.
A typical text box is a rectangle of any size, possibly with a border that separates the text box from the rest of the interface. Text boxes may contain zero, one, or two scrollbars. Text boxes usually display a text cursor (commonly a blinking vertical line), indicating the current region of text being edited. It is common for the mouse cursor to change its shape when it hovers over a text box.
[https://en.wikipedia.org/wiki/Text_box]
name::
* McsEngl.guic.THROBBER@cptIt,
* McsEngl.gui'throbber@cptIt,
* McsEngl.throbber.gui@cptIt,
_DESCRIPTION:
A throbber is an animated graphical control element that visualizes that the program is performing an action in the background (such as downloading content, conducting intensive calculations or communicating with an external device).[1][2][3] In contrast to a progress bar, a throbber does not convey how much of the action has been completed.
[http://en.wikipedia.org/wiki/Throbber]
name::
* McsEngl.guic.TAB@cptIt,
* McsEngl.gui'tab@cptIt,
* McsEngl.tab.gui@cptIt,
====== lagoGreek:
* McsElln.καρτέλα-γραφικής-διεπαφής@cptIt,
_DESCRIPTION:
A tab is typically a rectangular small box which usually contains a text label or graphical icon associated with a view pane. When activated the view pane, or window, displays widgets associated with that tab; groups of tabs allow the user to switch quickly between different widgets. This is used in the web browsers Firefox, Internet Explorer, Konqueror, Opera, and Safari. With these browsers, you can have multiple web pages open at once in one window, and quickly navigate between them by clicking on the tabs associated with the pages. Tabs are usually placed in groups at the top of a window, but may also be grouped on the side or bottom of a window. Tabs are also present in the settings panes of many applications. Windows for example uses tabs in most of its control panel dialogues.
[http://en.wikipedia.org/wiki/Graphical_user_interface_elements]
name::
* McsEngl.guic.view.TABLE@cptIt,
* McsEngl.datagrid.gui@cptIt,
* McsEngl.gce.grid-view@cptIt,
* McsEngl.grid-view.gui@cptIt,
* McsEngl.gui'grid-view@cptIt,
* McsEngl.gui'table@cptIt,
* McsEngl.spreadsheet-control.gui@cptIt,
* McsEngl.spreadsheet-widget.gui@cptIt,
* McsEngl.table-view.gui@cptIt,
_DESCRIPTION:
A grid view or a datagrid is a graphical control element that presents a tabular view of data. A typical grid view also supports some or all of the following:
Clicking a column header to change the sort order of the grid
Dragging column headers to change their size and their order
In-place editing of viewed data
Row and column separators, and alternating row background colors
An interactive live demo example of this type of list can be seen here[1][dead link].
Some widget toolkits, these are libraries containing a collection of equally designed graphical control elements, distinguish between a grid and a datagrid. If this is the case, the term datagrid refers specifically to a graphical control element that can be linked to a database with little or no effort from the part of a programmer.
They are commonly used to display lists of files, such as the "Details" view in Windows XP file managers.
Grid views are sometimes referred to as spreadsheet widgets (or spreadsheet controls, with control being a common synonym for widget). This is due to grid views' visual and sometimes behavioral similarity to spreadsheet applications. However, though many grid views support editing of underlying data, they cannot be used for arbitrary calculations. Spreadsheet widgets occur frequently in scientific applications such as PSPP or SPSS.
[http://en.wikipedia.org/wiki/Grid_view]
name::
* McsEngl.guic.view.TREE@cptIt,
* McsEngl.gce.tree-view@cptIt,
* McsEngl.gui'tree@cptIt,
* McsEngl.gui'tree-view@cptIt,
* McsEngl.outline-view.gui@cptIt,
* McsEngl.tree-view.gui@cptIt,
_DESCRIPTION:
A tree view or an outline view is a graphical control element that presents a hierarchical view of information. Each item (often called a branch or a node) can have a number of subitems. This is often visualized by indentation in a list.
An item can be expanded to reveal subitems, if any exist, and collapsed to hide subitems.
Tree views are often seen in file manager applications, where they allow the user to navigate the file system directories. They are also used to present hierarchical data, such as an XML document. Extended tree view is the central component of an outliner application.
[http://en.wikipedia.org/wiki/Tree_view]
name::
* McsEngl.guic.WINDOW@cptIt,
* McsEngl.gui'window@cptIt,
* McsEngl.window.gui@cptIt,
_DESCRIPTION:
A window is an area on the screen that displays information, with its contents being displayed independently from the rest of the screen. An example of a window is what appears on the screen when the "My Documents" icon is clicked in the Windows Operating System. It is easy for a user to manipulate a window: it can be shown and hidden by clicking on an icon or application, and it can be moved to any area by dragging it (that is, by clicking in a certain area of the window – usually the title bar along the tops – and keeping the pointing device's button pressed, then moving the pointing device). A window can be placed in front or behind another window, its size can be adjusted, and scrollbars can be used to navigate the sections within it. Multiple windows can also be open at one time, in which case each window can display a different application or file – this is very useful when working in a multitasking environment. The system memory is the only limitation to the number of windows that can be open at once. There are also many types of specialized windows.[1]
A Container Window a window that is opened while invoking the icon of a mass storage device, or directory or folder and which is presenting an ordered list of other icons that could be again some other directories, or data files or maybe even executable programs. All modern container windows could present their content on screen either acting as browser windows or text windows. Their behaviour can automatically change according to the choices of the single users and their preferred approach to the graphical user interface.
A browser window allows the user to move forward and backwards through a sequence of documents or web pages. Web browsers are an example of these types of windows.
Text terminal windows are designed for embedding interaction with text user interfaces within the overall graphical interface. MS-DOS and UNIX consoles are examples of these types of windows.
A child window opens automatically or as a result of a user activity in a parent window. Pop-up windows on the Internet can be child windows.
A message window, or dialog box, is a type of child window. These are usually small and basic windows that are opened by a program to display information to the user and/or get information from the user. They usually have a button that must be pushed before the program can be resumed.
[http://en.wikipedia.org/wiki/Graphical_user_interface_elements]
===
A window is a separate viewing area on a computer display screen in a system that allows multiple viewing areas as part of a graphical user interface ( GUI ). Windows are managed by a windows manager as part of a windowing system .
A window can usually be resized by the user. For example, it can be stretched on any side, minimized, maximized, and closed. On today's multitasking operating systems, you can have a number of windows on your screen at the same time, interacting with each whenever you choose.
The window first came into general use as part of the Apple Macintosh. Later, Microsoft made the idea the foundation of its Windows operating system (which was actually a graphical user interface for the Disk Operating System ( DOS ) operating system on IBM-compatible PCs). The X Window System was developed as an open cross-platform windowing system for use in networks. It allows a client application in one computer to request windowing services at a user's workstation computer.
This was last updated in December 2005
Posted by: Margaret Rouse
name::
* McsEngl.guic.window.DIALOG-BOX@cptIt,
* McsEngl.dialog-box.gui@cptIt,
* McsEngl.dialogue-box.gui@cptIt,
* McsEngl.gce.dialog-box@cptIt,
* McsEngl.gui'dialog-box@cptIt,
* McsEngl.message-box.gui@cptIt,
_DESCRIPTION:
The graphical control element dialog box (or dialogue box) is a small window that communicates information to the user and prompt him for a response.
Dialog boxes are classified as "modal" or "modeless", depending on whether or not they block interaction with the software that initiated the dialog. The type of dialog box displayed is dependent upon the desired user interaction.
The simplest type of dialog box is the alert, which displays a message and may require an acknowledgment that the message has been read, usually by clicking "OK", or a decision as to whether or not an action should proceed, by clicking "OK" or "Cancel". Alerts are also used to display a "termination notice"—sometimes requesting confirmation that the notice has been read—in the event of either an intentional closing or unintentional closing ("crash") of an application or the operating system. (E.g., "Gedit has encountered an error and must close.") Although this is a frequent interaction pattern for modal dialogs, it is also criticized by usability experts as being ineffective for its intended use, which is to protect against errors caused by destructive actions,[1] and for which better alternatives exist.[2]
[http://en.wikipedia.org/wiki/Dialog_box]
name::
* McsEngl.guic.window.HOVER-BOX@cptIt,
* McsEngl.hint.gui@cptIt,
* McsEngl.hoverbox@cptIt,
* McsEngl.infotip@cptIt,
* McsEngl.tooltip@cptIt,
* McsEngl.popup-window@cptIt,
_DESCRIPTION:
A hoverbox is a popup window that is neither a tooltip nor a traditional popup, but is a popup that appears when the mouse is placed over an icon on the screen for a short period of time, without clicking.
Hoverboxes differ from tooltips in that hoverboxes support HTML elements and can be used to display forms, graphics and lists among other html elements.
Hoverboxes differ from traditional popups in that the user must hover over a page element to activate. Hoverboxes are not used for advertising nor survey collection.
Typically used to hide page elements that would otherwise clutter a website.
[https://en.wikipedia.org/wiki/Hoverbox]
===
The tooltip or infotip or a hint is a common graphical user interface element. It is used in conjunction with a cursor, usually a pointer. The user hovers the pointer over an item, without clicking it, and a tooltip may appear—a small "hover box" with information about the item being hovered over.[1] [2]Tooltips do not usually appear on mobile operating systems, because there is no cursor (though tooltips may be displayed when using a mouse).
[https://en.wikipedia.org/wiki/Tooltip]
===
In computing, a mouseover, mouse hover or hover box is a graphical control element that is activated when the user moves or "hovers" the pointer over its trigger area, usually with a mouse, but also possible using a digital pen. The graphical control element is particularly common in web browsers where the URL of a hyperlink can be viewed in the status bar. Site designers can easily define their own mouseover events using JavaScript[1] and/or Cascading Style Sheets.[2] In case of multiple layers the mouseover event is triggered by the uppermost layer.
Mouseover events are not limited to web design and are commonly used in modern GUI programming. Their existence might not even be known to the user as the events can be used to call any function and might affect only the internal workings of the program.
[https://en.wikipedia.org/wiki/Mouseover]
name::
* McsEngl.guic.window.MODAL@cptIt,
* McsEngl.modal-window.gui@cptIt,
* McsEngl.gce.modal-window@cptIt,
* McsEngl.gui'modal-window@cptIt,
* McsEngl.gui'window.modal@cptIt,
_DESCRIPTION:
In user interface design, a modal window is a graphical control element subordinate to an application's main window which creates a mode where the main window can't be used. The modal window is a child window that requires users to interact with it before they can return to operating the parent application, thus preventing the workflow on the application main window. Modal windows are often called heavy windows or modal dialogs because the window is often used to display a dialog box.
Modal windows are commonly used in GUI systems to command user awareness and to display emergency states, although they have been argued to be ineffective for that use.[1] Modal windows are prone to produce mode errors.
On the Web, they are often used to show images in detail, such as ones implemented by Lightbox library.[2][3]
[http://en.wikipedia.org/wiki/Modal_window]
name::
* McsEngl.gui'layout-manager@cptIt,
* McsEngl.layout-manager@cptIt,
_DESCRIPTION:
Layout managers are software components used in widget toolkits which have the ability to lay out graphical control elements by their relative positions without using distance units. It is often more natural to define component layouts in this manner than to define their position in pixels or common distance units, so a number of popular widget toolkits include this ability by default. Widget toolkits that provide this function can generally be classified into two groups:
Those where the layout behavior is coded in special graphic containers. This is the case in XUL and the .NET Framework widget toolkit (both in Windows Forms and in XAML).
Those where the layout behavior is coded in layout managers, that can be applied to any graphic container. This is the case in the Swing widget toolkit that is part of the Java API.
[http://en.wikipedia.org/wiki/Layout_manager]
name::
* McsEngl.gui'widget-toolkit@cptIt,
* McsEngl.widget-toolkit@cptIt,
_DESCRIPTION:
widget toolkits (libraries that contain a collection of graphical control elements)
[http://en.wikipedia.org/wiki/Panel_(computer_software)]
SPECIFIC:
* DESKTOP INTERFACE, UNIXWARE,
* OPEN LOOK, solaris,
* WORKPLACE SHELL of OS/2 2.1,
name::
* McsEngl.gui.OS@cptIt,
* McsEngl.native-gui@cptIt,
* McsEngl.gui.native@cptIt,
* McsEngl.os'gui@cptIt,
name::
* McsEngl.gui.PROGRAMING-LANGUAGE@cptIt,
* McsEngl.gui.lcp@cptIt,
* McsEngl.lcp'user-interface@cptIt,
* McsEngl.user-interface-element@cptIt,
_DESCRIPTION:
The gui a programing-languages uses.
[hmnSngo.2014-12-20]
name::
* McsEngl.gui.Webpage@cptIt,
* McsEngl.webpage-user-interface@cptIt,
* McsEngl.guiWpg@cptIt,
name::
* McsEngl.guiWpg'Resource@cptIt,
_ADDRESS.WPG:
* http://webix.com/widgets//
* http://photonkit.com/components//
name::
* McsEngl.gui.EVOLUTING@cptIt,
_ADDRESS.WPG:
* https://en.wikipedia.org/wiki/History_of_the_graphical_user_interface,
name::
* McsEngl.pui.medium.VOICE@cptIt,
* McsEngl.pui.VOICE@cptIt,
* McsEngl.audio-user-interface@cptIt,
* McsEngl.ui.audio@cptIt,
* McsEngl.ui.voice@cptIt,
* McsEngl.voice-user-interface@cptIt,
* McsEngl.VUI@cptIt,
_DESCRIPTION:
A voice–user interface (VUI) makes human interaction with computers possible through a voice/speech platform in order to initiate an automated service or process.
A VUI is the interface to any speech application. Controlling a machine by simply talking to it was science fiction only a short time ago. Until recently, this area was considered to be artificial intelligence. However, with advances in technology, VUIs have become more commonplace, and people are taking advantage of the value that these hands-free, eyes-free interfaces provide in many situations.
However, VUIs are not without their challenges. People have very little patience for a "machine that doesn't understand". Therefore, there is little room for error: VUIs need to respond to input reliably, or they will be rejected and often ridiculed by their users. Designing a good VUI requires interdisciplinary talents of computer science, linguistics and human factors psychology – all of which are skills that are expensive and hard to come by. Even with advanced development tools, constructing an effective VUI requires an in-depth understanding of both the tasks to be performed, as well as the target audience that will use the final system. The closer the VUI matches the user's mental model of the task, the easier it will be to use with little or no training, resulting in both higher efficiency and higher user satisfaction.
The characteristics of the target audience are very important. For example, a VUI designed for the general public should emphasize ease of use and provide a lot of help and guidance for first-time callers. In contrast, a VUI designed for a small group of power users (including field service workers), should focus more on productivity and less on help and guidance. Such applications should streamline the call flows, minimize prompts, eliminate unnecessary iterations and allow elaborate "mixed initiative dialogs", which enable callers to enter several pieces of information in a single utterance and in any order or combination. In short, speech applications have to be carefully crafted for the specific business process that is being automated.
Not all business processes render themselves equally well for speech automation. In general, the more complex the inquiries and transactions are, the more challenging they will be to automate, and the more likely they will be to fail with the general public. In some scenarios, automation is simply not applicable, so live agent assistance is the only option. A legal advice hotline, for example, would be very difficult to automate. On the flip side, speech is perfect for handling quick and routine transactions, like changing the status of a work order, completing a time or expense entry, or transferring funds between accounts.
[http://en.wikipedia.org/wiki/Voice_user_interface]
name::
* McsEngl.pui.LANGUAGE@cptIt,
* McsEngl.programing-language-user-interface@cptIt,
name::
* McsEngl.pui.OS@cptIt,
_DESCRIPTION:
An operating system shell is a software component that presents a user interface to various operating system functions and services. Thus, it is nearly synonymous with "operating system user interface".[1] The shell is so called because it is an outer layer of interface between the user and the innards of the operating system (the kernel).[2]
[http://en.wikipedia.org/wiki/Operating_system_user_interface]
name::
* McsEngl.cmrpgm'Documentation@cptIt,
* McsEngl.pgm'doc@cptIt,
* McsEngl.software-documentation@cptIt,
_DESCRIPTION:
Software documentation is like sex:
when it is good, it is very, very good; and
when it is bad, it is better than nothing. (Anonymous.)
name::
* McsEngl.cmrpgm'Problem@cptIt,
name::
* McsEngl.cmrpgm'Ηuman@cptIt,
* McsEngl.human.program@cptIt,
_SPECIFIC: division.CREATING:
* programer
* user#linkL#
name::
* McsEngl.cmrpgm'human.USER@cptIt,
* McsEngl.user.program@cptIt,
* McsEngl.pgm'user@cptIt,
name::
* McsEngl.cmrpgm'human.ADMINISTRATOR@cptIt,
* McsEngl.administrator.program@cptIt,
* McsEngl.pgm'administrator@cptIt,
name::
* McsEngl.cmrpgm'human.END-USER@cptIt,
* McsEngl.end-user.program@cptIt,
* McsEngl.pgm'end-user@cptIt,
name::
* McsEngl.cmrpgm'Licence@cptIt,
_DESCRIPTION:
Licenses are per-user, rather than per-machine, so you can enjoy Sublime Text on as many computers and operating systems as you wish with your license.
[https://www.sublimetext.com/buy]
_SPECIFIC:
* per machine##
* per OS##
* per user##
name::
* McsEngl.cmrpgm'ownership@cptIt,
_GENERIC:
* ownership#cptEconomy541.12#
Code can't be stolen under federal law, court rules
Judges find former Goldman Sachs programmer was wrongly charged with theft and espionage after he downloaded code to a high-speed trading system.
by Steven Musil April 11, 2012 6:48 PM PDT
The government's effort to prosecute corporate espionage was dealt a setback today when a federal appeals court ruled that downloaded code did not qualify as stolen under a federal theft statute.
The 2nd U.S. Circuit Court of Appeals in New York ruled today that former Goldman Sachs programmer Sergey Aleynikov was wrongly charged with theft of property under the National Stolen Property Act, which makes it illegal to steal trade secrets.
Aleynikov, 42, was convicted in December 2010 of downloading code for Goldman Sachs' high-speed computerized trading operations and uploading it to an overseas server before he left the Wall Street investment bank in 2009.
"Because Aleynikov did not 'assume physical control' over anything when he took the source code, and because he did not thereby 'deprive [Goldman] of its use,' Aleynikov did not violate the NSPA," Chief Judge Dennis Jacobs wrote in the three-judge panel's unanimous decision (see below). "We decline to stretch or update statutory words of plain and ordinary meaning in order to better accommodate the digital age."
Aleynikov was sentenced to eight years in prison but was released in February when the judges found that Aleynikov had also been wrong charged with espionage under the Economic Espionage Act of 1996.
While conceding that the code was "highly valuable," Jacobs said the code was never intended to be sold or licensed.
[http://news.cnet.com/8301-1009_3-57412779-83/code-cant-be-stolen-under-federal-law-court-rules/?tag=mncol;editorPicks]
name::
* McsEngl.MPL@cptIt,
* McsEngl.Mozilla-Public-License-Version-2.0@cptIt,
name::
* McsEngl.cmrpgm'Notation@cptIt,
From AAj:
- llll: LAST place we worked.
- ppp: Something wrong is there.
- nnn: general place to look at.
- addLng: A place where I have to add code for a new adding language.
- sout: system.out to check
- wrkrnd: specific workaround. A change in the program, must find another solution.
- toDo: In future, I must add functionality there.
- cnvntn: Convention, I use in the program that must be followed systematically everywhere in it, and I must remember it. [2008-11-14]
name::
* McsEngl.cmrpgm'State@cptIt,
_DESCRIPTION:
State refers to the information a program has access to and can operate on at a point in time.
This includes data stored in memory as well as OS memory, input/output ports, database, etc.
For example, the contents of variables in an application at any given instant are representative of the application's state.
[https://auth0.com/blog/glossary-of-modern-javascript-concepts/]
name::
* McsEngl.cmrpgm'PART@cptIt,
_SPECIFIC:
* documentation#ql:program'doc#,
* program-code#ql:program'code#
_DivisionPartialDoc:
* documentation#ql:program'doc#,
* program-code#ql:program'code#
_WHOLE:
* systemSoftware#cptItsoft490#
* systemItComputer#cptItsoft453#
Ενα πρόγραμα είναι χαρακτηριστικό μιας πληροφοριακής μηχανής.
name::
* McsEngl.cmrpgm'ENVIRONMENT@cptIt,
* McsEngl.cmrpgm'ecosystem@cptIt,
* McsEngl.cmrpgm'environment@cptIt,
* McsEngl.cpt'ecosystem-of-cmrpgm@cptIt,
* McsEngl.program'ecosystem@cptIt,
name::
* McsEngl.cmrpgm'Ηardware@cptIt,
The value of this attribute can be any subgeneral concept of the INFORMATION MACHINE#cptIt456#
name::
* McsEngl.cmrpgm'IDE@cptIt,
Κάθε προγραμμα έχει γραφτεί με κάποιο Language-program.
Ετσι κάθε προγραμα θα έχει αυτο το χαρακτηριστικο (ΜΕΤΑΒΛΗΤΗ) που θα παίρνει ΤΙΜΕΣ, τα συγκεκριμένα γλωσες-προγράματα.
[ΝΙΚΟΣ, 14 ΣΕΠΤ. 1994]
name::
* McsEngl.cmrpgm'ATTRIBUTE@cptIt,
name::
* McsEngl.cmrpgm'extensibility@cptIt,
* McsEngl.cmrpgm'plugin@cptIt,
name::
* McsEngl.cmrpgm'overlay@cptIt,
Overlay
An overlay is a section of a program that is temporarily stored on a direct access storage device, such as a disk drive, while another section of the same program is executing.
The overlay is then loaded into main memory in the same locations occupied by the last section of the program.
Overlays are used when the program requires more memory space than is available in main memory.
[SOURCE: PC-GLOSSARY 1993]
name::
* McsEngl.cmrpgm'DOING@cptIt,
* McsEngl.program'function@cptIt444,
====== lagoGreek:
* McsElln.ΠΡΟΓΡΑΜΜΑΤΟΣ-ΛΕΙΤΟΥΡΓΙΑ@cptIt,
name::
* McsEngl.cmrpgm'doing'DEFINITION@cptIt,
Καταρχας κάθε προγραμα συστήματος-πληροφοριακών-μηχανών εκτελεί την λειτουργία της επεξεργασίας της πληροφορίας. Εδώ αναφέρω τις υποδιαιρέσεις.
[ΝΙΚΟΣ, 22 ΣΕΠΤ. 1994]
ΠΡΟΣΟΧΗ:
Κάθε "κομπιουτερ" είναι ένα σύστημα "ΑΝΘΡΩΠΟΥ & ΜΗΧΑΝΗΣ", δηλαδη ΔΕΝ δουλεύει απόλυτα μόνο του, αλλά χρειάζεται και κάποιον άνθρωπο να το "οδηγεί". Ετσι κάθε ΛΕΙΤΟΥΡΓΙΑ/FUNCTION που κάνει, συνοδεύεται με την ΕΚΤΕΛΕΣΗ/COMMAND.
[ΝΙΚΟΣ, ΟΚΤ. 1994]
name::
* McsEngl.pgm'doing.specific@cptIt,
_SPECIFIC:
* application-function##
* BEGINING & END of a program,
* developing#ql:pgm'developing#
* PROCESSING FUNCTION##
* system-function##
* using-program,
name::
* McsEngl.cmrpgm'doing.EVALUATING@cptIt,
* McsEngl.pgm'evaluating@cptIt,
* McsEngl.program'evaluating@cptIt,
name::
* McsEngl.cmrpgm'doing.FUNCTING@cptIt,
* McsEngl.conceptIt444,
* McsEngl.techInfo.processing-function@cptIt,
* McsEngl.pgmCmr'usability@cptIt,
* McsEngl.pgm'functing@cptIt,
* McsEngl.program'functing@cptIt,
_DESCRIPTION:
The information processing of a proram.
- LAST number on functions: 27.
name::
* McsEngl.cmrpgm'doing.functing.APPLICATION(real-world)@cptIt,
_SPECIFIC:
ANIMATION#230, cpt.444-3#
AUDIO#247, cpt.444-12#
CALCULATIONS#428, cpt.444-13#
COMMUNICATION#373, cpt.444-14#
DOCUMENT MANAGEMENT#426, cpt.444-15#
HYPERTEXT#cpt.444-27#
SPELLING#cpt.444-25#
WORD'PROCESSING#cpt.444.26#
EDUCATION#411, cpt.444-16#
ENTERTAINMENT#413, cpt.444-17#
GRAPHICS#106, cpt.444-18#
MISCELLANEOUS#cpt.444-19#
OCR/OPTICAL CHARACTER RECOGNITION#336, cpt.444-20#
ORGANIZATION MANAGEMENT#427, cpt.444-21#
PIM/PERSONAL INFORMATION MANAGEMENT#342, cpt.444-22#
PROJECT'MANAGEMENT#101, cpt.444-23#
VIDEO#28#cptIt28#, cpt.444-24#
name::
* McsEngl.cmrpgm'doing.functing.SYSTEM@cptIt,
_SYSTEM:
APPLICATION GENERATOR#cpt.444-4#
CASE TOOL#cpt.444-5#
DEVICE DRIVER#cpt.444-6#
LANGUAGE#cpt.444-7#
OPERATING SYSTEM#cpt.444-8#
UTILITY#cpt.444-9#
VIRUS#cpt.444-10# & ANTIVIRUS#cpt.444-11#
name::
* McsEngl.cmrpgm'doing.USING@cptIt,
* McsEngl.pgm'using@cptIt,
_DEFINITION:
Program's usage I call the way this program is used in real situations.
[KasNik, 2007-12-01]
_SPECIFIC:
* web-program-using#ql:prgweb'using#
_SPECIFIC:
* administering##
* configuring#linkL#
* installing#linkL#
* starting#linkL#
name::
* McsEngl.cmrpgm'doing.DEPLOYMENT@cptIt,
* McsEngl.programing'deploying@cptIt,
_DESCRIPTION:
Deployment starts directly after the code is appropriately tested, approved for release, and sold or otherwise distributed into a production environment. This may involve installation, customization (such as by setting parameters to the customer's values), testing, and possibly an extended period of evaluation.[citation needed]
[http://en.wikipedia.org/wiki/Software_development_process]
_GENERIC:
* SOFTWARE#cptIt64#
* entity.whole.system#cptCore765#
name::
* McsEngl.cmrpgm.specific@cptIt,
* McsEngl.pgm.specific@cptIt,
* McsEngl.program.specific@cptIt,
_SPECIFIC:
* program.bytecode#cptIt59.8#
* program.game#cptItsoft413#
* program.machine#cptIt59.9#
* program.microprogram##
* program.system#cptItsoft331#
* program.systemNo#cptItsoft304#
* program.source#cptIt59.7#
name::
* McsEngl.cmrpgm.SPECIFIC-DIVISION.ABSTRACTNESS@cptIt,
_SPECIFIC:
* program.bytecode#cptIt59.8#
* program.machine#cptIt59.9#
* program.microprogram##
* program.source#cptIt59.7#
name::
* McsEngl.cmrpgm.SPECIFIC-DIVISION.system@cptIt,
_SPECIFIC:
* program.system#cptItsoft331#
* program.systemNo#cptItsoft304#
name::
* McsEngl.cmrpgm.SPECIFIC-DIVISION.net@cptIt,
_SPECIFIC:
* program.network#cptItsoft350#
* program.networkNo
name::
* McsEngl.cmrpgm.SPECIFIC-DIVISION.price@cptIt,
open source, freeware, shareware, or commercial.
_SPECIFIC:
* program.free#cptItsoft59.2#
* program.free.public_domain##
* program.semi_free##
* program.freeware##
* program.freeNo##
* program.freeNo.shareware#cptItsoft332#
name::
* McsEngl.cmrpgm.SPECIFIC-DIVISION.misc@cptIt,
_SPECIFIC:
* program.ARTIFICIAL_INTELIGENCE#cptItsoft497.6#
* program.CLIENT_SERVER#cptIt345#
* program.MEMORY_RESIDENT
* program.NEURAL_NETWORK#cptIt340#
* program.OBJECT_ORIENTED programs
* program.OLE#cptIt432#
_SPECIFIC:
* QUERY: ΠΡΟΓΡΑΜΑΤΑ-ΝΑ-ΑΓΟΡΑΣΩ#ql:[Level concept:cpt nikos.to.buy]#
* QUERY: ΠΡΟΓΡΑΜΑΤΑ-ΠΟΥ-ΕΧΩ#ql:[Level CONCEPT:rl3 fd-* | fd5-* | cdrom-*]##fd-* | fd5-* |cdrom-*#
name::
* McsEngl.cmrpgm.BYTECODE@cptIt,
* McsEngl.conceptIt59.8,
* McsEngl.bytecode@cptIt59,
_DEFINITION:
Bytecode is a binary representation of an executable program designed to be executed by a virtual machine rather than by dedicated hardware. Since it is processed by software, it is usually more abstract than machine code. Different parts of a program are often stored in separate files, similar to object modules.
[http://en.wikipedia.org/wiki/Bytecode]
name::
* McsEngl.cmrpgm.CONVERTER@cptIt,
* McsEngl.converter-program@cptIt,
* McsEngl.program.converter@cptIt,
* McsEngl.pgmCvr@cptIt,
_ADDRESS.WPG:
* binary-data: https://www.gbmb.org//
* number-base: http://www.binaryhexconverter.com// Try our new excellent and convenient binary, hexadecimal, decimal calculator online right now!
name::
* McsEngl.cmrpgm.CHEMISTRY@cptIt,
* McsEngl.chemistry-program@cptIt, {2012-11-13}
* McsEngl.sciChem'computer-program@cptIt, {2012-11-13}
_ADDRESS.WPG:
* http://www.chemview.gr/index.php?option=com_weblinks&view=category&id=2,
name::
* McsEngl.cmrpgm.DESKTOP@cptIt,
* McsEngl.desktop-application@cptIt,
* McsEngl.desktop-program@cptIt,
* McsEngl.pgm.desktop@cptIt,
_DESCRIPTION:
Desktop applications always had a special place in my heart. Ever since browsers and mobile devices got powerful, there’s been a steady decline of desktop applications which are getting replaced by mobile and web applications. Still, there’s are a lot of upsides to writing desktop applications -- they are always present once they’re in your start menu or dock, they’re alt(cmd)-tabbable (I hope that’s a word) and mostly connect better with the underlying operating system (with its shortcuts, notifications, etc) than web applications.
[https://medium.com/developers-writing/building-a-desktop-application-with-electron-204203eeb658#.ek8b39sxt]
name::
* McsEngl.cmrpgm.EXAMPLE@cptIt,
Pascal:
PROGRAM name
CONST
constants
VAR
variables
BEGIN
commands
END.
BASIC:
' comments
commands
END
_CREATED: {2012-11-13} {2011-08-24}
name::
* McsEngl.cmrpgm.FRAMEWORK@cptIt,
* McsEngl.conceptIt581,
* McsEngl.framework@cptIt581,
* McsEngl.software-framework@cptIt581,
_DESCRIPTION:
In computer programming, a software framework is an abstraction in which software providing generic functionality can be selectively changed by user code, thus providing application specific software. It is a collection of software libraries providing a defined application programming interface (API).
Frameworks contain key distinguishing features that separate them from normal libraries:
* inversion of control - In a framework, unlike in libraries or normal user applications, the overall program's flow of control is not dictated by the caller, but by the framework.[1]
* default behavior - A framework has a default behavior. This default behavior must actually be some useful behavior and not a series of no-ops.
* extensibility - A framework can be extended by the user usually by selective overriding or specialized by user code providing specific functionality.
* non-modifiable framework code - The framework code, in general, is not allowed to be modified. Users can extend the framework, but not modify its code.
There are different types of software frameworks: conceptual, application, domain, platform, component, service, development, etc.[2]
[http://en.wikipedia.org/wiki/Software_framework]
Software frameworks typically contain considerable housekeeping and utility code in order to help bootstrap user applications, but generally focus on specific problem domains, such as:
Artistic drawing, music composition, and mechanical CAD[3][4]
Compilers for different programming languages and target machines.[5]
Financial modeling applications[6]
Earth system modeling applications[7]
Decision support systems[8]
Media playback and authoring
Web applications
Middleware
High performance scientific computing
[http://en.wikipedia.org/wiki/Software_framework] {2012-11-13}
name::
* McsEngl.cmrpgm.FREE@cptIt,
* McsEngl.conceptCore59.2,
* McsEngl.free-program@cptIt59.2,
* McsEngl.free-software@cptIt59.2,
=== _NOTES: "Open-source software", "Software Libre", "FLOSS" (Free/Libre/Open-Source Software), and "FOSS" (Free and Open-Source Software) are the most common alternative terms.[2] The most popular alternative has been "open-source software".[2]
[http://en.wikipedia.org/wiki/Alternative_terms_for_free_software]
_DESCRIPTION:
Free software is software that can be used, studied, and modified without restriction, and which can be copied and redistributed in modified or unmodified form either without restriction, or with restrictions only to ensure that further recipients can also do these things. To make these acts possible, the human readable form of the program (called the source code) must be made available. The source code can be placed in the public domain, accompanied by a software license saying that the copyright holder permits these acts (a free software licence), etc.
Alternative terms for free software have been coined in an attempt to make the use of "free" less ambiguous. The most common is "open-source software", which has since evolved to refer to a subtly different sense of freedom. Free software is also known as "software libre", "free, libre and open-source software" ("FLOSS"), and "free/open-source software" ("FOSS").
Free software is distinct from freeware; freeware is proprietary software made available free of charge. Everyone is free to sell copies of free software, to use it commercially, and to charge for distribution and modifications. Because anyone who has a copy may distribute the software at no cost, the software generally is available at no cost. Free software business models are usually based on adding value such as support, training, customisation, integration, or certification. At the same time, some business models which work with non-free software are not compatible with free software, such as those that depend on a user having no choice but to pay for a license in order to lawfully use a software product.
The free software movement was launched in 1983 to make these freedoms available to every computer user.[1] Software that does not provide these freedoms is referred to as proprietary software or non-free software.
[http://en.wikipedia.org/wiki/Free_software]
_SPECIFIC:
* open_source_program
name::
* McsEngl.FOSDEM@cptIt, {2012-12-15}
FOSDEM (Free and Open source Software Developers' European Meeting) is a non-commercial, volunteer organized European event centered around free and open source software development. It is aimed at developers and anyone interested in the free and open source software movement. It aims to enable developers to meet and to promote the awareness and use of free and open source software.
FOSDEM is held annually during the first weekend of February at the Universitι Libre de Bruxelles Solbosh campus, situated in the southeast of Brussels, Belgium and easily reachable by public transport from Brussels-Central railway station.
[http://en.wikipedia.org/wiki/FOSDEM]
_CREATED: {2012-12-15} {2012-05-18}
name::
* McsEngl.conceptIt59.11,
* McsEngl.conceptIt80,
* McsEngl.pgm.OPEN-SOURCE,
* McsEngl.open-source-program@cptIt80, {2012-05-18}
* McsEngl.prgOsr@cptIt80, {2012-05-18}
_GENERIC:
* pgm.free#cptItsoft59.2#
_ADDRESS.WPG:
* https://opengov.ellak.gr/2019/01/12/tesseris-mithi-gia-to-anikto-logismiko/,
* The Architecture of Open Source Applications: http://www.aosabook.org/en/index.html,
name::
* McsEngl.conceptIt59.3,
* McsEngl.freeware-program@cptIt59.3,
* McsEngl.free-closed-source-program@cptIt59.3,
* McsEngl.pgm.freeware,
_DESCRIPTION:
Freeware is copyrighted computer software which is made available for use free of charge, for an unlimited time. Authors of freeware often want to "give something to the community", but also want to retain control of any future development of the software.
Freeware is different from shareware, where the user is required to pay (e.g. after some trial period or for additional functionality). It should be noted that although free software is sometimes used as a synonym for freeware, it is not the same as free software.
[http://en.wikipedia.org/wiki/Freeware]
κάθε ΟΜΑΔΑ προγραμάτων που υπάρχει.
* pgm.abstracting
* pgm.animation
* pgm.antivirus##
* pgm.calculations
*
* pgm.chemistry#linkL#ql:program.chemistry rl4##
* pgm.communication
* pgm.database
* pgm.device_driver
*
===
* pgm.economy_related
* pgm.game#cptItsoft413#
* pgm.finance#
* pgm.free
*
*
* pgm.managing.organization
* pgm.managing.organization.production#cptItsoft279#
* pgm.math#cptItsoft952#
* pgm.
* pgm.network#
* pgm.networkNo
* pgm.neural_network#
* pgm.object_oriented
* pgm.
* pgm.OFFICE_AUTOMATION##
* pgm.open_source#
* pgm.operating_system
*
=== pgm.p
* pgm.package
* pgm.
* pgm.shareware#
* pgm.spreadsheet
* pgm.statistics#cptItsoft952.1#
* pgm.system#
* pgm.systemNo
* pgm.training
*
*
* pgm.utility
=== pgm.w:
* pgm.web#cptItsoft580#
* pgm.workflow#linkL#ql:program.workflow rl4##
name::
* McsEngl.conceptIt331,
* McsEngl.prgSys@cptIt331, {2011-09-10}
* McsEngl.program.system@cptIt331,
* McsEngl.system-program@cptIt331,
* McsEngl.system-software,
* McsEngl.pgmStm,
* McsElln.ΠΡΟΓΡΑΜΜΑ-ΣΥΣΤΗΜΑΤΟΣ@cptIt331,
ΠΡΟΓΡΑΜΜΑ ΣΥΣΤΗΜΑΤΟΣ είναι ΠΡΟΓΡΑΜΜΑ#cptIt59.1# που δεν κάνει καμμία δουλεία από την καθημερινή ζωή.
[hmnSngo.1995-03]
ΚΑΘΕ προγραμα#cptIt59.1# που κάνει την 444-2 λειτουργια, ήτοι ΔΕΝ κάνει μια δουλεια απο την καθημερινή ζωή.
_WHOLE:
ΚΑΘΕ πληροφοριακών-μηχανων-συστημα έχει προγραματα-συστηματος.
name::
* McsEngl.pgmStm'FUNCTION@cptIt,
Αυτή η γενική λειτουργία υποδιαιρείται σε μικρότερες. Βάσει αυτών ταξινομούμαι τα προγράμματος συστήματος.
name::
* McsEngl.pgmStm'HARDWARE-OF-COMPUTER-STRUCTURE@cptIt,
name::
* McsEngl.pgmStm'INTEGRATED-DEVELOPMENT-ENVIRONMENT@cptIt,
name::
* McsEngl.pgmStm.SPECIFIC@cptIt,
_SPECIFIC: pgmStm.Alphabetically:
* antivirus#cptItsoft567#
* APPLICATION_GENERATOR#cptIt10#
* CASE_TOOL#cptIt341#
* COMPILER#cptItsoft401#
* DEVICE_DRIVER#cptIt429#
* IDE#cptIt430#
* INTERPRETER#cptItsoft513#
* OPERATING-SYSTEM#cptItsoft434#
* TRANSLATOR#cptItsoft533#
* UTILITIES#cptIt425#
* VIRUS#cptIt281# & ANTIVIRUS
name::
* McsEngl.cmrpgm.generic.SYSTEM.NO@cptIt,
* McsEngl.conceptIt304,
* McsEngl.application'program@cptIt304,
* McsEngl.APPLICATION-program@cptIt,
* McsEngl.application-software@cptIt304, {2011-08-24}
* McsEngl.application-software@cptIt,
* McsEngl.desktop-application@cptIt304, {2011-08-29}
* McsEngl.prgApp@cptIt304,
* McsEngl.program.application@cptIt304,
* McsEngl.user's'program@cptIt, {2007-12-07}
* McsEngl.pgmStmN@cptIt304, {2013-09-20}
====== lagoGreek:
* McsElln.ΠΡΟΓΡΑΜΑ-ΕΦΑΡΜΟΓΩΝ@cptIt,
=== _OLD:
* McsEngl.application@old,
APPLICATION PROGRAM ονομάζω το προγραμα#cptIt59.1# που κανει την application/εφαρμογη function\λειτουργια(444-1)
APPRICATION SOFTWARE: software written to perform some type of real world task, such as word processing or accounting.
Application software, also known as an application or an "app", is computer software designed to help the user to perform specific tasks. Examples include enterprise software, accounting software, office suites, graphics software and media players. Many application programs deal principally with documents. Apps may be bundled with the computer and its system software, or may be published separately. Some users are satisfied with the bundled apps and need never install one.
Application software is contrasted with system software and middleware, which manage and integrate a computer's capabilities, but typically do not directly apply them in the performance of tasks that benefit the user. The system software serves the application, which in turn serves the user.
Similar relationships apply in other fields. For example, a shopping mall does not provide the merchandise a shopper is seeking, but provides space and services for retailers that serve the shopper. Rail tracks similarly support trains, allowing the trains to transport passengers.
Application software applies the power of a particular computing platform or system software to a particular purpose. Some apps such as Microsoft Office are available in versions for several different platforms; others have narrower requirements and are thus called, for example, a Geography application for Windows or an Android application for education or Linux gaming. Sometimes a new and popular application arises which only runs on one platform, increasing the desirability of that platform. This is called a killer application.
[http://en.wikipedia.org/wiki/Application_software]
_WHOLE:
* a program is PART OF a computer_system, after installation.
name::
* McsEngl.pgmStmN'ENVIRONMENT@cptIt,
name::
* McsEngl.pgmStmN'APPLICATION@cptIt,
* McsEngl.conceptIt304.2,
* McsEngl.application'of'application'program@cptIt304.2,
* McsEngl.electronic-document@cptIt,
* McsEngl.data-file@cptIt,
* McsEngl.digital-data@cptIt,
* McsElln.ΗΛΕΚΤΡΟΝΙΚΟ-ΝΤΟΚΟΥΜΕΝΤΟ@cptIt,
* McsElln.ΨΗΦΙΑΚΑ-ΔΕΔΟΜΕΝΑ@cptIt,
_DEFINITION:
With application-programs, computers INPUT and OUTPUT data. These are its applications.
[KasNik, 2007-12-05]
Εφαρμογές που έχουν γίνει με τη χρήση κάποιου προγράματος εφαρμογών.
ELECTRONIC DOCUMENT είναι <δεδομένα> που παρήχθηκαν με ένα πρόγραμμα εφαρμογών. Είναι το αντίθετο των ντοκουμέντων χαρτιού.
name::
* McsEngl.pgmStmN'ognCompany@cptIt,
Ποια εταιρία το έφτιαξε(maker), Ποια το πουλάει(vendor), Ποια είναι αντιπρόσωπος
name::
* McsEngl.pgmStmN'Doing ::this.part@cptIt,
+++application function#cptIt444-1#
Every program DENOTES a data-processing.
[KasNik, 2007-12-05]
Η λειτουργία-εφαρμογης ταξινομείται σε πολλες άλλες και ανάλογα ταξονομούνται τα προγραμματα.
name::
* McsEngl.pgmStmN'FILE@cptIt,
name::
* McsEngl.pgmStmN'measure@cptIt,
{time.1992 NUMBER OF PROGRAMS
WIN programs: 5000
MAC programs: 4000
[byte Nov 11, 1992]
name::
* McsEngl.app.specific@cptIt,
* McsEngl.cmrpgm.specific@cptIt,
* McsEngl.pgmCmr.specific@cptIt,
_SPECIFIC: app.Alphabetically:
* ANIMATION#cptIt230#
* AUDIO#cptIt247#
* CALCULATIONS#cptIt428#
* COMMUNICATION#cptIt373#
* desktop-app#cptItsoft304.3#
* DOCUMENT-MANAGEMENT#cptIt426#
* EDUCATION#cptIt411#
* ENTERTAINMENT#cptIt413#
* GRAPHICS#cptIt106#
* MISCELLANEOUS,
* OCR#cptIt336#
* ORGANIZATION-MANAGEMENT#cptIt427#
* PIM#cptIt342#
* PROJECT-MANAGEMENT#cptIt101#
* TRAINING#cptIt462#
* VIDEO#cptIt28#
* VIEWER#cptIt228#
* VIRTUAL-REALITY#cptIt343#
* web-application#cptItsoft580#
===
custome'software
packaged'software
BUNDLE'SOFTWARE#cptIt352#
AUDIO/VIDEO
BIBLIOGRAPHY
BUSINESS/ECONOMICS
DICTIONARIES
DIRECTORIES
EDUCATION
ENCYCLOPEDIAS
EROTICISM
GAMES/LEISURE
GEOGRAPHY
GRAPHICS
HEALTH
HISTORY
LANGUAGE
LAW
MUSIC
NEWS
PUBLIC DOMAIN (FREEWARE, SHAREWARE)
SCIENCE & TECHNOLOGY
AGRONOMY
SOFTWARE
SPORTS
TRAVEL/TOURISM
name::
* McsEngl.pgmStmN.SPECIFIC-DIVISION.KRM (if uses krl)@cptIt,
_SPECIFIC:
* program.systemNo.knowledge_representation#cptItsoft497#
* program.systemNo.NON_KRP
name::
* McsEngl.pgmStmN.SPECIFIC-DIVISION.FUNCTION@cptIt,
_SPECIFIC:
* program.systemNo.ANIMATION#cptIt230#
* program.systemNo.AUDIO#cptIt247#
* program.systemNo.CALCULATIONS#cptIt428#
* program.systemNo.COMMUNICATION#cptIt373#
* program.systemNo.document_managing#cptIt426#
* program.systemNo.EDUCATION#cptIt411#
* program.systemNo.ENTERTAINMENT#cptIt413#
* program.systemNo.GRAPHICS#cptIt106#
* program.systemNo.OCR#cptIt336#
* program.systemNo.organization_managing#cptItsoft427#
* program.systemNo.PIM#cptIt342#
* program.systemNo.project_managing#cptIt101#
* program.systemNo.TRAINING#cptIt462#
* program.systemNo.video_managing#cptIt28#
* program.systemNo.VIEWER#cptIt228#
* program.systemNo.virtual_reality#cptIt343#
name::
* McsEngl.app.OPERATING-SYSTEM@cptIt,
_SPECIFIC:
* program.systemNo.DOS
* program.systemNo.UNIX,
* program.systemNo.WINDOWS,
name::
* McsEngl.pgmStmN.DESKTOP@cptIt,
* McsEngl.conceptIt304.3,
* McsEngl.desktop-program@cptIt304.3, {2011-09-06}
* McsEngl.prgDsk@cptIt304.3, {2011-09-06}
* McsEngl.programDesktop@cptIt304.3, {2011-09-06}
name::
* McsEngl.cmrpgm.GENERIC.NO@cptIt,
* McsEngl.conceptIt4,
* McsEngl.pgmCmr.individual@cptIt,
* McsEngl.concrete-program@cptIt,
* McsEngl.concrete'program@cptIt4,
* McsEngl.program.concrete@cptIt4,
* McsEngl.program.individual@cptIt4,
* McsEngl.program.instance@cptIt4, {2012-05-17}
_DESCRIPTION:
CONCRETE PROGRAM is a PROGRAM#cptIt59.1# that is concete#cptCore381.1#.
Αυστηρά με τον ορισμό, ΚΑΘΕ έκδοση ενός προγράμματος είναι 'συγκεκριμένο πρόγραμμα'. Για λόγους όμως χρησιμότητας ΔΕΝ ονομάζω τις διάφορες εκδόσεις. Ολες τις ονομάζω ΕΝΑ συγκεκριμένο πρόγραμμα.
[NIKOS, 1997apr]
name::
* McsEngl.cmrpgm.MACHINE@cptIt,
* McsEngl.conceptIt59.9,
* McsEngl.binary-code@cptIt,
* McsEngl.executable-program@cptIt,
* McsEngl.machine-code@cptIt,
* McsEngl.machine-program@cptIt, {2007-12-29}
* McsEngl.object-program@cptIt, {2007-12-28}
* McsEngl.object-code@cptIt,
====== lagoGreek:
* McsElln.ΑΝΤΙΚΕΙΜΕΝΟ-ΠΡΟΓΡΑΜΜΑ@cptIt,
_DEFINITION:
A program is a sequence of instructions that are executed by a CPU. While simple processors execute instructions one after the other, superscalar processors are capable of executing several instructions at once.
Program flow may be influenced by special 'jump' instructions that transfer execution to an instruction other than the following one. Conditional jumps are taken (execution continues at another address) or not (execution continues at the next instruction) depending on some condition.
[http://en.wikipedia.org/wiki/Machine_instruction]
When a piece of computer hardware can interpret a programming language directly, that language is called machine code.
[http://en.wikipedia.org/wiki/Programming_language_implementation]
OBJECT-CODE is the BIT-FORM of a program that a machine understands.
[hmnSngo.2002-04-24]
OBJECT CODE
is a program readable by a processor, bit format.
[NIKOS, 1997jan]
WHOLE:
* PROGRAM#ql:[Level CONCEPT:rl? conceptIt59]##cptIt59#
name::
* McsEngl.cmrpgm.MICROPROGRAM@cptIt,
* McsEngl.microcode@cptIt, {2007-12-29}
* McsEngl.microprogram@cptIt,
_DEFINITION:
A microprogram, or a microcode, is a rudimentary, lowest-level program that implements a CPU machine instruction. In a CPU using microcode, a single machine instruction is implemented by executing a series of microinstructions (a microprogram), similary to how an interpreter executes a high-level language statement using a series of machine instructions. Both microcode and microprogram also refer to a complete set of microinstruction-sequences for all machine code instructions a particular processor implements.
The microcode is written by the CPU engineer during the design phase. It is generally not meant to be visible or changeable by a normal programmer, not even an assembly programmer. This is because microcode itself can (by design) be dramatically changed with a new hardware generation, while machine code usually retains backwards compatibility. Microcode can also allow one computer microarchitecture to emulate another, usually more complex, architecture.
Confusingly, some hardware vendors, especially IBM, use microcode as a synonym for firmware, whether or not it actually implements the microprogramming of a processor.[1] Even simple firmware, such as the one used in a hard drive, is sometimes described as microcode.[2] Such use is not discussed here. The term microprogram does not involve this ambiguity.
[http://en.wikipedia.org/wiki/Microprogram]
name::
* McsEngl.cmrpgm.MOBILE@cptIt,
* McsEngl.pgmMobile@cptIt,
* McsEngl.pgmMbl@cptIt,
name::
* McsEngl.pgmMbl.WhatsApp-Messenger@cptIt,
* McsEngl.pgmWhatsApp@cptIt,
_DESCRIPTION:
WhatsApp Messenger is a cross-platform mobile messaging app which allows you to exchange messages without having to pay for SMS. WhatsApp Messenger is available for iPhone, BlackBerry, Windows Phone, Android and Nokia.
[https://www.whatsapp.com/security/?l=en]
===
Messages between WhatsApp users are protected with an endto-end
encryption protocol so that third parties and WhatsApp
cannot read them and so that the messages can only be decrypted
by the recipient. All types of WhatsApp messages (including
chats, group chats, images, videos, voice messages and files)
and WhatsApp calls are protected by end-to-end encryption.
WhatsApp servers do not have access to the private keys of
WhatsApp users, and WhatsApp users have the option to verify
keys in order to ensure the integrity of their communication.
The Signal Protocol library used by WhatsApp is Open Source, available
here: https://github.com/whispersystems/libsignal-protocol-java/
[file:///C:/Users/synagonism/Downloads/WhatsApp-Security-Whitepaper.pdf]
name::
* McsEngl.cmrpgm.PASSWORD-RECOVERING@cptIt,
* McsEngl.password-cracker@cptIt,
_DESCRIPTION:
ophcrack: Ophcrack is a Windows password cracker based on a time-memory trade-off using rainbow tables. This is a new variant of Hellman's original trade-off, with better performance. It recovers 99.9% of alphanumeric passwords in seconds.
[sf.net]
name::
* McsEngl.cmrpgm.CONCURRENT@cptIt,
* McsEngl.concurrent-program@cptIt,
_DESCRIPTION:
Concurrent computing is a form of computing in which programs are designed as collections of interacting computational processes that may be executed in parallel.[1] Concurrent programs (processes or threads) can be executed on a single processor by interleaving the execution steps of each in a time-slicing way, or can be executed in parallel by assigning each computational process to one of a set of processors that may be close or distributed across a network. The main challenges in designing concurrent programs are ensuring the correct sequencing of the interactions or communications between different computational executions, and coordinating access to resources that are shared among executions.[1] A number of different methods can be used to implement concurrent programs, such as implementing each computational execution as an operating system process, or implementing the computational processes as a set of threads within a single operating system process.
Pioneers in the field of concurrent computing include Edsger Dijkstra, Per Brinch Hansen, and C.A.R. Hoare.
[http://en.wikipedia.org/wiki/Concurrent_programming]
name::
* McsEngl.cmrpgm.os.MOBILE (pml)@cptIt,
* McsEngl.pgm.mobile@cptIt,
* McsEngl.mobile-application@cptIt,
* McsEngl.pml@cptIt,
* McsEngl.pgmMbl@cptIt,
name::
* McsEngl.pml'NativeScript@cptIt,
* McsEngl.NativeScript@cptIt,
_DESCRIPTION:
NativeScript is how you build cross-platform, native iOS and Android apps without web views. Use Angular, TypeScript or modern JavaScript to get truly native UI and performance while sharing skills and code with the web. Get 100% access to native APIs via JavaScript and reuse of packages from npm, CocoaPods and Gradle. Open source and backed by Progress.
[http://docs.nativescript.org/start/introduction]
name::
* McsEngl.pml'Resource@cptIt,
_ADDRESS.WPG:
* http://www.telerik.com/nativescript, Try NativeScript for Elegant, Cross-Platform, Native Mobile Apps
Get native UI and performance for iOS and Android from a single code base.
Leverage popular web skills - JavaScript, Angular and CSS.
Free and open source, now and forever.
name::
* McsEngl.cmrpgm.PORTABLE@cptIt,
* McsEngl.pgm.portable@cptIt,
* McsEngl.portable-application@cptIt,
_DESCRIPTION:
A portable application (portable app), sometimes also called standalone, is a program designed to run on a compatible computer without being installed in a way that modifies the computer's configuration information. This type of application can be stored on any storage device, including internal mass storage and external storage such as USB drives and floppy disks – storing its program files and any configuration information and data on the storage medium alone. If no configuration information is required a portable program can be run from read-only storage such as CD-ROMs and DVD-ROMs. Some applications are available in both installable and portable versions.
Like any application, portable applications must be compatible with the computer system hardware and operating system.
Depending on the operating system, portability is more or less complex to implement; to operating systems such as AmigaOS, all applications are by definition portable. Portable apps are distinct from software portability, source code written to be compilable into different executable programs for different computing platforms.
[http://en.wikipedia.org/wiki/Portable_application]
name::
* McsEngl.cmrpgm.measure@cptIt,
Πόσοι αγόρασαν το πρόγραμμα. Δυνητικοί αγοραστές.
{time.1992 QUANTITY:
WIN programs: 5000
MAC programs: 4000
[byte Nov 11, 1992]
Η ποσότητα των ΑΝΤΙΓΡΑΦΩΝ των συγκεκριμενων προγραμάτων, όπως τα ορισα παραπάνω είναι η Αγορά του προγράμματος (κανονική και παράνομη).
Αν έχω και εγώ αντιγραφο, θα δινω ΤΙΜΗ στη ΜΕΤΑΒΛΗΤΗ αυτη το αποθηκευτικο μέσο στο οποιο έχω το αντίγραφο.
Πειρατεία προγραμάτων είναι η ποσότητα των προγραμμάτων που δεν αγοράζονται απο την κατασκευαστική εταιρεία.
name::
* McsEngl.cmrpgm.SEARCHING@cptIt,
* McsEngl.searching-program@cptIt, {2012-11-25}
name::
* McsEngl.approximate-string-matching@cptIt, {2012-11-25}
* McsEngl.approximate-string-searching@cptIt, {2012-11-25}
* McsEngl.fuzzy-string-searching@cptIt, {2012-11-25}
In computer science, approximate string matching (often colloquially referred to as fuzzy string searching) is the technique of finding strings that match a pattern approximately (rather than exactly). The problem of approximate string matching is typically divided into two sub-problems: finding approximate substring matches inside a given string and finding dictionary strings that match the pattern approximately.
[http://en.wikipedia.org/wiki/Fuzzy_string_searching]
name::
* McsEngl.cmrpgm.SHAREWARE@cptIt,
* McsEngl.conceptIt332,
* McsEngl.program-SHAREWARE@cptIt,
* McsEngl.program.shareware@cptIt332,
* McsEngl.shareware'software@cptIt332,
* McsEngl.shareware'program@cptIt332,
Shareware is a marketing method for computer software. Shareware software is typically obtained free of charge, often by downloading from the Internet or on magazine cover-disks. A user tries out the program, and thus shareware has also been known as "try before you buy". A shareware program is accompanied by a request for payment, and the software's distribution license often requires such a payment.
[http://en.wikipedia.org/wiki/Shareware]
name::
* McsEngl.cmrpgm.SOURCE@cptIt,
* McsEngl.conceptIt59.7,
* McsEngl.human-program@cptIt, {2007-12-29}
* McsEngl.source-program@cptIt,
* McsEngl.source-code@cptIt,
====== lagoGreek:
* McsElln.ΠΗΓΑΙΟ-ΠΡΟΓΡΑΜΜΑ@cptIt,
* McsElln.ΠΗΓΑΙΟΣ-ΚΩΔΙΚΑΣ@cptIt,
_DEFINITION:
OBJECT-CODE is the SYMBOL-FORM of a program that a PROGRAMER understands.
[hmnSngo.2002-04-24]
SOURCE CODE
is a PROGRAM written in a form readable by a programmer.
[NIKOS, 1997jan]
name::
* McsEngl.cmrpgm.SOURCE.CLOSED@cptIt,
* McsEngl.closed-source-program@cptIt,
name::
* McsEngl.cmrpgm.SOURCE.OPEN@cptIt,
* McsEngl.open-source-program@cptIt,
_DESCRIPTION:
An open-source program can be free or commercial.
[hmnSngo.2013-09-03]
name::
* McsEngl.cmrpgm.SURVEY@cptIt,
* McsEngl.pgm.survey@cptIt,
* McsEngl.program.survey@cptIt,
* McsEngl.survey-program@cptIt,
name::
* McsEngl.cmrpgm.WEBNO@cptIt,
* McsEngl.pgmWebNo@cptIt,
* McsEngl.desktop-application@cptIt,
_DESCRIPTION:
A web application or "web app" is a software program that runs on a web server. Unlike traditional desktop applications, which are launched by your operating system, web apps must be accessed through a web browser.
Web apps have several advantages over desktop applications. Since they run inside web browsers, developers do not need to develop web apps for multiple platforms. For example, a single application that runs in Chrome will work on both Windows and OS X. Developers do not need to distribute software updates to users when the web app is updated. By updating the application on the server, all users have access to the updated version.
From a user standpoint, a web app may provide a more consistent user interface across multiple platforms because the appearance is dependent on the browser rather than the operating system. Additionally, the data you enter into a web app is processed and saved remotely. This allows you to access the same data from multiple devices, rather than transferring files between computer systems.
While web applications offer several benefits, they do have some disadvantages compared to desktop applications. Since they do not run directly from the operating system, they have limited access to system resources, such as the CPU, memory, and the file system. Therefore, high-end programs, such as video production and other media apps generally perform better as desktop applications. Web apps are also entirely dependent on the web browser. If your browser crashes, for example, you may lose your unsaved progress. Also, browser updates may cause incompatibilities with web apps, creating unexpected issues.
Some people prefer desktop apps, while others prefer web applications. Therefore, many software companies now offer both desktop and web versions of their most popular programs. Common examples include Microsoft Office, Apple iWork, and Intuit TurboTax. In most cases, files saved in the online version are compatible with the desktop version and vice versa. For example, if you save a .TAX2013 file in TurboTax Online, you can open and edit the file with the desktop version.
[http://techterms.com/definition/web_application]
name::
* McsEngl.cmrpgm.WORKFLOW@cptIt,
* McsEngl.workflow-computer-program@cptIt,
_DESCRIPTION:
A workflow application is a software application which automates, at least to some degree, a process or processes. The processes are usually business-related, but it may be any process that requires a series of steps that can be automated via software. Some steps of the process may require human intervention, such as an approval or the development of custom text, but functions that can be automated should be handled by the application. Advanced applications allow users to introduce new components into the operation.
For example, consider a purchase order that moves through various departments for authorization and eventual purchase. The order may be moved from department to department for approval automatically. When all authorizations are obtained, the requester of the purchase order is notified and given the authorization. A workflow process may involve constant change and update. For example, the normal approver of purchase orders may be on vacation, in which case, the application will request approval from alternate approvers.
[http://en.wikipedia.org/wiki/Workflow_application] {2012-11-13}
name::
* McsEngl.cmrpgm.EVOLUTING@cptIt,
* McsEngl.computer-program-life-cycle@cptIt, {2014-01-19}
* McsEngl.pgm'developing@cptIt,
* McsEngl.pgm'evoluting@cptIt,
* McsEngl.pgm'creating@cptIt49.10, {2012-05-20}
* McsEngl.cmrpgm'evoluting@cptIt,
* McsEngl.cmrpgm-life-cycle@cptIt, {2014-01-19}
* McsEngl.program.evoluting@cptIt,
* McsEngl.SDLC@cptIt, {2014-01-19}
* McsEngl.software-development-process@cptIt59.10, {2012-05-20}
* McsEngl.software-development-life-cycle@cptIt, {2014-01-19}
* McsEngl.pgmevg@cptIt,
* McsEngl.prgevlng@cptIt, {2012-11-24}
_DESCRIPTION:
A software development process, also known as a software development life cycle (SDLC), is a structure imposed on the development of a software product. Similar terms include software life cycle and software process. It is often considered a subset of systems development life cycle. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. Some people consider a life-cycle model a more general term and a software development process a more specific term. For example, there are many specific software development processes that 'fit' the spiral life-cycle model. ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the standard that defines all the tasks required for developing and maintaining software.
[http://en.wikipedia.org/wiki/Software_development_process]
{time.2001-01-15 WIKIPEDIA
Wikipedia was formally launched on 2001-01-15, as a single English-language edition at http://www.wikipedia.com/
[http://en.wikipedia.org/wiki/Wikipedia] 2007-11-29
{time.1995-03-25 first Wiki:
The WikiWikiWeb, also known as Ward's Wiki, WikiWiki or Wiki (with a capital 'W'), is the first implementation of a wiki. Written in Perl, it accompanies the Portland Pattern Repository (PPR) on c2.com and is located at c2.com/cgi/wiki. It contains various topics and discussions about software engineering. The term wiki that is used to refer to other similar groups of modifiable Web pages, e.g. Wikipedia, came from this original wiki.
In order to make the exchange of ideas between programmers easier, Ward Cunningham started developing the WikiWikiWeb in 1994 based on the ideas developed in HyperCard stacks that he built in the late 1980s.[1][2][3] He installed the WikiWikiWeb on his company Cunningham & Cunningham's website c2.com on 1995-03-25. Cunningham named WikiWikiWeb that way because he remembered a Honolulu International Airport counter employee telling him to take the so-called "Wiki Wiki" Chance RT-52 shuttle bus line that runs between the airport's terminals. "Wiki Wiki" is a reduplication of "wiki", a Hawaiian-language word for fast. Cunningham's idea was to make WikiWikiWeb's pages quickly editable by its users, so he initially thought about calling it "QuickWeb", but later changed his mind and dubbed it "WikiWikiWeb".
[http://en.wikipedia.org/wiki/WikiWikiWeb]
{time.1993 MOSAIC:
However, the explosion in popularity of the Web was triggered by NCSA Mosaic which was a graphical browser running originally on Unix but soon ported to the Apple Macintosh and Microsoft Windows platforms. Version 1.0 was released in September 1993, and was dubbed the killer application of the Internet. Marc Andreessen, who was the leader of the Mosaic team at NCSA, quit to form a company that would later be known as Netscape Communications Corporation. Netscape released its flagship Navigator product in October 1994, and it took off the next year.
[http://en.wikipedia.org/wiki/Web_browser] 2007-11-29
{time.1992 ΕΛΛΑΔΑ, ΕΟΚ.
ΣΤΟ HARDWARE ΤΑ ΠΟΣΟΣΤΑ ΣΕ ΣΥΝΟΛΟ ΑΓΟΡΑΣ ΕΙΝΑΙ 67% ΕΛΛΑΔΑ, 47% ΕΟΚ.
ΣΤΙΣ ΥΠΗΡΕΣΙΕΣ 9% " 27% "
ΣΤΟ SOFTWARE 17% " 15% "
ΥΠΟΣΤΗΡΙΞΗ HARDWARE 7% " 11% "
ΕΚΤΙΜΗΣΗ ΕΙΝΑΙ ΟΤΙ ΤΑ ΕΠΟΜΕΝΑ ΧΡΟΝΙΑ ΘΑ ΕΠΕΛΘΕΙ ΑΥΞΗΣΗ ΤΩΝ ΔΑΠΑΝΩΝ ΣΤΟΥΣ ΤΟΜΕΙΣ SOFTWARE, SERVICES ΓΙΑ ΤΗΝ ΕΛΛΑΔΑ.
ΠΟΣΟΣΤΟ ΔΑΠΑΝΩΝ ΠΛΗΡΟΦΟΡΙΚΗΣ 0,79% ΕΛΛΑΔΑ, ΕΟΚ *2%, ΙΣΠΑΝΙΑ, ΠΟΡΤΟΓΑΛΙΑ *1,5%
ΕΙΝΑΙ ΞΕΚΑΘΑΡΟ ΟΤΙ Η ΕΛΛΗΝΙΚΗ ΑΓΟΡΑ ΕΧΕΙ ΑΚΟΜΑ ΜΕΓΑΛΑ ΠΕΡΙΘΩΡΙΑ ΑΝΑΠΤΥΞΗΣ.
[COMPUTER GO, JUN 1993, 75]
{time.1991-1992 ΠΡΟΓΡΑΜΜΑΤΑ ΠΟΥ ΠΟΥΛΗΘΗΚΑΝ:
WINDOWS: 848 EK. 2,9 ΔΙΣ ΔΟΛΑΡΙΑ
DOS: 4247,1 ΕΚ. 3756,7 ΕΚ. ΔΟΛΑΡΙΑ
MAC: 607,8 EK. 932,2 EK. ΔΟΛΑΡΙΑ
OS/2: 67,9 EK. 72,1 ΕΚ. ΔΟΛΑΡΙΑ
ΣΥΜΦΩΝΑ ΜΕ ΣΤΟΙΧΕΙΑ ΤΗΣ DATAQUEST
[COMPUTER ΓΟ, ΜΑΡΤ 1993, 51]
{time.1990-1992 ΕΛΛΑΔΑ:
Η ΑΓΟΡΑ ΛΟΓΙΣΜΙΚΟΥ ΕΙΧΕ ΤΑ ΕΞΗΣ ΜΕΓΕΘΗ.
1990 6,326 ΔΙΣ ΔΡΧ 772,2 ΕΚ ΕΙΣΑΓΟΜΕΝΑ 61,2 ΕΚ ΕΞΑΓΟΜΕΝΑ
1991 10,71 ΔΙΣ ΔΡΧ, ΑΥΞ 24,1% 3.715 ΕΚ ΕΙΣΑΓΟΜΕΝΑ 250,1 ΕΚ ΕΞΑΓΟΜΕΝΑ
1992 14 ΔΙΣ ΔΡΧ, ΑΥΞ 30% (ΠΑΚΕΤΑ 60%, ΑΥΞΗΣΗ 27%)
[COMPUTER GO, JUN 1993, 75]
1987 2,6 ΔΙΣ ΔΡΧ
1988 3,5 ΔΙΣ ΔΡΧ
1989 5 ΔΙΣ ΔΡΧ
[ΒΗΜΑ, 22 ΙΟΥΛ 1990, Δ13]
{time.1989 WWW:
The World Wide Web (commonly shortened to the Web) is a system of interlinked, hypertext documents accessed via the Internet. With a web browser, a user views web pages that may contain text, images, videos, and other multimedia and navigates between them using hyperlinks. The World Wide Web was created in 1989 by Sir Tim Berners-Lee, working at CERN in Geneva, Switzerland.
[http://en.wikipedia.org/wiki/WWW] 2007-11-29
{time.1983
Microsoft Word is Microsoft's flagship word processing software. It was first released in 1983 under the name Multi-Tool Word for Xenix systems.[1] Versions were later written for several other platforms including IBM PCs running DOS (1983), the Apple Macintosh (1984), SCO UNIX, OS/2 and Microsoft Windows (1989).
[http://en.wikipedia.org/wiki/Microsoft_Word] 2007-11-29
{time.1981
KMS,an abbreviation of Knowledge Management System, was a commercial second generation hypermedia system, originally created as a successor for the early hypermedia system ZOG. KMS was developed by Knowledge Systems, a 1981 spinoff from the Computer Science Department of Carnegie-Mellon University.
The purpose of KMS was to let many users collaborate in creating and sharing information, and from the very beginning, the system was designed as a true multi-user system.
[http://en.wikipedia.org/wiki/KMS_%28Hypertext%29]
{time.1979 SPREADSHEET:
VisiCalc. ΤΟ ΠΡΩΤΟ "ΗΛΕΚΤΡΟΝΙΚΟ ΛΟΓΙΣΤΙΚΟ ΦΥΛΛΟ" ΓΙΑ ΠΡΟΣΩΠΙΚΟΥΣ ΚΟΜΠΙΟΥΤΕΡ.
[COMPUTER ΓΟ, ΜΑΡΤ 1993, 18]
{time.1975 OPERATING SYSTEM:
Το πρώτο πλατιάς χρήσης λειτουργικό σύστημα βασισμένο σε δίσκους.
[JARRET, 1987, 80#cptResource117]
{time.1967 HYPERTEXT EDITING SYSTEM:
It was the world's first working hypertext system. It ran in a 128K memory partition on a small IBM/360 mainframe and was funded by an IBM research contract... at Brown University ... under the leadership of Andries van Dam.
[Nielsen, 1990, 35#cptResource712]
{time.1960s DATABASE:
The first database management systems were developed in the 1960s.
[http://en.wikipedia.org/wiki/Database]
{time.1957 General_Problem_Solver:
General Problem Solver (GPS) was a computer program created in 1957 by Herbert Simon and Allen Newell to build a universal problem solver machine. Any formalized symbolic problem can be solved, in principle, by GPS. For instance: theorems proof, geometric problems and chess playing. It was based on Simon and Newell's theoretical work on logic machines. GPS was the first computer program which separated its knowledge of problems from its strategy of how to solve problems. It was implemented in the low-level IPL programming language.
While GPS solved simple problems such as the Towers of Hanoi that could be sufficiently formalized, it could not solve any real-world problems.
The user defined objects and operations that could be done on the objects and GPS generated heuristics by Means-ends analysis in order to solve problems. It focused on the available operations, finding what inputs were acceptable and what outputs were generated. It then created subgoals to get closer and closer to the goal.
The GPS paradigm eventually evolved into Soar.
[http://en.wikipedia.org/wiki/General_Problem_Solver]
name::
* McsEngl.pcrevg'stage@cptIt,
* McsEngl.program-evolution@cptIt,
Traditionally the phases of software development are called
- analysis,
- design,
- testing and
- implementation.
[Javelin, 1997]
name::
* McsEngl.pcrevg'stage.ANALYTIC-PHASE@cptIt,
* McsEngl.pgm'analytic-phase@cptIt,
_DESCRIPTION:
At some stage in the process of developing any program you must analyse what "things" your program has to represent. These things might be shapes, people, employees, accounts etc., If you're a good programmer you will tackle this analysis phase early. Many people write bad software because they try to avoid doing any thorough analysis and try to jump straight to the coding stage. This trap often catches many first time programmers so if you are new to programming you should take heed of this warning.
[Javelin, 1997]
name::
* McsEngl.pcrevg'stage.CREATING@cptIt,
* McsEngl.conceptIt59.10,
name::
* McsEngl.pcrevg'stage.LOAD-TIME@cptIt,
* McsEngl.load-time-of-program@cptIt,
* McsEngl.pgm'load-time@cptIt,
_DESCRIPTION:
In computing, a loader is the part of an operating system that is responsible for loading programs. It is one of the essential stages in the process of starting a program, as it places programs into memory and prepares them for execution. Loading a program involves reading the contents of the executable file containing the program instructions into memory, and then carrying out other required preparatory tasks to prepare the executable for running. Once loading is complete, the operating system starts the program by passing control to the loaded program code.
All operating systems that support program loading have loaders, apart from systems where code executes directly from ROM or in the case of highly specialized computer systems that only have a fixed set of specialized programs.
In many operating systems the loader is permanently resident in memory, although some operating systems that support virtual memory may allow the loader to be located in a region of memory that is pageable.
In the case of operating systems that support virtual memory, the loader may not actually copy the contents of executable files into memory, but rather may simply declare to the virtual memory subsystem that there is a mapping between a region of memory allocated to contain the running program's code and the contents of the associated executable file. (See memory-mapped file.) The virtual memory subsystem is then made aware that pages with that region of memory need to be filled on demand if and when program execution actually hits those areas of unfilled memory. This may mean parts of a program's code are not actually copied into memory until they are actually used, and unused code may never be loaded into memory at all.
[http://en.wikipedia.org/wiki/Load_time]
name::
* McsEngl.pcrevg'stage.RUN-TIME@cptIt,
* McsEngl.execution-time-of-program@cptIt,
* McsEngl.pgm'runtime-phase@cptIt,
* McsEngl.pgm'runtime-process@cptIt,
* McsEngl.pgmevg'stage.RELEASE@cptIt,
* McsEngl.runtime-phase@cptIt59i,
* McsEngl.runtime-program-lifcycle-phase@cptIt,
_DESCRIPTION:
In computer science, run time, run-time, runtime, or execution time is the time during which a program is running (executing), in contrast to other phases of a program's lifecycle such as compile time, link time, load time, etc.
A run-time error is detected after or during the execution of a program, whereas a compile-time error is detected by the compiler before the program is ever executed. Type checking, storage allocation, code generation, and code optimization are typically done at compile time, but may be done at run time depending on the particular language and compiler.
[http://en.wikipedia.org/wiki/Run_time_(program_lifecycle_phase)]
name::
* McsEngl.pcrevg'stage.VERSION@cptIt,
* McsEngl.conceptIt471,
* McsEngl.pgm'release@cptIt,
* McsEngl.pgm'version@cptIt,
* McsEngl.program'version@cptIt,
* McsEngl.version@cptIt471,
* McsEngl.version-of-a-program@cptIt,
* McsEngl.pgmvrn@cptIt, {2013-07-31}
====== lagoGreek:
* McsElln.ΕΚΔΟΣΗ-ΠΡΟΓΡΑΜΑΤΟΣ@cptIt,
Program's Version is a STAGE in program's development. As a human-being is the same entity in his life-cycle, the same I consider the program, one entity with different versions. Revolutionary versions create new qualities, new programs.
[nikkas {2000-04-13}]
ΕΚΔΟΣΗ ΠΡΟΓΡΑΜΑΤΟΣ είναι μετατροπες του προγράμματος που ΔΕΝ αλλοιώνουν τη βασική λειτουργία του προγράματος.
[ΝΙΚΟΣ, ΝΟΕΜ. 1994]
name::
* McsEngl.pcrvrn.BUG-FIX-RELEASE@cptIt,
beta-version:
> When Microsoft release Windows 7, they don't take a daily build and burn it on a DVD, they make beta 1, beta 2, beta X, then some RC, then a final release, that's what pre release are made for. And beta versions are not the same thing as daily build too
>+1 to that. Also - beta usually means (for desktop applications): we won't add more features.
[jEditDev]
name::
* McsEngl.pcrvrn.DATE-BASED-RELEASE@cptIt,
Personally, I like Marcelo's suggestion of a date-based release. I think quarterly releases might be doable, but certainly semi-annual releases should be achievable. Maybe like what Ubuntu does -- release in April and October, year in, year out. A month or so before release, create the branch, release a release candidate from the branch, fix whatever bugs are found on the branch (and merge those back to trunk), and release it on time.
[jEdit danson@grafidog.com]
name::
* McsEngl.pcrvrn.FEATURE-RELEASE@cptIt,
* McsEngl.Major-Feature-Release@cptIt,
name::
* McsEngl.pcrvrn.LTS@cptIt,
* McsEngl.pgm'LTS@cptIt,
LTS is an abbreviation for “Long Term Support”.
We produce a new Ubuntu Desktop and Ubuntu Server release every six months [diagram below]. That means you'll always have the latest and greatest applications that the open source world has to offer. Ubuntu is designed with security in mind. You get free security updates for at least 18 months on the desktop and server.
A new LTS version is released every 2 years. In previous releases, a Long Term Support (LTS) version had 3 years support on Ubuntu (Desktop) and 5 years on Ubuntu Server. Starting with Ubuntu 12.04 LTS, both versions will receive 5 years support. There is no extra fee for the LTS version; we make our very best work available to everyone on the same free terms. Upgrades to new versions of Ubuntu are and always will be free of charge.
[https://wiki.ubuntu.com/LTS]
name::
* McsEngl.pcrvrn.NUMBERING-SCHEMA@cptIt,
MajorNewFeatures.SecNewFeatures.BugFixes:
4.0.pre|alpa|beta|0|1|..
4.1.pre|alpa|beta|0|1|..
4.2.pre|alpa|beta|0|1|..
....
5.0.pre|alpa|beta|0|1|..
daily???
name::
* McsEngl.pcrvrn.SEMANTIC-VERSIONING (Braking.Feature.Fix)@cptIt,
* McsEngl.semver@cptIt,
* McsEngl.semantic-versioning@cptIt,
_DESCRIPTION:
Semantic Versioning 2.0.0
Summary
Given a version number MAJOR.MINOR.PATCH, increment the:
1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
[http://semver.org/]
===
A simple mnemonic for remembering this scheme is as follows:
breaking.feature.fix
[https://electron.atom.io/docs/tutorial/electron-versioning/]
name::
* McsEngl.pcrvrn.YEAR.MONTH.DAY-FEATUREMAJOR.FEATUREMINOR.BUG@cptIt,
_Notation:
* year.month.day-major.minor.patch, 2011-12-21
* 2011-12-21-0.0.9 (alpha),
* 2011-12-21-0.1.9 (beta),
* 2011-12-21-1.0.0,
Major.Minor.Release
1.18 = Major: 1, Minor: 18, (alpha|beta|etc.)
[ Trevor Parscal <tparscal@wikimedia.org> ]
_NOTATION:
* version.Yyyy.Mm.Dd.Major.Minor feature|bug release.
[hmnSngo.2013-07-02]
name::
* McsEngl.pcrevg'time-managing@cptIt,
February 16, 2016
From nczonline.net, with love.
View this email in your browser
Hi everyone,
If you were to ask me what soft skill should software engineers focus on before all others, my answer would be time management. I've seen so many good developers struggle at various points in their career through nothing more than time mismanagement. Time is the one non-renewable resource we all share, so managing it properly is key to not just professional success, but also personal success.
To start, most software estimates are wrong, and typically very wrong. We tend to assume the best case scenario (no interruptions, no requirement changes, etc.), underestimate the complexity, underestimate the amount of work, and overestimate our abilities. This can frequently lead to a time crunch, and therefore, a lot of stress. We all do this, which is why it helps to remind yourself to overcorrect your estimates. In general, people are happy when things come in early and angry when they come in late. How do you become better at estimates?
The truth is you will never become better estimates, and once you accept that, you can adjust accordingly. Estimate as you would normally and then multiply that number by two. For short tasks (a day or two), that gives you a pretty good estimate. For anything four days or longer, it's a good idea to round up to the nearest week; anything two months or longer, round up to the nearest month. Note that you haven't really become better at your estimate by doing this, you're just correcting for the fact that your initial estimate was wrong. In all likelihood, this adjusted estimate is also wrong, but hopefully it's closer to reality.
The other area where developers struggle is deciding what they work on each day. I've seen people get distracted by side projects, playing foosball, or other things besides what they should be getting done. Don't get me wrong, I'm a big believer in taking some time away from work during the day to refresh, but not at the expense of your actual tasks. I once worked with someone who didn't get any of their tasks done in a given week because they were too busy helping other people with their problems. While very nice, that sort of behavior isn't a good long-term strategy.
The solution? Every day, put two things on your "to do" list that you must absolutely get done. Make each small enough that there's a good chance you will get them done (break larger tasks into a series of smaller ones), and prioritize them so you know what to work on first. If you finish both, then the rest of the day you are free to do whatever you want. Or, you can take a break after you finish one and know that you're halfway to your goal. This is an approach I take whether I'm at work or away: two things I want to accomplish that day.
Effective time management isn't hard, it just takes some practice. Keep practicing!
Be well.
-N
name::
* McsEngl.conceptIt350,
* McsEngl.Cmrpgm.NETWORK@cptIt,
* McsEngl.FvMcs.Cmrpgm.NETWORK@cptIt,
* McsEngl.network-program@cptIt350,
* McsEngl.prgNet@cptIt350,
* McsEngl.program.network@cptIt350,
* McsEngl.pgmNet@cptIt350, {2013-07-23}
* McsElln.ΠΡΟΓΡΑΜΜΑ-ΔΙΚΤΥΟΥ@cptIt,
NETWORK PROGRAM is the program of an INFORMATION MACHINE SYSTEM whose the INFORMATION MACHINE is a NETWORK one. In other words it is the program of a NETWORK INFORMATION MACHINE SYSTEM.
[NIKOS, SEP. 1994]
NETWORK-SYSTEM program είναι κάθε προγραμα που χρησιμοποιείται απο ένα ΔΙΚΤΥΟ. Μ'άλλα λόγια, αυτά τα προγράμματα έχουν σαν ΟΝΤΟΤΗΤΑ, το ΔΙΚΤΥΟ ΥΠΟΛΟΓΙΣΤΩΝ(21).
name::
* McsEngl.pgmNet'remote-procedure-call@cptIt,
* McsEngl.remote-procedure-call@cptIt,
* McsEngl.rpc@cptIt,
_DESCRIPTION:
Remote procedure calls are a high-level communication paradigm that allows programmers to write network applications using procedure calls that hide the details of the underlying network. RPC implements a client/server system without requiring that callers be aware of the underlying network.
[http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&srch=&fname=/SGI_Developer/IRIX_NetPG/sgi_html/ch04.html]
name::
* McsEngl.json-rpc@cptIt,
_GENERIC:
* JSON#ql:json@cptIt554.6#
_DESCRIPTION:
JSON-RPC is a remote procedure call protocol encoded in JSON. It is a very simple protocol (and very similar to XML-RPC), defining only a handful of data types and commands. JSON-RPC allows for notifications (data sent to the server that does not require a response) and for multiple calls to be sent to the server which may be answered out of order.
[http://en.wikipedia.org/wiki/JSON-RPC]
name::
* McsEngl.xml-rpc@cptIt,
_DESCRIPTION:
XML-RPC is a remote procedure call (RPC) protocol which uses XML to encode its calls and HTTP as a transport mechanism.[1] "XML-RPC" also refers generically to the use of XML for remote procedure call, independently of the specific protocol. This article is about the protocol named "XML-RPC".
[http://en.wikipedia.org/wiki/XML-RPC]
_SPECIFIC: pgmNet.Alphabetically:
* client-server--program#cptItsoft345#
* client-server--database#cptItsoft144#
* web-program#cptItsoft580#
* APPLICATION network program#cptIt121#
* SYSTEM network program:
Firewall#cptItsoft104#
LAN TRAFIC COUNTERS#cptIt120#
NetBIOS
NetView, IBM Διαχείριση αρχείων
OPERATING SYSTEM#cptItsoft119#
PROXY SERVER#cptIt334#
TokenVIEW Plus, Proteon, έλεγχος συγκεντρωτών καλωδίων
name::
* McsEngl.pgmNet.APPLICATION@cptIt,
* McsEngl.conceptIt121,
* McsEngl.applications-network-system-program@cptIt,
* McsEngl.program.network.application@cptIt121,
* McsEngl.workgroup-productivity-software@cptIt,
_SPECIFIC:
* PROGRAM#ql:[Field program:workgroups]# {|4| workgroups}
* Brainstorm, Mustang Software
* Electronic-Mail#cptIt102: attSpe#
* Higgins
* Network Scheduler, Powercore
* Office Works
* PackRat
* Right Hand Man
* Shoebox 3
* Syzygy
* Tandy Workgroup Companion
* WordPerfect Office
name::
* McsEngl.pgmNet.BROWSER.WEB@cptIt,
* McsEngl.conceptIt1000,
* McsEngl.browser@cptIt19.4,
* McsEngl.Internet'browser@cptIt,
* McsEngl.pgmWeb.BROWSER@cptIt,
* McsEngl.program.browser@cptIt1059,
* McsEngl.program.wwwbrowser@cptIt1059,
* McsEngl.web-browser@cptIt,
* McsEngl.web-client@cptIt19.4,
* McsEngl.webbrowser@cptIt,
* McsEngl.www-client@cptIt,
* McsEngl.pgmWbr@cptIt,
* McsEngl.wbr@cptIt, {2013-08-18}
====== lagoGreek:
* McsElln.περιηγητής@cptIt,
* McsElln.ΦΥΛΛΟΜΕΤΡΗΤΗΣ@cptIt, [ΡΑΜ 1997φεβ 12]
_GENERIC:
* program-web#cptItsoft580#
* client-server-PROGRAM#ql:[Level OBJECT:rl? conceptIt345]##cptItsoft345#
_DESCRIPTION:
Τα clients προγράματα ονομάζονται και BROWERS των οποίων ευθύνη είναι η εύρεση/αναζήτηση της πληροφοριας ενος hypertext link και η εμφανιση της πληροφοριας που βρίσκεται στον server.
[COMPUTER GO, JAN. 1995, 76]
name::
* McsEngl.pgmWbr'evoluting@cptIt,
{time.2008}:
=== GOOGLE CHROME:
Internet Explorer is one of the most widely used web browsers, attaining a peak of about 95% usage share during 2002 and 2003.[6] Its usage share has since declined with the launch of Firefox (2004) and Google Chrome (2008), and with the growing popularity of operating systems such as OS X, Linux and Android that do not run Internet Explorer.
[http://en.wikipedia.org/wiki/Internet_Explorer]
{time.2004}:
=== MOZILLA FIREFOX:
Internet Explorer is one of the most widely used web browsers, attaining a peak of about 95% usage share during 2002 and 2003.[6] Its usage share has since declined with the launch of Firefox (2004) and Google Chrome (2008), and with the growing popularity of operating systems such as OS X, Linux and Android that do not run Internet Explorer.
[http://en.wikipedia.org/wiki/Internet_Explorer]
{time.1995}:
=== INTERNET EXPLORER:
Internet Explorer (formerly Microsoft Internet Explorer and Windows Internet Explorer, commonly abbreviated IE or MSIE) is a series of graphical web browsers developed by Microsoft and included as part of the Microsoft Windows line of operating systems, starting in 1995. It was first released as part of the add-on package Plus! for Windows 95 that year. Later versions were available as free downloads, or in service packs, and included in the Original Equipment Manufacturer (OEM) service releases of Windows 95 and later versions of Windows.
[http://en.wikipedia.org/wiki/Internet_Explorer]
name::
* McsEngl.pgmWbr'layout-engine (rendering)@cptIt,
* McsEngl.engine.webbrower@cptIt,
* McsEngl.html-engine@cptIt, {2014-04-08}
* McsEngl.layout-engine.webbrower@cptIt,
* McsEngl.pgmWbr'engine@cptIt,
* McsEngl.pgmWbr'rendering-engine@cptIt,
* McsEngl.rendering-engine.webbrower@cptIt,
* McsEngl.web-browser-engine@cptIt, {2013-08-18}
_DEFINITION:
A web browser engine, (sometimes called layout engine or rendering engine), is a software component that takes marked up content (such as HTML, XML, image files, etc.) and formatting information (such as CSS, XSL, etc.) and displays the formatted content on the screen. It draws on the content area of a window, which is displayed on a monitor or a printer. A layout engine is typically embedded in web browsers, e-mail clients, e-book readers, on-line help systems or other applications that require the displaying (and editing) of web content. Engines may wait for all data to be received before rendering a page, or may begin rendering before all data is received. This can result in pages changing as more data is received, such as images being filled in or a flash of unstyled content if rendering begins before formatting information is received.
[http://en.wikipedia.org/wiki/Web_browser_engine] 2013-08-18,
===
From the Javascript programmers point of view, what tends to be most important is not which browser version is being used, but which layout engine version is being used. The layout engine is the part of the browser that actually interprets the the HTML and draws stuff on the screen. It handles the execution of Javascript code and provides the document object model and event models that the Javascript code interacts with. There are several different layout engines around, and most of them are used in many different browsers. Here's a few of the most widely used ones:
Layout Engine Browser
Trident Internet Explorer for Windows
Maxthon
Netscape 8.1
Tasman Internet Explorer 5 for Macintosh
Gecko Firefox
Netscape 6 and later
Mozilla
Camino
K-Meleon
SeaMonkey
Epiphany 2.20 and before
Galeon
KHTML Konqueror
WebKit Safari
Chrome
iCab 4 and later
Epiphany 2.26 and later
OmniWeb
Shiira
Midori
Presto Opera
iCab iCab 3 and before
Tkhtml Html Viewer
[http://unixpapa.com/js/gecko.html]
_SPECIFIC:
Active
Blink Gecko KHTML Prince Servo Trident WebKit
Inactive
Amaya Boxely Gazelle GtkHTML HTMLayout iCab Mariner Presto Tasman Tkhtml
[http://en.wikipedia.org/wiki/Gecko_(layout_engine)] {2014-05-18}
name::
* McsEngl.blink-engine@cptIt,
_DESCRIPTION:
Blink is a web browser engine developed as part of the Chromium project[1] by Google with contributions from Opera Software ASA, Intel, Samsung and others.[2][3] It was first announced in April 2013.[4] It is a fork of the WebCore component of WebKit[5] and is used in Chrome starting at version 28,[6][7] Opera (15+),[6] Amazon Silk and other Chromium based browsers as well as Android's (4.4+) WebView and Qt's upcoming WebEngine.
While Chrome's version of WebCore followed its development, a large amount of its code was dedicated to enabling features which Chrome does not use (such as its sandboxing and multi-process model in WebKit2, which differs from Chrome's implementation). The fork would allow developers to simplify the codebase by removing unneeded code, while also giving them greater flexibility in adding new features. The fork will also deprecate vendor prefixes; experimental functionality will instead be enabled on an opt-in basis.[8] Aside from these planned changes, Blink currently remains relatively similar to WebCore.[7] By commit count, Google has been the largest contributor to the WebKit code base since late 2009.[9]
Blink's naming was influenced by the non-standard presentational blink HTML tag, which was introduced by Netscape Navigator, and supported by Presto and Gecko-based browsers until August 2013.[1][10][11]
[http://en.wikipedia.org/wiki/Blink_(layout_engine)]
name::
* McsEngl.EdgeHTML@cptIt,
_DESCRIPTION:
EdgeHTML is a proprietary layout engine developed by Microsoft for the "Spartan" web browser. It is a fork of Trident designed for improved support of web standards.[2] The rendering engine was released as an experimental option in the Windows 10 Preview 9926 build.[3]
The rendering engine is the primary engine used by "Spartan". It is also used in Internet Explorer 11, in a dual-engine arrangement with Trident (which is available for backward compatibility reasons) in Windows 10.[4]
A review of the engine in the latest Windows 10 build by AnandTech found substantial benchmark improvements over Trident; particularly JavaScript engine performance, which is now up to par with that of Google Chrome.[5] Other benchmarks focusing on the performance of the WebGL API found EdgeHTML to perform much better than Google Chrome and Mozilla Firefox.[6]
[http://en.wikipedia.org/wiki/EdgeHTML]
name::
* McsEngl.Gecko@cptIt,
* McsEngl.Gecko-engine@cptIt,
_DESCRIPTION:
Gecko is a web browser engine used in many applications developed by Mozilla Foundation and the Mozilla Corporation (notably the Firefox web browser including its mobile version and their e-mail client Thunderbird), as well as in many other open source software projects. Gecko is free and open-source software subject to the terms of the Mozilla Public License version 2.
It is designed to support open Internet standards, and is used by different applications to display web pages and, in some cases, an application's user interface itself (by rendering XUL). Gecko offers a rich programming API that makes it suitable for a wide variety of roles in Internet-enabled applications, such as web browsers, content presentation, and client/server.[6]
Gecko is written in C++ and is cross-platform, and runs on various operating systems including BSDs, Linux, OS X, Solaris, OS/2, AIX, OpenVMS, and Microsoft Windows. Its development is now overseen by the Mozilla Foundation and is licensed under version 2 of the Mozilla Public License.[7]
[http://en.wikipedia.org/wiki/Gecko_(layout_engine)]
name::
* McsEngl.Trident-engine@cptIt,
_DESCRIPTION:
Trident (also known as MSHTML) is the name of the layout engine for the Microsoft Windows version of Internet Explorer.
It was first introduced with the release of Internet Explorer version 4.0 in October 1997; it has been steadily upgraded and remains in use today. For versions 7 and 8 of Internet Explorer, Microsoft made significant changes to the Trident layout engine to improve compliance with web standards and add support for new technologies.[2][3][4] Since then, Microsoft intends to comply with many modern web standards[citation needed], and also intends to significantly update the layout engine to be more competitive and modern compared to other current layout engines.
[http://en.wikipedia.org/wiki/Trident_(layout_engine)]
name::
* McsEngl.WebKit@cptIt,
* McsEngl.WebKit-engine@cptIt,
_DESCRIPTION:
WebKit is a layout engine software component for rendering web pages in web browsers. It powers Apple's Safari web browser and was previously used in Google's Chrome web browser. By September 2013, WebKit browser market share[5] was larger than that of both the Trident engine used by Internet Explorer and the Gecko engine used by Firefox.
WebKit also forms the basis for the experimental browser included with the Amazon Kindle e-book reader, as well as the default browser in the Apple iOS, BlackBerry Browser in OS 6 and above, and Tizen mobile operating systems. WebKit's C++ application programming interface provides a set of classes to display web content in windows, and implements browser features such as following links when clicked by the user, managing a back-forward list, and managing a history of pages recently visited.
WebKit's HTML and JavaScript code was originally a fork of the KHTML and KJS libraries from KDE,[6] and has now been further developed by individuals from KDE, Apple, Google, Nokia, Bitstream, BlackBerry, Igalia, and others.[7] OS X, Windows, Linux, and some other Unix-like operating systems are supported by the project.[8] On April 3, 2013, Google announced that it had forked WebCore, a component of WebKit to be used in future versions of Google Chrome and Opera under the name Blink.[9][10]
WebKit is available under a BSD-form license[11] with the exception of the WebCore and JavaScriptCore components, which are available under the GNU Lesser General Public License. By March 7 2013, WebKit is a trademark of Apple, registered with the U.S. Patent and Trademark Office.[12]
[http://en.wikipedia.org/wiki/WebKit]
name::
* McsEngl.pgmWbr'plugin@cptIt,
name::
* McsEngl.Netscape-Plugin-Application-Programming-Interface-(NPAPI)@cptIt,
* McsEngl.NPAPI@cptIt,
_DESCRIPTION:
Netscape Plugin Application Programming Interface (NPAPI) is a cross-platform plugin architecture used by many web browsers.
It was first developed for Netscape browsers, starting in 1995 with Netscape Navigator 2.0, but was subsequently adopted in Internet Explorer 3 in 1996 and implemented by many other browsers, although some browsers later dropped support.
For stability and security reasons, Google Chrome decided, in 2013, to start phasing out support for NPAPI.[1] As of Chrome version 42, NPAPI is disabled by default and must be re-enabled explicitly. Google intends to remove support entirely in version 45, due in September 2015.[2][3]
A plugin declares that it handles certain content types (e.g. "audio/mp3"). When the browser encounters that content type it loads the associated plugin, sets aside space within the browser context for the plugin to render and then streams data to it. The plugin is then responsible for rendering the data. The plugin runs in-place within the page, as opposed to older browsers that had to launch an external application to handle unknown content types.
The application programming interface (API) requires each plugin to implement and expose approximately 15 functions for initializing, creating, destroying and positioning plugin content. The NPAPI also supports scripting, printing, full screen plugins, windowless plugins and content streaming.
[http://en.wikipedia.org/wiki/NPAPI]
name::
* McsEngl.pgmWbr'view-page-source@cptIt,
_DESCRIPTION:
On a PC in Chrome or FireFox right click anywhere on the page (except the ads) and select "View page source", or even easier just click "Ctrl-U". In IE "Ctrl-U" doesn't work; you have to right click the page and select "View Source".
[http://www.html-5-tutorial.com/doctype.htm]
_SPECIFIC: browser.Alphabetically:
* Google-chrome#cptItsoft578#
* Internet-explorer#cptItsoft1068#
* Mosaic#cptIt161#(hypermedia program)
* Mozilla-firefox#cptItsoft577#
* Netscape, πολλά υποσχόμενος.
name::
* McsEngl.pgmWbr.EDGE {2015}@cptIt,
* McsEngl.ie12@cptIt,
* McsEngl.microsoft-edge@cptIt,
* McsEngl.msedge@cptIt,
* McsEngl.pgmWbr.SPARTAN@cptIt,
* McsEngl.browser.spartan@cptIt,
* McsEngl.Spartan-browser@cptIt,
* McsEngl.Spartan-program@cptIt,
* McsEngl.pgmEdg@cptIt,
* McsEngl.pgmSpn@cptIt,
_DESCRIPTION:
Microsoft Edge (codenamed “Project Spartan”) is the new default browser built for Windows 10.
[https://msdn.microsoft.com/en-us/library/dn904191(v=vs.85).aspx]
===
"Spartan" is the codename of a web browser under development by Microsoft. Officially unveiled on January 21, 2015, and first publicly released as a preview on March 30, 2015, it will replace Internet Explorer as the default browser of Windows 10 and Windows 10 for smartphones and tablets.
"Spartan" is designed to be a lightweight web browser with an engine built around web standards that is "designed for interoperability with the modern web". It removes support for legacy technologies such as ActiveX in favor of extensions and integration with other Microsoft services, such as the Cortana assistant and OneDrive, and will also offer annotation tools and a reading mode.
[http://en.wikipedia.org/wiki/Spartan_(browser)]
name::
* McsEngl.pgmEdg'edgineJS@cptIt,
* McsEngl.ChakraCore@cptIt,
name::
* McsEngl.pgmEdg'resource@cptIt,
_ADDRESS.WPG:
* developer: https://dev.windows.com/en-us/microsoft-edge//
* https://msdn.microsoft.com/en-us/library/dn904191(v=vs.85).aspx,
name::
* McsEngl.conceptIt578,
* McsEngl.chrome@cptIt578,
* McsEngl.google-chrome@cptIt578,
* McsEngl.gchrome@cptIt578,
* McsEngl.pgmChrm,
* McsEngl.pgmWeb.CHROME,
* McsEngl.program.Google-Chrome,
* McsEngl.pgmCrm,
1. The limit is 5MB, not 50MB.
2. Are you not familiar with the Chrome Web App concept? there is a permission called "unlimitedStorage", which lets websites have precisely that. It requires an installation, of course.
chromium-apps is a discussion group that is meant for discussion Chrome Web Apps, so you are welcome to join and ask for more information about anything you do not understand, after reading the documentation I referenced above.
name::
* McsEngl.pgmCrm'API@cptIt,
Go to: "about:flags" to enable the Web Audio API
http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specification.html
name::
* McsEngl.pgmCrm'CHROMIUM@cptIt,
* McsEngl.chromium@cptIt578i,
_DEFINITION:
* Chromium is an open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web. This site contains design documents, architecture overviews, testing information, and more to help you learn to build and work with the Chromium source code.
[http://www.chromium.org/]
* Just make sure you (manually) update Chromium. It does not have an automatic update mechanism, so security risks can exist if you do not update your version every week or so.
Also, I hope you know it is much less stable than Google Chrome.
?PhistucK 2010-10-07
_ADDRESS.WPG:
* http://www.chromium.org//
* http://en.wikipedia.org/wiki/Chromium_%28web_browser%29,
_Computer_language:
Chromium is mainly written in C++, some C (third part libraries) and some Assembly (V8).
Some of the user interface (the Settings tab, for example) uses JavaScript/CSS/HTML.
The build tools use Perl, Python and some other languages (BASH?).
[Alon Gothshmidt phistuck@gmail.com]
Chromium is the name given to the open source project and the browser source code released and maintained by the Chromium Project.[6] It is possible to install the latest precompiled snapshots for Windows, Linux and Mac,[7] or by downloading the source code and building it manually on those platforms. Google takes this source code and adds an integrated Flash Player[8], the Google name and logo, an auto-updater system called GoogleUpdate, an opt-in option for users to send Google their usage statistics and crash reports as well as, in some instances, RLZ tracking (see Google Chrome) which transmits information in encoded form to Google, for example, when and where Chrome has been downloaded. By default, Chromium only supports Vorbis, Theora and WebM codecs for the HTML5 audio and video tags, while Google Chrome supports these in addition to H.264, AAC, and MP3. Certain Linux distributions may add support for other codecs to their customized versions of Chromium.[9]
In June 2010 Google confirmed that the RLZ tracking token is only present in versions of Chrome that are downloaded as part of marketing promotions and distribution partnerships and not in versions of Chrome downloaded from the Google website directly or in any versions of Chromium. The RLZ source code was also made open source at the same time so that developers can confirm what it is and how it works.[10]
[http://en.wikipedia.org/wiki/Chromium_%28web_browser%29] 2010-10-07
e308ad5e31abe3e9525d439c603f8a96@yahoo.com
List of Chromium Command Line Switches (Canary Build)
There are lots of command lines which can be used with the Chromium
browser. Some change behavior of features, others are for debugging or
experimenting. This page lists the available switches including their
conditions and descriptions. (Last updated 2011-07-23).
--disk-cache-dir ? Use a specific disk cache location, rather than one
derived from the UserDatadir.
--disk-cache-size ? Forces the maximum disk space to be used by the
disk cache, in bytes.
--enable-fastback ? Enable the fastback page cache.
--enable-ssl-cached-info ? Enables TLS cached info extension.
--media-cache-size ? Forces the maximum disk space to be used by the
media cache, in bytes.
REFERENCES
"List of Chromium Command Line Switches « Peter Beverloo" -
http://peter.sh/experiments/chromium-command-line-switches/
name::
* McsEngl.pgmCrm'DevTools@cptIt,
* McsEngl.chrome-developer-tools@cptIt,
* McsEngl.devTools@cptIt,
_DESCRIPTION:
The Chrome Developer Tools (DevTools for short), are a set of web authoring and debugging tools built into Google Chrome. The DevTools provide web developers deep access into the internals of the browser and their web application. Use the DevTools to efficiently track down layout issues, set JavaScript breakpoints, and get insights for code optimization.
[https://developer.chrome.com/devtools]
name::
* McsEngl.pgmCrm'EVOLUTION@cptIt,
There currently are five versions of the browsers based on Chromium:
Google Chrome (Stable): The most stable edition, intended for most users.
Google Chrome (Beta): Receives updates a few weeks in advance of the
stable versions.
Google Chrome (Dev): Intended for web-developers or people who like
new features. Updated about weekly.
Google Chrome (Canary): Receives a new build every few days, gets
close to nightlies. These won't be tested by humans.
Chromium (nightlies): Builds created from the tip-of-tree, the latest
source-code. These are created every few hours. Chromium can be really
unstable.
name::
* McsEngl.pgmCrm'EXTENSION (crx)@cptIt,
* McsEngl.crx@cptIt578i,
* McsEngl.chrome-extension-itsoft@cptIt578i,
crx'DEFINITION:
An extension is a zipped bundle of files — HTML, CSS, JavaScript, images, and anything else you need — that adds functionality to the Google Chrome browser. Extensions are essentially web pages, and they can use all the APIs that the browser provides to web pages, from XMLHttpRequest to JSON to HTML5.
[http://code.google.com/chrome/extensions/overview.html]
===
Extensions in Google Chrome are basically webpages. You have javascript files, stylesheets and images. You can even use JavaScript libraries like jQuery.
The extensions are, however, treated a bit differently than your regular webpage, which is displayed in the browser. You can have access to all the opened tabs, to the user’s browsing history, you can manipulate all the pages that are opened, send AJAX requests to any website and much more.
You also have the benefit (or the limitation) that your extension runs only on one browser. You can forget all compatibility issues and embrace Google Chrome’s hot new HTML5 features
[http://tutorialzine.com/2010/06/making-first-chrome-extension/]
===
Extensions are essentially web pages (html+js+css), and they can use all the APIs that the browser provides to web pages, from XMLHttpRequest to JSON to HTML5. Common features are boosted with a Chrome.* API.
[http://talks.codegram.com/creating-basic-chrome-extensions#/description]
name::
* McsEngl.crx'API@cptIt,
* McsEngl.crx'Example-code@cptIt,
name::
* McsEngl.chrome.browserAction module@cptIt,
_ADDRESS.WPG:
* http://code.google.com/chrome/extensions/browserAction.html
name::
* McsEngl.chrome.browserAction@cptIt578i,
* McsEngl.crx'browserAction@cptIt578i,
name::
* McsEngl.chrome.browserAction.onClicked()@cptIt,
* McsEngl.chrome.browserAction.onClicked@cptIt578i,
* McsEngl.crx'onClicked@cptIt578i,
chrome.browserAction.onClicked.addListener(function(Tab tab) {...});
Fired when a browser action icon is clicked. This event will not fire if the browser action has a popup.
chrome.browserAction.onClicked.addListener(updateIcon);
name::
* McsEngl.chrome.browserAction.setBadgeBackgroundColor()@cptIt,
* McsEngl.chrome.browserAction.setBadgeBackgroundColor@cptIt578i,
* McsEngl.crx'setBadgeBackgroundColor@cptIt578i,
setBadgeBackgroundColor
void chrome.browserAction.setBadgeBackgroundColor(object details)
Sets the background color for the badge.
_Code.crx:
chrome.browserAction.setBadgeBackgroundColor({color:[0,0,255,255]});
name::
* McsEngl.chrome.browserAction.setBadgeText()@cptIt,
* McsEngl.chrome.browserAction.setBadgeText@cptIt578i,
* McsEngl.crx'setBadgeText@cptIt578i,
chrome.browserAction.setBadgeText(object details)
Sets the badge text for the browser action. The badge is displayed on top of the icon.
name::
* McsEngl.chrome.browserAction.setIcon()@cptIt,
* McsEngl.chrome.browserAction.setIcon@cptIt578i,
* McsEngl.crx'setIcon@cptIt578i,
_Code.crx:
chrome.browserAction.setIcon({path:"icon" + current + ".png"});
chrome.browserAction.setIcon({path:"img/icon.png", tabId:tab.id})
name::
* McsEngl.chrome.browserAction.setPopup()@cptIt,
* McsEngl.chrome.browserAction.setPopup@cptIt578i,
* McsEngl.crx'setPopup@cptIt578i,
chrome.browserAction.setPopup(object details)
Sets the html document to be opened as a popup when the user clicks on the browser action's icon.
name::
* McsEngl.chrome.browserAction.setTitle()@cptIt,
* McsEngl.chrome.browserAction.setTitle@cptIt578i,
* McsEngl.crx'setTitle@cptIt578i,
chrome.browserAction.setTitle(object details)
Sets the title of the browser action. This shows up in the tooltip.
name::
* McsEngl.chrome.extension module@cptIt,
* McsEngl.chrome.extension@cptIt578i,
* McsEngl.crx'extension@cptIt578i,
SOURCE:
* http://code.google.com/chrome/extensions/extension.html
_DESCRIPTION:
The chrome.extension module has utilities that can be used by any extension page. It includes support for exchanging messages between an extension and its content scripts or between extensions, as described in detail in Message Passing.
[http://code.google.com/chrome/extensions/extension.html]
name::
* McsEngl.chrome.extension.getBackgroundPage()@cptIt,
crx'ex.Options_Page_communicating_to_Background_Page:
options.html
var bkg = chrome.extension.getBackgroundPage()
bkg.startExtension();
bkg.stopExtension();
background.html
function startExtension() {
console.log('Starting Extension');
}
function stopExtension() {
console.log('Stopping Extension');
}
EXAMPLE:
chrome.extension.getBackgroundPage().location.href="background.html";
reloads extension.
name::
* McsEngl.chrome.extension.getURL()@cptIt,
* McsEngl.crx'getURL@cptIt,
_DEFINITION:
string chrome.extension.getURL(string path)
Converts a relative path within an extension install directory to a fully-qualified URL.
Referring to extension files
Get the URL of an extension's file using chrome.extension.getURL(). You can use the result just like you would any other URL, as the following code shows.
//Code for displaying <extensionDir>/images/myimage.png:
var imgURL = chrome.extension.getURL("images/myimage.png");
document.getElementById("someImage").src = imgURL;
name::
* McsEngl.chrome.extension.getViews():@cptIt,
* McsEngl.crx'getViews@cptIt,
array of DOMWindow chrome.extension.getViews(, object fetchProperties)
Returns an array of the JavaScript 'window' objects for each of the pages running inside the current extension.
EXAMPLE:
chrome.extension.getViews().forEach(function(view){
view.alert("Hello world");
});
name::
* McsEngl.chrome.extension.onRequest@cptIt,
* McsEngl.crx'onRequest@cptIt,
Note: If multiple pages are listening for onRequest events, only the first to call sendResponse() for a particular event will succeed in sending the response. All other responses to that event will be ignored.
chrome.extension.onRequest.addListener(
function(request, sender, sendResponse) {
console.log(sender.tab ?
"from a content script:" + sender.tab.url :
"from the extension");
if (request.greeting == "hello")
sendResponse({farewell: "goodbye"});
else
sendResponse({}); // snub them.
});
rlEXAMPLE_CONTENTsCRIPT:
chrome.extension.onRequest.addListener(
function(req, sender, sendResponse){
switch(req.method){
case 'parseOutline':
sendResponse(parseOutline());
break;
case 'jumpToHeader':
jumpToHeader(req.index);
break;
}
}
);
chrome.extension.onRequest.addListener(
function(req, sender, sendResponse) {
switch (req.msg) {
case "getOutline":
var outline = HTML5Outline(document.body);
sendResponse(outline ? outline.asHTML(true) : "No outline - is there a FRAMESET?");
break;
rlEXAMPLE_BACKGROUND:
chrome.extension.onRequest.addListener(
function(request, sender){
if (request.msg == "showAction") {
chrome.pageAction.show(sender.tab.id);
}
}
);
name::
* McsEngl.chrome.extension.sendRequest({}; function(response) {})@cptIt,
* McsEngl.crx'sendRequest@cptIt,
* McsEngl.chrome.extension.sendRequest@cptIt578i,
_DESCRIPTION:
chrome.extension.sendRequest(string extensionId, any request, function responseCallback)
Sends a single request to other listeners within the extension.
Similar to chrome.extension.connect, but only sends a single request with an optional response.
[http://code.google.com/chrome/extensions/extension.html#method-sendRequest]
chrome.extension.sendRequest(window.getSelection().toString());
chrome.extension.sendRequest({greeting: "hello"},
function(response) {
console.log(response.farewell);
});
rlEXAMPLE_CONTENTsCRIPT:
chrome.extension.sendRequest({msg : "showAction"});
====================================
Yes, everything is asynchronous.
You have sent a request. The response will not be received immediately.
You put a "return" in the function you have assigned to the callback, it
returns this value to... nothing.
What you should do, is something like that -
function GetResponseAndAct(Response)
{
var server =3D "https://" + Response.hostname + ":" + Response.port;
}
function getHostParm(parm)
{
chrome.extension.sendRequest({name: parm}, GetResponseAndAct)
}
getHostParm("hostname");
name::
* McsEngl.chrome.i18n module@cptIt,
SOURCE:
* http://code.google.com/chrome/extensions/i18n.html
string chrome.i18n.getMessage(string messageName, string or array of string substitutions)
Gets the localized string for the specified message. If the message is missing, this method returns an empty string (''). If the format of the getMessage() call is wrong — for example, messageName is not a string or the substitutions array is empty or has more than 9 elements — this method returns undefined.
name::
* McsEngl.chrome.pageAction module@cptIt,
SOURCE:
* http://code.google.com/chrome/extensions/pageAction.html
_USAGE:
Use page actions to put icons inside the address bar. Page actions represent actions that can be taken on the current page, but that aren't applicable to all pages. Some examples:
* Subscribe to this page's RSS feed
* Make a slideshow out of this page's photos
MANIFEST:
{
"name": "My extension",
...
"page_action": {
"default_icon": "icons/foo.png", // required
"default_title": "Do action", // optional; shown in tooltip
"default_popup": "popup.html" // optional
},
...
}
name::
* McsEngl.chrome.pageAction.show()@cptIt,
chrome.pageAction.show(integer tabId)
Shows the page action. The page action is shown whenever the tab is selected.
name::
* McsEngl.chrome.tabs module@cptIt,
SOURCE:
* http://code.google.com/chrome/extensions/tabs.html
name::
* McsEngl.chrome.tabs.create()@cptIt,
chrome.tabs.getSelected(null,function(tab) {
var urlTab = tab.url;
chrome.tabs.create({url:urlTab});
});
chrome.tabs.create({"url":url, "selected":true});
chrome.tabs.create({url:chrome.extension.getURL("tabs_api.html")});
name::
* McsEngl.chrome.tabs.executeScript()@cptIt,
* McsEngl.crx'executeScript@cptIt,
chrome.tabs.executeScript(integer tabId, object details, function callback)
Injects JavaScript code into a page.
chrome.tabs.executeScript(null, {file: "content_script.js"});
chrome.tabs.executeScript(null, {code:"document.body.bgColor='red'"});
chrome.tabs.executeScript(tab.id, {code: "alert('Hello World')" });
name::
* McsEngl.chrome.tabs.getAllInWindow()@cptIt,
chrome.tabs.getAllInWindow(null, function(tabs){
tabs.forEach(function(tab){
alert("Hello world\n" + tab.url);
});
});
name::
* McsEngl.chrome.tabs.getCurrent()@cptIt,
(function callback)
Gets the tab that this script call is being made from. May be undefined if called from a non-tab context (for example: a background page or popup view).
name::
* McsEngl.chrome.tabs.getSelected()@cptIt,
(integer windowId, function callback)
Gets the tab that is selected in the specified window.
name::
* McsEngl.chrome.tabs.insertCSS()@cptIt,
chrome.tabs.insertCSS(integer tabId, object details, function callback)
Injects CSS into a page.
name::
* McsEngl.chrome.tabs.onRemoved()@cptIt,
* McsEngl.chrome.tabs.onRemoved@cptIt578i,
* McsEngl.crx'onRemoved@cptIt,
chrome.tabs.onRemoved.addListener(function(integer tabId) {...});
Fires when a tab is closed.
_Code.crx:
chrome.tabs.onRemoved.addListener(function(a)
{
delete activeTabIds[a]
});
name::
* McsEngl.chrome.tabs.onSelectionChanged()@cptIt,
* McsEngl.chrome.tabs.onSelectionChanged@cptIt578i,
* McsEngl.crx'onSelectionChanged@cptIt,
_DEFINITION:
chrome.tabs.onSelectionChanged.addListener(function(integer tabId, object selectInfo) {...});
Fires when the selected tab in a window changes.
_Code.crx:
chrome.tabs.onSelectionChanged.addListener(
function (tabId, selectInfo) {
currentTabId = tabId;
updatePowerStateByID(-1);
chrome.tabs.sendRequest(tabId, { type: "request.power.state" });
}//function
);
name::
* McsEngl.chrome.tabs.onUpdated()@cptIt,
* McsEngl.chrome.tabs.onUpdated@cptIt578i,
* McsEngl.crx'onUpdated@cptIt,
_DEFINITION:
chrome.tabs.onUpdated.addListener(function(integer tabId, object changeInfo, Tab tab) {...});
Fires when a tab is updated.
_Code.crx:
chrome.tabs.onUpdated.addListener(function(b,a,c)
{
if(a.status==="loading"){delete activeTabIds[b]}
});
name::
* McsEngl.chrome.tabs.sendRequest()@cptIt,
* McsEngl.chrome.tabs.sendRequest@cptIt578i,
* McsEngl.crx'sendRequest@cptIt,
Sending a request from the extension to a content script looks very similar, except that you need to specify which tab to send it to. This example demonstrates sending a message to the content script in the selected tab.
background.html
===============
chrome.tabs.getSelected(null, function(tab) {
chrome.tabs.sendRequest(tab.id, {greeting: "hello"},
function(response) {
console.log(response.farewell);
});
});
_EXAMPLE_BACKGROUND:
function parseOutline(callback){
chrome.tabs.getSelected(null, function(tab){
chrome.tabs.sendRequest(tab.id, {method:'parseOutline'},
function(outline){
callback(outline)
});
});
}
function jumpToHeader(indx){
chrome.tabs.getSelected(null, function(tab){
chrome.tabs.sendRequest(tab.id, {method:'jumpToHeader', index:indx});
});
}
rlEXAMPLE_POPUP:
chrome.tabs.getSelected(null,
function(tab){
chrome.tabs.sendRequest(tab.id, {msg:"getOutline"},
function(outline){
...
name::
* McsEngl.chrome.tabs.update()@cptIt,
chrome.tabs.update(integer tabId, object updateProperties, function callback)
Modifies the properties of a tab. Properties that are not specified in updateProperties are not modified.
chrome.tabs.update(existing_tab.id, {"selected":true});
name::
* McsEngl.chrome.contextMenus module@cptIt,
_ADDRESS.WPG:
* http://code.google.com/chrome/extensions/contextMenus.html
name::
* McsEngl.crx'contextMenus@cptIt,
integer chrome.contextMenus.create(object createProperties, function callback)
Creates a new context menu item. Note that if an error occurs during creation, you may not find out until the creation callback fires (the details will be in chrome.extension.lastError).
name::
* McsEngl.chrome.windows module@cptIt,
_ADDRESS.WPG:
* http://code.google.com/chrome/extensions/windows.html
name::
* McsEngl.crx'windows@cptIt,
chrome.windows.getAll({"populate":true}, function(windows) {
var existing_tab = null;
for (var i in windows) {
var tabs = windows[i].tabs;
for (var j in tabs) {
var tab = tabs[j];
if (tab.url == url) {
existing_tab = tab;
break;
}
}
}
name::
* McsEngl.crx'contextMenus@cptIt,
* McsEngl.crx'ex.contextMenus@cptIt,
Here is the code for the full extension:
manifest.json - file
-------------
{
"name": "Context Menus Sample",
"description": "Shows some of the features of the Context Menus
API",
"version": "1.0",
"permissions": ["contextMenus"],
"background_page": "bkg.htm"
}
bkg.htm - file
-------------
<html>
<head>
<script src="click.js" defer="DEFER"></script>
</head>
<textarea id="tmp-clipboard"></textarea>
</html>
click.js - file
-------------
// Copyright (c) 2010 The Chromium Authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can
be
// found in the LICENSE file.
var cmenus = chrome.contextMenus
// Create one test item for each context type.
var contexts = ["page","selection","link","editable","image","video",
"audio"];
var context = contexts[2];
var title = "Copy link name and link address";
var id = cmenus.create({"title": title, "contexts":[context],
"onclick": _urlOnClick});
function _urlOnClick ( info,tab ) {
var _url = info.linkUrl
var _name = info.selectionText
var _val = "\"" + _name + "\" - " + _url
var _win = chrome.extension.getBackgroundPage();
var _d = _win.document;
var _textarea = _d.getElementById("tmp-clipboard");
_textarea.value = _val
_textarea.select ()
_d.execCommand("copy", false, null);
} // function _urlOnClick
[[chromium-discuss] New idea for the chrome popup contextmenu] 2011-07-23
name::
* McsEngl.crx'contextMenus.GetTitleOfCurrent@cptIt,
You cannot do it in the same way, you have to inject a script into the tab (either a content script or by using chrome.tabs.executeScript), you can use the Tab argument to identify the tabs to which you need to inject the script using chrome.tabs.executeScript, or to which you need to send a message (in case you are using a content script).
Within the injected script, use message passing to pass the information to the background page by using chrome.extension.sendRequest({title: document.title}, function(){}) to send the title to the background page (in which you should receive the message with chrome.extension.onRequest.addListener).
?PhistucK
On Sat, Oct 2, 2010 at 22:54, Arpit <self@techraga.in> wrote:
Hi,
This is regarding Context Menu APIs. I am looking for the way to get
the title of current page, in the same manner as we can get its URL by
using pageUrl (ref: http://code.google.com/chrome/extensions/beta/contextMenus.html).
name::
* McsEngl.crx'file-accessing@cptIt,
Referring to extension files
Get the URL of an extension's file using chrome.extension.getURL(). You can use the result just like you would any other URL, as the following code shows.
//Code for displaying <extensionDir>/images/myimage.png:
var imgURL = chrome.extension.getURL("images/myimage.png");
document.getElementById("someImage").src = imgURL;
[https://developer.chrome.com/extensions/content_scripts.html]
name::
* McsEngl.crx'messages.json@cptIt,
In messages.json, each user-visible string has a name, a "message" item, and an optional "description" item. The name is a key such as "extName" or "search_string" that identifies the string. The "message" specifies the value of the string in this locale. The optional "description" provides help to translators, who might not be able to see how the string is used in your extension. For example:
{
"search_string": {
"message": "hello%20world",
"description": "The string we search for. Put %20 between words that go together."
},
...
}
{
"gmailcheck_name":{"message":"Έλεγχος του Google Mail"},
"gmailcheck_description":{"message":"Εμφανίζει τον αριθμό των μη αναγνωσμένων μηνυμάτων στα εισερχόμενα του Google Mail σας. Μπορείτε επίσης να κάνετε κλικ στο κουμπί για να ανοίξετε τα εισερχόμενά σας."},
"gmailcheck_node_error":{"message":"Σφάλμα: έγινε ανάκτηση ροής, αλλά δεν βρέθηκε κόμβος <fullcount>"},
"gmailcheck_exception":{"message":"εξαίρεση: $1","placeholders":{"1":{"content":"$1"}}}
}
name::
* McsEngl.crx'page-loading@cptIt,
* McsEngl.crx'ex.page-loading@cptIt,
I think you can get what you're after by having a sendRequest() fire
directly from your content script.
In content_script.js:
chrome.extension.sendRequest({request: {op:
"pageLoadStarted"}});
In background.html:
chrome.extension.onRequest.addListener(function(request, sender,
sendResponse) {
console.log('onRequest: ' + JSON.stringify(request));
console.log(JSON.stringify(sender));
});
This fires right after tabUpdated and whenever a page starts loading.
It only fires when the page is actually re/loaded from the web.
Alternately, check out the webNavigation.onBeforeNavigate event in the
Chrome experimental APIs.
Joel
[crx] 2011-06-04
name::
* McsEngl.crx'FILE@cptIt,
Each extension has the following files:
- A manifest file
- One or more HTML files (unless the extension is a theme)
- Optional: One or more JavaScript files
- Optional: Any other files your extension needs — for example, image files
While you're working on your extension, you put all these files into a single folder. When you distribute your extension, the contents of the folder are packaged into a special ZIP file that has a .crx suffix. If you put your extension in the gallery, the gallery creates the .crx file for you. For details on distributing extensions, see Hosting.
[http://code.google.com/chrome/extensions/overview.html]
name::
* McsEngl.crx'MANIFEST-FILE@cptIt,
* McsEngl.crx'file.manifest@cptIt,
* McsEngl.crx'manifest@cptIt,
_ADDRESS.WPG:
* http://developer.chrome.com/extensions/manifest.html,
* http://developer.chrome.com/extensions/tut_migration_to_manifest_v2.html,
* http://code.google.com/chrome/extensions/manifest.html
_DESCRIPTION:
Manifest version 1 was deprecated in Chrome 18, and support will be phased out according to the manifest version 1 support schedule. The changes from version 1 to version 2 fall under two broad categories: API changes and Security changes.
[http://developer.chrome.com/extensions/tut_migration_to_manifest_v2.html]
===
The manifest file, called manifest.json, gives information about the extension, such as the most important files and the capabilities that the extension might use. Here's a typical manifest file for a browser action that uses information from google.com:
{
"name": "My Extension",
"version": "2.1",
"description": "Gets information from Google.",
"icons": { "128": "icon_128.png" },
"background_page": "bg.html",
"permissions": ["http://*.google.com/", "https://*.google.com/"],
"browser_action": {
"default_title": "",
"default_icon": "icon_19.png",
"default_popup": "popup.html"
}
}
name::
* McsEngl.crx'manifest'field@cptIt,
_DESCRIPTION:
Field summary
The following code shows the supported manifest fields, with links to the page that discusses each field. The only fields that are always required are name and version.
[https://developer.chrome.com/extensions/manifest.html]
crx'manifest'NAME:
* it is displayd on: chrome://extensions/ page.
"name": "A browser action which changes its icon when clicked.",
"name": "EasyReader2",
crx'manifest'BRROSER_ACTION:
Use browser actions to put icons in the main Google Chrome toolbar, to the right of the address bar. In addition to its icon, a browser action can also have a tooltip, a badge, and a popup.
[https://developer.chrome.com/extensions/browserAction.html]
===
"browser_action": {
"default_icon": "images/icon19.png", // required
"default_title": "Google Mail", // optional; shown in tooltip of extension's icon
"default_popup": "popup.html" // optional
},
"browser_action": {
"default_title": "",
"default_icon": "icon_19.png",
"default_popup": "popup.html"
}
"browser_action": {
"name": "Click to change the icon's color"
}
crx'manifest'manifest_version:
manifest_version
One integer specifying the version of the manifest file format your package requires. As of Chrome 18, developers should specify 2 (without quotes) to use the format as described by this document:
"manifest_version": 2
Consider manifest version 1 deprecated as of Chrome 18. Version 2 is not yet required, but we will, at some point in the not-too-distant future, stop supporting packages using deprecated manifest versions. Extensions, applications, and themes that aren't ready to make the jump to the new manifest version in Chrome 18 can either explicitly specify version 1, or leave the key off entirely.
The changes between version 1 and version 2 of the manifest file format are described in detail in the manifest_version documentation.
[https://developer.chrome.com/extensions/manifest.html#manifest_version]
crx'manifest'PAGE_ACTION:
"page_action": {
"default_icon": "myicon.png",
"popup": "popup.html"
crx'manifest'PERMISSIONS:
"tabs",
"bookmarks",
"contextMenus",
"cookies",
"notifications"
"http://www.google.com/",
"https://www.google.com/",
"http://*.google.com/",
"http://*/*",
"https://*/*"
"experimental",
"permissions": ["http://*.google.com/", "https://*.google.com/"],
"permissions": [
"tabs", "http://*/*"
],
"permissions": [
"http://www.google.com/",
"https://www.google.com/",
"http://*.google.com/"
],
- Note that starting from Chrome 7, you will not need the "tabs" permission if you only use chrome.tabs.create or chrome.tabs.update.
[@?PhistucK 2010-09-21]
crx'manifest'CONTENT_SCRIPTS:
Content scripts are JavaScript files that run in the context of web pages. By using the standard Document Object Model (DOM), they can read details of the web pages the browser visits, or make changes to them.
[https://developer.chrome.com/extensions/content_scripts.html]
===
"content_scripts": [ {
"matches": [ "<all_urls>" ],
"matches": ["http://*/*", "https://*/*"],
"js": ["content.js"],
"all_frames": true
}]
"js" : ["contentscript.js"],
"run_at" : "document_idle",
"all_frames" : false
crx'manifest'BACKGROUND_PAGE:
"background_page": "background.html",
crx'manifest'VERSION:
"version": "1.0",
* does NOT accept: 09, only 9.
- wrong: 2010-09-26
- right: 2010.9.26
===
One to four dot-separated integers identifying the version of this extension. A couple of rules apply to the integers: they must be between 0 and 65535, inclusive, and non-zero integers can't start with 0. For example, 99999 and 032 are both invalid.
Here are some examples of valid versions:
"version": "1"
"version": "1.0"
"version": "2.10.2"
"version": "3.1.2.4567"
The autoupdate system compares versions to determine whether an installed extension needs to be updated. If the published extension has a newer version string than the installed extension, then the extension is automatically updated.
The comparison starts with the leftmost integers. If those integers are equal, the integers to the right are compared, and so on. For example, 1.2.0 is a newer version than 1.1.9.9999.
A missing integer is equal to zero. For example, 1.1.9.9999 is newer than 1.1.
For more information, see Autoupdating.
[https://developer.chrome.com/extensions/manifest.html#version]
crx'manifest'DEFAULT_LOCALE:
"default_locale": "en_US",
crx'manifest'INCOGNITO:
"incognito": "split",
crx'manifest'CHROME_URL_OVERRIDES:
"chrome_url_overrides": {
"newtab": "blank.html"
}
crx'manifest'OPTIONS_PAGE:
"options_page": "options.html",
crx'manifest'ICONS:
"icons": { "128": "icon.png" },
"icons": {
"16": "icon-bitty.png",
"48": "icon-small.png",
"128": "icon-large.png"
},
"icons": {
"48": "img/docs_spreadsheets-48.gif",
"128": "img/docs_spreadsheets-128.gif"
},
crx'manifest'update_url:
"update_url": "http://clients2.google.com/service/update2/crx",
crx'manifest'omnibox_keyword:
"omnibox_keyword": "src",
crx'manifest'key:
"key": ".....",
crx'manifest'content_security_policy:
If you want to load jQuery from Google's CDN you have to add the following content security rule to your manifest file.
...
"content_security_policy": "script-src 'self' https://*.googleapis.com; object-src 'self'",
[http://stackoverflow.com/a/13449456]
crx'manifest'web_accessible_resources:
An array of strings specifying the paths (relative to the package root) of packaged resources that are expected to be usable in the context of a web page. For example, an extension that injects a content script with the intention of building up some custom interface for example.com would whitelist any resources that interface requires (images, icons, stylesheets, scripts, etc.) as follows:
{
...
"web_accessible_resources": [
"images/my-awesome-image1.png",
"images/my-amazing-icon1.png",
"style/double-rainbow.css",
"script/double-rainbow.js"
],
...
}
name::
* McsEngl.crx'BACKGROUND-PAGE@cptIt,
_ADDRESS.WPG:
* http://code.google.com/chrome/extensions/background_pages.html
_DESCRIPTION:
A common need for extensions is to have a single long-running script to manage some task or state. Background pages to the rescue.
... the background page is an HTML page that runs in the extension process. It exists for the lifetime of your extension, and only one instance of it at a time is active.
[http://code.google.com/chrome/extensions/background_pages.html]
===
* A background page is one of those web pages you can’t see.
here can be only one background page per extension and it’ll exist as long as the browser is open (and the extension remains installed).
[http://supercollider.dk/2010/04/chrome-extensions-for-web-hackers-part-%E2%85%A1-background-pages-255]
You need to add a background page, which is easily added by adding the background_page option to your manifest.json:
view sourceprint?
1 {
2 "name": "My Extension",
3 ...
4 "background_page": "background.html",
5 ...
6 }
A background page runs at all times when the extension is enabled. You cannot see it, but it can modify other aspects of the extension, like setting the browser action badge. For example, the following example would set the icon badge to the number of unread items in a hypothetical service:
view sourceprint?
01 function getUnreadItems(callback) {
02 $.ajax(..., function(data) {
03 process(data);
04 callback(data);
05 });
06 }
07
08 function updateBadge() {
09 getUnreadItems(function(data) {
10 chrome.browserAction.setBadgeText({text:data.unreadItems});
11 });
12 }
[http://julianapena.com/2010/01/how-to-build-a-chrome-extension-part-4-background-pages-and-scheduling-requests/]
_MANIFEST:
"background_page": "background.html",
name::
* McsEngl.crx'background-Reaction-Icon-Click@cptIt,
chrome.browserAction.onClicked.addListener(
function(tab){
tocCurrentTabId=tab.id;
chrome.tabs.sendRequest(tab.id, {type:"toggleState"});
}
);
name::
* McsEngl.crx'CONTENT-SCRIPTS@cptIt,
_ADDRESS.WPG:
* http://code.google.com/chrome/extensions/content_scripts.html,
_DESCRIPTION:
These allow you to run JavaScript for pages visited.
===
Content scripts are JavaScript files that run in the context of web pages. By using the standard Document Object Model (DOM), they can read details of the web pages the browser visits, or make changes to them.
Here are some examples of what content scripts can do:
Find unlinked URLs in web pages and convert them into hyperlinks
Increase the font size to make text more legible
Find and process microformat data in the DOM
However, content scripts have some limitations. They cannot:
Use chrome.* APIs (except for parts of chrome.extension)
Use variables or functions defined by their extension's pages
Use variables or functions defined by web pages or by other content scripts
Make cross-site XMLHttpRequests
These limitations aren't as bad as they sound. Content scripts can indirectly use the chrome.* APIs, get access to extension data, and request extension actions by exchanging messages with their parent extension. Content scripts can also communicate with web pages using the shared DOM. For more insight into what content scripts can and can't do, learn about the execution environment.
Manifest
===
Since content scripts run in the context of a web page and not the extension, they often need some way of communicating with the rest of the extension. For example, an RSS reader extension might use content scripts to detect the presence of an RSS feed on a page, then notify the background page in order to display a page action icon for that page.
Communication between extensions and their content scripts works by using message passing.
_DETECTION:
Changes to the manifest are _not_ automatically detected. You must
reload the extension to pick them up.
Changes to the script files should be automatically detected and
re-applied while running in unpacked mode.
[aa@chromium.org]
name::
* McsEngl.crx'content-script'MANIFEST@cptIt,
crx'matches:
* http://code.google.com/chrome/extensions/match_patterns.html
matches lets you specify on which pages you want your content script to work, by providing a set of match patterns.
- "matches": ["http://news.google.com/*"],
- "matches": [ "<all_urls>"]
"content_scripts": [
{
"matches": ["http://www.google.com/*"],
"css": ["mystyles.css"],
"js": ["jquery.js", "myscript.js"]
"all_frames": true
}
],
"content_scripts": [
{
"matches": ["http://news.google.com/*"],
"js" : ["contentscript.js"]
}
The content_scripts entry in your manifest can take multiple parameters, like so:
"content_scripts": [
{
"matches": ["http://mysite.com/a.html"],
"js": ["a.js"]
},
{
"matches": ["http://mysite.com/b.html"],
"js": ["b.js"]
}
],
Hope that's what you were looking for.
~Arne
"js": ["toc-jquery-1.4.2.min.js", "toc.js"],
=========
"js": ["toc.js"],
"js": ["toc-jquery-1.4.2.min.js"],
does NOT work.
[2010-10-13]
name::
* McsEngl.crx'ex.Content-Script-communicating-to-Background-Page@cptIt,
When you are referring to "Code being injected to the page" is that any website? If so, you would need to use a content script with Message Passing. To do so, you can do this.
content_script.js
==============
chrome.extension.sendRequest({action:'start'},
function(response) {
console.log('Start action sent');
});
background.html
=============
function onRequest(request, sender, sendResponse) {
if (request.action == 'start')
startExtension()
else if (request.action == 'stop')
stopExtension()
sendResponse({});
};
chrome.extension.onRequest.addListener(onRequest);
[http://stackoverflow.com/questions/2998775/chrome-extension-message-passing]
Content scripts run in a different security context than the background page, so they won't have access to scripts included on the background page.. Either create the object in the background page and use message passing from the background script to trigger calls to the oauth object, or include the two files in the list of js files injected with your content script.
name::
* McsEngl.crx'OPTIONS-PAGE@cptIt,
_ADDRESS.WPG:
* http://code.google.com/chrome/extensions/options.html
_DESCRIPTION:
To allow users to customize the behavior of your extension, you may wish to provide an options page. If you do, a link to it will be provided from the extensions management page at chrome://extensions. Clicking the Options link opens a new tab pointing at your options page.
_MANIFEST:
{
"name": "My extension",
...
"options_page": "options.html",
...
}
_CODE.HML:
<html>
<head><title>My Test Extension Options</title></head>
<script type="text/javascript">
// Saves options to localStorage.
function save_options() {
var select = document.getElementById("color");
var color = select.children[select.selectedIndex].value;
localStorage["favorite_color"] = color;
// Update status to let user know options were saved.
var status = document.getElementById("status");
status.innerHTML = "Options Saved.";
setTimeout(function() {
status.innerHTML = "";
}, 750);
}
// Restores select box state to saved value from localStorage.
function restore_options() {
var favorite = localStorage["favorite_color"];
if (!favorite) {
return;
}
var select = document.getElementById("color");
for (var i = 0; i < select.children.length; i++) {
var child = select.children[i];
if (child.value == favorite) {
child.selected = "true";
break;
}
}
}
</script>
<body onload="restore_options()">
Favorite Color:
<select id="color">
<option value="red">red</option>
<option value="green">green</option>
<option value="blue">blue</option>
<option value="yellow">yellow</option>
</select>
<br>
<button onclick="save_options()">Save</button>
</body>
</html>
name::
* McsEngl.crx'CASH-DIR@cptIt,
\Documents and Settings\HoKoNoUmo\Local Settings\Application Data\Google\Chrome\User Data\Default\Extensions
* You can find there code of installed extentions.
name::
* McsEngl.crx'ISOLATED-WORLD@cptIt,
As you might know, each tab in the Chrome browser runs in an isolated process. This is done both for stability and security but it also means that Chrome is very good at running many small “web browsers”. Extensions run in isolated processes as well. In fact, you could say that extensions run inside hidden tabs. To put it differently, an extension is just a web page you can’t see.
[http://supercollider.dk/2010/04/chrome-extensions-for-web-hackers-part-%E2%85%A1-background-pages-255]
name::
* McsEngl.crx'LOCAL-STORAGE@cptIt,
When you use localStorage from content scripts, you use the localStorage of the page, not the localStorage of the extension.
In order to get values from the localStorage of the extension, you will have to use message passing.
?PhistucK
Used_Local_Storage:
I guess only manual tracking is possible -
Length = 0;
for (x in localStorage)
Length += localStorage[x].length * 2; // Times 2 is because it is stored as UTF16.
That will be a fair estimation, I guess.
[PhistucK]
name::
* McsEngl.crx'MESSAGE-PASSING@cptIt,
* McsEngl.crx'Page-Communication@cptIt,
SOURCE:
* http://code.google.com/chrome/extensions/messaging.html
crx'ex.Message_from_ContentScritp:
Sending a request from a content script looks like this:
contentscript.js
================
chrome.extension.sendRequest({greeting: "hello"}, function(response) {
console.log(response.farewell);
});
crx'ex.Message_to_ContentScritp_in_SelectedTab:
This example demonstrates sending a message to the content script in the selected tab.
background.html
===============
chrome.tabs.getSelected(null, function(tab) {
chrome.tabs.sendRequest(tab.id, {greeting: "hello"}, function(response) {
console.log(response.farewell);
});
});
name::
* McsEngl.crx'POPUP-PAGE@cptIt,
name::
* McsEngl.crx.ex.POPUP@cptIt,
Is there a way to find if current window it is a tab or popup or is
there a better way to do this?
How about -
if (chrome.extension.getViews({type: "popup"}).length == 1)
console.log("I am in a popup")
else
console.log("I am not in a popup.");
name::
* McsEngl.crx'RESTART@cptIt,
False is the default.
True is the equivalent of Ctrl+F5 (without resending any form data, of course).
name::
* McsEngl.crx'PUBLISH@cptIt,
* McsEngl.crx'hosting@cptIt,
_PROCESS:
1) develop it locally and test at: chrome://extentions (load unpacked)
- commit to git repository, if you have.
2) zip all files and subdirectories and upload to
- https://chrome.google.com/webstore/developer/dashboard,
Developer Dashboard:
* https://chrome.google.com/extensions/developer/dashboard,
Hosting:
* http://code.google.com/chrome/extensions/hosting.html
Gallery information for developers: Extension gallery FAQs:
* http://www.google.com/support/chrome/bin/answer.py?answer=113909
Other Deployment Options:
* http://code.google.com/chrome/extensions/external_extensions.html,
Small tile - 440x280: View current
This small tile image has been rejected due to the following reasons:
Text is too small
Image is too blurry
name::
* McsEngl.crx'resource@cptIt,
_ADDRESS.WPG:
* http://developer.chrome.com/extensions/tut_migration_to_manifest_v2.html,
* https://developer.chrome.com/extensions/samples.html,
group: Chromium-extensions:
* http://groups.google.com/a/chromium.org/group/chromium-extensions/topics?hl=en
Making Your First Google Chrome Extension:
* http://tutorialzine.com/2010/06/making-first-chrome-extension//
Chrome Extensions for Web Hackers, Part I: Introduction
posted March 28th, 2010
* http://supercollider.dk/2010/03/chrome-extensions-for-web-hackers-245
Chrome Extensions for Web Hackers, Part II: Background Pages
posted April 18th, 2010,
* http://supercollider.dk/2010/04/chrome-extensions-for-web-hackers-part-%E2%85%A1-background-pages-255
Controlling desktop notifications in chrome extensions:
* http://www.fienipa.com/blog/controlling-desktop-notifications-chrome-extensions
name::
* McsEngl.crx'EXAMPLE@cptIt,
I put examples AND where information is lied, non only here.
Here mainly I put examples from MANY entities.
[2010-10-03]
name::
* McsEngl.crx'ex.Access-current-page-vars-functions@cptIt,
[crx] Proposition: add experimental API to access current web page js (vars, functions)
On 13 oct, 02:45, paulmillr <paulpmi...@gmail.com> wrote:
> I propose to add experimental API to access current web page variables
> and functions.
>
> For example, I want to build full-featured CoffeeScript console. But I
> can't do this because chrome extensions cannot access page vars. And
> console without access to variables is (almost) useless.
>
> What do you think about this?
I think it could be nice. Anyway, you *can* access to page variables
and functions but it's a bit tricky.
In order to insert a script in a page, you can use:
- SCRIPT element injection into the page from content-script
- location.href = "javascript: /* your script here */";
Then, if you need your content script to be able to communicate with
injected scripts, you can use:
- window.postMessage
- custom events
With these 2 "tricks", you should be able to code your CoffeeScript
console.
[gildas]
name::
* McsEngl.crx'ex.COMPUTED-STYLE@cptIt,
window.getComputedStyle(document.documentElement)
?PhistucK
On Wed, Oct 6, 2010 at 05:39, U.P. <umair.p@live.com> wrote:
I am working on a chromium extension for web developers. I want to
include the computed style (that appear in developer tools) in my
extension.
name::
* McsEngl.crx'ex.CURRENT-PAGE-FROM-BACKGROUND@cptIt,
chrome.browserAction.onClicked.addListener(
function(tab){
chrome.tabs.getSelected(null,function(tab)
{
chrome.tabs.executeScript(null, {code:"document.body.style.backgroundColor='red'"});
});
});
name::
* McsEngl.crx'ex.CURRENT-PAGE-FROM-CONTENT-SCRIPT@cptIt,
name::
* McsEngl.crx'ex.CURRENT-PAGE-FROM-POPUP@cptIt,
<script>
function click(color) {
chrome.tabs.executeScript(null,
{code:"document.body.style.backgroundColor='" + color.id + "'"});
window.close();
}
</script>
<div onclick="click(this)" id="red">red</div>
You should be doing something like this (in popup.html):
function doSomethingWithTabUrl(tab) {
// do whatever you need to do with src in this function,
// because it might not (read: probably wont) be available
// outside of it.
}
chrome.tabs.getCurrent(doSomethingWithTabUrl);
name::
* McsEngl.crx'ex.Display-Popup-From-ContextMentu@cptIt,
Mmm... something like -
var div = document.createElement("DIV");
div.style.position = "fixed";
div.style.top = "5px";
div.style.left = "5px";
div.style.width = "400px";
div.style.height = "400px";
div.style.backgroundColor = "black";
div.style.color = "white";
div.innerHTML = "Some <b>html</b>.";
document.body.appendChild(div);
[PhistucK]
name::
* McsEngl.crx'ex.locale@cptIt,
Report of existing locales and missing translations
* http://gist.github.com/631174
name::
* McsEngl.crx'ex.JSON@cptIt,
Ok, I used
chrome.bookmarks.getTree(function (tree)
JSON.stringify(tree)
}
to export in JSON, but now the problem is how to import it?
name::
* McsEngl.crx'ex.Save-File@cptIt,
Save to... the computer, the internet?
Computer - FileSystem API and FileReader API, I guess.
Internet - there is an upload support in AJAX, I think.
?PhistucK
On Sun, Oct 24, 2010 at 06:50, Derek ? <derek1906@gmail.com> wrote:
What is a good way to save .mp3 files?
(with an upload button in an extension's page)
Manually saving a dynamically created page
Dan dan.chicot@gmail.com to Chromium-exten.
show details 12:36 PM (43 minutes ago)
This worked, thank you very much indeed
On Sep 4, 6:34 am, Gildas <gildas.lorm...@gmail.com> wrote:
> Here is the only way I know to do this.
>
> Open an HTML page stored into your extension in the new tab. In this
> page, put a script that asks for the content to the background page
> and inserts it into the document. The title of the page will be used
> as a filename when saving the page.
>
> Warning: the opened page has the same permissions than the background
> page, you should only inject "trusted content" (e.g. no external
> resources).
name::
* McsEngl.crx.Chrome-Alpha by phunny.phacts@cptIt,
ADDRESS:
* https://chrome.google.com/extensions/detail/papfpipabpficccgpbkahpaldkfhhgnk
name::
* McsEngl.crx.Chrome-Screen-Splitter by jiajw0426@cptIt,
* https://chrome.google.com/extensions/detail/opbmmnbaobijfdmjfmeliikhhkhiboal?hl=en
Chrome Screen Splitter.
Split your chrome to two parts:left and right or top and bottom.you can change the url of any part.
name::
* McsEngl.crx.Chromey-Calculator by bwrobinett@cptIt,
* https://chrome.google.com/extensions/detail/acgimceffoceigocablmjdpebeodphgc?hl=en-US
name::
* McsEngl.crx.GROUP-CHARACTER@cptIt,
crx.Unicode_Converter bryanlynn.com
(3) - 105 users - Weekly installs: 22
UTF-8 formatted pages require unicode.
* https://chrome.google.com/extensions/detail/pdaicbicoecjecfnfiloanbhmfphdmkk#
* converts chars to Τ
name::
* McsEngl.crx.GROUP-EDITOR@cptIt,
crx.PageEdit by gildas
(9) - 423 users - Weekly installs: 46
Edit any HTML page into Chrome with this powerful WYSIWYG editor
* https://chrome.google.com/extensions/detail/ebkclgoaabaibghklgknnjdemknjaeic
crx.iDOC: by thaddee.tyl@gmail.com
* The Internet In-Page Editor. Edit any web page freely and save them.
* https://chrome.google.com/extensions/detail/eedkhkkodpoimgjngbeeejkgpbdgonbl
* http://github.com/espadrine/iDoc
crx.Chrome_Editor
(36) - 8,721 users - Weekly installs: 1,028
Edit HTML easily, right inside your browser.
Verified author: bryanlynn.com
* https://chrome.google.com/extensions/detail/nglgdmkkiemejlladcdjegcllaieegoe##
crx.Web_Editor by Derek
(8) - 164 users - Weekly installs: 317
Use me to change the any pages to the way you like it! :) Also you can remove ads that you don't want too.
* https://chrome.google.com/extensions/detail/claldafnnhbflndjbjlmlefpcifojcag#
name::
* McsEngl.crx.GROUP-SEARCH@cptIt,
crx.Search_the_current site:
* https://chrome.google.com/extensions/detail/jliolpcnkmolaaecncdfeofombdekjcp?hl=en
- The search is done not only on the 1 page you are currently viewing as [Ctrl]+[F] does but instead Google is used to "site search" in ALL pages of the site you are viewing at the time. Search websites the easy way!
crx.Search_Box by tirokea
(142) - 9,958 users - Weekly installs: 709
Search Box lets you to easily search on Google, Yahoo, YouTube, Bing, Twitter and more, with the help of a simple toolbar button
* https://chrome.google.com/extensions/detail/mknehpjhljpfaghmicofickbkdagooni?hl=en#
crx.Search_Center by tim.ker
(76) - 2,798 users - Weekly installs: 371
Quickly Search & re-search multiple sites without having to type your search terms again and again
* https://chrome.google.com/extensions/detail/ndfplmdnbnefomnjiknbpejdceedhdmf?hl=en#
name::
* McsEngl.crx.GROUP-TAB-MANAGEMENT@cptIt,
crx.Frame_two_pages by lubos.motl:
* https://chrome.google.com/extensions/detail/eldgpcphflnopbjadiaonofideekgdgm?hl=en
* Once you click at the extension's icon, the current tab will be merged with the previous one (on the left) into a frameset with two columns (frames) or rows (options offer 3 buttons: rows/columns/ad_hoc). They'll be ordered in the same way as the tabs (left, right).
name::
* McsEngl.crx.GROUP-TABLE-OF-CONTENTS@cptIt,
HTML5 Outliner by Dominykas Blyze:
* crx.Html5_Outliner,
* https://chrome.google.com/extensions/detail/afoibpobokebhgfnknfndkgemglggomo?hl=en
Chrome Outliner by genki.gthp.net:
* crx.Chrome_Outliner,
* https://chrome.google.com/extensions/detail/jlppdmdapoeahlgfmioblnpfhfgcigim?hl=en
EasyReader by anton.johansson
* crx.EasyReader,
(16) - 223 users - Weekly installs: 44
EasyReader can customize and improve the readability of long web articles
* https://chrome.google.com/extensions/detail/boamfheepdiallipiieadpmnklbhadhc
* Anton Johansson: http://portfolio.antonj.se// (sweeden)
Easy Reader by leximus
* https://chrome.google.com/extensions/detail/hbajbpkpelbiganplmkpapgedbhdpaok#
(15 Ratings) - 182 users - Weekly installs: 28
Make your read process more comfortable and easy.
Install
This is a little helper add-on. Basic idea is to let your eyes be always focused on needed information. It is usual situation when You are trying to extract needed text information from large media site (see sreenshoots) and your attention always goes anywhere on the page but not to needed text. Such situations are time-cost and not letting You 100% focus on reading. Even more, it is annoying You and it forcing your reading process to be hard and nervous.
name::
* McsEngl.crx.Google-Keep@cptIt,
* McsEngl.google-keep@cptIt,
_Description:
Quickly capture what’s on your mind and recall it easily wherever you are.
Save what’s on your mind.
Quickly save, access and organize the information you want with Google Keep. Create a text note, add a photo, or type up a quick list.
Notes are everywhere you are
Everything you create with Keep syncs seamlessly between the Android app (goo.gl/XTJqg) and on the web at Google Drive (drive.google.com/keep).
No connection? No problem.
With the Keep Chrome web app, any notes you create while you’re offline are synced back to the web and your other devices when your connection returns.
Your notes, your way
Create a to-do list with checkboxes, save a photo, customize notes with colors and more.
Reminders when and where you need them.
Use a time or location reminder to be reminded at the right time or place.
By installing this item, you agree to the Google Terms of Service and Privacy Policy at https://www.google.com/intl/en/policies/.
[https://chrome.google.com/webstore/detail/google-keep/hmjkmjkepdijhoojdojkdfohbdgmmhki/details]
name::
* McsEngl.crx.IE-TAB@cptIt,
You can install the IE Tab extension and set automatic opening in IE tab for certain URLs there.
Alternatively, you can keep on using Internet Explorer and install Google Chrome Frame, which will show pages with Chrome inside Internet Explorer.
name::
* McsEngl.crx.INSTALLED@cptIt,
* McsEngl.chrome'extension.installed@cptIt,
crx.GOOGLE_DICTIONARY:
* https://chrome.google.com/webstore/detail/google-dictionary-by-goog/mgijmajocgfcbeboacabfgobmjgjcoja,
- has pronunciations.
TRANSLATE_SELECTION:
* https://chrome.google.com/webstore/detail/translate-selection/goanabmlmgfinmjohhepcpffcnkeobjm,
FORCASTFOX:
* https://chrome.google.com/webstore/detail/forecastfox/ihffmkcfkejomlfnilnmkokcpgclhfeg,
SILVER-BIRD:
* https://chrome.google.com/webstore/detail/silver-bird/encaiiljifbdbjlphpgpiimidegddhic,
- twitter.
MY EXTENSIONS:
* https://chrome.google.com/webstore/detail/my-extensions/igejgfmbjjjjplnnlgnbejpkpdajkblm,
ALEXA:
* http://www.alexa.com/toolbar?utm_source=top-nav&utm_medium=www&utm_campaign=toolbar,
TAKE A BREAK:
* https://chrome.google.com/webstore/detail/take-a-break/kfcgkgmiedhpoalhpmalhjjcnhpkapgl,
APP LAUNCHER:
* https://chrome.google.com/webstore/detail/app-launcher/odmpalfplhaahlgnkkonchfhpegdcgjm,
- on webstore we can see out applications and manage them.
SPEED-DIAL 2:
* http://speeddial2.com//
HTML5 OUTLINER:
* https://chrome.google.com/webstore/detail/html5-outliner/afoibpobokebhgfnknfndkgemglggomo,
RESIZE ANYTHING:
* https://chrome.google.com/webstore/detail/resize-anything/nofodndahephmgeebcefmilcncabjecd,
PERIODIC TABLE OF ELEMENTS:
* https://chrome.google.com/webstore/detail/periodic-table-of-element/jnohcckikkoebhhponbeeckkdhomgffa,
GOOGLE TRANSLATE:
* https://chrome.google.com/webstore/detail/google-translate/aapbdbdomjkkjkaonfhkkikfgjllcleb,
SCREEN CAPTURE:
* https://chrome.google.com/webstore/detail/screen-capture-by-google/cpngackimfmofbokmjmljamhdncknpmg,
FIREBUG LITE FOR CHROME:
* https://chrome.google.com/webstore/detail/firebug-lite-for-google-c/bmagokdooijbeehmkpknfglimnifench,
ALL SEARCH 2:
* https://chrome.google.com/webstore/detail/all-search-2/ablgfdbkccjcpfchcaiboagcmcjajkoa,
- goes to wikipedia, etc.
name::
* McsEngl.crx.jsshell by webdev.hb@cptIt,
_ADDRESS:
* https://chrome.google.com/extensions/detail/kmgmkbicahmbceidoidjbkbpkfogaldh#
jsshell is a small command window placed at the bottom of your Chrome browser that lets you run jQuery and jLinq commands no matter what page you're on! Just type in a script into the editor then press CTRL+Enter to run it!
name::
* McsEngl.crx.My-Shortcats@cptIt,
My Shortcuts
(321 Ratings) - 29,722 users - Weekly installs: 1,036
A simple extension that allows you to quickly create a new Email, Calendar Event, or Google Doc with minimal clicks.
[https://chrome.google.com/extensions/detail/bjcpobipejlbogodeiendpdgcdambjgo#]
name::
* McsEngl.crx.PDFescape-Free-PDF-Editor@cptIt,
PDFescape Free PDF Editor
(7) - 2,882 users - Weekly installs: 381
Edit, form fill, and view pdf files directly in Google Chrome, free.
Verified author: www.pdfescape.com
* https://chrome.google.com/extensions/detail/gdefoklganepljiopdnglodohlgfikkl
name::
* McsEngl.crx.READER@cptIt,
name::
* McsEngl.crx.MagicScroll (ePub)@cptIt,
Read your favorite books.
MagicScroll is a minimalist ebook reader.
Unique Scrolling Experience.
Read books naturally with MagicScroll or turn on auto-scroll to scroll the page without moving the text.
Read millions of books with MagicScroll.
MagicScroll works with the popular ePUB format.
MagicScroll can read books from online libraries, like Project Gutenberg
Full Offline Support
MagicScroll works without an internet connection.
Sign in to access your books on iPhone, iPad and Android devices.
We reply to all our emails. Please get in touch at support@magicscroll.net
[https://chrome.google.com/webstore/detail/magicscroll-ebook-reader/ghgnmgfdoiplfmhgghbmlphanpfmjble]
name::
* McsEngl.crx.Regular-Expression-Checker by bizsimon@cptIt,
_ADDRESS:
* https://chrome.google.com/extensions/detail/pgnkpcgniljiolidjmodgfljeomjjiha#
name::
* McsEngl.crx.SECURITY@cptIt,
name::
* McsEngl.crx.KB-SSL-Enforcer@cptIt,
KB SSL Enforcer
(181)Productivityfrom https://kbit.dk40,361 users
name::
* McsEngl.crx.SPEED-DIAL@cptIt,
_ADDRESS:
* https://chrome.google.com/extensions/detail/dgpdioedihjhncjafcpgbbjdpbbkikmi
name::
* McsEngl.crx.TableOfContents (toc)@cptIt,
* McsEngl.crxToc@cptIt,
* McsEngl.toc@cptIt578i,
* McsEngl.TableOfContents@cptIt578i,
* McsEngl.TableOfContents-chrome-extension@cptIt,
* McsEngl.table-of-contents-chrome-extension@cptIt,
_ADDRESS.WPG:
* http://synagonism.net/program/table-of-contents//
* https://chrome.google.com/extensions/detail/eeknhipceeelbgdbcmchicoaoalfdnhi
* https://chrome.google.com/extensions/developer/dashboard
* http://www.google.com/analytics//
* https://chrome.google.com/webstore/detail/eeknhipceeelbgdbcmchicoaoalfdnhi##
* https://github.com/nikkas/TableOfContents,
* http://nikkas.github.com/TableOfContents/git-repository.html,
_DESCRIPTION:
* Creates the Table-of-Contents as an expandable-tree of a selected-tab, using the algorithm defined in HTML-5 spec (http://dev.w3.org/html5/spec/Overview.html#outlines).
Also, clicking on a heading-element in the page, highlights in the toc-tree this heading and expands ONLY its parent-nodes. In a HTML-5 doc (using the section-element, clicking anywhere in the page, shows your position in the toc-tree).
Licence: GPL.
This is my first extension. Actually, I have learned JavaScript writing it.
Also this year (2010), I published my JAVA open-source HtmlMgr (http://htmlmgr.sourceforge.net/) program with which I am doing similar things with TableOfContents. But java leaves in a prehistoric era in relation to html. With HtmlMgr I propose the usage of a common-format for IDs representing the structure of a doc. This way anyone can refer INSIDE any html-doc.
Many thanks to those I have studied their codes:
1) HTML5 Outliner by Dominykas Bly�e. I used his implementation of html5-outline-algorithm.
2) http://www.dhtmlgoodies.com/ for the expandable-tree code.
3) EasyReader extension of Anton Johansson
4) Chrome Outliner by genki.gthp.net
5) ...
_WebAnalytics:
* https://www.google.com/analytics/settings/home?scid=19285371
<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-19285371-1']);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script>
=============== on background ====================
<html>
<head>
<script src='http://www.google-analytics.com/ga.js' type='text/javascript'></script>
<script type="text/javascript">
// INSERT YOUR GOOGLE ANALYTICS ID HERE
var analyticsID = "UA-XXXXXXX-X";
// TRACKER OBJECT
var tracker;
// TYPICAL INTEGRATION INTO YOUR INITIALISATION
function init() {
setupTracking();
}
// SETUP
function setupTracking() {
if((analyticsID != undefined) && (typeof(_gat) == 'object')) {
try {
tracker = _gat._getTracker(analyticsID);
tracker._setAllowAnchor(true);
tracker._setDomainName("none");
tracker._setAllowLinker(true);
// SAMPLE PAGEVIEW CALL (SUGGESTED FOR BACKGROUND PAGE)
trackPageview('/session');
}
catch(err) {
// INTEGRATE WITH YOUR ERROR HANDLING
// alert(err);
}
}
}
function trackPageview(page) {
if(analyticsID != undefined) {
return tracker._trackPageview(page);
}
/* alert("Page tracking was successful? " + success + "\n\n" +
"page: " + page + "\n"); */
}
function trackEvent(category, action, optional_label, optional_value) {
if(analyticsID != undefined) {
return tracker._trackEvent(category, action, optional_label, optional_value);
}
/* alert("Event tracking was successful? " + success + "\n\n" +
"category: " + category + "\n" +
"action: " + action + "\n" +
"optional_label: " + optional_label + "\n" +
"optional_value: " + optional_value + "\n"); */
}
</script>
</head>
<body onLoad="init();">
</body>
</html>
How can I provide support for users of my extension?
You can set up discussion groups to communicate with your users. One way of doing so is through Google Groups.
name::
* McsEngl.crxToc'bug@cptIt,
_BadgeText:
* when we have 2 tabs with toc, closing one, the badgetext disapears.
==> to be 'on' until all toc will close. 2013-06-20.
name::
* McsEngl.crxToc'FILE@cptIt,
_LIST:
* manifest.json 677 B 12/6/10 4:35:43 PM
* README.md 372 B 11/13/10 6:22:29 PM
* toc-background.html 2456 B 12/6/10 4:34:39 PM
* toc-img-128.png 553 B 11/13/10 6:22:29 PM
* toc-img-16.png 210 B 11/13/10 6:22:29 PM
* toc-img-48.png 409 B 11/13/10 6:22:29 PM
* toc-img-item.png 269 B 11/13/10 6:22:29 PM
* toc-img-minus.png 267 B 11/13/10 6:22:29 PM
* toc-img-plus.png 269 B 11/13/10 6:22:29 PM
* toc-jquery-1.4.3.min.js 76.1 kB 11/13/10 6:22:29 PM
* toc-splitter.js 4.7 kB 12/6/10 4:39:13 PM
* toc.css 1199 B 12/6/10 4:37:39 PM
* toc.js 27.4 kB 12/6/10 4:31:03 PM
name::
* McsEngl.crxToc'GitRepo@cptIt,
SENARIO-MASTER:
* changes at g:/file1/TableOfContents
* copy on git (\TableOfContents)
SENARIO-MASTER:
* open git/bash (paraphrase on keepass/GitHub)
* cd \tableofcontents
* ls
** $ git checkout master //displays the 'master' brance
** copy changes //from d:/file1a/tableofcontents
- run 'git status' to see your changes,
* $ git add file-name //for new files
* $ git rm "filename" //for files to remove
* $ git commit -a -m "version 2010.12.6.3" //with "
* $ git tag v2010.12.6.3
* $ git push github
* logout
===
2013-11-03:
fatal: The current branch master has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream github master
SENARIO-GH-PAGES:
* open git/bash
* cd \tableofcontents
* ls
* $ git checkout gh-pages
* ls
* make changes.
* $ git commit -a -m "git-repo versioning"
* $ git push github gh-pages
* logout
$ git config -l
core.symlinks=false
core.autocrlf=true
color.diff=auto
pack.packsizelimit=2g
help.format=html
http.sslcainfo=/bin/curl-ca-bundle.crt
sendemail.smtpserver=/bin/msmtp.exe
user.name=Kaseluris-Nikos-1959
user.email=kaseluris.nikos@gmail.com
merge.tool=kdiff3
mergetool.kdiff3.path=c:/Program Files/KDiff3/kdiff3.exe
diff.guitool=kdiff3
difftool.kdiff3.path=c:/Program Files/KDiff3/kdiff3.exe
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
remote.github.url=git@github.com:nikkas/TableOfContents.git
remote.github.fetch=+refs/heads/*:refs/remotes/github/*
branch.gh-pages.remote=github
branch.gh-pages.merge=refs/heads/gh-pages
gui.wmstate=normal
gui.geometry=1094x457+27+27 251 206
name::
* McsEngl.crxToc'HTML-PAGE@cptIt,
<html>
<head>
</hed>
<body>
<div id="idSplitterContainer">
<div id="idTocDivToc">
<ul>the toc</ul>
</div>
<div id="idSplitBar">
</div>
<div id="idTocDivCntnt">
...the original page
</div>
</div>
</body>
</html>
name::
* McsEngl.crxToc'publishing@cptIt,
_PROCESS:
1) make modifications on \file1a\tableofcontents\master
- put new version on manifest!!!
2) copy on git-repo: \tableofcontents
3) run git-and-'push'#ql:crxtoc'gitrepo# to github
4) zip the files and publish at: https://chrome.google.com/extensions/developer/dashboard,
5) update page at synagonism.net.
name::
* McsEngl.crx.Take-A-Break@cptIt,
by happyanyday
(5) - 58 users - Weekly installs: 8
Remind you when to take a break while surfing.
* https://chrome.google.com/extensions/detail/kfcgkgmiedhpoalhpmalhjjcnhpkapgl
name::
* McsEngl.crx.THEME@cptIt,
_DESCRIPTION:
A theme is a special kind of extension that changes the way the browser looks. Themes are packaged like regular extensions, but they don't contain JavaScript or HTML code.
[https://developer.chrome.com/extensions/themes.html]
name::
* McsEngl.crx.TRANSLATING@cptIt,
_SPECIFIC:
* Auto-Translate: https://chrome.google.com/webstore/detail/auto-translate/obgoiaeapddkeekbocomnjlckbbfapmk,
name::
* McsEngl.crx.TTS@cptIt,
_ADDRESS.WPG:
* http://www.sitepoint.com/create-text-to-speech-chrome-extension//
name::
* McsEngl.crx.Wikipedia-Companion - Mini Wiki Browser by mongolian2010@cptIt,
* https://chrome.google.com/extensions/detail/dhgpkiiipkgmckicafkhcihkcldbdeej#
name::
* McsEngl.pgmCrm'JavaScript@cptIt,
Chrome uses V8 JavaScript Engine, it implements ECMAScript ECMA-262, http://www.ecma-international.org/publications/standards/Ecma-262.htm.
For more information regarding V8, you can see their project page http://code.google.com/p/v8/. For references and syntax, you can always read the standards mentions above.
-chromium-dev
+chromium-discuss
This should be in the discuss mailing list instead :) or perhaps in the V8 mailing lists.
Kind regards,
Mohamed Mansour
name::
* McsEngl.pgmCrm'layout-engine@cptIt,
_DESCRIPTION:
Google Chrome is a freeware web browser[10] developed by Google. It used the WebKit layout engine until version 27 and, with the exception of its iOS releases, from version 28 and beyond uses the WebKit fork Blink.
[http://en.wikipedia.org/wiki/Google_Chrome]
name::
* McsEngl.pgmCrm'PLUGINS@cptIt,
about:plugins:
shows the installed plugins, from where you can remove them.
name::
* McsEngl.pgmCrm'RUN@cptIt,
_ADDRESS.WPG:
* http://chrisbitting.com/2014/03/04/allow-local-file-access-in-chrome-windows//
No, this is a command line switch that is available for the official build at runtime. Just add it.
Close Chrome entirely (Wrench-->Exit).
Start menu-->Run...-->chrome.exe --use-system-ssl-->OK.
name::
* McsEngl.pgmCrm'Settings@cptIt,
chrome://settings/handlers:
* protocol handler.
* remove gmail handler.
List of Chrome URLs
chrome://accessibility
chrome://appcache-internals
chrome://blob-internals
chrome://bookmarks
chrome://cache
chrome://chrome-urls
chrome://conflicts
chrome://crashes
chrome://credits
chrome://dns
chrome://downloads
chrome://extensions
chrome://flags
chrome://flash
chrome://gpu
chrome://history
chrome://inspect
chrome://ipc
chrome://media-internals
chrome://memory
chrome://nacl
chrome://net-internals
chrome://newtab
chrome://omnibox
chrome://plugins
chrome://policy
chrome://predictors
chrome://print
chrome://profiler
chrome://quota-internals
chrome://settings
chrome://signin-internals
chrome://stats
chrome://sync-internals
chrome://terms
chrome://tracing
chrome://user-actions
chrome://version
chrome://view-http-cache
chrome://webrtc-internals
For Debug
The following pages are for debugging purposes only. Because they crash or hang the renderer, they're not linked directly; you can type them into the address bar if you need them.
chrome://crash
chrome://kill
chrome://hang
chrome://shorthang
chrome://gpuclean
chrome://gpucrash
chrome://gpuhang
chrome://ppapiflashcrash
chrome://ppapiflashhang
Google Chrome 27.0.1453.116 (Official Build 206485) m
OS Windows
WebKit 537.36 (@152168)
JavaScript V8 3.17.6.15
Flash 11.7.700.225
User Agent Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36
Command Line "\Documents and Settings\HoKoNoUmo\Local Settings\Application Data\Google\Chrome\Application\chrome.exe" --flag-switches-begin --enable-sync-favicons --enable-full-history-sync --sync-keystore-encryption --flag-switches-end
Executable Path \Documents and Settings\HoKoNoUmo\Local Settings\Application Data\Google\Chrome\Application\chrome.exe
Profile Path \Documents and Settings\HoKoNoUmo\Local Settings\Application Data\Google\Chrome\User Data\Default
Variations 717f26fa-663ea14f
f9b252d0-fd526c81
b533da8e-b7749fd1
65957c53-1c6cadd0
ff3fc1a6-766fa2d
7f6da4bf-92e135fa
75f7fb7e-766fa2d
24dca50e-837c4893
ca65a9fe-91ac3782
3028188e-d60b5a5f
5a3c10b5-e1cc0f14
244ca1ac-4ad60575
f47ae82a-746c2ad4
246fb659-92bb99a9
f296190c-d7f6b13c
4442aae2-a90023b1
75f0f0a0-a5822863
e2b18481-3a9ae350
e7e71889-e1cc0f14
[2013-07-03]
name::
* McsEngl.pgmCrm'user-stylesheet@cptIt,
2. Locate User Stylesheet File
Open a URL "about:version". You can see "Profile Path" in that page. The location of the user stylesheet file is Profile Path -> User StyleSheets -> Custom.css.
name::
* McsEngl.pgmCrm'shortcut@cptIt,
* McsEngl.pgmCrm'key@cptIt,
name::
* McsEngl.pgmCrm'Web-App@cptIt,
* McsEngl.conceptIt578.1,
* McsEngl.chrome'application@cptIt578.1, {2012-10-11}
* McsEngl.Chrome-Web-Apps@cptIt578.1,
_DESCRIPTION:
PhistucK
2012-10-11 10:08 AM (17 minutes ago)
to pchazal, chromium-discu.
Hosted Chrome applications are websites with additional permissions (like geolocation, notifications, unlimited storage). Instead of asking the user for all of the permissions separately, the user permits everything when they install the application.
Packaged applications have much more capabilities, they can change stuff in the browser and more and do more things than regular websites.
See the documentation for more information about the additional capabilities.
?PhistucK
* http://developer.chrome.com/apps/about_apps.html,
===
Apps and Extensions: A Different User Experience
There’s no “better” approach here; apps and extensions are simply different creatures. Let’s understand apps first. They are just how they sound: applications you can run inside your browser with a dedicated user interface and, typically, rich user interaction. We’ve already had the concept of “web apps” in the browser for a few years, as something more rich and interactive than a website, but less cumbersome and monolithic than a desktop application. Examples include games, photo editors, and video players; all of these categories are viable as tightly focused apps running inside the browser. Google Chrome is just formalizing the web app concept in a way that will be familiar to anyone who’s used apps on a smartphone.
How about extensions? Extensions also provide functionality, but unlike apps, there is little or no UI component. Instead, they extend the functionality of Google Chrome and the websites being viewed in it. For example, they can extend Google Chrome by adding a new button to the address bar, such as an ever-present currency converter. Buttons like this can also apply to the current website being viewed—for example, click the currency converter button to convert all prices on the website you’re viewing. Similarly, you can introduce new items to the context menu, change the behavior of the omnibox (the input field on the address bar), access the user’s browsing history (with consent), and much more. You can alter web pages too—for example, embed a “mail this” button next to every link in every page, or customize the layout of your favorite website.
Compared to apps, extensions cut across websites and web apps; they are usually in effect across all websites (though some are site-specific). Apps don’t combine with other apps in this way; they run standalone, like any regular website. You can get a better idea of what extensions can do by browsing the Extensions Gallery.
...
The main difference between apps and extensions, from a technical perspective, is a special “launch” parameter in the manifest. It’s present only in apps, and it tells Google Chrome what to show when the user starts up an installed app. There are also a whole bunch of parameters specific to extension functionality—for example, you would use the “page_action” parameter to add a button to the address bar. So are these things mutually exclusive—you either have a “launch” parameter or have the extension parameters? Not quite...
[http://code.google.com/chrome/webstore/articles/apps_vs_extensions.html]
Major Differences Between Chrome Extension and Chrome Web Apps
One of the major differences between Chrome extensions and web applications is their location. Majority of the Chrome extensions can be downloaded from Chrome Extensions Gallery whereas Chrome Web Apps can be installed from Chrome Web Store.
Another major difference between Chrome extensions and web apps is the fact that while extensions are used to enhance the functionality of the Chrome Browser, web apps run within the browser having a different user interface. Unlike web applications, extensions have little or sometimes no UI component.
From a technical perspective the major difference between Chrome Apps and extensions is the presence of “launch” parameter in apps which indicates Chrome to show when user starts an application installed by him/her.
[http://www.chromeplugins.org/extensions/chrome-web-apps-extensions-spot-the-difference/]
name::
* McsEngl.pgmCrm'Web-page-certificate@cptIt,
_LINUX:
Marco netuse@lavabit.com via chromium.org
3:28 PM (1 hour ago)
to chromium-discu.
2012-10-15 Deleterios:
Hi Deleterios
> > How can I tell chromium to trust the sites certificate?
> >
>
> Did you try this:
> http://code.google.com/p/chromium/wiki/LinuxCertManagement ?
Whow!! I executed this command:
certutil -d sql:$HOME/.pki/nssdb -A -t "P,," \
-n <certificate nickname> -i <certificate filename>
and it works perfectly, no annoying message any more. The setting is
persistent across restarts. Such a simple solution. You're my hero!
Thanks a million!
name::
* McsEngl.pgmFfx'addon@cptIt,
_DESCRIPTION:
Add-ons are installable enhancements to the Mozilla Foundation's projects, and projects based on them. Add-ons allow the user to add or augment application features, use themes to their liking, and handle new types of content.
[https://en.wikipedia.org/wiki/Add-on_%28Mozilla%29]
name::
* McsEngl.pgmFfx'addon.SPECIFIC@cptIt,
_SPECIFIC:
* https://addons.mozilla.org/en-US/firefox/addon/pdfjs//
_SPECIFIC:
* dictionary##
* extension##
* plugin
* theme
===
What are the different types of add-ons?
There are several kinds of add-ons that customize Firefox in different ways:
Extensions add new features to Firefox or modify existing functionality. There are extensions that allow you to block advertisements, download videos from websites, integrate more closely with social websites, and add features you see in other applications.
Complete Themes change the entire appearance of Firefox, usually including icons, colors, dialogs, and other visual styles.
Themes are lightweight themes that use background images to customize your Firefox toolbars.
Search Providers add additional choices to the search box dropdown. These providers allow you to quickly search any website.
Dictionaries & Language Packs add support for additional languages to Firefox.
Plugins help Firefox display or understand different types of media, such as Adobe Flash or Apple Quicktime.
[https://addons.mozilla.org/en-US/faq]
name::
* McsEngl.pgmFfx'addon.DICTIONARY@cptIt,
* McsEngl.ffx'dictionary@cptIt,
name::
* McsEngl.pgmFfx'addon.EXTENSION (xpi)@cptIt,
* McsEngl.ffx'extension@cptIt577i,
* McsEngl.xpi@cptIt,
_DESCRIPTION:
Extensions add new functionality to Mozilla applications such as Firefox, SeaMonkey and Thunderbird. They can add anything from a toolbar button to a completely new feature. They allow the application to be customized to fit the personal needs of each user if they need additional features, while keeping the applications small to download.
Extensions are different from plugins, which help the browser display specific content like playing multimedia files. Extensions are also different from search plugins, which plug additional search engines in the search bar.
===
Extensions are packaged and distributed in ZIP files or Bundles, with the XPI (pronounced “zippy”) file extension.
[https://developer.mozilla.org/en/Building_an_Extension]
name::
* McsEngl.xpi'directory@cptIt,
MyExt/
chrome/
chrome/chromeFiles/
chrome/chromeFiles/content/
defaults/
defaults/preferences/
[http://www.rietta.com/firefox/Tutorial/conf]
name::
* McsEngl.xpi'file.chrome.manifest@cptIt,
* McsEngl.xpi'manifest-file@cptIt,
content sample chrome/chromeFiles/content/
This line says that for the chrome package named 'sample', Firefox can find the content files at the location chrome/chromeFiles/content which is a path relative to the location of chrome.manifest (you created this directory above).
[http://www.rietta.com/firefox/Tutorial/conf]
name::
* McsEngl.xpi'file.install.rdf@cptIt,
* McsEngl.xpi'install-manifest@cptIt,
* McsEngl.xpi'install.rdf@cptIt,
_EXAMPLE:
<?xml version="1.0"?>
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:em="http://www.mozilla.org/2004/em-rdf#">
<Description about="urn:mozilla:install-manifest">
<em:id>sample@example.net</em:id>
<em:version>1.0</em:version>
<em:type>2</em:type>
<!-- Target Application this extension can install into,
with minimum and maximum supported versions. -->
<em:targetApplication>
<Description>
<em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
<em:minVersion>1.5</em:minVersion>
<em:maxVersion>3.6.*</em:maxVersion>
</Description>
</em:targetApplication>
<!-- Front End MetaData -->
<em:name>sample</em:name>
<em:description>A test extension</em:description>
<em:creator>Your Name Here</em:creator>
<em:homepageURL>http://www.example.com/</em:homepageURL>
</Description>
</RDF>
_xpi'ID:
id: This is this value which uniquely identifies your extension. This ID should simply be your email address. This ensures that the ID will be different than those of other extensions. It is possible to use a GUID as well, but this is no longer necessary or recommended.
[http://www.rietta.com/firefox/Tutorial/conf]
_xpi'type:
type: This integer value represents the type of addon being installed. For an extension, this number should always be 2.
[http://www.rietta.com/firefox/Tutorial/conf]
_xpi'version:
version: This string identifies the version of the extension being installed. The version number is completely up to you, however it is recommended that you use versions less than 1.0 when in development stages. When you feel confident your extension works well, you may make the version be 1.0. Future improvements should increase the version number as appropriate. For Firefox 1.5, a version string consists of one or more version sections, separated with dots. Each version section is a sequence of four parts : <number-a><string-b><number-c><string-d>, where each of the parts is optional. Numbers are integers base 10, and strings are ASCII. Example: 1b2a.
[http://www.rietta.com/firefox/Tutorial/conf]
_xpi'targetApplication:
The <em:minVersion> and <em:maxVersion> fields simply tell Firefox which versions of Firefox the extension is designed for. These values will be compared to the value of the app.extensions.version preference and can be different from the actual version of Firefox (yes, it is annoying). For example, Firefox versions 1.0 - 1.0.6 all have app.extensions.version of 1.0.
[http://www.rietta.com/firefox/Tutorial/conf]
The last section of data describes your extension:
name: This line simply defines the name of your extension and is intended for display in the UI of Firefox.
description: This line should describe the functionality of your extension and is intended to be displayed in the UI. It should fit on one line in order to display properly in the user interface.
creator: This line should contain your name and will be used to display your name in the UI.
homepageURL: This line is optional and is simply just a link to the author's homepage. If you have a personal homepage that you would like to reference, put it here.
[http://www.rietta.com/firefox/Tutorial/conf]
name::
* McsEngl.xpi'file.javascript@cptIt,
* McsEngl.xpi'file.script@cptIt,
_DESCRIPTION:
All of the guts of your extension will be written in JavaScript. If you already know JavaScript than you are good to go! If you are new to JavaScript it is highly recommended that you read through the next section and the supporting documentation to get used to the syntax.
All of your JavaScript code files should go in the content directory of your extension. This is where the XUL files go as well, so they will be able to easily reference the code. Just insert the following line in an XUL file that needs to run functions from your files...
<script type="application/x-javascript" src="chrome://hpsched/content/mycode.js" />
Make sure you use the chrome URI so that Firefox can find the file correctly.
[http://www.rietta.com/firefox/Tutorial/backend]
name::
* McsEngl.xpi'file.language@cptIt,
* McsEngl.xpi'language-file@cptIt,
name::
* McsEngl.xpi'file.preferences@cptIt,
* McsEngl.xpi'file.options@cptIt,
_DESCRIPTION:
In most cases you will want to set what should be the default setting for a preference. For example, in the Home Page Scheduler www.google.com is the default startupHomePage if the user does not provide one. You may create these default preferences in a file within your defaults/preferences directory (you created this directory earlier). All .js files within this directory will be loaded by the Preference System when necessary, so the name of your file does not matter. We chose to use our package name: hpsched.js.
Within this file you may add lines like this:
pref("extensions.hpsched.defaultHomePage", "www.google.com");
pref("extensions.hpsched.schedules", "");
Notice that, by default, no scheduled events are created, so we just initialized this to an empty string.
[http://www.rietta.com/firefox/Tutorial/prefs]
Referencing from JavaScript:
The steps necessary to reference the preferences system from within the JavaScript code could have been made simpler, but it is not too bad. First, your file must have access to the Preference Manager component. To do that, you must add the following line of code to your file:
var prefManager = Components.classes["@mozilla.org/preferences-service;1"]
.getService(Components.interfaces.nsIPrefBranch);
Now that you have access to the preference manager you can get and set preferences using getIntPref()/getBoolPref()/getCharPref() and setIntPref()/setBoolPref()/setCharPref(). These functions are very straight forward and have been used in the code samples above.
[http://www.rietta.com/firefox/Tutorial/prefs]
name::
* McsEngl.xpi'file.xul@cptIt,
* McsEngl.xpi'file.interface@cptIt,
* McsEngl.xpi'xul@cptIt,
_GENERIC:
* firefox-xul#ql:ffx'xul#
_DESCRIPTION:
Most Firefox extensions have one goal in common: wanting to add or change some graphical element(s) in Firefox. Fortunately for us, adding and modifying GUIs (Graphical User Interfaces) is quite easy thanks to the decision to create an interfacing language specifically for Firefox, from the ground up. This language is called XUL (XML User Interface Language, pronounced zool) and is not too difficult to learn, as it follows the normal XML syntax.
Graphical elements, such as buttons, lists, menus, and windows, are all XUL elements that have been placed into an XUL file and loaded by the browser. XUL files are always found within the content section of a Chrome package. Remember the last step when we added the content line to the chrome.manifest? That told Firefox that the XUL files for that package, sample, could be found in that content directory. Thus, when making GUIs just put the .xul files in your content directory, along with any JavaScript files that will be needed.
[http://www.rietta.com/firefox/Tutorial/guis]
name::
* McsEngl.xpi'publishing@cptIt,
* McsEngl.xpi'distributing@cptIt,
_DESCRIPTION:
The best way to distribute your new Firefox extension is through Mozilla's developer website. The "Developer Control Panel" allows you to add/remove new versions of your extension, add/remove screenshots, update the compatibility information, and more. Most importantly, users will be able to download and install your extension through the built-in extension retrieval system. The URL is http://addons.mozilla.org/developers/.
You will need to register with Mozilla to be able to use this service. Click "Join Mozilla Update!" in the bottom right hand corner to register. You will need to check your email to complete the registration process (the email was sent immediately for us). Once you are logged in you will have the opportunity to upload your new extension. Please note that it will take several days for your extension to be approved by Mozilla, this limits how much 'junk' can be posted to the website.
Once accepted your new Firefox extension will be available along with other developers' extensions at https://addons.mozilla.org/extensions/?application=firefox. You can also find this website through Firefox by clicking Tools, then Extensions, and then clicking the "Get More Extensions" link.
If you choose to host your Firefox extension on your own website, make sure that you serve it as application/x-xpinstall (this will be the default on most servers). This will allow people using Firefox to automatically install your new extension just by clicking the link!
[http://www.rietta.com/firefox/Tutorial/dist]
name::
* McsEngl.xpi'puckaging@cptIt,
_DESCRIPTION:
Simply follow these two steps to package your extension:
Open up your 'MyExt' folder and create a zip file containing all of the files and folders. Note that you should not zip up the MyExt folder itself, instead zip of the files and folders that are inside it.
Rename the file extension from .zip to .xpi.
The name of your .xpi file does not matter; just pick something that makes sense to you. To test your package you can simply drag the .xpi file into your Firefox browser. Once you let go of the file, Firefox should recognize it as an extension and ask you if you would like to install it. Say yes!
Your Firefox extension will be unverified and thus will make you wait a few seconds before you can install it. This is to ensure you understand there could be bad code within the file. Verifying your extension requires a lot of work that is beyond this tutorial (it is quite expensive, too).
[http://www.rietta.com/firefox/Tutorial/dist]
name::
* McsEngl.xpi'resource@cptIt,
_ADDRESS.WPG:
* https://developer.mozilla.org/en/Extensions,
* https://addons.mozilla.org/en-US/developers//
=== tutorial
* https://developer.mozilla.org/en-US/docs/XUL/School_tutorial/The_Essentials_of_an_Extension?redirectlocale=en-US&redirectslug=XUL_School%2FThe_Essentials_of_an_Extension,
* http://www.rietta.com/firefox/Tutorial/overview,
* https://developer.mozilla.org/en/docs/Building_an_Extension,
name::
* McsEngl.xpi'security@cptIt,
_DESCRIPTION:
Writing Secure Code
Anytime an application (such as Firefox) allows user code to execute without being validated can open up security vulnerabilities. As a developer it is your responsibility to ensure that your extension does not open any vulnerabilities to the Firefox browser.
While most extension code is JavaScript, it has significantly more permissions than ordinary JavaScript found on a website. For example, JavaScript within an extension that is registered with the Mozilla Chrome registry has access to the local file system. When building a new extension, you should take into security concerns from day one.
Users should also be cautious when downloading and installing extensions. Fortunately, now that you know how to develop extensions, you can spend time reading through the source code of an extension before you choose to install it on your computer!
Prevention
Maintaining a secure browser is important business. The Firefox source code is maintained by a large number of developers and reviewed by many security experts. However, a particular extension is less likely to be reviewed by as many people. Unfortunately, a vulnerability in an extension is also a vulnerability in the browser that exposes all users to potential harm.
Once attacks are developed for a vulnerability they spread rapidly over the Internet and can often be used for nasty things such as identity theft. While more attention is generally given to security after something bad happens, an ounce of prevention is worth a pound of cure (Building, 19).
After you have finished your extension, you should monitor the various security reporting mailing lists and databases, including Bugtraq, CERT Advisories, and the RISKS digests. Look for vulnerability reports for similar extensions and premptively fix similar problems in yours.
Bugs, Flaws, and Vulnerabilities
To understand the risk in any given software system, it is important to consider how vulnerabilities are identified and exploited. Problems arise in the presence of a software bug or design flaw, which are often the result of inaccurate assumptions. There is an every growing volume of online documentation and some very good books on topics of exploiting software and building secure software. It is important to be familiar with these topics and learn from historical exploits because "related programming errors give rise to similar exploit techniques" (Exploit, 38).
A software exploit takes advantage of a vulnerability to cause the program to do something that it was not intended to do. For example, it may allow an attacker to gain access to a user’s private information and make changes to someone else’s computer system. One of the most dangerous forms of attack is called an arbitrary code execution, which can allow spy-ware and viruses to be installed and many nasty things.
Bugs and flaws in a piece of software cause vulnerabilities. A bug is a software problem that is caused by simple implementation problems, such as not explicitly initializing a variable or misusing a system call. Whereas a bug can often easily be fixed by code modifications, a flaw is a much deeper problem. A flaw is a design decision that can be exploited despite implementation.
Lessons from the Greasemonkey Security Flaw
Greasemonkey is a popular Firefox extension that allows you to create scripts that can add new features to a page, remove features from a page, fix a page that is broken, or add data from other websites to a page. For example, a lot of people use Greasemonkey to insert a Delete button next to the archive button in Gmail. Some of the GreaseMonkey user scripts affect specific sites, some can affect other extensions, and some can apply to all sites. This kind of powerful manipulation has serious security implications and you can totally screw up the visuals of certain websites. However, the developers of the extension really didn't consider the security angle too much. They had a real relaxed attitude about it. Aaron Boodman, one of the developers, said: "User scripts run in content's security context. I don't see any possible problems". However, Mark Pilgrim, one of the main early adopters of GreaseMonkey disovered a huge security hole that would allow data to be leaked to remote sites.
This was a huge embaressment intially to the developers of GreaseMonkey as well as the open source community. It became a big deal and users were advised to downgrade their version of Firefox. Slashdot also ran a story about the whole ordeal. The open source community had also traditionally touted that open source software was inherently secure because the open source process makes it so through collaborative culture that makes people check each other's code. Even though Firefox itself was not the culprit, the extension itself exposed way too much of users' computers via poorly-implemented APIs.
There were several lessons to be learned from this development debacle. Firstly, just because the overall browser is secure doesn't mean the extension automatically is going to be secure. A disciplined approach to reducing the attack surface area is necessary. Secondly, after a vulnerability has been exposed, being open about it and confronting the issue head on allows information to given to those who need it, such as developers, IT folks, users, and security pros. This was one of the nice things about the way Boodman handled the flaw in his extension. He updated the Mozilla extension website to warn users, conducted an open mailing list, and sought advice from people who were willing to help. Your reaction after finding a flaw is also as important as taking measures to prevent them.
Important Concepts
The following outline includes some important security concepts, without explanation. All of these topics are covered in depth in Building Secure Software. It is a good idea to look through the Internet and the resources listed at the end of this article.
Principle 1: Secure the Weakest Link
Principle 2: Practice Security in Depth
Principle 3: Fail Securely
Principle 4: Follow the Principle of Least Privilege
Principle 5: Compartmentalize
Principle 6: Keep it Simple
Principle 7: Promote Privacy
Principle 8: Remember That Hiding Secrets is Hard
Principle 9: Be Reluctant to Trust
Principle 10: Use Your Community Resources
[http://www.rietta.com/firefox/Tutorial/security]
name::
* McsEngl.xpi.FireFTP@cptIt,
* McsEngl.FireFTP@cptIt,
_ADDRESS.WPG:
* http://fireftp.net//
* https://github.com/mimecuvalo/fireftp,
_DESCRIPTION:
FireFTP is a free, secure, cross-platform FTP/SFTP client for Mozilla Firefox which provides easy and intuitive access to FTP/SFTP servers.
[http://fireftp.net//]
_HUMAN:
* Mime C(uvalo: https://github.com/mimecuvalo,
_ATTRIBUTE:
Features
It's free!
Cross-platform: Works on Windows, Mac OS X, Linux
Secure: SSL/TLS/SFTP support, same encryption used with online banking and shopping
Synchronization: Keep directories in sync while navigating
Directory Comparison: Compare directory content (compares subdirectories too!)
International: Available in over 20 languages
Character Set Support: UTF8 and just about any other character encoding supported
Automatic reconnect and resuming of tranfers
Search/Filtering
Integrity Checks of transfers (XMD5, XSHA1)
Export/Import accounts
Remote Editing
File Hashing: Generate hashes of files (MD5, various SHA's)
Drag & Drop
File Compression: Using MODE Z
Timestamp Synchronization
Proxy support
FXP support
Advanced properties (CHMOD, recursive CHMOD, thumbnails)
Tutorials and help files available for support
IPv6 support
Open Source!
Seamless integration with Mozilla Firefox
...did we mention it's free? :-)
[http://fireftp.net/features.html]
name::
* McsEngl.fireftp'confinguring@cptIt,
_DESCRIPTION:
How do I view and manually edit the config files?
The config files are found in your Firefox profile folder. More info on finding that folder here: http://www.mozilla.org/support/firefox/profile. fireFTPsites.dat contains your account settings (but not your passwords - those are saved in a different place along with your other Firefox passwords - see the above question for where to find that). The other file is fireFTPprograms.dat which stores programs used by the Open With... feature. If your accounts become corrupted for some reason or if the Open With... feature stops working you can check out these files for problems.
[http://fireftp.net/help.html]
name::
* McsEngl.fireftp'installing@cptIt,
I've downloaded the XPI file. Can I install it manually?
One of the following should work:
Open the file in Firefox using File->Open.
Drag the file into a Firefox window or tab.
Drag the file into the Extension Manager.
[http://fireftp.net/help.html]
name::
* McsEngl.xpi.Home-Page-Scheduler@cptIt,
_DESCRIPTION:
The demonstration extension is named 'Home Page Scheduler' and provides the user with the ability to easily schedule specific websites to be their Home Page depending on the current time and day. For example, you may prefer for your home page to be weather.com between 8am-10am, cnn.com between 10am-2pm, slashdot.org between 2pm-5pm, and google.com in the evening.
[http://www.rietta.com/firefox/Tutorial/overview]
name::
* McsEngl.xpi.RESTART@cptIt,
* McsEngl.xpi.classic@cptIt,
* McsEngl.xpi.traditional@cptIt,
* McsEngl.xpi.XUL@cptIt,
_DESCRIPTION:
Since Firefox 4 (and other Mozilla 2 based applications) there are two types of extensions:
Traditional, classic, or XUL extensions are more powerful, but more complicated to build and require a restart to install.
Restartless, or bootstrapped extensions do not require a restart to install but are more limited than traditional extensions. The Add-on SDK and the Add-on Builder can be used to build restartless extensions with ease.
[https://developer.mozilla.org/en/docs/Building_an_Extension]
name::
* McsEngl.xpi.RESTART.NO@cptIt,
* McsEngl.xpi.bootstrapped@cptIt,
* McsEngl.xpi.restartless@cptIt,
_ADDRESS.WPG:
* https://developer.mozilla.org/en-US/docs/Extensions/Bootstrapped_extensions,
_DESCRIPTION:
Since Firefox 4 (and other Mozilla 2 based applications) there are two types of extensions:
Traditional, classic, or XUL extensions are more powerful, but more complicated to build and require a restart to install.
Restartless, or bootstrapped extensions do not require a restart to install but are more limited than traditional extensions. The Add-on SDK and the Add-on Builder can be used to build restartless extensions with ease.
[https://developer.mozilla.org/en/docs/Building_an_Extension]
name::
* McsEngl.pgmFfx'addon.PLUGIN@cptIt,
* McsEngl.ffx'plugin@cptIt,
name::
* McsEngl.pgmFfx'addon.THEME@cptIt,
* McsEngl.ffx'theme@cptIt,
name::
* McsEngl.pgmFfx'chrome@cptIt,
_DESCRIPTION:
Chrome historically has many meanings in Mozilla.
Browser chrome / Chrome
The "browser chrome" is the UI around the web page, as opposed to the content area.
More generally, chrome is the entirety of entities making up the user interface of a specific application or extension.
A chrome:// URL
An URL using the chrome:// protocol. Code loaded from a chrome URL has extended, or chrome, privileges.
XUL-based applications load the code for their interface from chrome:// URLs.
Chrome privileges
The code running with chrome privileges is allowed to do everything, unlike the web content, which is restricted in several ways.
chrome argument to window.open
Passing the chrome argument to window.open opens a new window without any browser interface elements.
chrome folder
This folder is usually a part of a XUL-based application installation. Applications usually load their UI files from the files in this folder.
-chrome command line argument
Starts the application and opens the specified XUL file in a top level window. E.g. mozilla -chrome chrome://inspector/content starts the DOM Inspector.
Chrome package
A chrome package consists of a set of chrome providers. There are three basic types of chrome providers:
Content. Content can consist of any file type viewable from within Mozilla. In particular, the content provider most often consists of a set of XUL, JavaScript and XBL binding files.
Locale. Translations for multi-language support. The two main types of files are DTD files and java-style properties files.
Skin. The skin provider provides complete appearance data for the user interface. Consisting of CSS files and images.
chrome.rdf
The chrome registry, stores the list of registered chrome packages and other information. It was located in the install directory and in the profile. It is no longer used since Gecko 1.8 (Firefox 1.5).
See also
(Note that while both of the documents below mention contents.rdf files, an easier way of registering your chrome providers - using Chrome Manifests - is supported since Firefox 1.5 / Toolkit 1.8)
[https://developer.mozilla.org/en-US/docs/Chrome]
===
Before we talk about the Chrome Manifest file we must learn what 'chrome' means. Chrome is the term used to refer to Interface Packages created for Firefox. The Firefox browser contains a component, the Chrome Manager, that handles the installation and loading of the various parts of Firefox. Everything from the guts (global, browser, etc.) to extensions (such as yours!) register themselves with this manager.
[http://www.rietta.com/firefox/Tutorial/conf]
name::
* McsEngl.pgmFfx'config@cptIt,
* McsEngl.ffx'options@cptIt,
* McsEngl.ffx'preferences@cptIt,
_DESCRIPTION:
Firefox provides you with the Preferences System for these tasks. To see all of the currently stored preferences in your Firefox, type 'about:config' into the location bar and press return. This page will show you a listing of all the current preferences and their values. For example, browser.startup.homepage tells the browser what page to load when the user wishes to visit their home page.
A preference can be an int, bool, or string.
[http://www.rietta.com/firefox/Tutorial/prefs]
name::
* McsEngl.pgmFfx'confing.menu-bar@cptIt,
name::
* McsEngl.pgmFfx'cookie@cptIt,
_DESCRIPTION:
A cookie is information stored on your computer by a website you visit.
In some browsers, each cookie is a small file but in Firefox, all cookies are stored in a single file, located in the Firefox profile folder.
Cookies often store your settings for a website, such as your preferred language or location. When you return to the site, Firefox sends back the cookies that belong to the site. This allows the site to present you with information customized to fit your needs.
Cookies can store a wide range of information, including personally identifiable information (such as your name, home address, email address, or telephone number). However, this information can only be stored if you provide it - websites cannot gain access to information you didn't provide to them, and they can't access other files on your computer.
By default, the activities of storing and sending cookies are invisible to you. However, you can change your Firefox settings to allow you to approve or deny cookie storage requests, delete stored cookies automatically when you close Firefox, and more.
[http://support.mozilla.org/en-US/kb/cookies-information-websites-store-on-your-computer]
name::
* McsEngl.pgmFfx'font@cptIt,
ff'MINIMUM_FONT:
* επεξεργασία/προτιμήσεις/περιεχομενο/γραμματοσειρά/προχωρημένοι/ελάχιστοΜέγεθος
name::
* McsEngl.pgmFfx'profile@cptIt,
_DESCRIPTION:
A profile in Firefox is a collection of bookmarks, browser settings, extensions, passwords, and history; in short, all of your personal settings. These items are stored as a collection of files in a special folder on your hard drive. Shortly, we will find out where this folder is located. In case you didn’t already know, Firefox uses a default profile to store all of your personal settings.
[http://www.borngeek.com/firefox/profile-tutorial/]
===
A Firefox profile stores all of your important data, such as your bookmarks, history, cookies, and passwords. This article explains how to copy the files to a new profile, lists important files in the profile and describes what information is stored in these files.
If you are having a problem with Firefox then sometimes, rather than trying to find and fix the exact cause of the problem, it is easier just to make a new Firefox profile and copy your most important data over to it. The Reset Firefox feature will do this for you automatically.
[http://support.mozilla.org/en-US/kb/Recovering%20important%20data%20from%20an%20old%20profile]
_FOLDER:
\Documents and Settings\HoKoNoUmo\Application Data\Mozilla\Firefox\Profiles\8go6yscz.default,
name::
* McsEngl.pgmFfx'profile'creating@cptIt,
The Five-Minute Profile Creation Guide
If you want to get a new profile up and running quickly, use this quick “five-minute” guide. This guide assumes use of the Windows operating system, but these steps will generally work on any platform:
Make sure all instances of Firefox are closed.
Select Start » Run from the Windows Start menu.
Type the following command and click OK: firefox -ProfileManager
In the resulting Profile Manager window, click the Create Profile button.
Click the Next button in the profile creation wizard.
In the second step of the wizard, provide a name for the new profile and click the Finish button. Make sure that the name you choose does not contain any spaces.
Back in the Profile Manager, click the Exit button.
We now need to create a shortcut that will use our new profile instead of the default. Here’s how:
First and foremost, don’t ever use the “Don’t ask at startup” option in the Profile Manager. By checking this checkbox, any instance of Firefox you run on your computer will make use of the selected profile. In essence, this option allows you to change which profile is your default. This is counter-productive if you are testing nightly builds where you might want to have a new profile for each build.
Create a shortcut to the Firefox instance you want to use with your custom profile. I typically just copy the existing Firefox shortcut and paste it somewhere, renaming it appropriately (i.e. “Development Sandbox”).
In Windows, right click this shortcut and select Properties.
In the Target field, append the following text to the end of the command (replace the {Profile_Name} portion with the actual name you gave your profile): -P "{Profile_Name}"
Click the OK button.
Now when you double click the shortcut you just created, and no other Firefox instances are running, Firefox will start using your custom profile.
[http://www.borngeek.com/firefox/profile-tutorial/]
name::
* McsEngl.pgmFfx'security@cptIt,
name::
* McsEngl.pgmFfx'master-password@cptIt,
Note: After you've set a master password, it needs to be entered the first time you remember a new password or remove passwords and each time you show your passwords, for each Firefox session.
Removing the master password
If you don't need a master password, you can remove it at any time:
At the top of the Firefox window, click on the Tools menu and then select Options
Click the Security panel.
Uncheck mark Use a master password. The Remove Master Password dialog will open.
Enter the current password to confirm you are authorized to remove it.
If you've forgotten your master password, see Reset your Master Password if you've forgotten it.
Click Remove.
Click OK in the dialog that appears to confirm its removal.
Click OK to close the Options window
[http://support.mozilla.org/en-US/kb/use-master-password-protect-stored-logins#w_removing-the-master-password]
name::
* McsEngl.pgmFfx'master-password-resetting@cptIt,
Reset your Master Password if you've forgotten it
Using the Master Password feature, you can protect all of your locally stored usernames and passwords with a master password. If you have forgotten your master password, you must reset it.
Warning: Resetting your master password will remove all of your saved usernames and passwords.
In the Firefox location bar, enter the following location:
chrome://pippki/content/resetpassword.xul
Press Enter.
The "Reset Master Password" page will appear. Click the Reset button, to reset your master password.
Fx5Win7ResetMasterPW
Remember: Resetting your master password will remove all of your saved usernames and passwords.
[http://support.mozilla.org/en-US/kb/reset-your-master-password-if-you-forgot-it]
name::
* McsEngl.pgmFfx'password-files@cptIt,
_DESCRIPTION:
Your passwords are stored in two different files, both of which are required:
key3.db - This file stores your key database for your passwords. To transfer saved passwords, you must copy this file along with the following file.
signons.sqlite - Saved passwords.
[http://support.mozilla.org/en-US/kb/Recovering%20important%20data%20from%20an%20old%20profile#w_passwords]
_SECURITY:
tjameson suggests that since Chrome can copy the passwords they are not safe. This isn't necessarily so. The passwords are encrypted using the master password. Chrome can copy the files containing the encrypted password, and it can decrypt them if it has the master password. It knows how to decrypt them because the method of encryption is public. It's the key (the master password) that keeps things safe. So the reason Chrome was able to decrypt the file was that the user supplied the master password. – Wayne Johnston Apr 6 '11 at 1:31
[http://superuser.com/questions/267005/where-are-my-firefox-passwords-saved]
name::
* McsEngl.pgmFfx'tip@cptIt,
CONNECTION-TO-TWITTER:
* remove cookies, related to twitter.
[2015-08-27]
name::
* McsEngl.pgmFfx'XUL@cptIt,
_GENERIC:
* interface-language##
_DESCRIPTION:
XUL (XML User Interface Language) is Mozilla's XML-based language for building user interfaces of applications like Firefox. The term XUL is sometimes used to refer to the whole Mozilla platform (e.g. XUL applications are applications using XUL and other components of the platform).
[https://developer.mozilla.org/en-US/docs/XUL]
===
Most Firefox extensions have one goal in common: wanting to add or change some graphical element(s) in Firefox. Fortunately for us, adding and modifying GUIs (Graphical User Interfaces) is quite easy thanks to the decision to create an interfacing language specifically for Firefox, from the ground up. This language is called XUL (XML User Interface Language, pronounced zool) and is not too difficult to learn, as it follows the normal XML syntax.
Graphical elements, such as buttons, lists, menus, and windows, are all XUL elements that have been placed into an XUL file and loaded by the browser. XUL files are always found within the content section of a Chrome package. Remember the last step when we added the content line to the chrome.manifest? That told Firefox that the XUL files for that package, sample, could be found in that content directory. Thus, when making GUIs just put the .xul files in your content directory, along with any JavaScript files that will be needed.
[http://www.rietta.com/firefox/Tutorial/guis]
name::
* McsEngl.pgmWbr.INTERNET-EXPLORER@cptIt,
* McsEngl.conceptItsoft1068,
* McsEngl.ie-browser@cptIt,
* McsEngl.Internet-explorer@cptIt19i,
* McsEngl.msie@cptIt,
* McsEngl.pgmIe@cptIt,
name::
* McsEngl.pgmIe'Advance-Java-Permistions-Editor@cptIt,
Jon,
To get to the advanced editor, go to your \windows\system directory (or \winnt\system32) and find the zonedon.reg file. Open zonedon.reg and click OK on the dialog that appears. Now go back to IE and open the custom settings as you did before. This time there will be an "Advanced Edit..." button in the lower left-hand corner of the dialog. Click this button to open the advanced editor.
Note that you shouldn't get the error message that you described unless your custom settings have previously been modified to something that the default editor can't handle. To re-enable the default editor, reset the custom Java permissions to High, Medium, or Low.
Paul
-----Original Message----- From: jchristi@sctcorp.com [SMTP:jchristi@sctcorp.com] Sent: Friday, December 12, 1997 10:40 AM To: advanced-java@xcf.berkeley.edu Subject: Advanced Java Permissions Editor for IE 4.01
Excuse the non-java programming question, but has someone successfully been able to modify the security settings for Java in IE 4.01....
You get there by doing this: View Menu, Internet Options... menu choice, Security Tab, Local Intranet Zone, Custom, Settings button, Java Permissions set to custom, click on Java Custom Settings button that appears, wait a minute for dialog to pop up, click on the Edit Permissions tab, and try to change something to "Enable" instead of "Disable", you get a dialog box that says "Permissions can be edited only by the advanced editor".
Does anyone know where I can get my hands on this advanced editor?
Thanks in advance, Jon
Unsubscription, archives, FAQ - http://www.xcf.berkeley.edu/lists.html
name::
* McsEngl.pgmIe'detection@cptIt,
I use the following function to detect version 9, 10 and 11 of IE:
function ieVersion() {
var ua = window.navigator.userAgent;
if (ua.indexOf("Trident/7.0") > 0)
return 11;
else if (ua.indexOf("Trident/6.0") > 0)
return 10;
else if (ua.indexOf("Trident/5.0") > 0)
return 9;
else
return 0; // not IE9, 10 or 11
}
[http://stackoverflow.com/a/27069089]
name::
* McsEngl.pgmIe.EVOLUTING@cptIt,
{time.2016-01-13}:
=== Παύση υποστήριξης στις παλιές εκδόσεις του Internet Explorer από τη Microsoft
Τετάρτη, 13 Ιανουαρίου 2016 12:09
Από χθες (Τρίτη, 12 Ιανουαρίου), μόνο η τελευταία έκδοση του Internet Explorer (Internet Explorer 11) λαμβάνει τεχνική υποστήριξη και security updates, όπως ανακοινώθηκε από τη Microsoft.
Ειδικότερα, ο Internet Explorer 11 θα συνεχίσει να λαμβάνει security updates, fixes συμβατότητας και τεχνική υποστήριξη σε Windows 7, Windows 8.1 και Windows 10.
«Ο Internet Explorer 11 προσφέρει βελτιωμένη ασφάλεια, καλύτερες επιδόσεις, καλύτερη backward συμβατότητα και υποστήριξη για τα web standards που βρίσκονται πίσω από τα σημερινά sites και υπηρεσίες. Η Microsoft ενθαρρύνει τους πελάτες να αναβαθμίσουν και να παραμείνουν up to date με τον πιο πρόσφατο browser για ταχύτερη, ασφαλέστερη εμπειρία browsing» ανακοινώθηκε σχετικά. Σημειώνεται ότι η εταιρεία είχε προειδοποιήσει σχετικά εδώ και μήνες, ενώ προσφάτως κυκλοφόρησε και ο Microsoft Edge, με τα Windows 10.
Αυτό σημαίνει πως δεν υπάρχει υποστήριξη των εκδόσεων 8,9 και 10, που εξακολουθούν να αντιπροσωπεύουν το 20% του web traffic, ενώ, όπως αναφέρεται σε δημοσίευμα του BBC, σύμφωνα με το Computerworld, μόνο το 55% των χρηστών του IE χρησιμοποιούν την τελευταία έκδοση. Επίσης, σύμφωνα με τη NetMarketShare, ο Internet Explorer κατέχει το 57% της αγοράς browsers, εν συγκρίσει με 25% για τον Chrome, 12% για τον Firefox και 5% για τον Safari.
Οι browsers συχνά στοχεύονται από χάκερ και κάποιοι ειδικοί εκτιμούν ότι έρχεται «κύμα» επιθέσεων τώρα που παύει η στήριξη προς τις παλαιότερες εκδόσεις- με επίδοξους κυβερνοεγκληματίες να έχουν συγκεντρώσει πληροφορίες για τα ευάλωτα σημεία των παλαιών εκδόσεων του Explorer, εν όψει των «τίτλων τέλους».
[http://www.naftemporiki.gr/story/1053826/pausi-upostiriksis-stis-palies-ekdoseis-tou-internet-explorer-apo-ti-microsoft]
name::
* McsEngl.pgmWbr.MOSAIC@cptIt,
* McsEngl.conceptIt161,
* McsEngl.cmrprogram.MOSAIC@cptIt,
* McsEngl.Internet'mosaic@cptIt161,
* McsEngl.mosaic@cptIt161,
To MOSAIC είναι ένα 'WWW#cptIt19#' CLIENT, ικανο να αναζητήσει πληροφορίες απο WWW servers, οι οποίοι επιστρέφουν τις πληροφορίες που ζητήθηκαν στο Mosaic client τερματικό σας.
[PC MASTER, oct. 1994, 55]
Ο τρόπος που ανακτά πληροφορίες είναι ίδιος με του Gopher, ΟΜΩΣ το mosaic διαβάζει αρχεια γραμένα σε μια ειδική γλώσα την HyperText Markup Language (HTML) που βασίζεται στην SGML. Μπορεί επίσης με τις συνδέσεις του να χρησιμοποιηθεί για προσβαση στα Gopher, WAIS, FTP ή σε άλλα εργαλεία "πλοήγησης". Για το λόγο αυτό καθίσταται το γενικής χρήσης interface για το Internet, για πολούς χρήστες.
[PC MASTER, OCT. 1994, 56]
US National Center for Supercomputing Applications of Illinois university.
name::
* McsEngl.pgmNet.CLIENT-SERVER@cptIt,
* McsEngl.conceptIt345,
* McsEngl.client-server-program@cptIt345,
* McsEngl.client-server-architecture@cptIt,
* McsEngl.client-server-software@cptIt,
* McsEngl.program.ClientServer@cptIt345,
* McsEngl.program.network.clientserver@cptIt345,
The client–server model of computing is a distributed application that partitions tasks or workloads between the providers of a resource or service, called servers, and service requesters, called clients.[1] Often clients and servers communicate over a computer network on separate hardware, but both client and server may reside in the same system. A server machine is a host that is running one or more server programs which share their resources with clients. A client does not share any of its resources, but requests a server's content or service function. Clients therefore initiate communication sessions with servers which await incoming requests.
[http://en.wikipedia.org/wiki/Client%E2%80%93server_model]
Η ΣΥΓΧΡΟΝΗ ΜΟΡΦΗ ΣΤΗΝ ΟΠΟΙΑ ΓΙΝΕΤΑΙ ΑΝΤΙΛΗΠΤΗ Η ΕΝΝΟΙΑ CLIENT SERVER ΕΧΕΙ ΝΑ ΚΑΝΕΙ ΠΙΟ ΠΟΛΥ ΜΕ ΣΟΦΤΓΟΥΕΡ ΠΑΡΑ ΜΕ ΧΑΡΝΤΓΟΥΕΡ. ΠΡΟΚΕΙΤΑΙ ΓΙΑ ΣΟΦΤΓΟΥΕΡ ΕΦΑΡΜΟΓΩΝ ΤΟ ΟΠΟΙΟ ΜΠΟΡΕΙ ΝΑ ΚΑΤΑΝΕΜΗΘΕΙ ΑΠΟ ΠΛΕΥΡΑΣ ΕΠΕΞΕΡΓΑΣΙΑΣ (ΣΕ ΕΠΙΠΕΔΟ ΔΙΕΡΓΑΣΙΩΝ ΤΟΥ ΛΕΙΤΟΥΡΓΙΚΟΥ ΣΥΣΤΗΜΑΤΟΣ ή ΚΑΙ ΣΕ ΑΝΩΤΕΡΟ) ΣΕ ΔΥΟ ή ΠΕΡΙΣΣΟΤΕΡΟΥΣ ΥΠΟΛΟΓΙΣΤΕΣ ΚΑΙ ΝΑ ΛΕΙΤΟΥΡΓΕΙ ΤΑΥΤΟΧΡΟΝΑ ΣΕ ΟΛΟΥΣ ...ΣΥΝΕΡΓΑΤΙΚΑ. ΣΤΗΝ ΟΥΣΙΑ ΚΑΘΕ ΤΜΗΜΑ ΚΛΑΙΕΝΤ ΚΑΝΕΙ ΤΗ ΔΙΚΗ ΤΟΥ ΕΠΕΞΕΡΓΑΣΙΑ ΚΑΙ ΣΤΕΛΝΕΙ ΣΤΟ ΤΜΗΜΑ ΣΕΡΒΕΡ ΤΑ ΑΠΟΤΕΛΕΣΜΑΤΑ-ΤΟΥ ΕΤΣΙ ΩΣΤΕ ΤΟΥΛΑΧΙΣΤΟΝ Η ΑΝΤΑΛΛΑΓΗ ΤΩΝ ΔΕΔΟΜΕΝΩΝ ΓΙΝΕΤΑΙ ΣΕ ΣΤΟΙΧΕΙΩΔΕΣ ΕΠΙΠΕΔΟ ΚΑΙ Ο ΚΑΘΕ ΕΝΑΣ ΚΛΑΙΕΝΤ ΠΑΙΡΝΕΙ ΜΟΝΟ ΑΥΤΑ ΠΟΥ ΤΟΥ ΧΡΕΙΑΖΟΝΤΑΙ ΓΙΑ ΤΗΝ ΕΡΓΑΣΙΑ ΤΟΥ ΚΑΙ ΤΙΠΟΤΕ ΑΛΛΟ.
- Η CLIENT-SERVER ΑΡΧΙΤΕΚΤΟΝΙΚΗ, ΥΛΟΠΟΙΗΜΕΝΗ ΠΡΩΤΙΣΤΩΣ ΣΕ ΕΦΑΡΜΟΓΕΣ RDBMS, ΣΗΜΕΡΑ ΑΠΟΤΕΛΕΙ ΤΟ ΠΡΩΤΟ ΒΗΜΑ ΠΡΟΣ ΤΗΝ ΚΑΤΕΥΘΥΝΗ ΤΗΣ ΠΡΑΓΜΑΤΙΚΑ ΚΑΤΑΝΕΜΗΜΕΝΗΣ ΕΠΕΞΕΡΓΑΣΙΑΣ ΣΕ ΟΛΑ ΤΑ ΕΠΙΠΕΔΑ ΤΟΥ SYSTEM ΚΑΙ ΤΟΥ APPLICATION SOFTWARE.
[CHIP, JAN 1994, 124]
name::
* McsEngl.conceptIt348,
* McsEngl.DCE@cptIt,
* McsEngl.dce@cptIt348,
* McsEngl.distributing-computing-environment@cptIt,
_GENERIC:
* STANDARD#cptIt139#
_DESCRIPTION:
DCE is a set of standards designed to help users and software vendors create client/server applicaitons.
It is a standard of the vendor consortium OSF.
[BYTE, JUN 193, 114]
Ο όρος client-server δεν είναι νέος στο λεξικό της πληροφορικής. Είναι τόσο παλιός όσο και η ανάπτυξη των πρώτων RDMS και έχει σαν πυρήνα την αποκέντρωση της πληροφορικής.
[ΣΥΝ, ΙΟΥΛ. 1994, 10]
Specific_concepts (level 3) =
* CLIENT-SERVER-DATABASES#cptIt144: attSpe#
* wwwBrowser#cptItsoft1059: attSpe# wwwServer
name::
* McsEngl.pgmNet.CLIENT-SERVER-DATABASE@cptIt,
* McsEngl.conceptIt144,
* McsEngl.ClientServer'database@cptIt144,
* McsEngl.client-server-database-program@cptIt,
* McsEngl.database.ClientServer@cptIt144,
_GENERIC:
* program-database#cptIt8#
* program-net#cptItsoft350#
DB2, IBM#cptItsoft587: attSpe#
DB2/2, IBM
ORACLE#cptItsoft464: attSpe#
SQLBASE of GUPTA,
SQL-SERVER of MICROSOFT
SYBASE
Because virtually all client/server database management software uses the SQL language, CLIENT TOOLS for working with these databases are commonly referred to as SQL FRONT ENDS.
Αυτά τα προγράματα δημιουργούν runtime εφαρμογες, δηλαδη προγράματα που εκτελούνται χωρίς να έχουν τη δυνατότητα δημιουργίας άλλων προγραμμάτων.
ObjectView Enterprise 3.0, KnowledgeWare,
PowerBuilder Enterprise 3.0a, Powersoft,
SQLWindows, Corporate Edition, 5.0, Gupta,
name::
* McsEngl.pgmNet.FIREWALL@cptIt,
* McsEngl.conceptIt104,
* McsEngl.internet-firewall@cptIt,
* McsEngl.firewall@cptIt104,
* McsElln.ΠΥΡΙΜΑΧΟΣ-ΤΟΙΧΟΣ@cptIt,
Είναι ένα ΠΡΟΓΡΑΜΜΑ που μεσολαβεί μεταξύ του διακομιστή-proxy και του υπολοίπου δικτύου επιχείρισης και αποτρέπει κάθε είδους μετακίνηση δεδομένων μεταξύ internet και δικτύου επιχείρισης, αν δεν ανήκει σε αυτές που έχει εκ των προτέρων εγκρίνει ο υπεύθυνος του δικτύου. Μεταξύ μας όμως, τίποτα δεν είναι απόρθητο.
[ΠΗΓΗ: ΡΑΜ 1997ιουλ, 119]
_GENERIC:
* tech-security#cptItsoft302#
* program-network#cptItsoft350#
name::
* McsEngl.pgmNet.GAME@cptIt,
* McsEngl.net-game@cptIt350i,
* McsEngl.online-game@cptIt350i,
An online game is a game played over some form of computer network. This almost always means the Internet or equivalent technology, but games have always used whatever technology was current: modems before the Internet, and hard wired terminals before modems. The expansion of online gaming has reflected the overall expansion of computer networks from small local networks to the Internet and the growth of Internet access itself. Online games can range from simple text based games to games incorporating complex graphics and virtual worlds populated by many players simultaneously. Many online games have associated online communities, making online games a form of social activity beyond single player games.
[http://en.wikipedia.org/wiki/Online_game]
name::
* McsEngl.pgmNet.iTALC@cptIt,
* McsEngl.conceptItsoft1045,
* McsEngl.iTALC-itsoft@cptItsoft1045,
* McsEngl.iTALC@cptItsoft1045,
* McsEngl.Intelligent-Teaching-And-Learning-with-Computers@cptIt,
iTALC is a use- and powerful didactical tool for teachers. It lets you view and control other computers in your network in several ways. It supports Linux and Windows 2000/XP and it even can be used transparently in mixed environments!
[http://italc.sourceforge.net/]
name::
* McsEngl.italc'INSTALLATION@cptIt,
_ADDRESS.WPG:
* http://www.youtube.com/watch?v=yh_dlzFqUp4,
WINDOWS:
1. download the program.
2. Install master on a machine. If reinstall, on key-setup, use the previous key. Export "key" on a net-folder.
3. Install service (client) only on other computer. Import "key" from the net folder.
UNISTALLATION-COMPLETE:
1) From "\Program Files\iTALC" run: ica -unregisterservice.
2) del iTALC
3) regedit: HK_LM/ SOFTWARE/iTALC SERVIE, delete.
name::
* McsEngl.pgmNet.LAN-TRAFIC-COUNTER@cptIt,
* McsEngl.conceptIt120,
* McsEngl.info-tech-speed@cptIt,
* McsEngl.speed.infotech@cptIt118,
_SPECIFIC:
* Emonitor, Brightwork Development, $300, good
* Network Inspector, Tiara Computer Systems, $1500
name::
* McsEngl.pgmNet.MediaWiki@cptIt,
* McsEngl.conceptIt580.4,
* McsEngl.mw@cptIt580.4,
* McsEngl.MediaWiki@cptIt580.4,
* McsEngl.pgmWeb.MediaWiki@cptIt,
_DESCRIPTION:
MediaWiki is a web-based wiki software application used by all projects of the Wikimedia Foundation, all wikis hosted by Wikia, and many other wikis, including some of the largest and most popular ones.[1] Originally developed to serve the needs of the free content Wikipedia encyclopedia, today it has also been deployed by companies as an internal knowledge management solution, and as a content management system. Notably, Novell uses it to operate several of its high traffic websites.[2]
MediaWiki is written in the PHP programming language, and can use either the MySQL or PostgreSQL relational database management system. MediaWiki is distributed under the terms of the GNU General Public License.
[http://en.wikipedia.org/wiki/MediaWiki]
name::
* McsEngl.mw'Application (site)@cptIt,
* McsEngl.mw'Site@cptIt,
_GENERIC:
* mw'whole.application,
* web-application#ql:web_app_it580.1#
_PART:
* user-code#ql:mw'user_code#,
* program,
===
* code,
* documentation,
name::
* McsEngl.mw'site'Code@cptIt,
* McsEngl.mw'code-of-app@cptIt,
_PART:
* endUser-code,
* programer-code,
===
* skin#ql:mw'skin#
name::
* McsEngl.mw'site.local.mw (1.17.0 WikiCbs)@cptIt,
_Database:
## Database settings
$wgDBtype = "mysql";
$wgDBserver = "localhost";
$wgDBname = "db_mediawiki";
$wgDBuser = "root";
$wgDBpassword = "hknm59\$";
_Logo:
$wgLogo - The URL of the site logo.
_ShortUrl:
* see#ql:mw'conf.short_url#
_SideBar:
* see#ql:mw'conf.sidebar#
_Seggest:
* see#ql:mw'conf.suggest#
_Extension:
* SimpleTable#ql:mw'extension.simpletable#,
* http://www.mediawiki.org/wiki/Extension:WikiEditor,
* MathJax#ql:mw'extension.mathjax#, math rendering,
* Lingo#ql:mw'extension.lingo#, popup abbreviation,
* Vector, enchancments navigation,
name::
* McsEngl.mw'site.local.mw180 (1.18.0)@cptIt,
_Database:
$wgDBtype = "mysql";
$wgDBserver = "localhost";
$wgDBname = "db_mw180";
$wgDBuser = "root";
$wgDBpassword = "hknm59\$";
name::
* McsEngl.mw'site.local.mw19@cptIt,
_GENERIC:
* ww-site#ql:ww'site#
_User:
* admin, admin1959,
* Synagonism, sng1959,
name::
* McsEngl.mw'site.local.w (1.17.0 clean)@cptIt,
_Database:
$wgDBtype = "mysql";
$wgDBserver = "localhost";
$wgDBname = "db_w";
$wgDBuser = "root";
$wgDBpassword = "hknm59\$";
name::
* McsEngl.mw'site.local.mwc (1.17.0 WikiConcept)@cptIt,
_Database:
$wgDBtype = "mysql";
$wgDBserver = "localhost";
$wgDBname = "db_mwc";
$wgDBuser = "root";
$wgDBpassword = "hknm59\$";
_Extension:
* ParserFunctions#ql:mw'extension.parserfunctions#: adds arithmetics and more on pages.
* WikiEditor, preferences: enable navigable toc,
_Skin:
1) h1-id="firstHeading" ===> before div-id="contentSub
2) .mw-topboxes ==> no background
3) search: a)modern.php: function searchBox() b) main.css: simpleSearh from vector.
_Configuration:
* suggest#ql:mw'conf.Suggest#,
* preferences: Auto-number headings (appearance).
name::
* McsEngl.mw'Bot@cptIt,
_DESCRIPTION:
A bot is a computer program that automatically retrieves or updates wiki pages when it is executed. In general, bots are used for repetitive maintenance tasks, whose volume and characteristics are too large to be performed manually by users.
Developing and executing bots is normally outside the role of normal users, requires programming experience and must be done in coordination with the wiki's admins.
By default, bot edits are hidden in Special:Recent changes.
[http://www.mediawiki.org/wiki/Help:Bots]
_Quantity:
More than 600 automated and semi-automated bots
[http://en.wikipedia.org/wiki/Mediawiki]
_ADDRESS.WPG:
* help: http://www.mediawiki.org/wiki/Help:Bots,
* manual: http://www.mediawiki.org/wiki/Bot,
* http://www.mediawiki.org/wiki/Manual:Bots,
* meta: http://meta.wikimedia.org/wiki/Bot,
* creating: http://meta.wikimedia.org/wiki/Pywikipediabot,
- http://en.wikipedia.org/wiki/Wikipedia:Creating_a_bot,
* http://botwiki.sno.cc/wiki/Main_Page,
* http://en.wikipedia.org/wiki/Wikipedia:Registered_bots,
name::
* McsEngl.bot'Usage@cptIt,
Why would I need to create a bot?
Bots can automate tasks and perform them much faster than humans. If you have a simple task that you need to perform lots of times (an example might be to add a template to all pages in a category with 1000 pages), then this is a task better suited to a bot than a human.
[http://en.wikipedia.org/wiki/Wikipedia:Creating_a_bot]
name::
* McsEngl.mw'Category@cptIt,
* McsEngl.mw'page.category@cptIt,
_GENERIC:
* mw-data,
* mw-page-collection#ql:mw'page.collection#
_DESCRIPTION:
Category
A category is a collection of pages automatically formed by MediaWiki by analyzing category tags in articles. Category tags are in the form Category:Extensions. The part after the ":" is the name of the Category. Adding a category tag causes a link to the category and any super-categories to go to the bottom of the page. As stated, it also results in the page being added to the category listing.
Category declaration
A category name placed at the bottom of any page. Pages are made members of categories by the use of the category declarations. Some people refer to category declarations as category tags. A category declaration looks like [[category:foo bar]] where foo bar is the title of the category page.
[http://www.mediawiki.org/wiki/Manual:Glossary]
===
Category is a PAGE that includes other pages. Because the program does not EXPLICITLY states that categrories express the generic-specific relations of pages and "namespaces#ql:mw'namespace#" whole-part relations of pages, authors are confused.
[hmnSngo.2011-12-20]
===
Categories, a software feature of MediaWiki, provide automatic indexes that are useful as tables of contents.
Together with links and templates they structure a project.
[http://meta.wikimedia.org/wiki/Help:Category]
===
Putting an item in a category
A page in any namespace can be put in a category by adding a category tag to the page (by convention, at the end of the page), e.g.: Category:Category name,
This lists the page on the appropriate category page automatically and also provides a link at the bottom of the page to the category page, which is in the namespace "Category". Pages can be included in more than one category by adding multiple category tags. These links do not appear at the location where you inserted the tag, but at the page margin in a fixed place, depending on the skin (the bottom for Monobook, the upper right corner for Standard). Category tags may be placed anywhere in the article, although they are typically added to the end of the article to avoid undesirable text display side effects. Category links are displayed in the order they occur in the article, unlike the automatic ordering of lists in the category pages themselves (see below).
===
In some cases, wikis use categories and category hierarchies that are not suitable for being treated in the above way. For example, Wikipedia uses a category called «Cities» not for collecting all cities but for all articles that are related in some ways to cities. Even the category «Cities in Canada» is used to collect all pages that have some relationship with that topic.
[http://semantic-mediawiki.org/wiki/Help:Inferencing]
name::
* McsEngl.mw'category'Page@cptIt,
* McsEngl.mw'category-description-page@cptIt,
* McsEngl.mw'category'article@cptIt,
_WHOLE:
* category-namespace#ql:mw'namespace.category#
_PART:
The category pages themselves contain 2 parts :
- at their beginning, an optional part may contain text that can be edited, like any other page,
- at their end, an ever present, automatically generated, alphabetical list of all pages in that category, in the form of links. (In fact, in ASCII order. See Help:Special page).
...
Categories exist even if their page has not been created, but these categories are isolated from others and serve little purpose for organization or navigation.
[http://www.mediawiki.org/wiki/Category]
name::
* McsEngl.mw'category'Creating@cptIt,
How to create categories
Creating a category is as simple as adding a link to a category that doesn't yet exist. For instance, to create the "fluffy creatures" category, you would edit an article and enter [[Category:Fluffy creatures]] the same way as adding it to any other category. The Category:Fluffy creatures will automatically be created when the edit is saved.
New categories can be created before assigning any page to it, in the same way as any other regular page.
[http://meta.wikimedia.org/wiki/Help:Category]
How to create subcategories
1) create a subcategory like any page: Category:Subcategory.
2) on subcategory-page set: [[Category:Supercategory]]
[hmnSngo.2011-12-05]
===
Subcategories may be created by putting [[Category:parent_category_name]] onto the page that you would like to make into a subcategory. This may seem counterintuitive, because you edit the subcategory page rather than the parent category page.
Let's say that you wanted to make the category called Roses into a subcategory of the category called Flowers.
Step 1 - Go to the page called [[Category:Roses]], and click edit this page.
Step 2 - Place the text [[Category:Flowers]] within the body of the [[Category:Roses]] article, and save.
Finished! Roses is now a subcategory of Flowers, and [[Category:Roses]] will be visible on [[Category:Flowers]].
name::
* McsEngl.mw'category'Code@cptIt,
_GENERIC:
* mw-code#ql:mw'code#
_SPECIFIC:
* category-extension#ql:mw'extension.Category#,
* category-table-(mw'category'table_in_db)#ql:mw'table.category#,
* categoryLinks-table#ql:mw'table.categorylinks#
name::
* McsEngl.mw'category'Configuring@cptIt,
* McsEngl.mw'configuring.category@cptIt,
_WHOLE:
* mw-configuring#ql:mw'configuration#
Category
$wgUseCategoryMagic (deprecated) - Should the category pseudo-namespace be used?
$wgCategoryCollation - A version indicator for collations that will be stored in cl_collation for all new rows.
$wgCategoryMagicGallery - On category pages, show thumbnail gallery for images belonging to that category instead of listing them as articles.
$wgCategoryPagingLimit - Paging limit for items in categories.
$wgUseCategoryBrowser - Enable DMOZ-like category tree at the bottom of pages
$wgCategoryPrefixedDefaultSortkey - Apply/remove page prefix (namespace name) at default category sortkey
[http://www.mediawiki.org/wiki/Manual:Configuration_settings#Category]
<div id='catlinks' class='catlinks'>
<div id="mw-normal-catlinks" class="mw-normal-catlinks">
<a href="/mw19/phase3/index.php/Special:Categories" title="Special:Cat"> Category</a>:
<ul>
<li><a href="/mw19/phase3/index.php/Category:EU" title="Category:EU"> EU</a></li>
</ul>
</div>
<br />
<hr />
<a href="/mw19/phase3/index.php/Category:Entity" title="Category:Entity">Entity</a>
> <a href="/mw19/phase3/index.php/Category:Society" title="Cat:Society"> Society</a>
> <a href="/mw19/phase3/index.php/Category:EU" title="Category:EU">EU</a>
</div>
name::
* McsEngl.mw'category'Extension@cptIt,
* McsEngl.mw'extension.Category@cptIt,
_SPECIFIC:
* mw'extension.CategoryTree: http://www.mediawiki.org/wiki/Extension:CategoryTree,
- The CategoryTree extension provides a dynamic view of the wiki's category structure as a tree. It uses AJAX to load parts of the tree on demand. CategoryTree was originally written by Daniel Kinzler as an external tool, but was later integrated into the MediaWiki software with the help of Tim Starling.
* mw'extension.Hierachy_of_categories: http://www.mediawiki.org/wiki/Extension:Hierachy_of_categories,
- This extension gives an overview about the root, currently 4 levels of sub and the incorrectly (cycles creating) categorized items. In addition the number of associated pages are given.
* mw'extension.Taxonomy: http://www.mediawiki.org/wiki/Extension:Taxonomy,
- top-down hierarchy.
name::
* McsEngl.mw'category'file.Category.php-in-includes@cptIt,
_Class:
* mw'class.Category: http://svn.wikimedia.org/doc/classCategory.html,
name::
* McsEngl.mw'category'file.Categoryfinder.php-in-includes@cptIt,
_Class:
* mw'class.Categoryfinder: http://svn.wikimedia.org/doc/classCategoryfinder.html,
name::
* McsEngl.mw'category'file.CategoryPage.php-in-includes@cptIt,
_FILE:
* \mw19\phase3\includes\CategoryPage.php">mw'CategoryPage.php,
* \mw19\phase3\includes\CategoryPage.php">mw'file.CategoryPage.php,
_Class:
* mw'class.CategoryPage: http://svn.wikimedia.org/doc/classCategoryPage.html,
- generic: Article#ql:mw'class.article#
name::
* McsEngl.mw'category'file.CategoryViewer.php-in-includes@cptIt,
* McsEngl.mw'CategoryViewer.php@cptIt,
_FILE: \mw19\phase3\includes\CategoryViewer.php">mw'file.CategoryViewer.php,
name::
* McsEngl.mw'category'file.WikiCategoryPage.php-in-includes@cptIt,
_FILE:
\mw19\phase3\includes\WikiCategoryPage.php">mw'file.WikiCategoryPage.php,
\mw19\phase3\includes\WikiCategoryPage.php">mw'WikiCategoryPage.php,
name::
* McsEngl.mw'category'Wikitext@cptIt,
* McsEngl.mw'category'tag@cptIt,
When a page belongs to one or more categories, these categories appear at the bottom of the page (or in the upper-right corner, depending on the skin being used).
To assign a category to a page, simply add the link "[[Category:Category name]]" to the page's wikitext. The usual place to add it is at the bottom of the page.
To link a category page within a page as a normal wiki link (without adding the page to the category), prefix the link name with a colon. For example: [[:Category:Not in this category|Display Label]]
Category tags may be placed anywhere in the wikitext, but they are typically added near the end. On Wikipedia the policy is that category tags are put after the main wikitext, but before any interlanguage links.
[http://meta.wikimedia.org/wiki/Help:Category]
name::
* McsEngl.mw'category'Hierarchy@cptIt,
Managing the category hierarchy
Categories may belong to other categories in a hierarchy. Since category pages are much like any other page, a Category tag may be added to the bottom of a category page.
It is a good idea to organize all categories into a hierarchy with a single top level category. The category structure can take the form of a tree with separate branches, but more often will have a graph structure. Generally, there should be a contiguous chain of parent-child links between each category and the top level category.
[http://www.mediawiki.org/wiki/Category]
name::
* McsEngl.mw'category'Index@cptIt,
Categories, a software feature of MediaWiki, provide automatic indexes that are useful as tables of contents.
Together with links and templates they structure a project.
[http://meta.wikimedia.org/wiki/Help:Category]
name::
* McsEngl.mw'category'Link@cptIt,
Every category has its own article, which can be linked to by writing [[:Category:Example category]].
[http://semantic-mediawiki.org/wiki/Help:Annotation]
name::
* McsEngl.mw'category'Member-page@cptIt,
* McsEngl.mw'categorized-page@cptIt,
* McsEngl.mw'category'element@cptIt,
To assign a category to a page, simply add the link "[[Category:Category name]]" to the page's wikitext. The usual place to add it is at the bottom of the page.
...
Any number of Category tags may be added to the page and the page will be listed in all of them.
...
On a categorised page, categories are displayed in the Categories: box strictly in the order they appear in the wikitext.
[http://www.mediawiki.org/wiki/Category]
name::
* McsEngl.mw'category'Name@cptIt,
Unlike other wiki pages, it is not possible to rename (move) a category. It is necessary to create a new category and change the Category tag on every page. The new category will not have the older category's page history, which is undesirable if there are many revisions.
[http://www.mediawiki.org/wiki/Category]
name::
* McsEngl.mw'category'Quantity@cptIt,
* McsEngl.mw'category'counting@cptIt,
Count
As described at Help:Magic_words#Other_2, {{PAGESINCATEGORY:Example}} or {{PAGESINCAT:Example}} return the number of articles in Category:Example (including articles in subcategories).
[http://meta.wikimedia.org/wiki/Help:Category#Count]
name::
* McsEngl.mw'category'Resource@cptIt,
_SPECIFIC:
* http://www.mediawiki.org/wiki/Category,
* http://www.mediawiki.org/wiki/Category:Category,
* http://www.mediawiki.org/wiki/Category:Category_extensions,
* http://www.mediawiki.org/wiki/Category:Category_hooks,
* http://www.mediawiki.org/wiki/Category:Category_variables,
* http://www.mediawiki.org/wiki/Category:CategoryPageView_extensions,
name::
* McsEngl.mw'category'Sorting-members@cptIt,
A sort key specifies under which letter heading, and where in the category list, the page will appear. You can add a sort key by placing it inside the tag after a pipe character. For example, the tag below will add the page under heading "S". Category:Name|Sort,
Sort keys are case-sensitive, and spaces and other characters are also valid. The order of the sections within a category follows the Unicode sort order. The sort key does not change the page title displayed in the category.
[http://www.mediawiki.org/wiki/Category]
Hiding a namespace from being displayed in Category:
I'm not sure how to hide the namespace, but you can ignore the namespace is the sorting of the category with either
{{DEFUALTSORT:{{PAGENAME}}}} for all categories it is in or [[Category:Blah Blah IIS|{{PAGENAME}}]] for just that category.
===
I know perl so my best explanation would be
if($title =~ /^STAR:/i) {
Do_no_add_to_cat;
} else {
Add_to_cat;
}
is this something that ParserFunctions
<http://www.mediawiki.org/wiki/Extension:ParserFunctions>can do?
Oops, sorry about the first answer. Yes, parserfunctions extension can handle it. Combined with a {{NAMESPACE}} magic word.
It would look like this.
{{#ifeq:{{NAMESPACE}}|STAR|[[Category:This Category]]|[[Category:That Category]]}}
This tells the parser, if Namespace is STAR, then This category, not equal, That Category
For your example you would have to use a double pipe.
{{#ifeq:{{NAMESPACE}}|STAR||[[Category:That Category]]}}
This tells the parser, if Namespace is STAR, then nothing(there is nothing between the two || characters), not equal, That category.
Zach H. luckenbach@gmail.com via lists.wikimedia.org
6:26 AM (5 hours ago)
to MediaWiki
Tom,
You are the man! Thanks for your assistance :) It works as prescribed and
all is happy and well in my MediaWiki.
Thanks again for being apart of an awesome community that is always willing
to help
Gerald Grenier roguebfl@cfl.rr.com via lists.wikimedia.org
6:38 AM (5 hours ago)
to MediaWiki
Though though unless you wand all the pages in NAMESPACE STAR to be sorted under S you will still want
{{#ifeq:{{NAMESPACE}}|STAR||[[Category:That Category|{{PAGENAME}}]]}} so that is will be sorted based on the pagename not the name space in the category list.
name::
* McsEngl.mw'category'Tree@cptIt,
* McsEngl.mw'category-tree@cptIt,
Special:CategoryTree enables you to visualize the tree structure of categories. The CategoryTree extension installed on MediaWiki allows in-page display of the tree.
[http://meta.wikimedia.org/wiki/Help:Category#Visualizing_category_tree]
name::
* McsEngl.mw'category.specific@cptIt,
For a complete list of all categories which have at least one page, see Special:Categories.
For a complete list of all categories, including the ones that don't have any page, see Special:Allpages/Category: (note the colon at the end).
[http://meta.wikimedia.org/wiki/Help:Category]
Parents: no parent categories
[-] Top level? (15 C, 1 P)
[+] MediaWiki Introduction? (1 C, 14 P)
[+] Configure? (2 C, 15 P)
[Χ] Corporate-friendly solution? (3 P)
[+] MediaWiki Development? (31 C, 153 P)
[+] Documentation? (6 C, 5 P)
[+] Events? (4 C)
[+] Extensions? (39 C, 15 P)
[+] Help? (1 C, 64 P)
[X] How-To? (4 P)
[+] MediaWiki components? (40 C)
[+] MediaWiki for site admins? (3 C, 7 P)
[Χ] MediaWiki for users? (2 P)
[+] MediaWiki.org website? (13 C, 17 P)
[+] MediaWiki References? (1 C, 40 P)
[+] Wikimedia Foundation? (2 C)
[http://www.mediawiki.org/wiki/Special:CategoryTree]
name::
* McsEngl.mw'category.Hidden@cptIt,
The categories that a page is in are normally listed at the bottom of the page. A category can be hidden from this list by adding the magic word "__HIDDENCAT__" to the category page. Hidden categories are not hidden from category pages (bug 15550).
Users can choose to see hidden categories in a separate "Hidden categories" list, by checking "Show hidden categories" in the "Appearance" section of Special:Preferences.
Hidden categories are automatically added to Category:Hidden categories. This category is specified in the system message MediaWiki:Hidden-category-category.
[http://www.mediawiki.org/wiki/Category]
name::
* McsEngl.mw'category.Subcategory@cptIt,
Subcategories
Creating subcategories takes only a few additional steps. Adding a category tag to a category page makes the edited category a subcategory of the category specified in the tag.
First create a new category page for the subcategory the same way you would make a regular category. For example, create [[Category:England]]
Then go to the newly created category page and edit it. Add the category tag for the parent category (e.g. [[Category:Country]]) to the page.
Then create a new page with a category link to England. In this example, the England category would then be a subcategory of the Country category.
e.g. adding link to the new page like this... Category:England,
Now to create a subcategory to subcategory England you need to create a new page with a category link to England wikipage and edit it (the category).
e.g. adding link to the page like this... Category:London,
For a live example see Category:Demo_1 which is a subcategory of Category:Demo.
[http://meta.wikimedia.org/wiki/Help:Category]
name::
* McsEngl.mw'category.Tracking@cptIt,
* McsEngl.mw'tracking-category@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Help:Tracking_categories,
name::
* McsEngl.mw'category.Uncused@cptIt,
_DESCRIPTION:
The following category pages exist, although no other page or category makes use of them.
name::
* McsEngl.mw'category.Wanted@cptIt,
name::
* McsEngl.mw'Data-code@cptIt,
* McsEngl.mw'data@cptIt,
* McsEngl.mw'data-of-application@cptIt,
_WHOLE:
* mw-application#ql:mw'application#,
* content-managing#ql:mw'content_managing#
_GENERIC:
* data-of-web-program#ql:prgweb'data#
_Sibling.Specific:
* processing-code,
* mixed-code,
_SPECIFIC:
* category#ql:mw'category#,
* email,
* geographic-coordinate,
* map,
* namespace#ql:mw'namespace#,
* page,
* page-content#ql:mw'page.content#,
* programer-data,
* quantity-number,
* quantity-temperature,
* quantity-time,
* telephone-number,
* text,
* URL,
* user-data,
* wikitext,
name::
* McsEngl.mw'data'Structure@cptIt,
Content structure
The concept of namespaces was used in the UseModWiki era of Wikipedia, where talk pages were at the title "<article name>/Talk". Namespaces were formally introduced in Magnus Manske's first "PHP script". They were reimplemented a few times over the years, but have kept the same function: to separate different kinds of content. They consist of a prefix, separated from the page title by a colon (e.g. Talk: or File: and Template:); the main content namespace has no prefix. Wikipedia users quickly adopted them, and they provided the community with different spaces to evolve. Namespaces have proven to be an important feature of MediaWiki, as they create the necessary preconditions for a wiki's community and set up meta-level discussions, community processes, portals, user profiles, etc.
The default configuration for MediaWiki's main content namespace is to be flat (no subpages), because it's how Wikipedia works, but it is trivial to enable them. They are enabled in other namespaces (e.g. User:, where people can for instance work on draft articles) and display breadcrumbs.
Namespaces separate content by type; within a same namespace, pages can be organized by topic using categories, a pseudo-hierarchical organization scheme introduced in MediaWiki 1.3.
[http://www.mediawiki.org/wiki/Manual:MediaWiki_architecture#Content_structure]
name::
* McsEngl.mw'data.Collection@cptIt,
_SPECIFIC:
* definition-list,
* ordered-list,
* table,
* unordered-list,
name::
* McsEngl.mw'data.EndUser@cptIt,
* McsEngl.mw'endUser-data@cptIt,
* McsEngl.mw'data.user@cptIt,
* McsEngl.mw'user-data@cptIt,
name::
* McsEngl.mw'data.Image@cptIt,
* McsEngl.mw'image-data@cptIt,
_Code.mw:
* PHP Fatal error: Class 'Image' not found in FreeMind.php on line 85
> $img = Image::newFromTitle($imageTitle);
> It seems that the class Image doesn't exist anymore in MediaWiki 1.16.2.
'Image' has been migrated over into the 'File' class, which is not 100%
compatible these days but takes over.
Try:
$img = wfFindFile($imageTitle);
name::
* McsEngl.mw'image-code@cptIt,
images in wikipedia:
//<pre><nowiki>
// Picture Popups for Mediawiki
// (c)2005 [[User:Zocky]]
// Released under GPL
document.write('<link rel="stylesheet" type="text/css" href="'
+ 'http://en.wikipedia.org/w/index.php?title=User:Zocky/PicturePopups.css'
+ '&action=raw&ctype=text/css&dontcountme=s">');
document.addEventListener('click',firstClick,true);
//Handle clicks on document until content is loaded
function firstClick(e)
{
var c=document.getElementById('content')||document.getElementById('article');
if (c) {
c.addEventListener('click',imageClick,false);
document.removeEventListener('click',firstClick,true); }
}
//Handle clicks on images
function imageClick(e)
{
if (!e.ctrlKey && !e.shiftKey && !e.metaKey && e.target.tagName=='IMG')
{
var t=e.target;
var caption=t.getAttribute('alt');
while (t.tagName!='A') { t=t.parentNode; }
var realurl = t.href;
var pictitle = unescape(realurl.match(/\/wiki\/Imagine:(.*)$/)[1].replace(/_/g," "));
if (caption!='Enlarge')
{
try
{
var captiondiv=t.nextSibling.nextSibling;
if (captiondiv.getAttribute('class')=='thumbcaption') {caption=captiondiv.innerHTML}
}
catch (er){}
x=Math.round(Math.random()*200);
y=Math.round(Math.random()*200);
var note_content_div=new_note(x, y, '[<a href="'+realurl+'"> > </a>] '+pictitle, '<blink><small><i>loading...</i></small></blink>',caption);
note_content_div.addEventListener('click',noteContentClick,true);
var cbSuccess=function(x,c)
{
note_content_div.innerHTML='';
note_content_div.appendChild(findDescendantById(c,'file')) || (note_content_div.innerHTML="Failed. <a>retry</a>");
try { note_content_div.appendChild(findDescendantById(c,'imageLicense')); } catch(er) {};
return true;
}
var cbFailure=function(x,c)
{
note_content_div.innerHTML==x.statusText;
return true;
}
loadText(realurl,cbSuccess,cbFailure);
}
else
{
var img = t.parentNode.parentNode.parentNode.firstChild.firstChild;
if (img.hasAttribute('thumbwidth'))
{
var dummy=img.getAttribute('thumbwidth')
img.setAttribute('thumbwidth',img.width);
img.width=dummy;
img.parentNode.parentNode.style.width=(img.width+2) + "px";
var dummy=img.getAttribute('thumbheight')
img.setAttribute('thumbheight',img.height);
img.height=dummy;
}
else
{
img.setAttribute('thumbwidth',img.width);
img.setAttribute('thumbheight',img.height);
var cbSuccess=function(x,c)
{
var dummy=findDescendantById(c,'file');
if (dummy.firstChild.tagName=='IMG')
{
img.src=dummy.firstChild.src;
img.width=dummy.firstChild.width;
img.height=dummy.firstChild.height;
}
else
{
img.width=dummy.firstChild.firstChild.width;
img.height=dummy.firstChild.firstChild.height;
img.src=dummy.firstChild.firstChild.src;
}
img.parentNode.parentNode.style.width=(img.width+2) + "px";
return true;
}
var cbFailure=function(x,c)
{
return true;
}
loadText(realurl,cbSuccess,cbFailure);
}
}
e.preventDefault();
}
}
//Stop popup images from linking to hi-res pages
function noteContentClick(e)
{
e.target.tagName=='IMG' && e.preventDefault() ;
}
//NOTES
var note_top=100;
var active_note;
var note_back='globalWrapper';
function note_icons(n)
{
return '<nobr>[<a onclick="toggle_note(\''+n+'\')"> - </a>] '
+ '[<a onclick="close_note(\''+n+'\')"> x </a>]</nobr>';
}
function new_note(x,y,title,content,caption)
{
var note_container=document.getElementById(note_back)
note_top++;
var note = document.createElement("div");
note.id = "note_" + note_top;
note.setAttribute('class', "imagenote");
note.setAttribute('minimized', "0");
x>0 && (note.style.left = x + "px") || (note.style.right = -x + "px");
y>0 && (note.style.top = y + "px") || (note.style.bottom = -y + "px");
note.style.zIndex=note_top;
note.innerHTML = '<table><tr class="imagenotetitlebar">'
+ '<td class="imagenotetitle" id="'+note.id+'_title"><span>' + title + '</span></td>'
+ '<td class="imagenoteicons" id="'+note.id+'_icons" align="right">' + note_icons(note.id) + '</td></tr>'
+ '<tr><td class="imagenotecontent" id="'+note.id+'_content" colspan="2">'+content+'</td></tr>'
+ '<tr><td class="imagenotecaption" id="'+note.id+'_caption" colspan="2">'+caption+'</td></tr></table>';
note_container.appendChild(note);
note.addEventListener("mousedown", pick_note, true);
note.addEventListener("click", click_note, true);
active_note=note;
return document.getElementById(note.id+'_content');
}
function close_note(n)
{
var note_container=document.getElementById(note_back);
note_container.removeChild(document.getElementById(n));
}
function toggle_note(n)
{
var note=document.getElementById(n);
note.setAttribute('minimized', 1-note.getAttribute('minimized'));
}
var note_dragging;
function pick_note(e)
{
active_note=e.currentTarget;
note_top++;
active_note.style.zIndex = note_top;
mouse_x = e.clientX; mouse_y = e.clientY;
active_note_top = parseInt(active_note.style.top); active_note_left = parseInt(active_note.style.left);
document.addEventListener("mousemove", drag_note, false);
document.addEventListener("mouseup", drop_note, false);
e.preventDefault();
note_dragging=false;
}
function drag_note(e)
{
var x = e.clientX;
var y = e.clientY;
active_note.style.top = (y - mouse_y + active_note_top) + "px"; active_note.style.left = (x - mouse_x + active_note_left) + "px";
note_dragging=true;
}
function drop_note(e)
{
document.removeEventListener("mousemove", drag_note, false);
document.removeEventListener("mouseup", drop_note, false);
}
function click_note(e)
{
note_dragging && e.preventDefault();
}
//DOWNLOADER
function loadText(url,cb1,cb2) {
var x = window.XMLHttpRequest ? new XMLHttpRequest()
: window.ActiveXObject ? new ActiveXObject("Microsoft.XMLHTTP")
: false;
var c=document.createElement("div");
if (x) {
x.onreadystatechange=function() {
x.readyState==4 && textLoaded(x,c,cb1,cb2)};
x.open("GET",url,true);
x.setRequestHeader('Accept','text/*');
x.send(null); }
}
function textLoaded(x,c,cb1,cb2) {
x.status==200
&& ((c.innerHTML=x.responseText) && cb1 && cb1(x,c))
|| ( cb2 && cb2(x,c) || alert(x.statusText));
}
//XML helper functions
function findDescendantById(node, id) {
if (node.id == id) { return node; }
var i, c;
for (i = node.firstChild; i != null; i=i.nextSibling) {
c = findDescendantById(i,id);
if (c != null)
return c; }
return null;
}
//</nowiki></pre>
[http://ro.wikipedia.org/w/index.php?title=Utilizator:Strainu/picture_popups.js]
name::
* McsEngl.mw'data.Table@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Help:Tables,
* http://meta.wikimedia.org/wiki/Help:Sorting,
* http://en.wikipedia.org/wiki/Help:Tables,
_Markup:
* table-wikitext#ql:mw'wikitext.table#
_Extension:
* http://www.mediawiki.org/wiki/Extension:DataTables,
name::
* McsEngl.mw'data.Time@cptIt,
* McsEngl.mw'content.Time@cptIt,
* McsEngl.mw'time@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Manual:Timestamp,
* http://www.mediawiki.org/wiki/Manual:Timezone,
* http://www.mediawiki.org/wiki/Date_formats,
name::
* McsEngl.mw'Database@cptIt,
* McsEngl.mw'db@cptIt,
_DESCRIPTION:
The database (see also database layout) contains the wikitext of the pages and various auxiliary information about pages, users, etc. It also contains all previous versions of all pages, as the MediaWiki software maintains its own version control system.
[http://www.mediawiki.org/wiki/Manual:MediaWiki_architecture]
name::
* McsEngl.mw'db'Code@cptIt,
* McsEngl.mw'database'code@cptIt,
_Directory:
* \public_html\mw19\phase3\includes\db\,
_ mw'database'File:
file Database.php
This file deals with database interface functions and query specifics/optimisations.
file DatabaseIbm_db2.php
This is the IBM DB2 database abstraction layer.
file DatabaseMssql.php
This is the MS SQL Server Native database abstraction layer.
file DatabaseMysql.php
This is the MySQL database abstraction layer.
file DatabaseOracle.php
This is the Oracle database abstraction layer.
file DatabasePostgres.php
This is the Postgres database abstraction layer.
file DatabaseSqlite.php
This is the SQLite database abstraction layer.
file LBFactory.php
Generator of database load balancing objects.
file LBFactory_Multi.php
Advanced generator of database load balancing objects for wiki farms.
file LoadBalancer.php
Database load balancing.
file LoadMonitor.php
Database load monitoring.
[http://svn.wikimedia.org/doc/group__Database.html]
CloneDatabase.php 4.6 kB 11/23/11 5:36:43 PM
Database.php 97.9 kB 11/23/11 5:36:43 PM
DatabaseError.php 8.3 kB 11/23/11 5:36:43 PM
DatabaseIbm_db2.php 42.6 kB 11/23/11 5:36:43 PM
DatabaseMssql.php 34.5 kB 11/23/11 5:36:43 PM
DatabaseMysql.php 22.6 kB 11/23/11 5:36:43 PM
DatabaseOracle.php 37.3 kB 11/23/11 5:36:43 PM
DatabasePostgres.php 26.7 kB 11/23/11 5:36:43 PM
DatabaseSqlite.php 21.2 kB 11/23/11 5:36:43 PM
DatabaseUtility.php 5.3 kB 11/23/11 5:36:43 PM
LBFactory_Multi.php 9.0 kB 11/23/11 5:36:43 PM
LBFactory_Single.php 1.9 kB 11/23/11 5:36:43 PM
LBFactory.php 9.4 kB 11/23/11 5:36:43 PM
LoadBalancer.php 29.7 kB 11/23/11 5:36:43 PM
LoadMonitor.php 4.4 kB 11/23/11 5:36:43 PM
_ mw'database'Class:
* mw'class.DatabaseBase,
Classes
class Blob
Utility classThis allows us to distinguish a blob from a normal string and an array of strings. More...
class CloneDatabase
Helper class for making a copy of the database, mostly for unit testing. More...
class DatabaseBase
Database abstraction object. More...
class DatabaseIbm_db2
Primary database interface. More...
class DatabaseMssql
class DatabaseMysql
Database abstraction object for mySQL Inherit all methods and properties of Database::Database(). More...
class DatabaseOracle
class DatabasePostgres
class DatabaseSqlite
class DatabaseSqliteStandalone
This class allows simple acccess to a SQLite database independently from main database settings. More...
class DBConnectionError
class DBError
Database error base class. More...
class DBObject
Utility class. More...
class DBQueryError
class DBUnexpectedError
interface Field
Base for all database-specific classes representing information about database fields. More...
class IBM_DB2Blob
Wrapper around binary large objects. More...
class IBM_DB2Field
This represents a column in a DB2 database. More...
class IBM_DB2Result
Wrapper to address lack of certain operations in the DB2 driver ( seek, num_rows ). More...
class LBFactory
An interface for generating database load balancers. More...
class LBFactory_Multi
A multi-wiki, multi-master factory for Wikimedia and similar installations. More...
class LoadBalancer
Database load balancing object. More...
interface LoadMonitor
An interface for database load monitoring. More...
class LoadMonitor_MySQL
Basic MySQL load monitor with no external dependencies Uses memcached to cache the replication lag for a short time. More...
class MssqlField
Utility class. More...
class MssqlResult
The MSSQL PHP driver doesn't support sqlsrv_num_rows, so we recall all rows into an array and maintain our own cursor index into that array...This is similar to the way the Oracle driver handles this same issue. More...
class MySQLField
Utility class. More...
class ORAField
Utility class. More...
class ORAResult
The oci8 extension is fairly weak and doesn't support oci_num_rows, among other things. More...
class ResultWrapper
Result wrapper for grabbing data queried by someone else. More...
class SQLiteField
[http://svn.wikimedia.org/doc/group__Database.html]
===
DatabaseLag
DatabaseLogEntry This class wraps around database result row
DatabaseMssql
DatabaseMysql Database abstraction object for mySQL Inherit all methods and properties of Database::Database()
DatabaseOracle
DatabasePostgres
DatabaseSqlite
DatabaseSqliteStandalone This class allows simple acccess to a SQLite database independently from main database settings
DatabaseSqliteTest sqlite Database
DatabaseTest Database DatabaseBase
DatabaseType
DatabaseUpdater Class for handling database updates
DateFormats Test various language time and date functions
DateFormatter Date formatter, recognises dates in plain text and formats them accoding to user preferences
DBABagOStuff Cache that uses DBA as a backend
DBAccessError Exception class for attempted DB access
DBConnectionError
DBError Database error base class
DBLockManager Version of LockManager based on using DB table locks
DBMasterPos An object representing a master or slave position in a replicated setup
DBObject Utility class
DBQueryError
DbTestPreviewer
DbTestRecorder
DBUnexpectedError
_Interface:
* mw'interface.DatabaseType,
name::
* McsEngl.mw'file.Database.php@cptIt,
_FILE:
\mw19\phase3\includes\db\Database.php">mw'Database.php,
Database.php
MediaWiki has a load of convenience functions and wrappers for interacting with the database. It also has an interesting load balancing scheme in place. It's recommended you use these wrappers. Check out Database.php for a complete listing of all the convenience functions, because these docs will only tell you about the non-obvious caveats. See Manual:Database access.
wfGetDB()
As this name suggests, this function gets you a reference of the database. There is no global that contains a database object.
When you call the function, you should pass it a parameter, the constant DB_MASTER or DB_SLAVE. Generally, you interact with the slave database when you're only performing read operations, and interact with the master when you're writing to the database. It's real easy to do, so do it, even if you only have one database.
[http://www.mediawiki.org/wiki/Manual:Special_pages]
name::
* McsEngl.mw'db'Function-wrapper@cptIt,
function select( $table, $vars, $conds = '', $fname = 'Database::select', $options = array() );
function selectRow( $table, $vars, $conds = '', $fname = 'Database::select', $options = array() );
function insert( $table, $a, $fname = 'Database::insert', $options = array() );
function insertSelect( $destTable, $srcTable, $varMap, $conds, $fname = 'Database::insertSelect', $insertOptions = array(), $selectOptions = array() );
function update( $table, $values, $conds, $fname = 'Database::update', $options = array() );
function delete( $table, $conds, $fname = 'Database::delete' );
function deleteJoin( $delTable, $joinTable, $delVar, $joinVar, $conds, $fname = 'Database::deleteJoin' );
function buildLike(/*...*/);
[http://www.mediawiki.org/wiki/Manual:Database_access]
name::
* McsEngl.mw'db'Query@cptIt,
* McsEngl.mw'db'select-function@cptIt,
* McsEngl.mw'select-fn-database@cptIt,
function select( $table, $vars, $conds = '', $fname = 'Database::select', $options = array() );
Wrapper function: select()
The select() function provides the MediaWiki interface for a SELECT statement. The components of the SELECT statement are coded as parameters of the select() function. An example is
$dbr = wfGetDB( DB_SLAVE );
$res = $dbr->select(
'category', // $table
array( 'cat_title', 'cat_pages' ), // $vars (columns of the table)
'cat_pages > 0', // $conds
__METHOD__, // $fname = 'Database::select',
array( 'ORDER BY' => 'cat_title ASC' ) // $options = array()
);
This example corresponds to the query
SELECT cat_title, cat_pages FROM category WHERE cat_pages > 0 ORDER BY cat_title ASC
Arguments are either single values (such as 'category' and 'cat_pages > 0') or arrays, if more than one value is passed for an argument position (such as array('cat_pages > 0', $myNextCond)). If you pass in strings, you must manually use DatabaseBase::addQuotes() on your values as you construct the string, as the wrapper will not do this for you. The array construction for $conds is somewhat limited; it can only do equality relationships (i.e. WHERE key = 'value').
[http://www.mediawiki.org/wiki/Manual:Database_access]
To make a read query, something like this usually suffices:
$dbr = wfGetDB( DB_SLAVE );
$res = $dbr->select( /* ...see docs... */ );
foreach( $res as $row ) {
...
}
[http://www.mediawiki.org/wiki/Manual:Database_access]
name::
* McsEngl.mw'db'Indexing@cptIt,
Unindexed queries are generally not welcome in MediaWiki, except in special pages derived from QueryPage.
...
Don't forget about indexes when designing databases, things may work smoothly on your test wiki with a dozen of pages, but will bring a real wiki to a halt.
[http://www.mediawiki.org/wiki/Manual:Database_access]
name::
* McsEngl.mw'db'Resource@cptIt,
_SPECIFIC:
* The current MySQL diagram for any MediaWiki version—with extensive comments—can be found in the maintenance/tables.sql file.
* http://www.mediawiki.org/wiki/Category:Database,
* http://www.mediawiki.org/wiki/Category:MediaWiki_database_tables,
* http://www.mediawiki.org/wiki/Category:Database_variables,
* http://www.mediawiki.org/wiki/Manual:Database_layout,
* http://www.mediawiki.org/wiki/Manual:Database_access,
* http://www.mediawiki.org/wiki/Manual:Coding_conventions/Database,
* http://meta.wikimedia.org/wiki/Wikidata/Notes,
* http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/maintenance/tables.sql?view=markup,
* http://yellowstone.cs.ucla.edu/schema-evolution/index.php/Schema_Evolution_Benchmark,
name::
* McsEngl.mw'db'Table@cptIt,
* McsEngl.mw'table@cptIt,
* McsEngl.mw'table-database@cptIt,
_ADDRESS.WPG:
* http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/maintenance/tables.sql?view=markup,
_ViewContent:
1) From phpMyAdmin export as json
2) jEdit: a)sr: "}, {" b) ","
_SPECIFIC:
archive
category
categorylinks
change_tag
config
externallinks
external_user
filearchive
hitcounter
image
imagelinks
interwiki
iwlinks
ipblocks
job
l10n_cache
langlinks
logging
log_search
math
msg_resource
msg_resource_links
module_deps
objectcache
oldimage
page
pagelinks
page_props
page_restrictions
protected_titles
querycache
querycachetwo
querycache_info
redirect
revision
searchindex
site_stats
tag_summary
templatelinks
text
trackbacks
transcache
updatelog
uploadstash
user
user_former_groups
user_groups
user_newtalk
user_properties
valid_tag
watchlist
===
The most important tables are probably page, revision, pagelinks and text.
[http://www.mediawiki.org/wiki/Manual:Database_layout]
name::
* McsEngl.mw'table.Page@cptIt,
* McsEngl.mw'page-table@cptIt,
_DESCRIPTION:
stores the metadata of the page.
[http://www.mediawiki.org/wiki/Manual:Recentchanges_table]
===
The page table can be considered the "core of the wiki". Each page in a MediaWiki installation has an entry here which identifies it by title and contains some essential metadata. It was first introduced in r6710, in MediaWiki 1.5.
The text of the page itself is stored in the text-table#ql:mw'table.text#. To retrieve the text of an article, MediaWiki first searches for page_title in this table. Then, page_latest is used to search the revision-table#ql:mw'table.revision# for rev_id, and rev_text_id is obtained in the process. The value obtained for rev_text_id is used to search for old_id in the text table to retrieve the text.
[http://www.mediawiki.org/wiki/Manual:Page_table]
_Example:
{
"page_id": 2,
"page_namespace": 0,
"page_title": "CBS",
"page_restrictions": "",
"page_counter": 192,
"page_is_redirect": 0,
"page_is_new": 0,
"page_random": 0.183681088616,
"page_touched": 20111025055645,
"page_latest": 6,
"page_len": 699
},
===
{
"page_id": 56,
"page_namespace": 14,
"page_title": "Entity",
"page_restrictions": "",
"page_counter": 12,
"page_is_redirect": 0,
"page_is_new": 0,
"page_random": 0.090163693795,
"page_touched": 20120207200759,
"page_latest": 153,
"page_len": 345
}
name::
* McsEngl.mw'table.Category@cptIt,
* McsEngl.mw'category-table@cptIt,
_WHOLE:
* category-code#ql:mw'category'code#
/* db_mwc.category */
[{
"cat_id": 1,
"cat_title": "Hknm",
"cat_pages": 2,
"cat_subcats": 0,
"cat_files": 0,
"cat_hidden": 0}]
name::
* McsEngl.mw'table.Categorylinks@cptIt,
* McsEngl.mw'categorylinks-table@cptIt,
_WHOLE:
* category-code#ql:mw'category'code#
_DESCRIPTION:
Contains:
- cl_from: the "id" of the page|subcategory which belongs (= is member) to a category.
- cl_to: the "name" of the category
- cl_sortkey: the "name" of the page|subcat member of category,
- cl_type: the type of the member: page, subcat
[hmnSngo.2012-02-05]
===
The categorylinks table stores entries on a page of the type [[category:abc]], which places the page into the category "abc" (for which an associated page may or may not exist). Links of the form [[:category:abc]] are not stored in categorylinks, but are handled as normal links. The editable parts of category pages are stored like other pages.
[http://www.mediawiki.org/wiki/Manual:Categorylinks_table]
_Example:
* Greece page (id=6) is member of cat "EU"
{
"cl_from": 6,
"cl_to": "EU",
"cl_sortkey": "GREECE",
"cl_sortkey_prefix": "",
"cl_timestamp": "2011-12-05 15:58:17",
"cl_collation": "uppercase",
"cl_type": "page"
},
* Society subcat (id=10) is member of cat "Entity"
{
"cl_from": 10,
"cl_to": "Entity",
"cl_sortkey": "SOCIETY",
"cl_sortkey_prefix": "",
"cl_timestamp": "2012-02-05 07:35:27",
"cl_collation": "uppercase",
"cl_type": "subcat"
},
name::
* McsEngl.mw'table.Page-props@cptIt,
_WHOLE:
* page-table#ql:mw'page'table#
_ADDRESS.WPG:
http://www.mediawiki.org/wiki/Manual:Page_props_table
name::
* McsEngl.mw'table.Page-restrictions@cptIt,
_WHOLE:
* page-table#ql:mw'page'table#
[http://www.mediawiki.org/wiki/Manual:Page_restrictions_table]
name::
* McsEngl.mw'table.Redirect@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Manual:Redirect_table,
name::
* McsEngl.mw'table.RecentChanges@cptIt,
* McsEngl.mw'recentchanges-table@cptIt,
_DESCRIPTION:
The recentchanges table contains information about the latest modifications done to the wiki (not older than $wgRCMaxAge; see also below). The contents of this table are used to generate the recent changes pages, related changes pages, watchlists, and the list of new pages, and contain information such as editors' IP addresses not found on other tables.
[http://www.mediawiki.org/wiki/Recentchanges_table]
===
Whenever anything happens on the wiki (e.g. page edit, move, delete, new user, etc.) a row is added to the recentchanges table giving details about the change.
[http://www.mediawiki.org/wiki/Manual:$wgRCMaxAge]
_Example:
{
"rc_id": 11,
"rc_timestamp": 20111025160833,
"rc_cur_time": 20111025160833,
"rc_user": 1,
"rc_user_text": "Admin",
"rc_namespace": 1,
"rc_title": "Main_Page",
"rc_comment": "Created page with \"Every page must have a \"discussion\" attribute.\"",
"rc_minor": 0,
"rc_bot": 0,
"rc_new": 1,
"rc_cur_id": 4, the page_id in the page-table#ql:mw'table.page#, which stores the metadata of the page
"rc_this_oldid": 11, the rev_id of the new-page-revision in the revision-table#ql:mw'table.revision#.
"rc_last_oldid": 0, the rev_id of the revision prior to this edit,
"rc_type": 1, Probably incomplete, type of modification: 1=new-page,
"rc_moved_to_ns": 0,
"rc_moved_to_title": "",
"rc_patrolled": 1,
"rc_ip": "127.0.0.1",
"rc_old_len": 0,
"rc_new_len": 46,
"rc_deleted": 0,
"rc_logid": 0,
"rc_log_type": null,
"rc_log_action": "",
"rc_params": ""
},
name::
* McsEngl.mw'table.Revision@cptIt,
* McsEngl.mw'revision-table@cptIt,
_DESCRIPTION:
The revision table holds metadata for every edit done to a page within the wiki. Every edit of a page creates a revision row, which holds information such as the user who made the edit, the time at which the edit was made, and a reference to the new wikitext in the text-table#ql:mw'table.text#.
Note that a row is partly about the edit operation and partly about the result of that operation, the new wikitext. It does not give a reference to the old wikitext.
[http://www.mediawiki.org/wiki/Manual:Revision_table]
_Usage:
The revision table is used for page history and user contributions listings.
[http://www.mediawiki.org/wiki/Manual:Revision_table]
_Example:
{
"rev_id": 76,
"rev_page": 8, equal to the page_id field of said page
"rev_text_id": 76, pointer to old_id in the text-table#ql:mw'table.text#, where text is stored.
"rev_comment": "",
"rev_user": 1,
"rev_user_text": "Admin",
"rev_timestamp": 20111226082947,
"rev_minor_edit": 0,
"rev_deleted": 0,
"rev_len": 190, length of the article after the revision, in bytes
"rev_parent_id": 74,
"rev_sha1": "s8zbj28wiibsmhcjbnucs1yc792swi9"
},
===
{
"rev_id": 124,
"rev_page": 54,
"rev_text_id": 124,
"rev_comment": "creation",
"rev_user": 1,
"rev_user_text": "Admin",
"rev_timestamp": 20120201142435,
"rev_minor_edit": 0,
"rev_deleted": 0,
"rev_len": 202,
"rev_parent_id": 0,
"rev_sha1": "7ar2b4x6e2b1buyuhi5rlg7r5xiqt3z"},
name::
* McsEngl.mw'table.SearchIndex@cptIt,
* McsEngl.mw'searchindex-table@cptIt,
_DESCRIPTION:
The searchindex table is used to provide full text searches. Those can only be done with the MyISAM table type and the text table (cur table in 1.4 and earlier) uses the InnoDB type to improve concurrency, so a copy is required. If using Postgres, this table does not exist: the full text information is stored as columns in the page and pagecontent tables directly.
[http://www.mediawiki.org/wiki/Manual:Searchindex_table]
_Example:
"si_page": 1,
"si_title": "main page",
"si_text": "
name::
* McsEngl.mw'table.Text@cptIt,
* McsEngl.mw'pagecontent-table@cptIt,
* McsEngl.mw'text-table@cptIt,
_WHOLE:
* page-table#ql:mw'page'table#
_DESCRIPTION:
The text table holds the wikitext of individual page revisions. If using Postgres, this table is named pagecontent.
[http://www.mediawiki.org/wiki/Manual:Text_table]
old_id
revision.rev_text_id in revision-table#ql:mw'table.revision# is a key to this column. (In MediaWiki 1.5+, archive.ar_text_id is also a key to this column.)
_Example:
{
"old_id": 146,
"old_text": "== Definition ==
Worldview is a \"view\" of the world of one person or group of persons with the same world conception.
== Whole ==
* KnowledgeBase of the site.",
"old_flags": "utf-8"}
===
{
"old_id": 22,
"old_text": "== Definition ==
Worldview is a \"view\" of the world of one person or group of persons with the same world conception.",
"old_flags": "utf-8"},
===
{
"old_id": 11,
"old_text": "Every page must have a \"discussion\" attribute.",
"old_flags": "utf-8"
},
name::
* McsEngl.mw'table.Watchlist@cptIt,
_DESCRIPTION:
"DESCRIBE mw_watchlist;" in version 1.16 gives the following:
mysql> DESCRIBE mw_watchlist;
+--------------------------+------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------------------------+------------------+------+-----+---------+-------+
| wl_user | int(10) unsigned | NO | PRI | NULL | |
| wl_namespace | int(11) | NO | PRI | 0 | |
| wl_title | varbinary(255) | NO | PRI | | |
| wl_notificationtimestamp | varbinary(14) | YES | | NULL | |
+--------------------------+------------------+------+-----+---------+-------+
[http://www.mediawiki.org/wiki/Manual:Watchlist_table]
name::
* McsEngl.mw'database.specific@cptIt,
* McsEngl.mw'db.specific@cptIt,
_SPECIFIC:
Currently there is MySQL and reasonable support for SQLite and PostgreSQL, also somewhat limited for Oracle and DB2, but there could be other databases in the future such as MSSQL or Firebird.
[http://www.mediawiki.org/wiki/Manual:Database_access]
name::
* McsEngl.mw'db.MySQL@cptIt,
* McsEngl.mw'MySql@cptIt,
GIVEN: page-title FIND: page-id.
SELECT page.page_id
FROM page
WHERE page.page_title = 'Economy' ;
The following code will select the most recent versions of all articles in the wikidb:
SELECT
p.page_id AS "Page ID",
p.page_title AS "Page Title",
r.rev_text_id AS "Revision ID",
t.old_id AS "Text ID"
FROM
wikidb.page p
INNER JOIN wikidb.revision r
ON p.page_latest = r.rev_id
INNER JOIN wikidb.text t
ON r.rev_text_id = t.old_id;
[http://www.mediawiki.org/wiki/Manual:Page_table]
name::
* McsEngl.mw'Code.Program@cptIt,
* McsEngl.mw'Code@cptIt,
* McsEngl.mw'code-of-program@cptIt,
* McsEngl.mw'codebase@cptIt,
* McsEngl.mw'programer-code@cptIt,
_WHOLE:
* mw-program#ql:mw_it580.4#
mw'code'size:
Size ~13.7 MB
[http://en.wikipedia.org/wiki/Mediawiki] 2011-10-08
_SPECIFIC:
* core,
* extension,
===
The core consists of MediaWiki code other than extensions.
[http://www.mediawiki.org/wiki/Core]
name::
* McsEngl.mw'code'Bug-trucker@cptIt,
* McsEngl.mw'Bug-trucker@cptIt,
* McsEngl.mw'Bugzilla@cptIt,
* McsEngl.mw'Debuging@cptIt,
* McsEngl.mediazilla@cptIt580i,
* McsEngl.Bugzilla@cptIt580i,
_ADDRESS.WPG:
* bug: http://www.mediawiki.org/wiki/Bugs,
* bug-specific: https://bugzilla.wikimedia.org/show_bug.cgi?id=33239,
* bug-comment: https://bugzilla.wikimedia.org/show_bug.cgi?id=27488#c9,
* https://bugzilla.wikimedia.org/page.cgi?id=bug-writing.html,
* http://www.mediawiki.org/wiki/Manual:How_to_debug,
* https://bugzilla.wikimedia.org//
* https://bugzilla.wikimedia.org/docs/en/html/using.html,
* https://bugzilla.wikimedia.org/docs/en/html/bug_page.html,
* http://www.chiark.greenend.org.uk/~sgtatham/bugs.html,
* docs: https://bugzilla.wikimedia.org/docs/en/html/index.html,
_DESCRIPTION:
MediaWiki has a public bug tracker, bugzilla.wikimedia.org, (alternatively known as Mediazilla), which uses Bugzilla. The site is also used for feature and enhancements requests.
[http://en.wikipedia.org/wiki/Mediawiki]
name::
* McsEngl.bugzilla'Resolution@cptIt,
_DESCRIPTION:
The Resolution field indicates what happened to this bug.
[https://bugzilla.wikimedia.org/page.cgi?id=fields.html]
_SPECIFIC:
Open-bugs:
No resolution yet. All bugs which are in one of these "open" states have no resolution set.
Closed-bugs:
FIXED
A fix for this bug is checked into the tree and tested.
INVALID
The problem described is not a bug.
WONTFIX
The problem described is a bug which will never be fixed.
DUPLICATE
The problem is a duplicate of an existing bug. When a bug is marked as a DUPLICATE, you will see which bug it is a duplicate of, next to the resolution.
WORKSFORME
All attempts at reproducing this bug were futile, and reading the code produces no clues as to why the described behavior would occur. If more information appears later, the bug can be reopened.
[https://bugzilla.wikimedia.org/page.cgi?id=fields.html]
name::
* McsEngl.bugzilla'Status@cptIt,
_DESCRIPTION:
The Status field indicates the current state of a bug. Only certain status transitions are allowed.
[https://bugzilla.wikimedia.org/page.cgi?id=fields.html]
_SPECIFIC:
Open Bugs
UNCONFIRMED
This bug has recently been added to the database. Nobody has confirmed that this bug is valid. Users who have the "canconfirm" permission set may confirm this bug, changing its state to CONFIRMED. Or, it may be directly resolved and marked RESOLVED.
CONFIRMED
This bug is valid and has recently been filed. Bugs in this state become IN_PROGRESS when somebody is working on them, or become resolved and marked RESOLVED.
IN_PROGRESS
This bug is not yet resolved, but is assigned to the proper person who is working on the bug. From here, bugs can be given to another person and become CONFIRMED, or resolved and become RESOLVED.
Closed Bugs
RESOLVED
A resolution has been performed, and it is awaiting verification by QA. From here bugs are either reopened and given some open status, or are verified by QA and marked VERIFIED.
VERIFIED
QA has looked at the bug and the resolution and agrees that the appropriate resolution has been taken. This is the final status for bugs.
[https://bugzilla.wikimedia.org/page.cgi?id=fields.html]
Other Fields
Assignee
The person in charge of resolving the bug.
Blocks
This bug must be resolved before the bugs listed in this field can be resolved.
Bug ID
The numeric id of a bug, unique within this entire installation of Bugzilla.
CC
Users who may not have a direct role to play on this bug, but who are interested in its progress.
Changed
When this bug was last updated.
Classification
Bugs are categorised into Classifications, Products and Components. classifications is the top-level categorisation.
Comment
Bugs have comments added to them by Bugzilla users.You can search for some text in those comments.
Component
Components are second-level categories; each belongs to a particular Product. Select a Product to narrow down this list.
Content
This is a field available in searches that does a Google-like 'full-text' search on the Summary and Comment fields.
Creation date
When the bug was filed.
Depends on
The bugs listed here must be resolved before this bug can be resolved.
Hardware
The hardware platform the bug was observed on. Note: When searching, selecting the option "All" only finds bugs whose value for this field is literally the word "All".
Keywords
You can add keywords from a defined list to bugs, in order to tag and group them.
OS
The operating system the bug was observed on. Note: When searching, selecting the option "All" only finds bugs whose value for this field is literally the word "All".
Priority
Engineers prioritize their bugs using this field.
Product
Bugs are categorised into Products and Components.
QA Contact
The person responsible for confirming this bug if it is unconfirmed, and for verifying the fix once the bug has been resolved.
Reporter
The person who filed this bug.
See Also
This allows you to refer to bugs in other installations. You can enter a URL to a bug in the 'Add Bug URLs' field to note that that bug is related to this one. You can enter multiple URLs at once by separating them with a comma.
You should normally use this field to refer to bugs in other installations. For bugs in this installation, it is better to use the Depends on and Blocks fields.
Severity
How severe the bug is, or whether it's an enhancement.
Summary
The bug summary is a short sentence which succinctly describes what the bug is about.
Target Milestone
The Target Milestone field is used to define when the engineer the bug is assigned to expects to fix it.
URL
Bugs can have a URL associated with them - for example, a pointer to a web site where the problem is seen.
Version
The version field defines the version of the software the bug was found in.
Votes
Some bugs can be voted for, and you can limit your search to bugs with more than a certain number of votes.
Web browser
A custom Drop Down field in this installation of Bugzilla.
[https://bugzilla.wikimedia.org/page.cgi?id=fields.html]
name::
* McsEngl.mw'Error@cptIt,
* McsEngl.mw'bug@cptIt,
PHP errors
To see PHP errors, add this to the very top of LocalSettings.php:
error_reporting( E_ALL );
ini_set( 'display_errors', 1 );
This will cause PHP errors to be shown on-page. This might make it easier for attackers to find a way into your server, so disable it again when you have found the problem.
[http://www.mediawiki.org/wiki/Manual:How_to_debug]
SQL errors
To display SQL errors in error messages instead of "(SQL query hidden)", add the following to LocalSettings.php:
$wgShowSQLErrors = true;
$wgDebugDumpSql = true;
[http://www.mediawiki.org/wiki/Manual:How_to_debug]
mw'error.wgMessageCache:
Notice: Undefined variable: wgMessageCache in \public_html\mw19\phase3\extensions\Data.php on line 41
Fatal error: Call to a member function addMessage() on a non-object in \public_html\mw19\phase3\extensions\Data.php on line 41
==>
in 1.18 is no working
[http://www.mediawiki.org/wiki/Extension_talk:Data#Working_in_1.18]
name::
* McsEngl.mw'code'Cashing@cptIt,
* McsEngl.mw'cashing@cptIt,
_DESCRIPTION:
MediaWiki is a very complex web-application, this means that it can take some time to render pages. To mitigate these costs, many MediaWiki administrators install one of many caching solutions. They are by no means compulsory, though they can decrease the time it takes pages to load, and decrease server workload. This page is divided into four sections, in order to cache everything, you need to enable a solution from each group. It is very likely that you do not need to cache everything, simply enable things that you can, until you have acceptable performance. In some cases, over-caching will cause a degradation of performance.
[http://www.mediawiki.org/wiki/Manual:Cache]
name::
* McsEngl.mw'code'Convention@cptIt,
* McsEngl.mw'Coding-convention@cptIt,
* McsEngl.mw'code-convention@cptIt,
* McsEngl.mw'code-notation@cptIt,
* McsEngl.mw'convention@cptIt,
* McsEngl.mw'notation@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Manual:Coding_conventions,
Naming/coding conventions:
These are meant to be descriptive, not dictatorial; I won't presume to tell
you how to program, I'm just describing the methods I chose to use for myself.
If you do choose to follow these guidelines, it will probably be easier for
you to collaborate with others on the project, but if you want to contribute
without bothering, by all means do so (and don't be surprised if I reformat
your code).
- I have the code indented with tabs to save file size and so that users can
set their tab stops to any depth they like. I use 4-space tab stops, which
work well. I also use K&R brace matching style. I know that's a religious
issue for some, so if you want to use a style that puts opening braces on
the next line, that's OK too, but please don't use a style where closing
braces don't align with either the opening brace on its own line or the
statement that opened the block--that's confusing as hell.
- Certain functions and class members are marked with /* private */, rather
than being marked as such. This is a hold-over from PHP 4, which didn't
support proper visibilities. You should not access things marked in this
manner outside the class/inheritance line as this code is subjected to be
updated in a manner that enforces this at some time in the near future, and
things will break. New code should use the standard method of setting
visibilities as normal.
- Member variables are generally "mXxx" to distinguish them. This should make
it easier to spot errors of forgetting the required "$this->", which PHP
will happily accept by creating a new local variable rather than complaining.
- Globals are particularly evil in PHP; it sets a lot of them automatically
from cookies, query strings, and such, leading to namespace conflicts; when
a variable name is used in a function, it is silently declared as a new
local masking the global, so you'll get weird error because you forgot the
global declaration; lack of static class member variables means you have to
use globals for them, etc. Evil, evil.
I think I've managed to pare down the number of globals we use to a scant
few dozen or so, and I've prefixed them all with "wg" so you can spot errors
better (odds are, if you see a "wg" variable being used in a function that
doesn't declare it global, that's probably an error).
Other conventions: Top-level functions are wfFuncname(), names of session
variables are wsName, cookies wcName, and form field values wpName ("p" for
"POST").
[\public_html\mw19\phase3\docs\design.txt]
name::
* McsEngl.mw'convention.space-on-code@cptIt,
MediaWiki favours a heavily-spaced style for optimum readability.
[http://www.mediawiki.org/wiki/Manual:Coding_conventions]
name::
* McsEngl.mw'code'Evolution@cptIt,
* McsEngl.mw'dev@cptIt,
* McsEngl.mw'developing@cptIt,
_GENERIC:
* mw-doing#ql:mw'doing#
_SPECIFIC:
* extension#ql:mw'extension#,
* hook#ql:mw'hook#,
* parser-function#ql:mw'parser_function#,
===
Extensions, along with Parser Functions and Hooks are the most effective way to change or enhance the functionality of MediaWiki.
[http://www.mediawiki.org/wiki/Manual:Tag_extensions]
name::
* McsEngl.mw'code'Extending@cptIt,
* McsEngl.mw'extending@cptIt,
Extending MediaWiki
MediaWiki has been designed to allow for modification without changing the "core code". This makes it easy to update to a new version of MediaWiki without having to manually merge in old extension code changes. There are five main extension points that allow developers to change or extend what MediaWiki can do. The extension points are:
* API – access the data and metadata of MediaWiki instances through a powerful web API.
* Hooks – every time a given event happens do something.
* Parser Functions – create a new command like: {{#if:...|...|...}}
* Skins – change the look and feel of MediaWiki.
* Special Pages – add a new special page.
* Tag Extensions – create a new tag like: <newtag>...</newtag>
[http://www.mediawiki.org/wiki/Developer_hub#Extending_MediaWiki]
name::
* McsEngl.mw'code'Gerrit@cptIt,
* McsEngl.mw'gerrit@cptIt,
_Login:
* https://labsconsole.wikimedia.org/wiki/Help:Access#Initial_log_in,
name::
* McsEngl.mw'code'Git@cptIt,
* McsEngl.mw'git@cptIt,
`git clone https://gerrit.wikimedia.org/r/p/test/mediawiki/core.git`
_ADDRESS.WPG:
* https://www.mediawiki.org/wiki/Git,
* https://www.mediawiki.org/wiki/Git/Workflow,
* https://www.mediawiki.org/wiki/Git_Graphical_User_Interfaces,
name::
* McsEngl.mw'code'HipHop@cptIt,
* McsEngl.mw'HipHop@cptIt,
HipHop is an open source PHP to C++ translator developed by Facebook.
HipHop support in MediaWiki is currently at an early stage of development. It should not be used by anyone except for developers wishing to improve the HipHop support.
[http://www.mediawiki.org/wiki/HipHop]
name::
* McsEngl.mw'code'Loading@cptIt,
* McsEngl.mw'Loading@cptIt,
Back in 1.17 we loaded things in the order:
StartProfiler, Defines, AutoLoader, DefaultSettings, LocalSettings
However the order we load things now is:
Init, AutoLoader, Profiler, Defines, StartProfiler, DefaultSettings,
LocalSettings
[Daniel Friesen, 2011-12-25]
name::
* McsEngl.mw'code'Repository@cptIt,
* McsEngl.mw'Repository@cptIt,
_ADDRESS.WPG:
* http://svn.wikimedia.org/svnroot/mediawiki//
* http://www.mediawiki.org/wiki/Commit_access_requests,
* http://www.mediawiki.org/wiki/Development_policy,
* http://www.mediawiki.org/wiki/Manual:Pre-commit_checklist,
* code-review: http://www.mediawiki.org/wiki/Special:Code/MediaWiki,
_DESCRIPTION:
The MediaWiki repository is hosted on mayflower, a Wikimedia server in Amsterdam, and is reachable from http://svn.wikimedia.org/svnroot/mediawiki//. The project uses a more or less standard hierarchy:
branches
tags
trunk
[http://www.mediawiki.org/wiki/Subversion]
name::
* McsEngl.mw'repo'brances@cptIt,
_DESCRIPTION:
branches is used for major coding work, testing huge patches, and testing unstable patches. Some developers have their own branch of the code here. It is also used to prepare new stable releases (through the well-known beta ? release candidate ? security & maintenance fix cycle). Each major stable series gets its own directory as REL<major_version>_<minor_version>. For example, MediaWiki 1.9 work is being done in REL1_9.
[http://www.mediawiki.org/wiki/Subversion]
name::
* McsEngl.mw'repo'tags@cptIt,
* McsEngl.mw'tags-repository@cptIt,
_DESCRIPTION:
tags is a special hierarchy used to save the state of the software at a given point in the time. You should NEVER make any change to it as this is only useful when releasing new versions. That task is handled solely by the MediaWiki release manager (Tim Starling).
There is an additional subproject named wikimedia-web, which hosts the Wikimedia portal files located at http://www.wikimedia.org/. You usually don't want to modify anything there without referring to the Wikimedia Foundation and/or the Wikimedia system administrators.
[http://www.mediawiki.org/wiki/Subversion]
name::
* McsEngl.mw'repo'trunk@cptIt,
* McsEngl.mw'trunk-repository@cptIt,
_DESCRIPTION:
Pre-production work is made in the trunk tree. Since Wikimedia servers run the code in this tree for production usage, patches made in this tree must not break the code. You should also avoid rewriting extensive portions of the trunk as well. MediaWiki itself is in the phase3 subdirectory of the trunk.
[http://www.mediawiki.org/wiki/Subversion]
name::
* McsEngl.mw'code'Resource@cptIt,
_SPECIFIC:
* http://www.mediawiki.org/wiki/Manual:MediaWiki_architecture,
* http://www.mediawiki.org/wiki/User:Wikinaut/Books/MediaWiki_Developer%27s_Guide,
* http://www.mediawiki.org/wiki/User:Dantman/Analytics_integration,
_ADDRESS.WPG (mw'code'resource):
* http://svn.wikimedia.org/doc//
* http://www.mediawiki.org/wiki/Manual:Code,
* http://www.mediawiki.org/wiki/Code_review_tags,
* http://www.mediawiki.org/wiki/Code_review_guide,
* http://www.mediawiki.org/wiki/Code_review,
* https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker/Workshop,
* mw'irc: http://webchat.freenode.net//#mediawiki,#wikimedia-dev,
* http://www.mediawiki.org/wiki/Developer_hub,
* http://www.mediawiki.org/wiki/Category:Manual,
* http://www.mediawiki.org/wiki/Category:MediaWiki_Development,
* lists: http://www.mediawiki.org/wiki/Mailing_lists,
* list: http://lists.wikimedia.org/pipermail/wikitech-l//
* https://lists.wikimedia.org/mailman/listinfo/wikitech-l,
* http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/EducationProgram/EducationProgram.php?view=markup#l80,
name::
* McsEngl.mw'code'Subclassing@cptIt,
* McsEngl.mw'Subclassing@cptIt,
_DESCRIPTION:
Subclassing: MediaWiki expects certain kinds of extensions to be implemented as subclasses of a MediaWiki provided base class:
Special pages - Subclasses of the SpecialPage class are used to build pages whose content is dynamically generated using a combination of the current system state, user input parameters, and database queries. Both reports and data entry forms can be generated. They are used for both reporting and administration purposes.
Skins - Skins change the look and feel of MediaWiki by altering the code that outputs pages by subclassing the MediaWiki class SkinTemplate.
[http://www.mediawiki.org/wiki/Manual:Developing_extensions#Extension_types]
_SPECIFIC:
* skin#ql:mw'skin#,
* specialPage-extension#ql:mw'extension.specialpage#
name::
* McsEngl.mw'code'Subversion@cptIt,
* McsEngl.mw'subversion@cptIt,
* McsEngl.mw'svn@cptIt,
* McsEngl.mw'commit@cptIt,
Commit access requests commit-access-requests@wikimedia.org
ts@wikimedia.org 2011-12-13:
2:18 PM (2 hours ago)
to me
Nikos,
Thank you for requesting commit access for MediaWiki!
I'm sorry for the wait. Your request for commit access has been approved and your
account has been created.
You have only been given access to extensions and branches at this time. If you
wish to have commit access to the MediaWiki core at a later date, please send
another request to commit-access-requests@wikimedia.org.
Please create a file in the /USERINFO directory describing yourself, following the
examples there and at
https://www.mediawiki.org/wiki/Commit_access_requests#Getting_started_and_set_up .
Do not forget to set the svn:eol-style property!
Then, please commit the skin to /trunk/extensions/skins.
We recommend you read the following pages:
http://www.mediawiki.org/wiki/Security_for_developers
http://www.mediawiki.org/wiki/Manual:Coding_conventions
http://www.mediawiki.org/wiki/Commit_access
http://www.mediawiki.org/wiki/Subversion
Thanks for contributing to the MediaWiki community.
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/USERINFO_file,
Getting started and set up
Once you have an account, you will need to follow some steps before you can commit anything.
1. Read Subversion to get an overview of the Subversion source control system.
2. Read Subversion/auto-props and do exactly what it says to set up auto-props.
3. Create a USERINFO file.
4. Checkout using svn+ssh:// instead of http:// , or it simply won't work (you may get a 403 Forbidden unexpected return value).
Note: If you are prompted for a password during checkout and your SSH key doesn't need a passphrase, this may be an indication that your account has not been set up correctly. If you're using Windows, check that Pageant is running with your private key stored.
5. Check out two copies of MediaWiki: one instance for development and testing, and another instance that you will apply patches to and commit from. This structure makes it easier to commit clean patches. To do this, use:
svn co svn+ssh://username@svn.wikimedia.org/svnroot/mediawiki/trunk/phase3 wikimedia-dev
svn co svn+ssh://username@svn.wikimedia.org/svnroot/mediawiki/trunk/phase3 wikimedia-commit
6. Have a coder link your SVN account to your wiki account, so that you receive emails when somebody comments on your commits. If you're feeling bold, you could instead ask a coder to make you a coder; you can then link your account yourself at [[Special:Code/MediaWiki/author/<your name>]].
1. run pagent from: \DL\PROGRAM\SECURITY\putty.
- open private-key.
2. on \svn\USERINFO:
- svn+ssh://synagonism@svn.wikimedia.org/svnroot/mediawiki/USERINFO/
- create file synagonism
- add file
- property: svn:eol-style native
- commit at version 106338
3. on \svn\mw-skins, right click checkout for:
svn+ssh://synagonism@svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/skins
4. on \svn\mw-skins-commit, right click checkout for:
- svn+ssh://synagonism@svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/skins
- add files
- commit
===
1) 2011-12-15: first commit revision 106341.
[http://www.mediawiki.org/wiki/Special:Code/MediaWiki]
_Adding_files:
- on working: add new files, directories.
- on new files: right-click/tortoise/add
If you're using Windows, check that Pageant is running with your private key stored.
[https://www.mediawiki.org/wiki/Commit_access_requests#Getting_started_and_set_up]
name::
* McsEngl.mw'code.API@cptIt,
* McsEngl.mw'API@cptIt,
_DESCRIPTION:
MediaWiki has an API (Application Programming Interface) available for this purpose. An API is a protocol for standardised communication between two computer programs. Check API:Client code for more information.
To access a wiki through the API a bot must have a user account, which has been granted 'bot' permissions.
[http://www.mediawiki.org/wiki/Help:Bots]
===
The other main entry point for MediaWiki, besides index.php, is api.php, used to access its machine-readable query API (Application Programming Interface).
Wikipedia users originally created "bots" that worked by screen scraping the HTML content served by MediaWiki; this method was very unreliable and broke many times. To improve this situation, developers introduced a read-only interface (located at query.php), which then evolved into a full-fledged read and write machine API providing direct, high-level access to the data contained in the MediaWiki database[8].
Client programs can use the API to login, get data, and post changes. The API supports thin web-based JavaScript clients and end-user applications. Almost anything that can be done via the web interface can basically be done through the API. Client libraries implementing the MediaWiki API are available in many languages, including Python and .NET.
[http://www.mediawiki.org/wiki/Manual:MediaWiki_architecture#API]
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/API,
* code: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/api//
* faq: http://www.mediawiki.org/wiki/API:FAQ,
===
* https://www.ibm.com/developerworks/xml/library/x-phpwikipedia/index.html,
* http://www.mediawiki.org/wiki/Category:MediaWiki_API_Overview,
name::
* McsEngl.mw'api'Action@cptIt,
* McsEngl.mw'action-of-api@cptIt,
* McsEngl.mw'command-of-api@cptIt,
_SPECIFIC:
query,
sitematrix, review, reviewactivity, flagconfig, titleblacklist, emailcapture, opensearch, userdailycontribs, clicktracking, specialclicktracking, articlefeedback, wikilove, wikiloveimagelog, moodbar, feedbackdashboard, feedbackdashboardresponse, stabilize, login, logout, expandtemplates, parse, feedcontributions, feedwatchlist, help, paraminfo, rsd, compare, purge, rollback, delete, undelete, protect, block, unblock, move, edit, upload, filerevert, emailuser, watch, patrol, import, userrights
name::
* McsEngl.mw'api'action.Parse@cptIt,
http://en.wikipedia.org/w/api.php?action=parse&text={{:Coastal_California}}__TOC__&prop=sections:
{
toclevel: 1,
level: "2",
line: "Government",
number: "2",
index: "T-2",
fromtitle: "Coastal_California",
byteoffset: null,
anchor: "Government"
},
name::
* McsEngl.mw'api'action.Query@cptIt,
_QUERY:
* http://www.mediawiki.org/w/api.php?action=query&prop=info&titles=Manual:Page%20table,
* http://www.mediawiki.org/w/api.php?action=query&prop=info&pageids=10501,
* http://localhost/mw19/phase3/api.php?action=query&titles=Main%20Page
name::
* McsEngl.mw'api'action.Search@cptIt,
_Search:
http://en.wikipedia.org/w/index.php?title=Special:Search&search=XXX,
name::
* McsEngl.mw'api'Call@cptIt,
The API is called by sending HTTP requests to api.php. For example, on the English Wikipedia, the URL is http://en.wikipedia.org/w/api.php ; other wikis have api.php with similar URLs: just use api.php where the usual URL has index.php. If you're trying to access the API on a third-party (non-Wikimedia-operated) wiki and can't figure out the URL of api.php, contact the wiki's owner.
From 1.17 onwards, MediaWiki supports RSD. An RSD marker is present on every page pointing to an RSD descriptor which indicates where to find the API.
[http://www.mediawiki.org/wiki/API:FAQ#call_the_API.3F]
_Code.mw:
$mediawiki_root = '/Users/eyeRmonkey/www/mediawiki-test';
putenv("MW_INSTALL_PATH=$mediawiki_root");
// Initialise common code
require ($mediawiki_root . '/includes/WebStart.php');
class MediaWikiAPIWrapper {
public function make_fake_request($params) {
$request = new FauxRequest($params, true);
$api = new ApiMain($request);
// Process data & use an output buffer to capture the resutls
$api->execute();
$result = $api->getResult();
$data = &$result->getData();
return $data;
}
}
[http://auzigog.com/2009/01/11/creating-a-mediawiki-api-instance-outside-installation-directory/]
name::
* McsEngl.mw'api'Format@cptIt,
_SPECIFIC:
json, jsonfm, php, phpfm, wddx, wddxfm, xml, xmlfm, yaml, yamlfm, rawfm, txt, txtfm, dbg, dbgfm, dump, dumpfm
_Example:
http://en.wikipedia.org/w/api.php?action=query
&titles=Albert%20Einstein
&prop=info
&format=jsonfm
===
{
"query": {
"pages": {
"736": {
"pageid": 736,
"ns": 0,
"title": "Albert Einstein",
"touched": "2011-11-27T11:02:41Z",
"lastrevid": 462652447,
"counter": "",
"length": 94094
}
}
}
}
_SPECIFIC:
json JSON format callback (opt): Wraps the output into a given function call
php serialized PHP format
wddx WDDX format
xml XML format
yaml YAML format
rawfm JSON format with the debugging elements (HTML) callback (opt): Wraps the output into a given function call
txt PHP print_r() format
dbg PHP var_export() format
dump PHP var_dump() format
[http://www.mediawiki.org/wiki/API:Data_formats]
name::
* McsEngl.mw'api'Prop@cptIt,
_Example:
http://en.wikipedia.org/w/api.php?action=query
&titles=Albert%20Einstein
&prop=info
&inprop=protection%7Ctalkid
name::
* McsEngl.mw'api'Titles@cptIt,
_Example:
http://localhost/mw19/phase3/api.php?action=query
&titles=Main%20Page
===
<?xml version="1.0"?>
<api>
<query>
<pages>
<page pageid="1" ns="0" title="Main Page" />
</pages>
</query>
</api>
http://en.wikipedia.org/w/api.php?action=query
&titles=Albert%20Einstein
&prop=info
&inprop=protection%7Ctalkid
name::
* McsEngl.mw'code.Class@cptIt,
* McsEngl.mw'class@cptIt,
_SPECIFIC:
* http://svn.wikimedia.org/doc/annotated.html,
_Hierarchy:
* http://svn.wikimedia.org/doc/hierarchy.html,
_SPECIFIC:
Class List
Here are the classes, structs, unions and interfaces with brief descriptions:
* mw'class_DiffEngine Class used internally by Diff to actually compute the diffs
* mw'class_DiffOp
* mw'class_DiffOp_Add
* mw'class_DiffOp_Change
* mw'class_DiffOp_Copy
* mw'class_DiffOp_Delete
* mw'class_HWLDF_WordAccumulator
* mw'class.Action
* mw'class.ActiveUsersPager This class is used to get a list of active users
* mw'class.AddContentToNewPageTestCase
* mw'class.AddNewPageTestCase
* mw'class.AjaxDispatcher Object-Oriented Ajax functions
* mw'class.AjaxResponse Handle responses for Ajax requests (send headers, print content, that sort of thing)
* mw'class.AllmessagesTablePager Use TablePager for prettified output
* mw'class.AllTrans Get all the translations messages, as defined in the English language file
* mw'class.AlphabeticPager IndexPager with an alphabetic list and a formatted navigation bar
* mw'class.AlterSharedConstraints This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version
* mw'class.AncientPagesPage Implements Special:Ancientpages
* mw'class.AnsiTermColorer Set of classes to help with test output and such
* mw'class.APCBagOStuff This is a wrapper for APC's shared memory functions
* mw'class.ApiBase This abstract class implements many basic API functions, and is the base of all API classes
* mw'class.ApiBlock API module that facilitates the blocking of users
* mw'class.ApiBlockTest Database
* mw'class.ApiComparePages
* mw'class.ApiDelete API module that facilitates deleting pages
* mw'class.ApiDisabled API module that dies with an error immediately
* mw'class.ApiEditPage A module that allows for editing and creating pages
* mw'class.ApiEmailUser API Module to facilitate sending of emails to users
* mw'class.ApiExpandTemplates API module that functions as a shortcut to the wikitext preprocessor
* mw'class.ApiFeedContributions
* mw'class.ApiFeedWatchlist This action allows users to get their watchlist items in RSS/Atom formats
* mw'class.ApiFileRevert
* mw'class.ApiFormatBase This is the abstract base class for API formatters
* mw'class.ApiFormatDbg API PHP's var_export() output formatter
* mw'class.ApiFormatDump API PHP's var_dump() output formatter
* mw'class.ApiFormatFeedWrapper This printer is used to wrap an instance of the Feed class
* mw'class.ApiFormatJson API JSON output formatter
* mw'class.ApiFormatPhp API Serialized PHP output formatter
* mw'class.ApiFormatPhpTest API Database
* mw'class.ApiFormatRaw Formatter that spits out anything you like with any desired MIME type
* mw'class.ApiFormatTestBase
* mw'class.ApiFormatTxt API Text output formatter
* mw'class.ApiFormatWddx API WDDX output formatter
* mw'class.ApiFormatXml API XML output formatter
* mw'class.ApiFormatXmlRsd
* mw'class.ApiFormatYaml API YAML output formatter
* mw'class.ApiHelp This is a simple class to handle action=help
* mw'class.ApiImport API module that imports an XML file like Special:Import does
* mw'class.ApiImportReporter Import reporter for the API
* mw'class.ApiLogin Unit to authenticate log-in attempts to the current wiki
* mw'class.ApiLogout API module to allow users to log out of the wiki
* mw'class.ApiMain This is the main API class, used for both external and internal processing
* mw'class.ApiMove API Module to move pages
* mw'class.ApiOpenSearch
* mw'class.ApiPageSet This class contains a list of pages that the client has requested
* mw'class.ApiParamInfo
* mw'class.ApiParse
* mw'class.ApiPatrol Allows user to patrol pages
* mw'class.ApiProtect
* mw'class.ApiPurge API interface for page purging
* mw'class.ApiPurgeTest Database
* mw'class.ApiQuery This is the main query class
* mw'class.ApiQueryAllCategories Query module to enumerate all categories, even the ones that don't have category pages
* mw'class.ApiQueryAllimages Query module to enumerate all available pages
* mw'class.ApiQueryAllLinks Query module to enumerate links from all pages together
* mw'class.ApiQueryAllmessages A query action to return messages from site message cache
* mw'class.ApiQueryAllpages Query module to enumerate all available pages
* mw'class.ApiQueryAllUsers Query module to enumerate all registered users
* mw'class.ApiQueryBacklinks This is a three-in-one module to query: * backlinks - links pointing to the given page, * embeddedin - what pages transclude the given page within themselves, * imageusage - what pages use the given image
* mw'class.ApiQueryBase This is a base class for all Query modules
* mw'class.ApiQueryBlocks Query module to enumerate all user blocks
* mw'class.ApiQueryCategories A query module to enumerate categories the set of pages belong to
* mw'class.ApiQueryCategoryInfo This query adds the <categories> subelement to all pages with the list of categories the page is in
* mw'class.ApiQueryCategoryMembers A query module to enumerate pages that belong to a category
* mw'class.ApiQueryContributions This query action adds a list of a specified user's contributions to the output
* mw'class.ApiQueryDeletedrevs Query module to enumerate all deleted revisions
* mw'class.ApiQueryDisabled API module that does nothing
* mw'class.ApiQueryDuplicateFiles A query module to list duplicates of the given file(s)
* mw'class.ApiQueryExternalLinks A query module to list all external URLs found on a given set of pages
* mw'class.ApiQueryExtLinksUsage
* mw'class.ApiQueryFilearchive Query module to enumerate all deleted files
* mw'class.ApiQueryGeneratorBase
* mw'class.ApiQueryImageInfo A query action to get image information and upload history
* mw'class.ApiQueryImages This query adds an <images> subelement to all pages with the list of images embedded into those pages
* mw'class.ApiQueryInfo A query module to show basic page information
* mw'class.ApiQueryIWBacklinks This gives links pointing to the given interwiki
* mw'class.ApiQueryIWLinks A query module to list all interwiki links on a page
* mw'class.ApiQueryLangBacklinks This gives links pointing to the given interwiki
* mw'class.ApiQueryLangLinks A query module to list all langlinks (links to correspanding foreign language pages)
* mw'class.ApiQueryLinks A query module to list all wiki links on a given set of pages
* mw'class.ApiQueryLogEvents Query action to List the log events, with optional filtering by various parameters
* mw'class.ApiQueryPageProps A query module to show basic page information
* mw'class.ApiQueryProtectedTitles Query module to enumerate all create-protected pages
* mw'class.ApiQueryQueryPage Query module to get the results of a QueryPage-based special page
* mw'class.ApiQueryRandom Query module to get list of random pages
* mw'class.ApiQueryRecentChanges A query action to enumerate the recent changes that were done to the wiki
* mw'class.ApiQueryRevisions A query action to enumerate revisions of a given page, or show top revisions of multiple pages
* mw'class.ApiQuerySearch Query module to perform full text search within wiki titles and content
* mw'class.ApiQuerySiteinfo A query action to return meta information about the wiki site
* mw'class.ApiQueryStashImageInfo A query action to get image information from temporarily stashed files
* mw'class.ApiQueryTags Query module to enumerate change tags
* mw'class.ApiQueryTest Database
* mw'class.ApiQueryUserInfo Query module to get information about the currently logged-in user
* mw'class.ApiQueryUsers Query module to get information about a list of users
* mw'class.ApiQueryWatchlist This query action allows clients to retrieve a list of recently modified pages that are part of the logged-in user's watchlist
* mw'class.ApiQueryWatchlistRaw This query action allows clients to retrieve a list of pages on the logged-in user's watchlist
* mw'class.ApiResult This class represents the result of the API operations
* mw'class.ApiRollback
* mw'class.ApiRsd API module for sending out RSD information
* mw'class.ApiTest Database
* mw'class.ApiTestCase
* mw'class.ApiTestCaseUpload * Abstract class to support upload tests
* mw'class.ApiTestContext
* mw'class.ApiTestUser
* mw'class.ApiUnblock API module that facilitates the unblocking of users
* mw'class.ApiUndelete
* mw'class.ApiUpload
* mw'class.ApiUploadTest Database
* mw'class.ApiUserrights
* mw'class.ApiWatch API module to allow users to watch a page
* mw'class.ApiWatchTest Database
* mw'class.ArchivedFile Class representing a row of the 'filearchive' table
* mw'class.ArrayDiffFormatter A pseudo-formatter that just passes along the Diff::$edits array
* mw'class.Article Class for viewing MediaWiki article and history
* mw'class.ArticleTablesTest Database
* mw'class.ArticleTest
* mw'class.AtomFeed Generate an Atom feed
* mw'class.AttachLatest
* mw'class.AuthPlugin Authentication plugin interface
* mw'class.AuthPluginUser
* mw'class.AutoLoader
* mw'class.Autopromote This class checks if user can get extra rights because of conditions specified in $wgAutopromote
* mw'class.BacklinkCache Class for fetching backlink lists, approximate backlink counts and partitions
* mw'class.BackupDumper
* mw'class.BackupReader
* mw'class.BadTitleError Show an error page on a badtitle
* mw'class.BagOStuff Interface is intended to be more or less compatible with the PHP memcached client
* mw'class.BaseDump Readahead helper for making large MediaWiki data dumps; reads in a previous XML dump to sequentially prefetch text records already normalized and decompressed
* mw'class.BaseTemplate New base template for a skin's template extended from QuickTemplate this class features helper methods that provide common ways of interacting with the data stored in the QuickTemplate
* mw'class.BatchedQueryRunner Run a database query in batches and wait for slaves
* mw'class.bench_HTTP_HTTPS
* mw'class.bench_if_switch
* mw'class.bench_strtr_str_replace
* mw'class.bench_wfIsWindows
* mw'class.BenchmarkDeleteTruncate
* mw'class.Benchmarker
* mw'class.BenchmarkHooks
* mw'class.BenchmarkPurge
* mw'class.BitmapHandler Generic handler for bitmap images
* mw'class.BitmapHandler_ClientOnly Handler for bitmap images that will be resized by clients
* mw'class.BitmapMetadataHandler Class to deal with reconciling and extracting metadata from bitmap images
* mw'class.BitmapMetadataHandlerTest
* mw'class.BitmapScalingTest
* mw'class.Blob Utility classThis allows us to distinguish a blob from a normal string and an array of strings
* mw'class.Block
* mw'class.BlockListPager
* mw'class.BlockTest Database Blocking
* mw'class.BmpHandler Handler for Microsoft's bitmap format; getimagesize() doesn't support these files
* mw'class.BrokenRedirectsPage A special page listing redirects to non existent page
* mw'class.CacheDependency
* mw'class.CacheStats Show statistics from the cache
* mw'class.CacheTime
* mw'class.CapsCleanup
* mw'class.Category Category objects are immutable, strictly speaking
* mw'class.Categoryfinder The "Categoryfinder" class takes a list of articles, creates an internal representation of all their parent categories (as well as parents of parents etc
* mw'class.CategoryPage Special handling for category description pages, showing pages, subcategories and file that belong to the category
* mw'class.CategoryPager TODO: Allow sorting by count
* mw'class.CategoryViewer
* mw'class.CdbFunctions Common functions for readers and writers
* mw'class.CdbReader Read from a CDB file
* mw'class.CdbReader_DBA Reader class which uses the DBA extension
* mw'class.CdbReader_PHP CDB reader class
* mw'class.CdbTest Test the CDB reader/writer
* mw'class.CdbWriter Write to a CDB file
* mw'class.CdbWriter_DBA Writer class which uses the DBA extension
* mw'class.CdbWriter_PHP CDB writer class
* mw'class.CgzCopyTransaction Class to represent a recompression operation for a single CGZ blob
* mw'class.ChangePassword
* mw'class.ChangesFeed Feed to Special:RecentChanges and Special:RecentChangesLiked
* mw'class.ChangesList Base class for all changes lists
* mw'class.ChangeTags
* mw'class.ChannelFeed
* mw'class.CheckAutoLoader
* mw'class.CheckBadRedirects
* mw'class.CheckExtensionsCLI
* mw'class.CheckImages
* mw'class.CheckLanguageCLI
* mw'class.CheckStorage
* mw'class.CheckSyntax
* mw'class.CheckUsernames
* mw'class.ChronologyProtector Class for ensuring a consistent ordering of events as seen by the user, despite replication
* mw'class.CleanupRemovedModules
* mw'class.CleanupSpam
* mw'class.CleanUpTest Additional tests for UtfNormal::cleanUp() function, inclusion regression checks for known problems
* mw'class.clear_stats
* mw'class.ClearInterwikiCache
* mw'class.CliInstaller Class for the core installer command line interface
* mw'class.CLIParser CLI script to easily parse some wikitext
* mw'class.CloneDatabase Helper class for making a copy of the database, mostly for unit testing
* mw'class.Collation
* mw'class.CologneBlueTemplate
* mw'class.CommandLineInc
* mw'class.CommandLineInstaller
* mw'class.CompareParsers
* mw'class.CompressOld
* mw'class.ConcatenatedGzipHistoryBlob Concatenated gzip (CGZ) storage Improves compression ratio by concatenating like objects before gzipping
* mw'class.Conf
* mw'class.ConfEditor This is a state machine style parser with two internal stacks: * A next state stack, which determines the state the machine will progress to next * A path stack, which keeps track of the logical location in the file
* mw'class.ConfEditorParseError Exception class for parse errors
* mw'class.ConfEditorToken Class to wrap a token from the tokenizer
* mw'class.ConstantDependency
* mw'class.ContextSource The simplest way of implementing IContextSource is to hold a RequestContext as a member variable and provide accessors to it
* mw'class.ContribsPager Pager for Special:Contributions
* mw'class.ConverterRule Parser for rules of language conversion , parse rules in -{ }- tag
* mw'class.ConvertLinks
* mw'class.ConvertUserOptions
* mw'class.Cookie
* mw'class.CookieJar
* mw'class.CopyFileOp Copy a file from one storage path to another in the backend
* mw'class.CoreLinkFunctions Various core link functions, registered in Parser::firstCallInit()
* mw'class.CoreParserFunctions Various core parser functions, registered in Parser::firstCallInit()
* mw'class.CoreTagHooks Various tag hooks, registered in Parser::firstCallInit()
* mw'class.CountMessages Count how many messages we have defined for each language
* mw'class.CreateAndPromote
* mw'class.CreateFileOp Create a file in the backend with the given content
* mw'class.CreditsAction
* mw'class.CSSJanus This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version
* mw'class.CSSJanus_Tokenizer Utility class used by CSSJanus that tokenizes and untokenizes things we want to protect from being janused
* mw'class.CSSMin
* mw'class.csvStatsOutput Csv output
* mw'class.CurlHttpRequest MWHttpRequest implemented using internal curl compiled into PHP
* mw'class.Database Legacy support: Database == DatabaseMysql
* mw'class.DatabaseBase Database abstraction object
* mw'class.DatabaseConf
* mw'class.DatabaseIbm_db2 Primary database interface
* mw'class.DatabaseInstaller Base class for DBMS-specific installation helper classes
* mw'class.DatabaseLag
* mw'class.DatabaseLogEntry This class wraps around database result row
* mw'class.DatabaseMssql
* mw'class.DatabaseMysql Database abstraction object for mySQL Inherit all methods and properties of Database::Database()
* mw'class.DatabaseOracle
* mw'class.DatabasePostgres
* mw'class.DatabaseSqlite
* mw'class.DatabaseSqliteStandalone This class allows simple acccess to a SQLite database independently from main database settings
* mw'class.DatabaseSqliteTest sqlite Database
* mw'class.DatabaseTest Database DatabaseBase
* mw'class.DatabaseType
* mw'class.DatabaseUpdater Class for handling database updates
* mw'class.DateFormats Test various language time and date functions
* mw'class.DateFormatter Date formatter, recognises dates in plain text and formats them accoding to user preferences
* mw'class.DBABagOStuff Cache that uses DBA as a backend
* mw'class.DBAccessError Exception class for attempted DB access
* mw'class.DBConnectionError
* mw'class.DBError Database error base class
* mw'class.DBLockManager Version of LockManager based on using DB table locks
* mw'class.DBMasterPos An object representing a master or slave position in a replicated setup
* mw'class.DBObject Utility class
* mw'class.DBQueryError
* mw'class.DbTestPreviewer
* mw'class.DbTestRecorder
* mw'class.DBUnexpectedError
* mw'class.DeadendPagesPage A special page that list pages that contain no link to other pages
* mw'class.DefaultSettings
* mw'class.DeferrableUpdate Interface that deferrable updates should implement
* mw'class.DeferredUpdates Class for mananging the deferred updates
* mw'class.DelayedParserTest A class to delay execution of a parser test hooks
* mw'class.DeleteAction
* mw'class.DeleteArchivedFiles Delete archived (non-current) files from the database
* mw'class.DeleteArchivedFilesImplementation Core functions for deleteArchivedFiles.php
* mw'class.DeleteArchivedRevisions Delete archived (deleted from public) revisions from the database
* mw'class.DeleteArchivedRevisionsImplementation Delete archived (deleted from public) revisions from the database
* mw'class.DeleteBatch Deletes a batch of pages Usage: php deleteBatch.php [-u <user>] [-r <reason>] [-i <interval>] [listfile] where [listfile] is a file where each line contains the title of a page to be deleted, standard input is used if listfile is not given
* mw'class.DeletedContribsPager Implements Special:DeletedContributions to display archived revisions
* mw'class.DeletedContributionsPage
* mw'class.DeleteDefaultMessages Deletes all pages in the MediaWiki namespace which were last edited by "MediaWiki default"
* mw'class.DeleteFileOp Delete a file at the given storage path from the backend
* mw'class.DeleteImageCache This script delete image information from the cache
* mw'class.DeleteLogFormatter This class formats delete log entries
* mw'class.DeleteOldRevisions Delete old (non-current) revisions from the database
* mw'class.DeleteOrphanedRevisions Maintenance script to delete revisions which refer to a nonexisting page Sometimes manual deletion done in a rush leaves crap in the database
* mw'class.DeletePageAdminTestCase
* mw'class.DeleteRevision Delete one or more revisions by moving them to the archive table
* mw'class.DeleteSelfExternals We want to make this whole thing as seamless as possible to the end-user
* mw'class.DependencyWrapper This class stores an arbitrary value along with its dependencies
* mw'class.DerivativeContext An IContextSource implementation which will inherit context from another source but allow individual pieces of context to be changed locally eg: A ContextSource that can inherit from the main RequestContext but have a different Title instance set on it
* mw'class.DerivativeRequest Similar to FauxRequest, but only fakes URL parameters and method (POST or GET) and use the base request for the remaining stuff (cookies, session and headers)
* mw'class.Diff Class representing a 'diff' between two sequences of strings
* mw'class.DifferenceEngine
* mw'class.DiffFormatter A class to format Diffs
* mw'class.DiffHistoryBlob Diff-based history compression Requires xdiff 1.5+ and zlib
* mw'class.Digit2Html This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version
* mw'class.DisambiguationsPage A special page that lists pages containing links to disambiguations pages
* mw'class.DjVuHandler Handler for DjVu images
* mw'class.DjVuImage Support for detecting/validating DjVu image files and getting some basic file metadata (resolution etc)
* mw'class.DoubleRedirectJob Job to fix double redirects after moving a page
* mw'class.DoubleRedirectsPage A special page listing redirects to redirecting page
* mw'class.DoubleReplacer Class to perform secondary replacement within each replacement string
* mw'class.DummyExtensionsTest Needed to avoid warnings like 'No tests found in class "ExtensionsTestSuite"
* mw'class.DummyLinker
* mw'class.DummyTermColorer
* mw'class.Dump7ZipOutput Sends dump output via the p7zip compressor
* mw'class.DumpBZip2Output Sends dump output via the bgzip2 compressor
* mw'class.DumpDBZip2Output
* mw'class.DumpFileOutput Stream outputter to send data to a file
* mw'class.DumpFilter Dump output filter class
* mw'class.DumpGZipOutput Sends dump output via the gzip compressor
* mw'class.DumpIterator
* mw'class.DumpLatestFilter Dump output filter to include only the last revision in each page sequence
* mw'class.DumpLinks Copyright (C) 2005 Brion Vibber <brion@pobox.com> http://www.mediawiki.org/
* mw'class.DumpMessages Dump an entire language, using the keys from English so we get all the values, not just the customized ones
* mw'class.DumpMultiWriter Base class for output stream; prints to stdout or buffer or whereever
* mw'class.DumpNamespaceFilter Dump output filter to include or exclude pages in a given set of namespaces
* mw'class.DumpNotalkFilter Simple dump output filter to exclude all talk pages
* mw'class.DumpOutput Base class for output stream; prints to stdout or buffer or whereever
* mw'class.DumpPipeOutput Stream outputter to send data to a file via some filter program
* mw'class.DumpRenderer
* mw'class.DumpRev This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version
* mw'class.DumpSisterSites Quickie page name dump script for SisterSites usage
* mw'class.EditAction
* mw'class.EditCLI Make an edit
* mw'class.EditPage The edit page/HTML interface (split from Article) The actual database and text munging is still in Article, but it should get easier to call those from alternate interfaces
* mw'class.EditPageTest
* mw'class.EditWatchlistCheckboxSeriesField
* mw'class.EditWatchlistNormalHTMLForm Extend HTMLForm purely so we can have a more sane way of getting the section headers
* mw'class.EhcacheBagOStuff Client for the Ehcache RESTful web service - http://ehcache.org/documentation/cache_server.html TODO: Simplify configuration and add to the installer
* mw'class.EmailConfirmation Special page allows users to request email confirmation message, and handles processing of the confirmation code when the link in the email is followed
* mw'class.EmailInvalidation Special page allows users to cancel an email confirmation using the e-mail confirmation code
* mw'class.EmaillingJob Old job used for sending single notification emails; kept for backwards-compatibility
* mw'class.EmailNotification This module processes the email notifications when the current page is changed
* mw'class.EmailPasswordTestCase
* mw'class.EmptyBagOStuff A BagOStuff object with no objects in it
* mw'class.EnhancedChangesList Generate a list of changes using an Enhanced system (uses javascript)
* mw'class.EnotifNotifyJob Job for email notification mails
* mw'class.ErrorPageError An error page which can definitely be safely rendered using the OutputPage
* mw'class.ExampleObject
* mw'class.Exif Class to extract and validate Exif data from jpeg (and possibly tiff) files
* mw'class.ExifBitmapHandler Stuff specific to JPEG and (built-in) TIFF handler
* mw'class.ExifBitmapTest
* mw'class.ExifRotationTest Tests related to auto rotation
* mw'class.ExifTest
* mw'class.ExplodeIterator An iterator which works exactly like:
* mw'class.ExportProgressFilter
* mw'class.extensionLanguages
* mw'class.ExtensionsTestSuite This test suite runs unit tests registered by extensions
* mw'class.ExternalStore Constructor class for data kept in external repositories
* mw'class.ExternalStoreDB DB accessable external objects
* mw'class.ExternalStoreHttp Example class for HTTP accessable external objects
* mw'class.ExternalStoreTest External Store tests
* mw'class.ExternalUser A class intended to supplement, and perhaps eventually replace, AuthPlugin
* mw'class.ExternalUser_Hardcoded This class supports external authentication from a literal array dumped in LocalSettings.php
* mw'class.ExternalUser_MediaWiki This class supports authentication against an external MediaWiki database, probably any version back to 1.5 or something
* mw'class.ExternalUser_vB This class supports the proprietary vBulletin forum system <http://www.vbulletin.com>, versions 3.5 and up
* mw'class.ExtraParserTest Parser-related tests that don't suit for parserTests.txt
* mw'class.FakeConverter Fake language converter
* mw'class.FakeDimensionFile
* mw'class.FakeMaintenance Fake maintenance wrapper, mostly used for the web installer/updater
* mw'class.FakeMemCachedClient Backwards compatibility alias for EmptyBagOStuff
* mw'class.FakeResultWrapper Overloads the relevant methods of the real ResultsWrapper so it doesn't go anywhere near an actual database
* mw'class.FakeTitle Fake title class that triggers an error if any members are called
* mw'class.Fallback This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version
* mw'class.FatalError Exception class which takes an HTML error message, and does not produce a backtrace
* mw'class.FauxRequest WebRequest clone which takes values from a provided array
* mw'class.FauxResponse
* mw'class.FauxResponseTest
* mw'class.FeedItem A base class for basic support for outputting syndication feeds in RSS and other formats
* mw'class.FeedUtils Helper functions for feeds
* mw'class.FetchText Communications protocol
* mw'class.FewestrevisionsPage Special page for listing the articles with the fewest revisions
* mw'class.Field Base for all database-specific classes representing information about database fields
* mw'class.File Implements some public methods and some protected utility functions which are required by multiple child classes
* mw'class.FileBackend Base class for all file backend classes (including multi-write backends)
* mw'class.FileBackendGroup Class to handle file backend registration
* mw'class.FileBackendMultiWrite This class defines a multi-write backend
* mw'class.FileBackendStore Base class for all backends associated with a particular storage medium
* mw'class.FileBackendStoreShardListIterator FileBackendStore helper function to handle file listings that span container shards
* mw'class.FileBackendTest FileRepo FileBackend
* mw'class.FileCacheBase
* mw'class.FileDeleteForm File deletion user interface
* mw'class.FileDependency
* mw'class.FileDuplicateSearchPage Searches the database for files of the requested hash, comparing this with the 'img_sha1' field in the image table
* mw'class.FileOp Helper class for representing operations with transaction support
* mw'class.FileOpScopedPHPTimeout FileOp helper class to expand PHP execution time for a function
* mw'class.FileRepo Base class for file repositories
* mw'class.FileRepoStatus Generic operation result class for FileRepo-related operations
* mw'class.FileRepoTest
* mw'class.FindHooks
* mw'class.FixBug20757
* mw'class.FixDoubleRedirects
* mw'class.FixExtLinksProtocolRelative Fixes any entries for protocol-relative URLs in the externallinks table, replacing each protocol-relative entry with two entries, one for http and one for https
* mw'class.FixSlaveDesync This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version
* mw'class.FixTimestamps This script fixes timestamp corruption caused by one or more webservers temporarily being set to the wrong time
* mw'class.FixUserRegistration Fix the user_registration field
* mw'class.ForeignAPIFile Foreign file accessible through api.php requests
* mw'class.ForeignAPIRepo A foreign repository with a remote MediaWiki with an API thingy
* mw'class.ForeignDBFile Foreign file with an accessible MediaWiki database
* mw'class.ForeignDBRepo A foreign repository with an accessible MediaWiki database
* mw'class.ForeignDBViaLBRepo A foreign repository with a MediaWiki database accessible via the configured LBFactory
* mw'class.ForkController Class for managing forking command line scripts
* mw'class.FormAction
* mw'class.FormatExif For compatability with old FormatExif class which some extensions use
* mw'class.FormatJson JSON formatter wrapper class
* mw'class.FormatMetadata Format Image metadata values into a human readable form
* mw'class.FormatMetadataTest
* mw'class.FormlessAction Actions generally fall into two groups: the show-a-form-then-do-something-with-the-input format (protect, delete, move, etc), and the just-do-something format (watch, rollback, patrol, etc)
* mw'class.FormOptions Helper class to keep track of options when mixing links and form elements
* mw'class.FormOptionsExposed This file host two test case classes for the MediaWiki FormOptions class:
* mw'class.FormOptionsInitializationTest : tests initialization of the class
* mw'class.FormOptionsInitializationTest Test class for FormOptions initialization Ensure the FormOptions::add() does what we want it to do
* mw'class.FormOptionsTest This file host two test case classes for the MediaWiki FormOptions class:
* mw'class.FormOptionsInitializationTest : tests initialization of the class
* mw'class.FormSpecialPage Special page which uses an HTMLForm to handle processing
* mw'class.FSFile Class representing a non-directory file on the file system
* mw'class.FSFileBackend Class for a file system (FS) based file backend
* mw'class.FSFileBackendFileList Wrapper around RecursiveDirectoryIterator that catches exception or does any custom behavoir that we may want
* mw'class.FSLockManager Simple version of LockManager based on using FS lock files
* mw'class.FSRepo A repository for files accessible via the local filesystem
* mw'class.GanConverter
* mw'class.GenderCache Caches user genders when needed to use correct namespace aliases
* mw'class.GenerateCollationData Generate first letter data files for Collation.php
* mw'class.GenerateNormalizerData Generates normalizer data files for Arabic and Malayalam
* mw'class.GenerateRandomImages
* mw'class.GenerateSitemap
* mw'class.GetLagTimes This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version
* mw'class.GetSlaveServer This script reports the hostname of a slave server
* mw'class.GetTextMaint Outputs page text to stdout, useful for command-line editing automation
* mw'class.GIFHandler Handler for GIF images
* mw'class.GIFHandlerTest
* mw'class.GIFMetadataExtractor GIF frame counter
* mw'class.GIFMetadataExtractorTest
* mw'class.GlobalDependency
* mw'class.GlobalTest
* mw'class.GlobalWithDBTest Database
* mw'class.HashBagOStuff This is a test of the interface, mainly
* mw'class.HashtableReplacer Class to perform replacement based on a simple hashtable lookup
* mw'class.HistoryAction This class handles printing the history page for an article
* mw'class.HistoryBlob Base class for general text storage via the "object" flag in old_flags, or two-part external storage URLs
* mw'class.HistoryBlobCurStub To speed up conversion from 1.4 to 1.5 schema, text rows can refer to the leftover cur table as the backend
* mw'class.HistoryBlobStub Pointer object for an item within a CGZ blob stored in the text table
* mw'class.HistoryPage Backwards-compatibility alias
* mw'class.HistoryPager
* mw'class.Hooks Hooks class
* mw'class.HooksTest
* mw'class.Html This class is a collection of static functions that serve two purposes:
* mw'class.HTMLBlockedUsersItemSelect Items per page dropdown
* mw'class.HTMLCacheUpdate Class to invalidate the HTML cache of all the pages linking to a given title
* mw'class.HTMLCacheUpdateJob Job wrapper for HTMLCacheUpdate
* mw'class.HTMLCheckField A checkbox field
* mw'class.HTMLEditTools
* mw'class.HTMLFileCache
* mw'class.HTMLFloatField A field that will contain a numeric value
* mw'class.HTMLForm Object handling generic submission, CSRF protection, layout and other logic for UI forms
* mw'class.HTMLFormField The parent class to generate form fields
* mw'class.HTMLHiddenField
* mw'class.HTMLInfoField An information field (text blob), not a proper input
* mw'class.HTMLIntField A field that must contain a number
* mw'class.HTMLMultiSelectField Multi-select field
* mw'class.HTMLRadioField Radio checkbox fields
* mw'class.HTMLSelectAndOtherField Double field with a dropdown list constructed from a system message in the format * Optgroup header ** <option value>=""> * New Optgroup header Plus a text field underneath for an additional reason
* mw'class.HTMLSelectField A select dropdown field
* mw'class.HTMLSelectOrOtherField Select dropdown field, with an additional "other" textbox
* mw'class.HTMLSubmitField Add a submit button inline in the form (as opposed to HTMLForm::addButton(), which will add it at the end)
* mw'class.HtmlTest Tests for includes/Html.php
* mw'class.HTMLTextAreaField
* mw'class.HTMLTextField
* mw'class.Http Various HTTP related functions
* mw'class.HttpError Show an error that looks like an HTTP server error
* mw'class.HttpRequest HttpRequest was renamed to MWHttpRequest in order to prevent conflicts with PHP's HTTP extension which also defines an HttpRequest class
* mw'class.HttpStatus
* mw'class.HttpTest Broken
* mw'class.IBM_DB2Blob Wrapper around binary large objects
* mw'class.IBM_DB2Field This represents a column in a DB2 database
* mw'class.IBM_DB2Helper
* mw'class.Ibm_db2Installer Class for setting up the MediaWiki database using IBM_DB2
* mw'class.IBM_DB2Result Wrapper to address lack of certain operations in the DB2 driver ( seek, num_rows )
* mw'class.Ibm_db2Updater Class for handling updates to IBM_DB2 databases
* mw'class.IContextSource Interface for objects which can provide a context on request
* mw'class.IcuCollation
* mw'class.IdentityCollation Collation class that's essentially a no-op
* mw'class.IEContentAnalyzer This class simulates Microsoft Internet Explorer's terribly broken and insecure MIME type detection algorithm
* mw'class.IEUrlExtension Internet Explorer derives a cache filename from a URL, and then in certain circumstances, uses the extension of the resulting file to determine the content type of the data, ignoring the Content-Type header
* mw'class.IEUrlExtensionTest Tests for IEUrlExtension::findIE6Extension
* mw'class.ImageBuilder
* mw'class.ImageCleanup
* mw'class.ImageGallery Image gallery
* mw'class.ImageHandler Media handler abstract base class for images
* mw'class.ImageHistoryList Builds the image revision log shown on image pages
* mw'class.ImageHistoryPseudoPager
* mw'class.ImageListPager
* mw'class.ImagePage Class for viewing MediaWiki file description pages
* mw'class.ImageQueryPage Variant of QueryPage which uses a gallery to output results, thus suited for reports generating images
* mw'class.ImportReporter Reporting callback
* mw'class.ImportSiteScripts
* mw'class.ImportStreamSource
* mw'class.ImportStringSource
* mw'class.IncludableSpecialPage Shortcut to construct an includable special page
* mw'class.IndexPager IndexPager is an efficient pager which uses a (roughly unique) index in the data set to implement paging, rather than a "LIMIT offset,limit" clause
* mw'class.InfoAction
* mw'class.InitEditCount
* mw'class.InitStats
* mw'class.InstallDocFormatter
* mw'class.InstallDocFormatterTest
* mw'class.Installer Base installer class
* mw'class.Interwiki The interwiki class All information is loaded on creation when called by Interwiki::fetch( $prefix )
* mw'class.IP A collection of public static functions to play with IP address and IP blocks
* mw'class.IPBlockForm
* mw'class.IPTC Class for some IPTC functions
* mw'class.IPTCTest
* mw'class.IPTest Tests for IP validity functions
* mw'class.IuConverter
* mw'class.JavaScriptMinifier JavaScript Minifier
* mw'class.JavaScriptMinifierTest
* mw'class.Job Class to both describe a background job and handle jobs
* mw'class.JpegHandler JPEG specific handler
* mw'class.JpegMetadataExtractor Class for reading jpegs and extracting metadata
* mw'class.JpegMetadataExtractorTest
* mw'class.JpegTest
* mw'class.JSCompilerContext
* mw'class.JSMinPlus
* mw'class.JSNode
* mw'class.JsonTest
* mw'class.JSParseHelper Maintenance script to do test JavaScript validity parses using jsmin+'s parser
* mw'class.JSParser
* mw'class.JSToken
* mw'class.JSTokenizer
* mw'class.KkConverter Kazakh (???????) converter routines
* mw'class.KuConverter Kurdish converter routines
* mw'class.Lang2Po
* mw'class.LangMemUsage Dumb program that tries to get the memory usage for each language file
* mw'class.Language Internationalisation code
* mw'class.LanguageAm Amharic (????)
* mw'class.LanguageAmTest Tests for MediaWiki languages/LanguageAm.php
* mw'class.LanguageAr Arabic (???????)
* mw'class.LanguageArTest Tests for MediaWiki languages/LanguageAr.php
* mw'class.LanguageAz Azerbaijani (Az?rbaycan)
* mw'class.LanguageBe Belarusian normative (?????????? ????)
* mw'class.LanguageBe_tarask Belarusian in Tara?kievica orthography (?????????? ???????????)
* mw'class.LanguageBeTaraskTest
* mw'class.LanguageBeTest Tests for MediaWiki languages/LanguageBe.php
* mw'class.LanguageBg Bulgarian (?????????)
* mw'class.LanguageBh Bihari (???????)
* mw'class.LanguageBhTest Tests for MediaWiki languages/LanguageBh.php
* mw'class.LanguageBs Bosnian (bosanski)
* mw'class.LanguageBsTest Tests for MediaWiki languages/LanguageBs.php
* mw'class.LanguageConverter Base class for language conversion
* mw'class.LanguageConverterTest
* mw'class.LanguageCs Czech (?e?tina [subst
* mw'class.LanguageCsTest Tests for MediaWiki languages/classes/Languagecs.php
* mw'class.LanguageCu Old Church Slavonic (????? ??????????)
* mw'class.LanguageCuTest Tests for MediaWiki languages/LanguageCu.php
* mw'class.LanguageCy Welsh (Cymraeg)
* mw'class.LanguageCyTest Tests for MediaWiki languages/classes/LanguageCy.php
* mw'class.LanguageDsb Lower Sorbian (Dolnoserbski)
* mw'class.LanguageDsbTest Tests for MediaWiki languages/classes/LanguageDsb.php
* mw'class.LanguageEo Esperanto (Esperanto)
* mw'class.LanguageEt Estonian (Eesti)
* mw'class.LanguageFi Finnish (Suomi)
* mw'class.LanguageFr French (Fran?ais)
* mw'class.LanguageFrTest Tests for MediaWiki languages/classes/LanguageFr.php
* mw'class.LanguageGa Irish (Gaeilge)
* mw'class.LanguageGan Class that handles both Traditional and Simplified Chinese right now it only distinguish gan_hans, gan_hant
* mw'class.LanguageGaTest Tests for MediaWiki languages/classes/LanguageGa.php
* mw'class.LanguageGd Scots Gaelic (G?idhlig)
* mw'class.LanguageGdTest Tests for MediaWiki languages/classes/LanguageGd.php
* mw'class.LanguageGv Manx (Gaelg)
* mw'class.LanguageGvTest Tests for MediaWiki languages/classes/LanguageGv.php
* mw'class.LanguageHe Hebrew (?????)
* mw'class.LanguageHeTest Tests for MediaWiki languages/classes/LanguageHe.php
* mw'class.LanguageHi Hindi (??????)
* mw'class.LanguageHiTest Tests for MediaWiki languages/LanguageHi.php
* mw'class.LanguageHr Croatian (hrvatski)
* mw'class.LanguageHrTest Tests for MediaWiki languages/classes/LanguageHr.php
* mw'class.LanguageHsb Upper Sorbian (Hornjoserbsce)
* mw'class.LanguageHsbTest Tests for MediaWiki languages/classes/LanguageHsb.php
* mw'class.LanguageHu Hungarian localisation for MediaWiki
* mw'class.LanguageHy Armenian (???????)
* mw'class.LanguageHyTest Tests for MediaWiki languages/LanguageHy.php
* mw'class.LanguageIu Inuktitut
* mw'class.LanguageJa Japanese (???)
* mw'class.LanguageKaa Karakalpak (Qaraqalpaqsha)
* mw'class.LanguageKk Class that handles Cyrillic, Latin and Arabic scripts for Kazakh right now it only distinguish kk_cyrl, kk_latn, kk_arab and kk_kz, kk_tr, kk_cn
* mw'class.LanguageKk_cyrl Kazakh (???????)
* mw'class.LanguageKm Khmer (?????????)
* mw'class.LanguageKsh Ripuarian (Ripoar?sh)
* mw'class.LanguageKshTest Tests for MediaWiki languages/classes/LanguageKsh.php
* mw'class.LanguageKu Kurdish (Kurd? / ?????)
* mw'class.LanguageKu_ku Kurdish
* mw'class.LanguageLa Latin (lingua Latina)
* mw'class.LanguageLn Lingala (Ling?la)
* mw'class.LanguageLnTest Tests for MediaWiki languages/classes/LanguageLn.php
* mw'class.LanguageLt Lithuanian (Lietuvi?)
* mw'class.LanguageLtTest Tests for MediaWiki languages/LanguageLt.php
* mw'class.LanguageLv Latvian (Latvie?u)
* mw'class.LanguageLvTest Tests for MediaWiki languages/classes/LanguageLv.php
* mw'class.LanguageMg Malagasy (Malagasy)
* mw'class.LanguageMgTest Tests for MediaWiki languages/classes/LanguageMg.php
* mw'class.LanguageMk Macedonian (??????????)
* mw'class.LanguageMkTest Tests for MediaWiki languages/classes/LanguageMk.php
* mw'class.LanguageMl Malayalam (??????)
* mw'class.LanguageMlTest Tests for MediaWiki languages/LanguageMl.php
* mw'class.LanguageMo Moldavian (????????????)
* mw'class.LanguageMoTest Tests for MediaWiki languages/classes/LanguageMo.php
* mw'class.LanguageMt Maltese (Malti)
* mw'class.LanguageMtTest Tests for MediaWiki languages/classes/LanguageMt.php
* mw'class.LanguageMy Burmese (Myanmasa)
* mw'class.LanguageNlTest Tests for MediaWiki languages/LanguageNl.php
* mw'class.LanguageNso Northern Sotho (Sesotho sa Leboa)
* mw'class.LanguageNsoTest Tests for MediaWiki languages/classes/LanguageNso.php
* mw'class.LanguageOs Ossetian (????)
* mw'class.LanguagePl Polish (polski)
* mw'class.LanguagePlTest Tests for MediaWiki languages/classes/LanguagePl.php
* mw'class.LanguageQqx For all translated messages, this returns the name of the message bracketed
* mw'class.LanguageRo Romanian (Rom?n?)
* mw'class.LanguageRoTest Tests for MediaWiki languages/classes/LanguageRo.php
* mw'class.LanguageRu Russian (??????? ????)
* mw'class.LanguageRuTest Tests for MediaWiki languages/classes/LanguageRu.php
* mw'class.languages
* mw'class.LanguageSe Northern Sami (S?megiella)
* mw'class.LanguageSeTest Tests for MediaWiki languages/classes/LanguageSe.php
* mw'class.LanguageSgs Samogitian (?emait??ka)
* mw'class.LanguageSgsTest Tests for MediaWiki languages/classes/LanguageSgs.php
* mw'class.LanguageSh Serbo-Croatian (Srpskohrvatski / ??????????????)
* mw'class.LanguageShi Tachelhit
* mw'class.LanguageShTest Tests for MediaWiki languages/classes/LanguageSh.php
* mw'class.LanguageSk Slovak (Sloven?ina)
* mw'class.LanguageSkTest Tests for MediaWiki languages/classes/LanguageSk.php
* mw'class.LanguageSl Slovenian (Sloven??ina)
* mw'class.LanguageSlTest Tests for MediaWiki languages/classes/LanguageSl.php
* mw'class.LanguageSma Southern Sami (?arjelsaemien)
* mw'class.LanguageSmaTest Tests for MediaWiki languages/classes/LanguageSma.php
* mw'class.LanguageSr Serbian (?????? / Srpski)
* mw'class.LanguageSr_ec Serbian (cyrillic script)
* mw'class.LanguageSr_el Serbian (latin script)
* mw'class.LanguageSrTest Tests for MediaWiki languages/LanguageTr.php
* mw'class.LanguageTest
* mw'class.LanguageTg Tajik (??????)
* mw'class.LanguageTi Tigrinya (????)
* mw'class.LanguageTiTest Tests for MediaWiki languages/classes/LanguageTi.php
* mw'class.LanguageTl Tagalog (Tagalog)
* mw'class.LanguageTlTest Tests for MediaWiki languages/classes/LanguageTl.php
* mw'class.LanguageToTest
* mw'class.LanguageTr Turkish (T?rk?e)
* mw'class.LanguageTrTest Tests for MediaWiki languages/LanguageTr.php
* mw'class.LanguageTyv Tyvan localization (???? ???) From friends at tyvawiki.org
* mw'class.LanguageUk Ukrainian (?????????? ????)
* mw'class.LanguageUkTest Tests for MediaWiki languages/classes/LanguageUk.php
* mw'class.LanguageWa Walloon (Walon)
* mw'class.LanguageWaTest Tests for MediaWiki languages/classes/LanguageWa.php
* mw'class.LanguageYue Cantonese (??)
* mw'class.LanguageZh Class that handles both Traditional and Simplified Chinese right now it only distinguish zh_hans, zh_hant, zh_cn, zh_tw, zh_sg and zh_hk
* mw'class.LanguageZh_hans Simplified Chinese
* mw'class.LBFactory An interface for generating database load balancers
* mw'class.LBFactory_Fake LBFactory class that throws an error on any attempt to use it
* mw'class.LBFactory_Multi A multi-wiki, multi-master factory for Wikimedia and similar installations
* mw'class.LBFactory_Simple A simple single-master LBFactory that gets its configuration from the b/c globals
* mw'class.LBFactory_Single An LBFactory class that always returns a single database object
* mw'class.LCStore Interface for the persistence layer of LocalisationCache
* mw'class.LCStore_Accel LCStore implementation which uses PHP accelerator to store data
* mw'class.LCStore_CDB LCStore implementation which stores data as a collection of CDB files in the directory given by $wgCacheDirectory
* mw'class.LCStore_DB LCStore implementation which uses the standard DB functions to store data
* mw'class.LCStore_Null Null store backend, used to avoid DB errors during install
* mw'class.LegacyLogFormatter This class formats all log entries for log types which have not been converted to the new system
* mw'class.LegacyTemplate
* mw'class.License A License class for use on Special:Upload (represents a single type of license)
* mw'class.Licenses A License class for use on Special:Upload
* mw'class.LicensesTest
* mw'class.LikeMatch Used by DatabaseBase::buildLike() to represent characters that have special meaning in SQL LIKE clauses and thus need no escaping
* mw'class.LinkBatch Class representing a list of titles The execute() method checks them all for existence and adds them to a LinkCache object
* mw'class.LinkCache Cache for article titles (prefixed DB keys) and ids linked from one source
* mw'class.Linker Some internal bits split of from Skin.php
* mw'class.LinkFilter Some functions to help implement an external link filter for spam control
* mw'class.LinkHolderArray
* mw'class.LinkMarkerReplacer
* mw'class.LinkSearchPage Special:LinkSearch to search the external-links table
* mw'class.LinksUpdate See docs/deferred.txt
* mw'class.ListredirectsPage Special:Listredirects - Lists all the redirects on the wiki
* mw'class.LoadBalancer Database load balancing object
* mw'class.LoadBalancer_Single Helper class for LBFactory_Single
* mw'class.LoadMonitor An interface for database load monitoring
* mw'class.LoadMonitor_MySQL Basic MySQL load monitor with no external dependencies Uses memcached to cache the replication lag for a short time
* mw'class.LoadMonitor_Null
* mw'class.LocalFile Class to represent a local file in the wiki's own database
* mw'class.LocalFileDeleteBatch Helper class for file deletion
* mw'class.LocalFileMoveBatch Helper class for file movement
* mw'class.LocalFileRestoreBatch Helper class for file undeletion
* mw'class.LocalFileTest These tests should work regardless of $wgCapitalLinks Database
* mw'class.LocalisationCache Class for caching the contents of localisation files, Messages*.php and *.i18n.php
* mw'class.LocalisationCache_BulkLoad A localisation cache optimised for loading large amounts of data for many languages
* mw'class.LocalRepo A repository that stores files in the local filesystem and registers them in the wiki's own database
* mw'class.LocalSettingsGenerator Class for generating LocalSettings.php file
* mw'class.LockHolder LockServerDaemon helper class that keeps track of the locks
* mw'class.LockManager Class for handling resource locking
* mw'class.LockManagerGroup Class to handle file lock manager registration
* mw'class.LockServerDaemon Simple lock server daemon that accepts lock/unlock requests
* mw'class.LogEntry Interface for log entries
* mw'class.LogEntryBase Extends the LogEntryInterface with some basic functionality
* mw'class.LogEventsList
* mw'class.LogFormatter Implements the default log formatting
* mw'class.LoggedUpdateMaintenance Class for scripts that perform database maintenance and want to log the update in `updatelog` so we can later skip it
* mw'class.LoginForm Implements Special:UserLogin
* mw'class.LogPage Class to simplify the use of log pages
* mw'class.LogPager
* mw'class.LonelyPagesPage A special page looking for articles with no article linking to them, thus being lonely
* mw'class.LongPagesPage
* mw'class.LSLockManager Manage locks using a lock daemon server
* mw'class.MagicVariableTest
* mw'class.MagicWord This class encapsulates "magic words" such as redirect, __NOTOC__, etc
* mw'class.MagicWordArray Class for handling an array of magic words
* mw'class.MailAddress Stores a single person's name and email address
* mw'class.Maintenance Abstract maintenance class for quickly writing and churning out maintenance scripts with minimal effort
* mw'class.MaintenanceFormatInstallDoc
* mw'class.MakeLanguageSpec
* mw'class.ManualLogEntry Class for creating log entries manually, for example to inject them into the database
* mw'class.MappedDiff
* mw'class.MarkpatrolledAction
* mw'class.mcTest This script makes several 'set', 'incr' and 'get' requests on every memcached server and shows a report
* mw'class.MediaHandler Base media handler class
* mw'class.MediaHandlerTest
* mw'class.MediaTransformError Basic media transform error class
* mw'class.MediaTransformOutput Base class for the output of MediaHandler::doTransform() and File::transform()
* mw'class.MediaWiki Helper class for the index.php entry point
* mw'class.MediaWiki_I18N Wrapper object for MediaWiki's localization functions, to be passed to the template engine
* mw'class.MediaWikiBagOStuff Backwards compatibility alias
* mw'class.MediaWikiButtonsAvailabilityTestCase Test Case ID : 30 (http://www.mediawiki.org/wiki/New_installer/Test_plan) Test Case Name :'Back' and 'Continue' button availability Version : MediaWiki 1.18alpha
* mw'class.MediawikiCoreSmokeTestCase
* mw'class.MediawikiCoreSmokeTestSuite Stubs for now
* mw'class.MediaWikiDifferentDatabaseAccountTestCase Test Case ID : 04 (http://www.mediawiki.org/wiki/New_installer/Test_plan) Test Case Name : Install MediaWiki with different Database accounts for web access
* mw'class.MediaWikiDifferntDatabasePrefixTestCase Test Case ID : 02 (http://www.mediawiki.org/wiki/New_installer/Test_plan) Test Case Name : Install MediaWiki with the same database and the different database prefixes(Share one database between multiple wikis)
* mw'class.MediaWikiEditorConfig
* mw'class.MediaWikiEditorTestSuite
* mw'class.MediaWikiErrorsConnectToDatabasePageTestCase Test Case ID : 09 (http://www.mediawiki.org/wiki/New_installer/Test_plan) Test Case Name : Invalid/ blank values for fields in 'Connect to database' page
* mw'class.MediaWikiErrorsNamepageTestCase Test Case ID : 10 (http://www.mediawiki.org/wiki/New_installer/Test_plan) Test Case Name : Invalid/ blank values for fields in 'Name' page
* mw'class.MediaWikiExtraTestSuite
* mw'class.MediaWikiHelpFieldHintTestCase Test Case ID : 29 (http://www.mediawiki.org/wiki/New_installer/Test_plan) Test Case Name : Help field hint availability for the fields
* mw'class.MediaWikiInstallationCommonFunction
* mw'class.MediaWikiLangTestCase Base class that store and restore the Language objects
* mw'class.MediaWikiMySQLDataBaseTestCase Test Case ID : 01 (http://www.mediawiki.org/wiki/New_installer/Test_plan) Test Case Name : Install Mediawiki using 'MySQL' database type successfully Version : MediaWiki 1.18alpha
* mw'class.MediaWikiMySQLiteDataBaseTestCase Test Case ID : 06 (http://www.mediawiki.org/wiki/New_installer/Test_plan) Test Case Name : Install Mediawiki using 'MySQL' database type successfully Version : MediaWiki 1.18alpha
* mw'class.MediaWikiOnAlreadyInstalledTestCase Test Case ID : 03 (http://www.mediawiki.org/wiki/New_installer/Test_plan) Test Case Name : Install mediawiki on a already installed Mediawiki
* mw'class.MediaWikiParserTest The UnitTest must be either a class that inherits from MediaWikiTestCase or a class that provides a public static suite() method which returns an PHPUnit_Framework_Test object
* mw'class.MediaWikiProvide
* mw'class.MediaWikiRestartInstallationTestCase Test Case ID : 11, 12 (http://www.mediawiki.org/wiki/New_installer/Test_plan) Test Case Name : Install mediawiki on a already installed Mediawiki
* mw'class.MediaWikiRightFrameworkLinksTestCase Test Case ID : 14, 15, 16, 17 (http://www.mediawiki.org/wiki/New_installer/Test_plan) Test Case Name : User selects 'Read me' link
* mw'class.MediaWikiTestCase
* mw'class.MediaWikiUpgradeExistingDatabaseTestCase Test Case ID : 05 (http://www.mediawiki.org/wiki/New_installer/Test_plan) Test Case Name : Install Mediawiki by updating the existing database
* mw'class.MediaWikiUserInterfaceTestCase Test Case ID : 18 - 27 (http://www.mediawiki.org/wiki/New_installer/Test_plan) Test Case Name : UI of MediaWiki initial/ Language/ Welcome to MediaWiki!/ Connect to database/ Database settings/ Name/ Options/ Install/ Complete/ Restart Inslation pages Version : MediaWiki 1.18alpha
* mw'class.MemCachedClientforWiki
* mw'class.MemcachedPhpBagOStuff A wrapper class for the pure-PHP memcached client, exposing a BagOStuff interface
* mw'class.MergeHistoryPager
* mw'class.MergeMessageFileList
* mw'class.Message Methods which fullfil two basic services:
* mw'class.fetching interface messages
* mw'class.processing messages into a variety of formats
* mw'class.MessageBlobStore This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version
* mw'class.MessageCache Message cache Performs various MediaWiki namespace-related functions
* mw'class.MessageTest
* mw'class.MessageWriter
* mw'class.MigrateUserGroup Re-assign users from an old group to a new one
* mw'class.MimeMagic Implements functions related to mime types such as detection and mapping to file extension
* mw'class.MIMEsearchPage Searches the database for files of the requested MIME type, comparing this with the 'img_major_mime' and 'img_minor_mime' fields in the image table
* mw'class.MinifyScript
* mw'class.MockApi
* mw'class.MockDatabaseSqlite
* mw'class.MockOutputPage
* mw'class.MockSearch
* mw'class.ModernTemplate
* mw'class.MonoBookTemplate
* mw'class.MostcategoriesPage A special page that list pages that have highest category count
* mw'class.MostimagesPage A special page page that list most used images
* mw'class.MostlinkedCategoriesPage A querypage to show categories ordered in descending order by the pages in them
* mw'class.MostlinkedPage A special page to show pages ordered by the number of pages linking to them
* mw'class.MostlinkedTemplatesPage Special page lists templates with a large number of transclusion links, i.e
* mw'class.MostrevisionsPage
* mw'class.MoveBatch Maintenance script to move a batch of pages
* mw'class.MoveFileOp Move a file from one storage path to another in the backend
* mw'class.MoveLogFormatter This class formats move log entries
* mw'class.MovePageForm A special page that allows users to change page titles
* mw'class.MovePageTestCase
* mw'class.MssqlField Utility class
* mw'class.MssqlResult The MSSQL PHP driver doesn't support sqlsrv_num_rows, so we recall all rows into an array and maintain our own cursor index into that array...This is similar to the way the Oracle driver handles this same issue
* mw'class.MssqlSearchResultSet
* mw'class.MultiWriteBagOStuff A cache class that replicates all writes to multiple child caches
* mw'class.MWBlankClass
* mw'class.MWDebug New debugger system that outputs a toolbar on page view
* mw'class.MWDebugTest
* mw'class.MWException MediaWiki exception
* mw'class.MWExceptionHandler Handler class for MWExceptions
* mw'class.MWFunction This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version
* mw'class.MWFunctionTest
* mw'class.MWHookException
* mw'class.MWHttpRequest This wrapper class will call out to curl (if available) or fallback to regular PHP if necessary for handling internal HTTP requests
* mw'class.MWHttpRequestTester Class to let us overwrite MWHttpREquest respHeaders variable
* mw'class.MWInit Some functions that are useful during startup
* mw'class.MWMemcached This is the PHP client for memcached - a distributed memory cache daemon
* mw'class.MWNamespace This is a utility class with only static functions for dealing with namespaces that encodes all the "magic" behaviors of them based on index
* mw'class.MWNamespaceTest Test class for MWNamespace
* mw'class.MwSql Send SQL queries from the specified file to the database, performing variable replacement along the way
* mw'class.MWTidy Class to interact with HTML tidy
* mw'class.MWTidyWrapper Class used to hide mw:editsection tokens from Tidy so that it doesn't break them or break on them
* mw'class.MyContributionsTestCase
* mw'class.MySQLField Utility class
* mw'class.MysqlInstaller Class for setting up the MediaWiki database using MySQL
* mw'class.MySqlLockManager MySQL version of DBLockManager that supports shared locks
* mw'class.MySQLMasterPos
* mw'class.MySQLSearchResultSet
* mw'class.MysqlUpdater Mysql update list and mysql-specific update functions
* mw'class.MyWatchListTestCase
* mw'class.NamespaceConflictChecker Check for articles to fix after adding/deleting namespaces
* mw'class.NewFilesPager
* mw'class.NewPagesPager
* mw'class.NewParserTest Although marked as a stub, can work independently
* mw'class.NewUsersLogFormatter This class formats new user log entries
* mw'class.nextJobDB Pick a database that has pending jobs
* mw'class.NostalgiaTemplate
* mw'class.NothingClass
* mw'class.NukeNS Remove pages with only 1 revision from the MediaWiki namespace, without flooding recent changes, delete logs, etc
* mw'class.NukePage Erase a page record from the database Irreversible (can't use standard undelete) and does not update link tables
* mw'class.NullFileOp Placeholder operation that has no params and does nothing
* mw'class.NullLockManager Simple version of LockManager that does nothing
* mw'class.NullRepo File repository with no files, for performance testing
* mw'class.ObjectCache
* mw'class.ObjectFileCache
* mw'class.OldChangesList Generate a list of changes using the good old system (no javascript)
* mw'class.OldLocalFile Class to represent a file in the oldimage table
* mw'class.OracleInstaller Class for setting up the MediaWiki database using Oracle
* mw'class.OracleUpdater Class for handling updates to Oracle databases
* mw'class.ORAField Utility class
* mw'class.ORAResult The oci8 extension is fairly weak and doesn't support oci_num_rows, among other things
* mw'class.Orphans Look for 'orphan' revisions hooked to pages which don't exist And 'childless' pages with no revisions
* mw'class.OrphanStats Show some statistics on the blob_orphans table, created with trackBlobs.php
* mw'class.OutputPage This class should be covered by a general architecture document which does not exist as of January 2011
* mw'class.Page Abstract class for type hinting (accepts WikiPage, Article, ImagePage, CategoryPage)
* mw'class.PageArchive Used to show archived pages and eventually restore them
* mw'class.PageDeleteTestSuite
* mw'class.PageQueryPage Variant of QueryPage which formats the result as a simple link to the page
* mw'class.Pager Basic pager interface
* mw'class.PageSearchTestCase
* mw'class.Parser PHP Parser - Processes wiki markup (which uses a more user-friendly syntax, such as "[[link]]" for making links), and provides a one-way transformation of that wiki markup it into XHTML output / markup (which in turn the browser understands, and can display)
* mw'class.Parser_DiffTest
* mw'class.Parser_LinkHooks Parser with LinkHooks experiment
* mw'class.ParserCache
* mw'class.ParserOptions Set options of the Parser
* mw'class.ParserOptionsTest
* mw'class.ParserOutput
* mw'class.ParserPreloadTest Basic tests for Parser::getPreloadText
* mw'class.ParserTest
* mw'class.ParserTestParserHook
* mw'class.PasswordError Thrown by User::setPassword() on error
* mw'class.PatchSql Manually run an SQL patch outside of the general updaters
* mw'class.PathRouter PathRouter class
* mw'class.PathRouterTest Tests for the PathRouter parsing
* mw'class.PatrolLog Class containing static functions for working with logs of patrol events
* mw'class.PatrolLogFormatter This class formats patrol log entries
* mw'class.PermissionsError Show an error when a user tries to do something they do not have the necessary permissions for
* mw'class.PhpHttpRequest
* mw'class.PhpRefCallBugTester Test for PHP bug#50394 (PHP 5.3.x conversion to null only, not 5.2.x)
* mw'class.PHPUnitMaintClass
* mw'class.PhpXmlBugTester Test for PHP+libxml2 bug which breaks XML input subtly with certain versions
* mw'class.PNGHandler Handler for PNG images
* mw'class.PNGHandlerTest
* mw'class.PNGMetadataExtractor PNG frame counter
* mw'class.PNGMetadataExtractorTest
* mw'class.PoolCounter When you have many workers (threads/servers) giving service, and a cached item expensive to produce expires, you may get several workers doing the job at the same time
* mw'class.PoolCounter_Stub
* mw'class.PoolCounterWork Handy class for dealing with PoolCounters using class members instead of callbacks
* mw'class.PoolWorkArticleView
* mw'class.PopularPagesPage A special page that list most viewed pages
* mw'class.PopulateCategory
* mw'class.PopulateImageSha1 Optional upgrade script to populate the img_sha1 field
* mw'class.PopulateLogSearch Makes the required database updates for populating the log_search table retroactively
* mw'class.PopulateLogUsertext Makes the required database updates for Special:ProtectedPages to show all protected pages, even ones before the page restrictions schema change
* mw'class.PopulateParentId Makes the required database updates for rev_parent_id to be of any use
* mw'class.PopulateRevisionLength Populates the rev_len field for old revisions created before MW 1.10
* mw'class.PopulateRevisionSha1 Fills the rev_sha1 and ar_sha1 columns of revision and archive tables for revisions created before MW 1.19
* mw'class.PostgresField
* mw'class.PostgresInstaller Class for setting up the MediaWiki database using Postgres
* mw'class.PostgresSearchResult
* mw'class.PostgresSearchResultSet
* mw'class.PostgresUpdater Class for handling updates to Postgres databases
* mw'class.PPCustomFrame_DOM Expansion frame with custom arguments
* mw'class.PPCustomFrame_Hash Expansion frame with custom arguments
* mw'class.PPDAccum_Hash
* mw'class.PPDPart
* mw'class.PPDPart_Hash
* mw'class.PPDStack Stack class to help Preprocessor::preprocessToObj()
* mw'class.PPDStack_Hash Stack class to help Preprocessor::preprocessToObj()
* mw'class.PPDStackElement
* mw'class.PPDStackElement_Hash
* mw'class.PPFrame
* mw'class.PPFrame_DOM An expansion frame, used as a context to expand the result of preprocessToObj()
* mw'class.PPFrame_Hash An expansion frame, used as a context to expand the result of preprocessToObj()
* mw'class.PPFuzzTest
* mw'class.PPFuzzTester
* mw'class.PPFuzzUser
* mw'class.PPNode There are three types of nodes: * Tree nodes, which have a name and contain other nodes as children * Array nodes, which also contain other nodes but aren't considered part of a tree * Leaf nodes, which contain the actual data
* mw'class.PPNode_DOM
* mw'class.PPNode_Hash_Array
* mw'class.PPNode_Hash_Attr
* mw'class.PPNode_Hash_Text
* mw'class.PPNode_Hash_Tree
* mw'class.PPTemplateFrame_DOM Expansion frame with template arguments
* mw'class.PPTemplateFrame_Hash Expansion frame with template arguments
* mw'class.Preferences We're now using the HTMLForm object with some customisation to generate the Preferences form
* mw'class.PreferencesForm Some tweaks to allow js prefs to work
* mw'class.PrefixSearch PrefixSearch - Handles searching prefixes of titles and finding any page names that match
* mw'class.PreprocessDump
* mw'class.Preprocessor
* mw'class.Preprocessor_DOM
* mw'class.Preprocessor_Hash Differences from DOM schema: * attribute nodes are children * <h> nodes that aren't at the top are replaced with <possible-h>
* mw'class.PreprocessorTest
* mw'class.PreviewPageTestCase
* mw'class.Profiler
* mw'class.ProfilerSimple Simple profiler base class
* mw'class.ProfilerSimpleText The least sophisticated profiler output class possible, view your source! :)
* mw'class.ProfilerSimpleTrace Execution trace
* mw'class.ProfilerSimpleUDP ProfilerSimpleUDP class, that sends out messages for 'udpprofile' daemon (the one from mediawiki/trunk/udpprofile SVN )
* mw'class.ProfilerStub
* mw'class.Protect Protect or unprotect an article
* mw'class.ProtectAction
* mw'class.ProtectedPagesPager
* mw'class.ProtectedTitlesPager
* mw'class.ProtectionForm Handles the page protection UI and backend
* mw'class.PruneFileCache Prune file cache for pages, objects, resources, ect
* mw'class.PurgeAction
* mw'class.PurgeDeletedFiles Scans the deletion log and purges affected files within a timeframe
* mw'class.PurgeList Send purge requests for listed pages to squid
* mw'class.PurgeOldText Purge old text records from the database
* mw'class.PurgeParserCache
* mw'class.QueryAllSpecialPagesTest
* mw'class.QueryPage This is a class for doing query pages; since they're almost all the same, we factor out some of the functionality into a superclass, and let subclasses derive from it
* mw'class.QuickTemplate Generic wrapper for template functions, with interface compatible with what we use of PHPTAL 0.7
* mw'class.RandomImageGenerator RandomImageGenerator: does what it says on the tin
* mw'class.RandomPage Special page to direct the user to a random page
* mw'class.RangeDifference Alternative representation of a set of changes, by the index ranges that are changed
* mw'class.RawAction A simple method to retrieve the plain source of an article, using "action=raw" in the GET request string
* mw'class.RawPage Backward compatibility for extensions
* mw'class.RCCacheEntry
* mw'class.RCDatabaseLogEntry
* mw'class.RdfMetaData
* mw'class.ReadOnlyError Show an error when the wiki is locked/read-only and the user tries to do something that requires write access
* mw'class.ReassignEdits Reassign edits from a user or IP address to another user
* mw'class.RebuildAll Rebuild link tracking tables from scratch
* mw'class.RebuildFileCache Build file cache for content pages
* mw'class.RebuildLocalisationCache Rebuild the localisation cache
* mw'class.RebuildMessages This script purges all language messages from the cache
* mw'class.RebuildRecentchanges Rebuild link tracking tables from scratch
* mw'class.RebuildTextIndex Rebuild search index table from scratch
* mw'class.RecentChange Utility class for creating new RC entries
* mw'class.RecompressTracked
* mw'class.RedirectSpecialPage Shortcut to construct a special page alias
* mw'class.RefreshImageCount Quickie hack; patch-ss_images.sql uses variables which don't replicate properly
* mw'class.RefreshImageMetadata
* mw'class.RefreshLinks Refresh link tables
* mw'class.RefreshLinksJob Background job to update links for a given title
* mw'class.RefreshLinksJob2 Background job to update links for a given title
* mw'class.RegexlikeReplacer Class to replace regex matches with a string similar to that used in preg_replace()
* mw'class.RemoveUnusedAccounts Remove unused user accounts from the database An unused account is one which has made no edits
* mw'class.RenameDbPrefix Run this script to after changing $wgDBprefix on a wiki
* mw'class.RenderAction
* mw'class.ReplacementArray Replacement array for FSS with fallback to strtr() Supports lazy initialisation of FSS resource
* mw'class.Replacer Base class for "replacers", objects used in preg_replace_callback() and StringUtils::delimiterReplaceCallback()
* mw'class.RepoGroup Prioritized list of file repositories
* mw'class.RequestContext Group all the pieces relevant to the context of a request into one instance
* mw'class.ResetUserTokens
* mw'class.ResourceFileCache
* mw'class.ResourceLoader Dynamic JavaScript and CSS resource loading system
* mw'class.ResourceLoaderContext Object passed around to modules which contains information about the state of a specific loader request
* mw'class.ResourceLoaderFileModule ResourceLoader module based on local JavaScript/CSS files
* mw'class.ResourceLoaderFilePageModule ResourceLoader definition for MediaWiki:Filepage.css
* mw'class.ResourceLoaderModule Abstraction for resource loader modules, with name registration and maxage functionality
* mw'class.ResourceLoaderNoscriptModule Module for site customizations
* mw'class.ResourceLoaderSiteModule Module for site customizations
* mw'class.ResourceLoaderStartUpModule
* mw'class.ResourceLoaderTest
* mw'class.ResourceLoaderTestModule
* mw'class.ResourceLoaderUserCSSPrefsModule Module for user preference customizations
* mw'class.ResourceLoaderUserGroupsModule Module for user customizations
* mw'class.ResourceLoaderUserModule Module for user customizations
* mw'class.ResourceLoaderUserOptionsModule Module for user preference customizations
* mw'class.ResourceLoaderUserTokensModule Module for user tokens
* mw'class.ResourceLoaderWikiModule Abstraction for resource loader modules which pull from wiki pages
* mw'class.ResultWrapper Result wrapper for grabbing data queried by someone else
* mw'class.RevDel_ArchivedFileItem Item class for a filearchive table row
* mw'class.RevDel_ArchivedFileList List for filearchive table items
* mw'class.RevDel_ArchivedRevisionItem Item class for a archive table row by ar_rev_id -- actually used via RevDel_RevisionList
* mw'class.RevDel_ArchiveItem Item class for a archive table row
* mw'class.RevDel_ArchiveList List for archive table items, i.e
* mw'class.RevDel_FileItem Item class for an oldimage table row
* mw'class.RevDel_FileList List for oldimage table items
* mw'class.RevDel_Item Abstract base class for deletable items
* mw'class.RevDel_List Abstract base class for a list of deletable items
* mw'class.RevDel_LogItem Item class for a logging table row
* mw'class.RevDel_LogList List for logging table items
* mw'class.RevDel_RevisionItem Item class for a live revision table row
* mw'class.RevDel_RevisionList List for revision table items
* mw'class.ReverseChronologicalPager IndexPager with a formatted navigation bar
* mw'class.RevertAction Dummy class for pages not in NS_FILE
* mw'class.RevertFileAction Class for pages in NS_FILE
* mw'class.Revision
* mw'class.RevisiondeleteAction
* mw'class.RevisionDeleter Temporary b/c interface, collection of static functions
* mw'class.RevisionDeleteUser
* mw'class.RevisionItem Item class for a live revision table row
* mw'class.RevisionItemBase Abstract base class for revision items
* mw'class.RevisionList
* mw'class.RevisionListBase List for revision table items for a single page
* mw'class.RevisionTest
* mw'class.RollbackAction User interface for the rollback action
* mw'class.RollbackEdits Rollback all edits by a given user or IP provided they're the most recent edit (just like real rollback)
* mw'class.RSSFeed Generate a RSS feed
* mw'class.RunJobs This script starts pending jobs
* mw'class.Sanitizer XHTML sanitizer for MediaWiki
* mw'class.SanitizerTest
* mw'class.SanitizerValidateEmailTest
* mw'class.SavePageTestCase
* mw'class.ScopedLock Self releasing locks
* mw'class.SearchDump
* mw'class.SearchEngine Contain a class for special pages
* mw'class.SearchEngineDummy Dummy class to be used when non-supported Database engine is present
* mw'class.SearchEngineTest This class is not directly tested
* mw'class.SearchHighlighter Highlight bits of wikitext
* mw'class.SearchIBM_DB2 Search engine hook base class for IBM DB2
* mw'class.SearchMssql Search engine hook base class for Mssql (ConText)
* mw'class.SearchMySQL Search engine hook for MySQL 4+
* mw'class.SearchNearMatchResultSet A SearchResultSet wrapper for SearchEngine::getNearMatch
* mw'class.SearchOracle Search engine hook base class for Oracle (ConText)
* mw'class.SearchPostgres Search engine hook base class for Postgres
* mw'class.SearchResult
* mw'class.SearchResultSet
* mw'class.SearchResultTooMany
* mw'class.SearchSqlite Search engine hook for SQLite
* mw'class.SearchUpdate Database independant search index updater
* mw'class.SearchUpdateMyISAM Placeholder class
* mw'class.SearchUpdateTest Search
* mw'class.Selenium Selenium connector This is implemented as a singleton
* mw'class.SeleniumConfig
* mw'class.SeleniumConfigurationTest
* mw'class.SeleniumLoader
* mw'class.SeleniumServerManager
* mw'class.SeleniumTestCase
* mw'class.SeleniumTestConsoleLogger
* mw'class.SeleniumTestConstants
* mw'class.SeleniumTester
* mw'class.SeleniumTestHTMLLogger
* mw'class.SeleniumTestListener
* mw'class.SeleniumTestSuite
* mw'class.Services_JSON Converts to and from JSON format
* mw'class.Services_JSON_Error
* mw'class.ServicesJsonTest
* mw'class.SevenZipStream Stream wrapper around 7za filter program
* mw'class.ShiConverter
* mw'class.ShortPagesPage SpecialShortpages extends QueryPage
* mw'class.ShowJobs Based on runJobs.php
* mw'class.ShowStats Maintenance script to show the cached statistics
* mw'class.SideBarTest Skin
* mw'class.SimpleSeleniumConfig
* mw'class.SimpleSeleniumTestCase
* mw'class.SimpleSeleniumTestSuite Sample test suite
* mw'class.SiteConfiguration This is a class used to hold configuration settings, particularly for multi-wiki sites
* mw'class.SiteConfigurationTest
* mw'class.SiteStats Static accessor class for site_stats and related things
* mw'class.SiteStatsInit Class designed for counting of stats
* mw'class.SiteStatsUpdate Class for handling updates to the site_stats table
* mw'class.Skin The main skin class that provide methods and properties for all other skins
* mw'class.SkinChick Inherit main code from SkinTemplate, set the CSS and template filter
* mw'class.SkinCologneBlue
* mw'class.SkinLegacy
* mw'class.SkinModern Inherit main code from SkinTemplate, set the CSS and template filter
* mw'class.SkinMonoBook Inherit main code from SkinTemplate, set the CSS and template filter
* mw'class.SkinMySkin Inherit main code from SkinTemplate, set the CSS and template filter
* mw'class.SkinNostalgia
* mw'class.SkinSimple Inherit main code from SkinTemplate, set the CSS and template filter
* mw'class.SkinStandard
* mw'class.SkinTemplate Template-filler skin base class Formerly generic PHPTal (http://phptal.sourceforge.net/) skin Based on Brion's smarty skin
* mw'class.SkinVector SkinTemplate class for Vector skin
* mw'class.SocketArray LockServerDaemon helper class that keeps track socket states
* mw'class.SpecialActiveUsers
* mw'class.SpecialAllmessages
* mw'class.SpecialAllpages Implements Special:Allpages
* mw'class.SpecialBlankpage Special page designed for basic benchmarking of MediaWiki since it doesn't really do much
* mw'class.SpecialBlock A special page that allows users with 'block' right to block users from editing pages and other actions
* mw'class.SpecialBlockList A special page that lists existing blocks
* mw'class.SpecialBlockme A special page called by proxy_check.php to block open proxies
* mw'class.SpecialBookSources Special page outputs information on sourcing a book with a particular ISBN The parser creates links to this page when dealing with ISBNs in wikitext
* mw'class.SpecialCategories
* mw'class.SpecialChangeEmail Let users change their email address
* mw'class.SpecialChangePassword Let users recover their password
* mw'class.SpecialComparePages Implements Special:ComparePages
* mw'class.SpecialContributions Special:Contributions, show user contributions in a paged list
* mw'class.SpecialCreateAccount CreateAccount --> UserLogin/signup
* mw'class.SpecialEditWatchlist Provides the UI through which users can perform editing operations on their watchlist
* mw'class.SpecialEmailUser A special page that allows users to send e-mails to other users
* mw'class.SpecialExport A special page that allows users to export pages in a XML file
* mw'class.SpecialFilepath A special page that redirects to the URL of a given file
* mw'class.SpecialImport MediaWiki page data importer
* mw'class.SpecialJavaScriptTest
* mw'class.SpecialListAdmins ListAdmins --> ListUsers/sysop
* mw'class.SpecialListBots ListBots --> ListUsers/bot
* mw'class.SpecialListFiles
* mw'class.SpecialListGroupRights This special page lists all defined user groups and the associated rights
* mw'class.SpecialListUsers
* mw'class.SpecialLockdb A form to make the database readonly (eg for maintenance purposes)
* mw'class.SpecialLog A special page that lists log entries
* mw'class.SpecialMergeHistory Special page allowing users with the appropriate permissions to merge article histories, with some restrictions
* mw'class.SpecialMycontributions Shortcut to construct a special page pointing to current user contributions
* mw'class.SpecialMypage SpecialMypage, SpecialMytalk and SpecialMycontributions special pages are used to get user independant links pointing to the user page, talk page and list of contributions
* mw'class.SpecialMytalk Shortcut to construct a special page pointing to current user talk page
* mw'class.SpecialMyuploads Redirect to Special:Listfiles?user=$wgUser
* mw'class.SpecialNewFiles
* mw'class.SpecialNewpages A special page that list newly created pages
* mw'class.SpecialPage Parent special page class, also static functions for handling the special page list
* mw'class.SpecialPageFactory Factory for handling the special page list and generating SpecialPage objects
* mw'class.SpecialPasswordReset Special page for requesting a password reset email
* mw'class.SpecialPermanentLink Redirect from Special:PermanentLink/### to index.php?oldid=###
* mw'class.SpecialPreferences A special page that allows users to change their preferences
* mw'class.SpecialPrefixindex Implements Special:Prefixindex
* mw'class.SpecialProtectedpages A special page that lists protected pages
* mw'class.SpecialProtectedtitles A special page that list protected titles from creation
* mw'class.SpecialRandomredirect Special page to direct the user to a random redirect page (minus the second redirect)
* mw'class.SpecialRecentChanges A special page that lists last changes made to the wiki
* mw'class.SpecialRecentchangeslinked This is to display changes made to all articles linked in an article
* mw'class.SpecialRecentchangesTest Test class for SpecialRecentchanges class
* mw'class.SpecialRedirectToSpecial
* mw'class.SpecialRevisionDelete Special page allowing users with the appropriate permissions to view and hide revisions
* mw'class.SpecialSearch Implements Special:Search - Run text & title search and display the output
* mw'class.SpecialSearchTest Test class for SpecialSearch class Copyright © 2012, Antoine Musso
* mw'class.SpecialSpecialpages A special page that lists special pages
* mw'class.SpecialStatistics Special page lists various statistics, including the contents of `site_stats`, plus page view details if enabled
* mw'class.SpecialTags A special page that lists tags for edits
* mw'class.SpecialUnblock A special page for unblocking users
* mw'class.SpecialUndelete Special page allowing users with the appropriate permissions to view and restore deleted content
* mw'class.SpecialUnlockdb Implements Special:Unlockdb
* mw'class.SpecialUpload Form for handling uploads and special page
* mw'class.SpecialUploadStash
* mw'class.SpecialUploadStashTooLargeException
* mw'class.SpecialUserlogout Implements Special:Userlogout
* mw'class.SpecialVersion Give information about the version of MediaWiki, PHP, the DB and extensions
* mw'class.SpecialWatchlist
* mw'class.SpecialWhatLinksHere Implements Special:Whatlinkshere
* mw'class.SqlBagOStuff Class to store objects in the database
* mw'class.Sqlite This class contains code common to different SQLite-related maintenance scripts
* mw'class.SQLiteField
* mw'class.SqliteInstaller Class for setting up the MediaWiki database using SQLLite
* mw'class.SqliteMaintenance Performs some operations specific to SQLite database backend
* mw'class.SqliteSearchResultSet
* mw'class.SqliteUpdater Class for handling updates to Sqlite databases
* mw'class.SqlSearchResultSet This class is used for different SQL-based search engines shipped with MediaWiki
* mw'class.SquidPurgeClient An HTTP 1.0 client built for the purposes of purging Squid and Varnish
* mw'class.SquidPurgeClientPool
* mw'class.SquidUpdate Handles purging appropriate Squid URLs given a title (or titles)
* mw'class.SrConverter There are two levels of conversion for Serbian: the script level (Cyrillics <-> Latin), and the variant level (ekavian <->iyekavian)
* mw'class.StandardTemplate
* mw'class.statsOutput A general output object
* mw'class.Status Generic operation result class Has warning/error list, boolean status and arbitrary value
* mw'class.StorageTypeStats
* mw'class.StoreBatchTest FileRepo
* mw'class.StoreFileOp Store a file into the backend from a file on the file system
* mw'class.StreamFile
* mw'class.StringUtils A collection of static methods to play with strings
* mw'class.StripState
* mw'class.StructureTest The tests here verify the structure of the code
* mw'class.StubContLang Stub object for the content language of this wiki
* mw'class.StubObject Class to implement stub globals, which are globals that delay loading the their associated module code by deferring initialisation until the first method call
* mw'class.StubUserLang Stub object for the user language
* mw'class.SubmitAction
* mw'class.SvgHandler Handler for SVG images
* mw'class.SVGMetadataExtractor
* mw'class.SVGMetadataExtractorTest
* mw'class.SVGReader
* mw'class.SwiftFileBackend Class for an OpenStack Swift based file backend
* mw'class.SwiftFileBackendFileList SwiftFileBackend helper class to page through object listings
* mw'class.TableCleanup
* mw'class.TableCleanupTest
* mw'class.TableDiffFormatter Wikipedia Table style diff formatter
* mw'class.TablePager Table-based display with a user-selectable sort order
* mw'class.TagHookTest Parser
* mw'class.TempFSFile This class is used to hold the location and do limited manipulation of files stored temporarily (usually this will be $wgTmpDirectory)
* mw'class.TemplateCategoriesTest Database
* mw'class.TestConverter Test converter (from Tajiki to latin orthography)
* mw'class.TestFileIterator
* mw'class.TestRecorder
* mw'class.TestSample
* mw'class.TextPassDumper
* mw'class.textStatsOutput Output text
* mw'class.TgConverter Converts Tajiki to latin orthography
* mw'class.ThrottledError Show an error when the user hits a rate limit
* mw'class.ThumbnailImage Media transform output for images
* mw'class.TiffHandler Handler for Tiff images
* mw'class.TiffTest
* mw'class.TimeAdjustTest
* mw'class.Title Represents a title within MediaWiki
* mw'class.TitleArray Note: this entire file is a byte-for-byte copy of UserArray.php with s/User/Title/
* mw'class.TitleArrayFromResult
* mw'class.TitleCleanup
* mw'class.TitleDependency
* mw'class.TitleListDependency
* mw'class.TitleMethodsTest
* mw'class.TitlePermissionTest Database
* mw'class.TitleTest
* mw'class.cssjanus::Tokenizer
* mw'class.TrackBlobs
* mw'class.TransformParameterError Shortcut class for parameter validation errors
* mw'class.UcdXmlReader
* mw'class.UncategorizedCategoriesPage A special page that lists uncategorized categories
* mw'class.UncategorizedImagesPage Special page lists images which haven't been categorised
* mw'class.UncategorizedPagesPage A special page looking for page without any category
* mw'class.UncategorizedTemplatesPage Special page lists all uncategorised pages in the template namespace
* mw'class.Undelete
* mw'class.UnifiedDiffFormatter A formatter that outputs unified diffs
* mw'class.UnlistedSpecialPage Shortcut to construct a special page which is unlisted by default
* mw'class.UnprotectAction
* mw'class.UnregisteredLocalFile A file object referring to either a standalone local file, or a file in a local repository with no database, for example an FileRepo repository
* mw'class.UnusedCategoriesPage
* mw'class.UnusedimagesPage A special page that lists unused images
* mw'class.UnusedtemplatesPage A special page that lists unused templates
* mw'class.UnwatchAction
* mw'class.UnwatchedpagesPage A special page that displays a list of pages that are not on anyones watchlist
* mw'class.UpdateArticleCount
* mw'class.UpdateDoubleWidthSearch
* mw'class.UpdateLogging
* mw'class.UpdateMediaWiki
* mw'class.UpdateRestrictions
* mw'class.UpdateSearchIndex
* mw'class.UpdateSpecialPages
* mw'class.UploadBase UploadBase and subclasses are the backend of MediaWiki's file uploads
* mw'class.UploadChunkFileException
* mw'class.UploadChunkZeroLengthFileException
* mw'class.UploadDumper Dump a the list of files uploaded, for feeding to tar or similar
* mw'class.UploadForm Sub class of HTMLForm that provides the form section of SpecialUpload
* mw'class.UploadFromChunks Implements uploading from chunks
* mw'class.UploadFromFile Implements regular file uploads
* mw'class.UploadFromStash Implements uploading from previously stored file
* mw'class.UploadFromUrl Implements uploading from a HTTP resource
* mw'class.UploadFromUrlJob Job for asynchronous upload-by-url
* mw'class.UploadFromUrlTest Broken Upload
* mw'class.UploadFromUrlTestSuite
* mw'class.UploadSourceAdapter This is a horrible hack used to keep source compatibility
* mw'class.UploadSourceField A form field that contains a radio box in the label
* mw'class.UploadStash UploadStash is intended to accomplish a few things:
* mw'class.enable applications to temporarily stash files without publishing them to the wiki
* mw'class.UploadStashBadPathException
* mw'class.UploadStashCleanup
* mw'class.UploadStashFile
* mw'class.UploadStashFileException
* mw'class.UploadStashFileNotFoundException
* mw'class.UploadStashNoSuchKeyException
* mw'class.UploadStashNotAvailableException
* mw'class.UploadStashNotLoggedInException
* mw'class.UploadStashTest Database
* mw'class.UploadStashWrongOwnerException
* mw'class.UploadStashZeroLengthFileException
* mw'class.UploadTest Upload
* mw'class.UploadTestHandler
* mw'class.UppercaseCollation
* mw'class.UsageException This exception will be thrown when dieUsage is called to stop module execution
* mw'class.User The User object encapsulates all of the user-specific settings (user_id, name, rights, password, email address, options, last login time)
* mw'class.UserArray
* mw'class.UserArrayFromResult
* mw'class.UserBlockedError Show an error when the user tries to do something whilst blocked
* mw'class.UsercreateTemplate
* mw'class.UserDupes Look for duplicate user table entries and optionally prune them
* mw'class.UserloginTemplate HTML template for Special:Userlogin form
* mw'class.UserMailer Collection of static functions for sending mail
* mw'class.userOptions
* mw'class.UserPreferencesTestCase
* mw'class.UserrightsPage Special page to allow managing user group membership
* mw'class.UserRightsProxy Cut-down copy of User interface for local-interwiki-database user rights manipulation
* mw'class.UsersPager This class is used to get a list of user
* mw'class.UserTest Database
* mw'class.UserWrapper
* mw'class.UtfNormal Unicode normalization routines for working with UTF-8 strings
* mw'class.VectorTemplate QuickTemplate class for Vector skin
* mw'class.ViewAction
* mw'class.ViewCountUpdate Update for the 'page_counter' field, when $wgDisableCounters is false
* mw'class.WaitForSlave
* mw'class.WantedCategoriesPage A querypage to list the most wanted categories - implements Special:Wantedcategories
* mw'class.WantedFilesPage Querypage that lists the most wanted files
* mw'class.WantedPagesPage A special page that lists most linked pages that does not exist
* mw'class.WantedQueryPage Class definition for a wanted query page like WantedPages, WantedTemplates, etc
* mw'class.WantedTemplatesPage A querypage to list the most wanted templates
* mw'class.WatchAction
* mw'class.WatchedItem
* mw'class.WatchlistCleanup
* mw'class.WatchlistEditor
* mw'class.WebInstaller Class for the core installer web interface
* mw'class.WebInstaller_Complete
* mw'class.WebInstaller_Copying
* mw'class.WebInstaller_DBConnect
* mw'class.WebInstaller_DBSettings
* mw'class.WebInstaller_Document
* mw'class.WebInstaller_ExistingWiki
* mw'class.WebInstaller_Install
* mw'class.WebInstaller_Language
* mw'class.WebInstaller_Name
* mw'class.WebInstaller_Options
* mw'class.WebInstaller_Readme
* mw'class.WebInstaller_ReleaseNotes
* mw'class.WebInstaller_Restart
* mw'class.WebInstaller_Upgrade
* mw'class.WebInstaller_UpgradeDoc
* mw'class.WebInstaller_Welcome
* mw'class.WebInstallerOutput Output class modelled on OutputPage
* mw'class.WebInstallerPage Abstract class to define pages for the web installer
* mw'class.WebRequest Encapsulates getting at data passed in the URL or via a POSTed form, handling remove of "magic quotes" slashes, stripping illegal input characters and normalizing Unicode sequences
* mw'class.WebRequestTest
* mw'class.WebResponse Allow programs to request this object from WebRequest::response() and handle all outputting (or lack of outputting) via it
* mw'class.wfAssembleUrl Unit tests for wfAssembleUrl()
* mw'class.wfBaseName Tests for wfBaseName()
* mw'class.wfBCP47 Unit tests for wfBCP47()
* mw'class.wfExpandUrl Unit tests for wfExpandUrl()
* mw'class.wfRemoveDotSegments Unit tests for wfRemoveDotSegments()
* mw'class.wfShorthandToIntegerTest
* mw'class.wfTimestamp
* mw'class.wfUrlencodeTest Tests for includes/GlobalFunctions.php -> wfUrlencode()
* mw'class.WikiCategoryPage Special handling for category pages
* mw'class.WikiDiff3 This diff implementation is mainly lifted from the LCS algorithm of the Eclipse project which in turn is based on Myers' "An O(ND) difference algorithm and its variations" (http://citeseer.ist.psu.edu/myers86ond.html) with range compression (see Wu et al
* mw'class.WikiError Since PHP4 doesn't have exceptions, here's some error objects loosely modeled on the standard PEAR_Error model
* mw'class.WikiErrorMsg Localized error message object
* mw'class.WikiExporter
* mw'class.WikiFilePage Special handling for file pages
* mw'class.WikiImporter XML file reader for the page data importer
* mw'class.WikiMap Helper tools for dealing with other locally-hosted wikis
* mw'class.WikiPage Class representing a MediaWiki article and history
* mw'class.WikiReference Reference to a locally-hosted wiki
* mw'class.WikiRevision
* mw'class.wikiStatsOutput Outputs WikiText
* mw'class.WikiXmlError Error class designed to handle errors involved with XML parsing
* mw'class.WinCacheBagOStuff Wrapper for WinCache object caching functions; identical interface to the APC wrapper
* mw'class.WithoutInterwikiPage Special page lists pages without language links
* mw'class.WordLevelDiff
* mw'class.XCacheBagOStuff Wrapper for XCache object caching functions; identical interface to the APC wrapper
* mw'class.XCFHandler Handler for the Gimp's native file format; getimagesize() doesn't support these files
* mw'class.Xml Module of static functions for generating XML
* mw'class.XmlDumpWriter
* mw'class.XmlJs
* mw'class.XmlJsCode A wrapper class which causes Xml::encodeJsVar() and Xml::encodeJsCall() to interpret a given string as being a JavaScript expression, instead of string data
* mw'class.XMLReader2
* mw'class.XmlSelect
* mw'class.XmlSelectTest
* mw'class.XmlTest
* mw'class.XmlTypeCheck
* mw'class.XMPInfo This class is just a container for a big array used by XMPReader to determine which XMP items to extract
* mw'class.XMPReader Class for reading xmp data containing properties relevant to images, and spitting out an array that FormatExif accepts
* mw'class.XMPTest
* mw'class.XMPValidate This contains some static methods for validating XMP properties
* mw'class.XMPValidateTest
* mw'class.ZhClient Client for querying zhdaemon
* mw'class.ZhConverter
* mw'class.ZipDirectoryReader A class for reading ZIP file directories, for the purposes of upload verification
* mw'class.ZipDirectoryReaderError Internal exception class
* mw'class.ZipDirectoryReaderTest
[http://svn.wikimedia.org/doc/annotated.html] 2012-02-10
name::
* McsEngl.mw'class.LinkCache@cptIt,
_File:
* \includes\LinkCash.php,
* Cache for article titles (prefixed DB keys) and ids linked from one source.
* Keeps information on existence of articles. See linkcache.txt.
name::
* McsEngl.mw'class.MediaWiki@cptIt,
* McsEngl.mw'MediaWiki-class@cptIt,
_ADDRESS.WPG:
* http://svn.wikimedia.org/doc/classMediaWiki.html,
name::
* McsEngl.mw'class.OutputPage@cptIt,
* McsEngl.mw'OutputPage-class@cptIt,
_File:
* OutputPage.php#ql:mw'file.outputpage.php#
_DESCRIPTION:
Encapsulates the entire HTML page that will be sent in response to any server request. It is used by calling its functions to add text, headers, etc., in any order, and then calling output() to send it all. It could be easily changed to send incrementally if that becomes useful, but I prefer the flexibility. This should also do the output encoding. The system allocates a global one in $wgOut.
[/docs/design.txt]
_ADDRESS.WPG:
* http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/OutputPage.php?view=log,
* http://www.mediawiki.org/wiki/Manual:OutputPage.php,
OutputPage->addHTML()
Essentially the quick and dirty substitute for echo. It takes your input and adds it to the buffer: no questions asked. In the below action, if $action contains user-data, it could easily have XSS, evil stuff, or the spawn of Satan injected in. You're better off using escaping (such as with the php function htmlentities) or the XML builders class to build trusted output.
$wgOut->addHTML('<form action="'.$action.'" method="post">');
[http://www.mediawiki.org/wiki/Manual:Special_pages]
name::
* McsEngl.mw'class.QuickTemplate@cptIt,
* McsEngl.mw'QuickTemplate-class@cptIt,
_DESCRIPTION:
The QuickTemplate class, defined in $IP/includes/SkinTemplate.php, allows to separate front-end user interface (UI) from backend stuff. It is currently—quite unfortunately—used by many skins. While skins shouldn't use this class, it certainly can be useful in some situations.
The source code documentation states that the QuickTemplate class is a [g]eneric wrapper for template functions, with interface compatible with what we use of PHPTAL 0.7.
[http://www.mediawiki.org/wiki/Manual:QuickTemplate]
name::
* McsEngl.mw'class.Skin@cptIt,
* McsEngl.mw'Skin-class@cptIt,
_DESCRIPTION:
Encapsulates a "look and feel" for the wiki. All of the functions that render HTML, and make choices about how to render it, are here, and are called from various other places when needed (most notably, OutputPage::addWikiText()). The StandardSkin object is a complete implementation, and is meant to be subclassed with other skins that mayoverride some of its functions. The User object contains a reference to a skin (according to that user's preference), and so rather than having a global skin object we just rely on the global User and get the skin with $wgUser->getSkin().
See also skin.txt.
[/docs/design.txt]
skin.txt
MediaWiki's default skin is called Vector. This has been the case since
the 1.17 release (2011). This replaces the popular skin, Monobook which
had been been the default since MediaWiki 1.3 (2004). It is now the
default skin on Wikimedia Projects.
There are three legacy skins which were introduced before MediaWiki 1.3:
* Standard (a.k.a. Classic): The old default skin written by Lee Crocker
during the phase 3 rewrite, in 2002.
* Nostalgia: A skin which looks like Wikipedia did in its first year (2001).
This skin is now used for the old Wikipedia snapshot at
http://nostalgia.wikipedia.org/
* Cologne Blue: A nicer-looking alternative to Standard.
The other skin that is widely used (and is the MediaWiki default before 1.17)
is Monobook.
* Monobook: Named after the black-and-white photo of a book, in the page background.
This was introduced in the 2004 release of 1.3
And there are four Monobook-derived skins which have been introduced since 1.3:
* MySkin: Monobook without the CSS. The idea is that you customise it using user
or site CSS (see below)
* Chick: A lightweight Monobook skin with no sidebar, the sidebar links are
given at the bottom of the page instead, as in the unstyled MySkin.
* Simple: A lightweight skin with a simple white-background sidebar and no
top bar.
* Modern: An attractive blue/grey theme with sidebar and top bar.
== Custom CSS/JS ==
It is possible to customise the site CSS and JavaScript without editing any
source files. This is done by editing some pages on the wiki:
* [[MediaWiki:Common.css]] -- for skin-independent CSS
* [[MediaWiki:Monobook.css]], [[MediaWiki:Simple.css]], etc. -- for
skin-dependent CSS
* [[MediaWiki:Common.js]], [[MediaWiki:Monobook.js]], etc. -- for custom
site JavaScript
These can also be customised on a per-user basis, by editing User:<name>/monobook.css,, [[User:<name>/monobook.js]], etc.
This feature has led to a wide variety of "user styles" becoming available,
which change the appearance of Monobook or MySkin:
http://www.mediawiki.org/wiki/Manual:Gallery_of_user_styles
If you want a different look for your wiki, that gallery is a good place to start.
== Drop-in custom skins ==
If you put a file in MediaWiki's skins directory, ending in .php, the name of
the file will automatically be added as a skin name, and the file will be
expected to contain a class called Skin<name> with the skin class. You can then
make that skin the default by adding to LocalSettings.php:
$wgDefaultSkin = '<name>';
You can also disable dropped-in or core skins using:
$wgSkipSkins[] = '<name>';
This technique is used by the more ambitious MediaWiki site operators, to
create complex custom skins for their wikis. It should be preferred over
editing the core Monobook skin directly.
See http://www.mediawiki.org/wiki/Manual:Skinning for more information.
== Extension skins ==
It is now possible (since MediaWiki 1.12) to write a skin as a standard
MediaWiki extension, enabled via LocalSettings.php. This is done by adding
it to $wgValidSkinNames, for example:
$wgValidSkinNames['mycoolskin'] = 'My cool skin';
and then registering a class in $wgAutoloadClasses called SkinMycoolskin, which
derives from Skin. This technique is apparently not yet used (as of 2008)
outside the DumpHTML extension.
name::
* McsEngl.mw'class.Page@cptIt,
* McsEngl.mw'Page-class@cptIt,
name::
* McsEngl.mw'class.Revision@cptIt,
* McsEngl.mw'Revision-class@cptIt,
Encapsulates individual page revision data and access to the revision/text/blobs storage system. Higher-level code should never touch text storage directly; this class mediates it.
[/docs/design.txt]
name::
* McsEngl.mw'class.User@cptIt,
* McsEngl.mw'User-class@cptIt,
_DESCRIPTION:
Encapsulates the state of the user viewing/using the site. Can be queried
for things like the user's settings, name, etc. Handles the details of
getting and saving to the "user" table of the database, and dealing with
sessions and cookies.
[\docs\design.txt]
name::
* McsEngl.mw'code.Constant@cptIt,
* McsEngl.mw'constant-of-program@cptIt,
mw'MEDIAWIKI_constant:
if ( !defined( 'MEDIAWIKI' ) )
die( 1 );
name::
* McsEngl.mw'code.Data@cptIt,
* McsEngl.mw'data-program@cptIt,
name::
* McsEngl.mw'code.Directory@cptIt,
mw'Directory.includes/
This directory stores common include files needed by MediaWiki.
mw'Directory.includes.db/
This directory contains the code for database support. Database.php provides MediaWiki's database abstraction layer.
mw'Directory.languages/
This directory contains files used for localization and internationalization.
mw'Directory.skins/
This directory contain all skins classes, JavaScripts, CSS and some images used by that skins.
Code for most special pages is in files named Special*.php in the /includes/specials/ directory.
name::
* McsEngl.mw'code.Editing@cptIt,
* McsEngl.mw'editing-code@cptIt,
name::
* McsEngl.mw'Real-time-collaboration@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Future/Real-time_collaboration,
* https://www.mediawiki.org/wiki/Extension:EtherpadLite,
* http://www.mediawiki.org/wiki/Visual_editor/Realtime_collaboration,
* http://www.waveprotocol.org//
name::
* McsEngl.mw'Visual-editor@cptIt,
* McsEngl.mw'edit-surface@cptIt,
* McsEngl.mwes@cptIt580.4i,
* McsEngl.mw'extension.VisualEditor@cptIt,
* McsEngl.mw'editor-visual@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Visual_editor,
* http://www.mediawiki.org/wiki/Visual_editor/Feedback,
* http://www.mediawiki.org/wiki/Visual_editor/Software_design,
* http://www.mediawiki.org/wiki/Special:VisualEditorSandbox#,
* bug: https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions&component=VisualEditor,
* http://blog.wikimedia.org/2011/12/13/help-test-the-first-visual-editor-developer-prototype//
* https://bugzilla.wikimedia.org/buglist.cgi?component=VisualEditor&list_id=65079,
name::
* McsEngl.mwes'Human@cptIt,
_Team:
Alolita Sharma,
Trevor Parscal,
Neil Kandalgaonkar,
Inez Korczynski,
Roan Kattouw,
Brion Vibber,
Gabriel Wicke,
name::
* McsEngl.mwes'Link@cptIt,
In VisualEditor (wysiwyg) link-activation is not yet implemented. So
far I have seen 3 methods for this:
i) double clicking
ii) ctrl + clicking
iii) popup the target, where you can activate the link.
I am using everyday a local hypertext wysiwyg editor for 20 years now
(yes before html!!!) which uses the double-click method. I vote for
this as the fastest and using only one hand.
===
I think you should add this to bugzilla, but I would vote for
CTRL+click. I feel this is the most common way now (Open/MS office apps
and CK editor use this). In any case hoverning a link should display
information on how you can go to the link.
[Maciej Jaros]
name::
* McsEngl.mwes'Page@cptIt,
_STRUCTURE:
* div: id=es-docs: the links to 3 docs.
* div: id=es-body:
div: id=es-toolbar-wrapper:
div: id=es-panes:
* div: id=mixpanel:
* textarea: es-surfaceview-textarea:
* div: class=es-surfaceView-cursor
* div: class=es-contextView
name::
* McsEngl.mw'code.File@cptIt,
* McsEngl.mw'file@cptIt,
* McsEngl.mw'file-code@cptIt,
_ADDRESS.WPG:
* http://svn.wikimedia.org/doc/files.html,
name::
* McsEngl.mw'file'Code@cptIt,
_ mw'class.File:
* mw'file_class:
Implements some public methods and some protected utility functions which are required by multiple child classes. More...
Inherited by FakeDimensionFile, ForeignAPIFile, LocalFile, and UnregisteredLocalFile.
[http://svn.wikimedia.org/doc/classFile.html]
name::
* McsEngl.mw'file'Enconding@cptIt,
Encoding
All text files must be encoded with UTF-8 without byte order marks.
Do not use Microsoft Notepad to edit files. Notepad always inserts BOM. BOM will stop PHP files from working since it is a special character inserted at the very top of the file and will be outputted by the web browser to the client.
In short, make sure your editor supports UTF-8 without BOM.
[http://www.mediawiki.org/wiki/Manual:Coding_conventions]
name::
* McsEngl.mw'Index.php@cptIt,
_DESCRIPTION:
This is the main web entry point for MediaWiki.
name::
* McsEngl.mw'file.WebStart.php-in-includes@cptIt,
* McsEngl.mw'WebStart.php-in-includes@cptIt,
_DESCRIPTION:
This does the initial setup for a web request.
* It does some security checks, starts the profiler and loads the configuration, and optionally loads Setup.php depending on whether MW_NO_SETUP is defined.
===>
require_once( "$IP/includes/Init.php" );
require_once( "$IP/includes/AutoLoader.php" );
require_once( "$IP/includes/profiler/Profiler.php" );
require_once( "$IP/includes/Defines.php" );
require( "$IP/StartProfiler.php" );
name::
* McsEngl.mw'GlobalFunctions.php@cptIt,
_ADDRESS.WPG:
* http://svn.wikimedia.org/doc/GlobalFunctions_8php.html,
name::
* McsEngl.mw'file.Html.php-in-includes@cptIt,
* McsEngl.mw'Html.php@cptIt,
name::
* McsEngl.mw'file.LinkCache.php-in-includes@cptIt,
* McsEngl.mw'LinkCache.php@cptIt,
name::
* McsEngl.mw'file.OutputPage.php@cptIt,
_FILE:
\mw19\phase3\includes\OutputPage.php">mw'OutputPage.php,
_DESCRIPTION:
Hold HTML and wikitext parsing. Will also generate the <head> element for non-SkinTemplate skins or part of it for SkinTemplate based skins.
[http://www.mediawiki.org/wiki/Manual:OutputPage.php]
_Class:
* OutputPage-class#ql:mw'class.outputpage#
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Database.php#OutputPage.php,
name::
* McsEngl.mw'file.Setup.php@cptIt,
* McsEngl.mw'Setup.php@cptIt,
name::
* McsEngl.mw'file.WebRequest.php@cptIt,
_FILE:
\mw19\phase3\includes\WebRequest.php">mw'WebRequest.php,
_ mw'class.WebRequest:
* mw'WebRequest_class,
* mw'wgRequest,
===
WebRequest.php
The WebRequest class is used to obtain information from the GET and POST arrays. Using this is recommended over directly accessing the superglobals, since the object does fun stuff like magic_quotes cleaning. The WebRequest object is accessible from extensions by including the global $wgRequest in the code.
[edit]WebRequest->getVal($key)
Returns a string that corresponds to the form input with the name $key.
[edit]WebRequest->get*()
Returns an int, bool, etc depending on the function called. For checkboxes for example, the function getBool is useful.
[edit]WebRequest->wasPosted()
Returns true if a form was posted.
[http://www.mediawiki.org/wiki/Manual:Special_pages]
name::
* McsEngl.mw'file.Wiki.php-in-includes@cptIt,
_DESCRIPTION:
* Helper class for the index.php entry point.
[http://svn.wikimedia.org/doc/Wiki_8php.html]
name::
* McsEngl.mw'code.function@cptIt,
* McsEngl.mw'function-of-program@cptIt,
_GENERIC:
* php-function#ql:php'function#
_ADDRESS.WPG:
[http://www.mediawiki.org/wiki/Manual:Special_pages]
* mw'makeFooterIcon( $icon, 'withoutImage' );
===> displays no icon in "powered by"
name::
* McsEngl.mw'function.Global@cptIt,
_ADDRESS.WPG:
* \public_html\mw19\phase3\includes\GlobalFunctions.php,
* mw'wfMsgExt():
- http://www.mediawiki.org/wiki/Manual:WfMsgExt,
name::
* McsEngl.mw'code.Global-variable@cptIt,
* McsEngl.mw'global-variable@cptIt,
* McsEngl.mw'variable.global@cptIt,
_WHOLE:
* mw-configuring#ql:mw'configuring#
_DESCRIPTION:
The global $wgUser represents the currently logged in user, and is usually what you will deal with when manipulating users.
[http://www.mediawiki.org/wiki/Manual:Special_pages]
===
Hundreds of globals are initialised on startup by MediaWiki. The majority of these global variables are configuration settings that are set in DefaultSettings.php and LocalSettings.php. (See Manual:Configuration settings for documentation on these variables.) There is no comprehensive documentation for the remaining few hundred globals, however some of the most important ones are listed below. They are typically initialised either in index.php or in Setup.php.
[http://www.mediawiki.org/wiki/Manual:Global_object_variables]
_Notation:
* WikimediaGlobal: $wgUser,
* ExtensionGlobal: $egSPLAutorefresh,
_SPECIFIC:
$mediaWiki - MediaWiki object, the main base class for the MediaWiki software. Initializes the $wgTitle and $wgArticle objects, and executes the URL actions.
$wgArticle - Article object corresponding to $wgTitle.
$wgContLang - Language object associated with the wiki being viewed.
$wgLang - Language object selected by user preferences
$wgLoadBalancer - LoadBalancer object, manages database connections. Note: This variable doesn't exist anymore in 1.13
$wgMessageCache - Message cache to manage interface messages
$wgOut - OutputPage object for HTTP response.
$wgParser - Parser object. Parser extensions register their hooks here.
$wgRequest - WebRequest object, to get request data
$wgTitle - Title object created from the request URL. Note: This variable should be avoided when possible, more sane title objects are usually available.
$wgUser - User object for the user associated with the current request.
Globals are evil. The original MediaWiki code relied on globals for processing context far too often. MediaWiki development since then has been a story of slowly moving context out of global variables and into objects. Storing processing context in object member variables allows those objects to be reused in a much more flexible way.
[http://www.mediawiki.org/wiki/Manual:Globals_are_evil]
wg refers to an important non-constant programming element used in the MediaWiki software, and is an abbreviation for "Wikipedia Global" (the naming pre-dates the spread of MediaWiki beyond Wikipedia).
In general, any global variable (variable that has global scope) within the software has this prefix to make it easily identifiable when programming. However, a casual hacker will mainly come across such variables in the files includes/DefaultSettings.php and LocalSettings.php, which define variables to control the behaviour of the software in various ways.
The DefaultSettings.php file stores the defaults for these values and should not be edited; the LocalSettings file is used to override these values for a specific site — if a particular variable is not mentioned in your LocalSettings file, copy the entry from DefaultSettings and amend as appropriate.
[http://www.mediawiki.org/wiki/Manual:Wg_variable]
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Manual:Configuration_settings,
* http://www.mediawiki.org/wiki/Manual:Configuration_settings_(alphabetical),
* http://www.mediawiki.org/wiki/Category:MediaWiki_configuration_settings,
name::
* McsEngl.mw'code.Interface@cptIt,
* McsEngl.mw'interface-of-program@cptIt,
name::
* McsEngl.mw'code.Language@cptIt,
* McsEngl.mw'language-in-code@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Language_in_MediaWiki,
_ mw'class.Language:
- mw'Language_class,
Language
Represents the language used for incidental text, and also has some
character encoding functions and other locale stuff. The current user
interface language is instantiated as $wgLang, and the local content
language as $wgContLang; be sure to use the *correct* language object
depending upon the circumstances.
See also language.txt.
[\public_html\mw19\phase3\docs\design.txt]
name::
* McsEngl.mw'code.Lua@cptIt,
* McsEngl.mw'Lua@cptIt,
_ADDRESS.WPG:
* https://www.mediawiki.org/wiki/Lua,
* https://www.mediawiki.org/wiki/Lua_scripting,
_Evolution:
{time.2012-08-22}:
Tim Starling tstarling@wikimedia.org
8:36 AM (4 hours ago)
to wikitech-l
Lua is now enabled on www.mediawiki.org.
Note that this is not a temporary deployment. You can rewrite existing
templates to use Lua, we're not going to break them by turning it off
again.
-- Tim Starling
name::
* McsEngl.mw'code.Misc@cptIt,
* McsEngl.mw'code'example@cptIt,
mw'code.Get_Path:
<a href="<?php echo $_SERVER['SCRIPT_NAME']; ?>/Help:Contents">Help</a>
name::
* McsEngl.mw'code.Module@cptIt,
_SPECIFIC:
Here is a list of all modules:
Ajax
API
Config
HTTP
Database
DifferenceEngine
Exception
Dump
ExternalStorage
ExternalUser
Feed
FileRepo
Deployment
PHPBugTests
JobQueue
UtfNormal
Cache
Pager
Parser
Profiler
Search
Skins
SpecialPage
Templates
Language
Benchmark
MaintenanceLanguage
Maintenance
Testing
[http://svn.wikimedia.org/doc/]
name::
* McsEngl.mw'code.Parser@cptIt,
* McsEngl.mw'parser@cptIt,
* McsEngl.mw'wikitext-parser@cptIt,
_DESCRIPTION:
Our current wikitext parser goes through many passes, with many regexps and a few explode()/implode()s. Not only is it kinda slow, it's prone to horrible frightening bugs when different levels interfere with each other (such as the URL-in-URL bugs).
[http://www.mediawiki.org/wiki/One-pass_parser]
_ mw'class.Parser:
- mw'Parser_class:
Class used to transform wikitext to html.
[\public_html\mw19\phase3\docs\design.txt]
name::
* McsEngl.mw'parser'Resource@cptIt,
_SPECIFIC:
* http://www.mediawiki.org/wiki/Markup_spec#Parser_outline,
* http://www.mediawiki.org/wiki/Category:Parser,
* http://www.mediawiki.org/wiki/Manual:Preprocessor_DOM.php,
* http://www.mediawiki.org/wiki/Alternative_parsers,
* http://www.mediawiki.org/wiki/User:HappyDog/WikiText_parsing,
name::
* McsEngl.mw'code.PHP@cptIt,
* McsEngl.mw'PHP@cptIt,
_DESCRIPTION:
PHP is a web template system that accidentally grew up into a fairly general language. PHP's syntax, capabilities, and execution model bear vague similarities to Perl; scripts are loaded by an "interpreter", compiled to bytecode, and then executed. The PHP interpreter can be run from the command line, CGI-style, or more commonly as an in-process Apache module.
[http://www.mediawiki.org/wiki/PHP_configuration]
name::
* McsEngl.mw'code.ResourceLoader@cptIt,
* McsEngl.mw'ResourceLoader@cptIt,
_DESCRIPTION:
ResourceLoader
Like in many web applications, MediaWiki's interface has become more interactive and responsive over the years, mostly through the use of JavaScript. Usability efforts initiated in 2008, as well as advanced media handling (e.g. online editing of video files), called for dedicated front-end performance improvements.
To optimize the delivery of JavaScript and CSS assets, the ResourceLoader module was developed to optimize delivery of JS and CSS. Started in 2009, it was completed in 2011 and has been a core feature of MediaWiki since version 1.17. ResourceLoader works by loading JS and CSS assets on demand, thus reducing loading and parsing time for unused features, for example in older browsers. It also minifies the code, groups resources to save requests, and can embed images as data URIs.
[http://www.mediawiki.org/wiki/Manual:MediaWiki_architecture#ResourceLoader]
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/ResourceLoader,
* http://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_(users),
_Extension:
The recommended method for extensions seems to define
$wgResourceModules['ext.myExtension'] in the MyExtension.php file
name::
* McsEngl.mw'code.Revision@cptIt,
* McsEngl.mw'revision@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Special:Code/MediaWiki/106341,
name::
* McsEngl.mw'code.Variable@cptIt,
* McsEngl.mw'variable-of-program@cptIt,
* McsEngl.mw'vr@cptIt, {2012-02-05}
Getting the value of a variable defined in LocalSettings.php:
Platonides Platonides@gmail.com via lists.wikimedia.org
10:50 PM (11 hours ago)
to wikitech-l
On 27/01/12 21:22, Vance - wrote:
Is there a way to look up the value of a variable defined in the
'LocalSettings.php' file ?
Inside an extension? Sure.
global $wgDBpassword, $wgOut;
$wgOut->addHTML("The database password is $wgDBpassword");
If you mean from the wiki, no. You can't do
{{#getMyVariable: $wgDBpassword}} and magically obtain the password.
You _could_ create an extension which did that, but it wouldn't be a good idea... :)
name::
* McsEngl.mw'code.JavaScript@cptIt,
* McsEngl.mw'JavaScript@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/JavaScript,
* http://www.mediawiki.org/wiki/JavaScript_performance,
* http://www.mediawiki.org/wiki/Manual:Coding_conventions#JavaScript_code,
_DESCRIPTION:
Before MediaWiki 1.16, most JavaScript was in wikibits.js and other files in /skins/common/. From MediaWiki 1.17 and later on these are modernized into an object oriented library stored in ResourceLoader modules. Also jQuery has been introduced in the core as of MediaWiki 1.16, and loaded by default on every page as of 1.17.
[http://www.mediawiki.org/wiki/JavaScript]
_Loading:
Inline JavaScript
In previous versions of MediaWiki, nearly all JavaScript resources were added in the head of the document. With the introduction of ResourceLoader, JavaScript resources are now loaded at the bottom of the body.
The motivation for this change has to do with the fact that most browsers will wait for scripts to load and execute before continuing to load the page. By placing scripts at the bottom, the entire page can be loaded before any scripts are executed, ensuring that all style sheets and images referenced by the HTML content as well as the CSS can be queued before the browser pauses to execute scripts, thus increasing parallelism, and in effect client-side performance.
A side-effect of this change is that scripts that have been injected arbitrarily into the body can not depend on functionality provided by scripts which are loaded at the bottom. It may be possible to improve backwards compatibility in the future, but there are no specific plans to do so at this time. We recommend to do javascript bindings from the modules rather than inline.
[http://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension_developers]
name::
* McsEngl.mw'js'Gadget@cptIt,
* McsEngl.mw'Gadget@cptIt,
Gadget
A gadget is a JavaScript tool that can be enabled from user preferences.
[http://www.mediawiki.org/wiki/Manual:Glossary]
name::
* McsEngl.mw'js'Global-variable@cptIt,
_ mw'wgAllowUserJs:
if $wgAllowUserJs is set to true, users can customize the interface for themselves only by creating user subpages with lowercase titles (see below).
name::
* McsEngl.mw'js'MediaWiki:Common.js@cptIt,
* McsEngl.mw'MediaWiki.Common.js@cptIt,
* McsEngl.mw'file.Common.js-at-MediaWiki@cptIt,
MediaWiki:Common.js contains JavaScript that will be loaded for all users. This file is loaded for all users, but there are similar files affecting only users of specific skins (see below).
[http://www.mediawiki.org/wiki/Manual:Interface/JavaScript]
name::
* McsEngl.mw'js'MediaWiki:skinname.js@cptIt,
* McsEngl.mw'MediaWiki.skinname.js@cptIt,
* McsEngl.mw'file.skinname.js-at-MediaWiki@cptIt,
name::
* McsEngl.mw'js'jQuery@cptIt,
* McsEngl.mw'jQuery@cptIt,
_DESCRIPTION:
We have been shipping the jQuery JavaScript library with MediaWiki since the 1.16 release.
[http://www.mediawiki.org/wiki/JQuery]
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/JQuery,
_Loading:
As of MediaWiki 1.17 all resources are (or should be) loaded through ResourceLoader. The default modules are stored in /resources. The jQuery file is in /resources/jquery/jquery.js. There are no static minified versions anymore as ResourceLoader takes care of this when combing and optimizing all queued files.
[http://www.mediawiki.org/wiki/JQuery]
_Version:
MediaWiki jQuery Notes
MediaWiki 1.16 jQuery 1.3.2
MediaWiki 1.17 jQuery 1.4.2 r65962
MediaWiki 1.18 jQuery 1.6.4 bug 28904, bug 29773 r91845, r92349, r99231, r99262
MediaWiki 1.19 jQuery 1.7.1 r105612
name::
* McsEngl.mw'Security@cptIt,
_DESCRIPTION:
Security
Because MediaWiki is the platform for high-profile sites such as Wikipedia, core developers and code reviewers have enforced strict security rules[1]. To make it easier to write secure code, MediaWiki gives developers wrappers around HTML output and database queries to handle escaping. To sanitize user input, one uses the WebRequest#ql:mw'webrequest_class# class, which analyzes data passed in the URL or via a POSTed form. It removes "magic quotes" slashes, strips illegal input characters and normalizes Unicode sequences. Cross-site request forgery (CSRF) is avoided by using tokens, and cross-site scripting (XSS) by validating inputs and escaping outputs, usually with PHP's htmlspecialchars() function. MediaWiki also provides (and uses) an XHTML sanitizer with the Sanitizer class, and database functions that prevent SQL injection.
[http://www.mediawiki.org/wiki/MediaWiki_architecture_document/text/revision_2#Security]
_PART:
* user-right#ql:mw'user_right#
[Mediawiki-l] faking IP address?
Platonides Platonides@gmail.com via lists.wikimedia.org
2012-05-28 7:21 PM (1 minute ago)
to mediawiki-l
On 27/05/12 12:24, Helmut Hullen wrote:
> Hallo,
>
> is it possible that a bad guy fakes his IP address when he creates a
> page?
>
> My wiki (arktur.de/Wiki) suffers from Wiki spam, and sometimes I see IP
> addresses from spammers which don't occur in the apache access_log.
>
> Viele Gruesse!
> Helmut
Kind of. If the spammer uses a proxy, and the proxy provides a
X-Forwarded-For header, with the IP of the client on behalf of which it
is forwarding the request (or more, if there were several proxy hops),
MediaWiki will use that IP instead, provided it trusts the proxy.
Your apache access_log will report the proxy in such case.
This is most interesting for the case where you have a reverse proxy
(such as squid or varnish) in front of your site.
A proxy is considered trusted if its ip appears on $wgSquidServers or
$wgSquidServersNoPurge.
name::
* McsEngl.mw'Version@cptIt,
* McsEngl.mw'release@cptIt,
Major MediaWiki releases are generated approximately every three to eight months by taking snapshots of the development trunk, which is kept continuously in a runnable state;[19] minor releases, or point releases, are issued as needed to correct bugs (especially security problems).
[http://en.wikipedia.org/wiki/Mediawiki]
Mark A. Hershberger mah@everybody.org via lists.wikimedia.org
2013-02-25 5:02 PM (1 hour ago)
to Wikimedia
After the discussion last week, I want to scope out a release policy so
that we'll all know what to expect.
* A major release will be made every six months.
* An LTS release will be made every two years. There will be a one-year
overlap in LTS support. For example, 1.19 is supported until May 2015.
1.23 will be released the year before that so that people will have 1.23
available as an LTS to move to and a year to make the transition.
* Releases notes will continue to be the basis for seeing what has
changed. Because of the nature of a volunteer-driven project, it isn't
possible to say with any certainty what *will* happen in the next 6-12
months.
* To mitigate the problem of release notes, we will publish a list of
new features in the upcoming LTS relative to the last LTS six months
before it comes out. This means that about the time when 1.22 comes
out, we'll have an announcement for 1.19 users letting them know what
changes they can expect in 1.23.
* Point releases will be made periodically. Frequency TBD. Every point
release will include updated i18n files as well as any bug fixes. No
new features will be back-ported to point releases.
Thanks,
Mark.
name::
* McsEngl.mw.1.19@cptIt,
_ADDRESS.WPG:
* https://www.mediawiki.org/wiki/MediaWiki_1.19,
name::
* McsEngl.mw.1.18 (2011-11-28)@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/MediaWiki_1.18,
name::
* McsEngl.mw.1.17 (2011-06-22)@cptIt,
_ResourceLoader
As of MediaWiki 1.17 all resources are (or should be) loaded through ResourceLoader. The default modules are stored in /resources. The jQuery file is in /resources/jquery/jquery.js. There are no static minified versions anymore as ResourceLoader takes care of this when combing and optimizing all queued files.
[http://www.mediawiki.org/wiki/JQuery]
name::
* McsEngl.mw.1.16 (2010-07-28)@cptIt,
_JQuery:
We have been shipping the jQuery JavaScript library with MediaWiki since the 1.16 release.
[http://www.mediawiki.org/wiki/JQuery]
_Message:
MediaWiki 1.16 introduces major changes in message handling, and the old wfLoadExtensionMessages function will no longer be needed (or supported).
[\public_html\mw19\phase3\extensions\SemanticMediaWiki\includes\SMW_GlobalFunctions.php]
name::
* McsEngl.mw'WebServer@cptIt,
name::
* McsEngl.mw'Apache@cptIt,
_DESCRIPTION:
* Apache is the recommended webserver for use with MediaWiki. Other servers such as IIS may work.
[http://www.mediawiki.org/wiki/Apache_configuration]
name::
* McsEngl.mw'Documentation@cptIt,
* McsEngl.mw'manual@cptIt,
_ADDRESS.WPG:
* http://svn.wikimedia.org/doc//
* http://www.mediawiki.org/wiki/Documentation,
* http://www.mediawiki.org/wiki/Manual:Contents,
* http://www.mediawiki.org/wiki/Project:Manual,
* http://www.mediawiki.org/wiki/Category:Manual,
* http://www.mediawiki.org/wiki/Special:AllPages/Manual::
name::
* McsEngl.mw'code.Doc@cptIt,
_doc_attribute:
* @author Stephan Gambke
* @deprecated since 1.17
* @file
* @ingroup Lingo
* @param $modules Array: list of jQuery modules which should be loaded
* @return Array: the list of modules which were not loaded.
* @since 1.16
* @todo FIXME: Another class handles sending the whole page to the client.
* @version
name::
* McsEngl.mw'Doing@cptIt,
_SPECIFIC:
* developing#ql:mw'developing#,
* using#ql:mw'using#
name::
* McsEngl.mw'updating@cptIt,
* McsEngl.mw'upgrading@cptIt,
[MediaWiki-l] how to run update.php without shell access?
Yury Katkov katkov.juriy@gmail.com
2012-11-02 8:31 AM (54 minutes ago)
AFAIK if you only have ftp access you can rename your LocalSettings.php,
install your wiki once again and move back LocalSettings.php
-----
Tim Starling
1:02 PM (2 hours ago)
to mediawiki-l
It's no longer necessary to remove LocalSettings.php to upgrade a wiki
using the web installer. Just navigate to mw-config/index.php and
follow the instructions.
---
I guess I'm a little confused on the terminology here; you said
"upgrade a wiki", and as far as I know, I'm not upgrading my mediawiki
to another version, just trying to run maintenance/update.php as per the
installation instructions for an extension.
---
K. Peachey p858snake@gmail.com
12:28 AM (7 hours ago)
It runs the same process.
name::
* McsEngl.mw'EndUser-code@cptIt,
* McsEngl.mw'user-code@cptIt,
* McsEngl.mw'content@cptIt, {2012-01-27}
_SPECIFIC:
* user-data#ql:mw'user_data#,
* user-processing-code,
* user--mixed-code,
* wikitext#ql:mw'wikitext#
name::
* McsEngl.mw'EndUser-interface-language@cptIt,
* McsEngl.mw'User-interface-language@cptIt,
* McsEngl.mw'loc@cptIt,
* McsEngl.mw'localisation@cptIt,
_DESCRIPTION:
Available in over 300 languages
[http://en.wikipedia.org/wiki/Mediawiki] 2011-10-08
_PART:
* content-languge,
* program-language,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Localisation,
* http://www.mediawiki.org/wiki/Project:Language_policy,
* http://www.mediawiki.org/wiki/Project:Translation,
name::
* McsEngl.mw'loc'Code@cptIt,
_ mw'file.Language.php,
* mw'Language.php,
_ mw'file.Names.php:
* mw'Names.php,
* http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3/languages/Names.php,
name::
* McsEngl.mw'class.Language@cptIt,
* McsEngl.mw'Language-class@cptIt,
_DESCRIPTION:
Language
Represents the language used for incidental text, and also has some
character encoding functions and other locale stuff. The current user
interface language is instantiated as $wgLang, and the local content
language as $wgContLang; be sure to use the *correct* language object
depending upon the circumstances.
See also language.txt.
[/docs/design.txt]
===
language.txt
The Language object handles all readable text produced by the software. The most
used function is getMessage(), usually called with the wrapper function wfMsg()
which calls that method on the global language object. It just returns a piece
of text given a text key. It is recommended that you use each key only
once--bits of text in different contexts that happen to be identical in English
may not be in other languages, so it's better to add new keys than to reuse them
a lot. Likewise, if there is text that gets combined with things like names and
titles, it is better to put markers like "$1" inside a piece of text and use
str_replace() than to compose such messages in code, because their order may
change in other languages too.
While the system is running, there will be one global language object, which
will be a subtype of Language. The methods in these objects will return the
native text requested if available, otherwise they fall back to sending English
text (which is why the LanguageEn object has no code at all--it just inherits
the English defaults of the Language base class).
The names of the namespaces are also contained in the language object, though
the numbers are fixed.
There are two ways to get a language object. You can use the globals $wgLang and $wgContLang for user interface and content language respectively. For an arbitrary language you can construct an object by using Language::factory( 'en' ), by replacing en with the code of the language. The list of codes is in languages/Names.php.
[http://www.mediawiki.org/wiki/Localisation]
name::
* McsEngl.mw'Evolution@cptIt,
_2011-06-22: 1.17.0
This is the first stable release of the MediaWiki 1.17 branch.
{time.2003}:
The Wikimedia Foundation was announced on June 20, 2003, and in July, Wikipedia contributor Daniel Mayer suggested the name "MediaWiki" for the software, as a play on "Wikimedia".[20] The name was gradually phased in beginning in August 2003. The name has frequently caused confusion due to its (intentional) similarity to the "Wikimedia" name (which itself is similar to "Wikipedia").[21]
[http://en.wikipedia.org/wiki/Mediawiki]
{time.2002}:
Initial release 25 January 2002
===
When Wikipedia was first launched in January 2001, it ran on the existing wiki software UseModWiki, which was written in Perl and stored all wiki pages in text files. This software soon proved limiting, both in its functionality and its performance. In mid-2001, Magnus Manske, a developer and student at the University of Cologne, who was also a Wikipedia editor, began working on new software that would replace UseModWiki, specifically for use by Wikipedia. This software was written in PHP and stored all its information in a MySQL database. It launched on the English Wikipedia in January 2002, and gradually was placed on all the Wikipedia language sites of that time. This software was referred to as "the PHP script" and as "phase II", with the name "phase I" retroactively given to the use of UseModWiki.
Increasing usage soon caused load problems again, and soon afterward, another rewrite of the software began, done by Lee Daniel Crocker, which was first known as "phase III". This new software was also written in PHP with a MySQL backend, and kept the basic interface of the phase II software, but was meant to be more scalable. It went live on Wikipedia in July 2002.
[http://en.wikipedia.org/wiki/Mediawiki]
MediaWiki is now using a "continuous integration" development model with
quarterly snapshot releases. The latest development code is always kept
"ready to run", and in fact runs our own sites on Wikipedia.
Release branches will continue to receive security updates for about a year
from first release, but nonessential bugfixes and feature development happen
will be made on the development trunk and appear in the next quarterly release.
[http://lists.wikimedia.org/pipermail/mediawiki-l/2006-April/011090.html]
name::
* McsEngl.mw'Expansion@cptIt,
_DESCRIPTION:
Expansion of templates, parser functions, variables (on this page collectively called templates in italics), and template parameters (tplargs) is done in substitution, and also as the first steps in page rendering. It consists of two phases: the creation of an XML parse tree, and producing the expanded wikitext. After expansion, two more steps are producing the HTML, and (in the user's browser) rendering the page. Considering intermediate results can be helpful in understanding the process.
[http://meta.wikimedia.org/wiki/Help:Expansion]
_SERVICE:
* http://meta.wikimedia.org/wiki/Special:ExpandTemplates,
This page takes some wikitext and expands everything in double braces recursively: templates, parser functions like {{#if:...}}, and variables like {{CURRENTDAY}}. A difference with recursive substitution is that the parameter default feature works. The preview section shows how the wikitext in the result section is rendered. This is typically, but not always, the same as how the wikitext in the input section is rendered.
name::
* McsEngl.mw'Extension@cptIt,
* McsEngl.extension-mw@cptIt,
_GENERIC:
* mw-developing#ql:mw'developing#
_DESCRIPTION:
Extensions let you customize how MediaWiki looks and works.
Wiki users can browse through existing extensions or request a new extension. System administrators can install (or remove) extensions on the MediaWiki installations that they manage. Developers can write new extensions or improve existing extensions.
[http://www.mediawiki.org/wiki/Manual:Extensions]
===
Special pages created by third party developers are generally stored in the extensions directory in their own file or as part of a larger extension.
[http://www.mediawiki.org/wiki/Manual:Special_pages]
name::
* McsEngl.mw'extension'Code@cptIt,
name::
* McsEngl.mw'extension'Global@cptIt,
* McsEngl.mw'extension'variable@cptIt,
_SPECIFIC:
The following 27 pages are in this category, out of 27 total.
A
* $wgAPIListModules
* $wgAPIMetaModules
* $wgAPIModules
* $wgAPIPropModules
* $wgAuth
* $wgAutoloadClasses
* $wgAvailableRights
C
* $wgExtensionAliasesFiles
D
* $wgDisableInternalSearch
E
* $wgExceptionHooks
* $wgExtensionAssetsPath
* $wgExtensionCredits
* $wgExtensionFunctions
* $wgExtensionMessagesFiles
* $wgExtensionsDirectory
* $wgExternalStores
* $wgExtNewFields
* $wgExtNewIndexes
* $wgExtNewTables
* $wgExtPGAlteredFields
* $wgExtPGNewFields
H
* $wgHooks
P
* $wgPagePropLinkInvalidations
* $wgParserOutputHooks
S
* $wgSkinExtensionFunctions
* $wgSpecialPages
* $wgSpecialPageCacheUpdates
[http://www.mediawiki.org/wiki/Category:Extension_variables]
_ mw'wgExtensionCredits:
* http://www.mediawiki.org/wiki/$wgExtensionCredits,
===
$type must be one of the following:
media (added in 1.11) - media handlers
parserhook - extensions that modify, add or replace functionality in the MediaWiki parser
specialpage - extensions that add special pages
variable (added in 1.6.0) - make a new variable
other - does something else
The description and author fields get parsed as wiki syntax. This is often used to provide links to the author's homepage in the author field.
[http://www.mediawiki.org/wiki/$wgExtensionCredits]
===
$wgExtensionCredits['parserhook'][] = array(
'path' => __FILE__,
'name' => 'SubPageList',
'version' => SPL_VERSION,
'author' => array(
'[http://www.mediawiki.org/wiki/User:Jeroen_De_Dauw Jeroen De Dauw]',
'Van de Bugger. Based on [http://www.mediawiki.org/wiki/Extension:SubPageList3 SubPageList3].',
),
'url' => 'https://www.mediawiki.org/wiki/Extension:SubPageList',
'descriptionmsg' => 'spl-desc'
);
name::
* McsEngl.mw'extension'Creating@cptIt,
1. create DIRECTORY wiki/extensions/MyExtension
2. create FILES:
* MyExtension.php
* SpecialMyExtension.php
* MyExtension.i18n.php
3. set on LocalSettings.php:
require_once( "$IP/extensions/MyExtension/MyExtension.php" );
name::
* McsEngl.mw'extension'File@cptIt,
A minimal extension will consist of three files, one for each part:
- MyExtension/MyExtension.php
Stores the setup instructions.
- MyExtension/MyExtension.body.php
Stores the execution code for the extension. For complex extensions, requiring multiple PHP files, the implementation code may instead be placed in a subdirectory, MyExtension/includes. For an example, see the Semantic MediaWiki extension.
- MyExtension/MyExtension.i18n.php
stores internationalization information for the extension.
[http://www.mediawiki.org/wiki/Manual:Developing_extensions]
_File:
Most special page extensions require three files: a small setup file, which will be loaded every time MediaWiki starts, an internationalization file, and a file with the bulk of the code. All of them should be placed in a new directory inside the MediaWiki extensions/ directory. MediaWiki coding conventions define the four files like this:
<ExtensionName>.php - The setup file.
Special<SpecialPageName>.php - The special page code.
.i18n.php - The internationalization file.
Generally the special page should be named after the extension: so the Gadgets extension has the file Gadgets.php and SpecialGadgets.php. Obviously if your extension has more than one special page, you'll need more names.
[http://www.mediawiki.org/wiki/Manual:Special_pages]
name::
* McsEngl.mw'extension'Part.Execution@cptIt,
MyExtension/MyExtension.body.php
Stores the execution code for the extension. For complex extensions, requiring multiple PHP files, the implementation code may instead be placed in a subdirectory, MyExtension/includes. For an example, see the Semantic MediaWiki extension.
name::
* McsEngl.mw'extension'Part.Internationalization@cptIt,
File:
MyExtension/MyExtension.i18n.php
stores internationalization information for the extension.
name::
* McsEngl.mw'extension'Part.Setup@cptIt,
_File:
MyExtension/MyExtension.php
Stores the setup instructions.
name::
* McsEngl.mw'extension'Publishing@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Manual:Developing_extensions#Publishing,
name::
* McsEngl.mw'extension'Resource@cptIt,
_SPECIFIC:
* help:
* manual: http://www.mediawiki.org/wiki/Manual:Extensions,
* faq: http://www.mediawiki.org/wiki/Extensions_FAQ,
* download: http://www.mediawiki.org/wiki/Special:ExtensionDistributor,
* dev: http://www.mediawiki.org/wiki/Manual:Developing_extensions,
* http://www.mediawiki.org/wiki/Extension:Contents,
== group ==
* category: http://www.mediawiki.org/wiki/Category:Extensions,
* stable: http://www.mediawiki.org/wiki/Extension_Matrix/stable,
* wysiwyg: http://www.mediawiki.org/wiki/Category:WYSIWYG_extensions,
* simple: http://www.mediawiki.org/wiki/List_of_simple_extensions,
=== code ===
* http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions//
name::
* McsEngl.mw'extension'Starting@cptIt,
go: server/wiki/Special:MyExtension
How do I enable an extension?
Copy the extension PHP file to your extensions folder and add a require_once( "extensions/ExtensionName/ExtensionName.php" ); statement to your LocalSettings.php, with ExtensionName being the filename of your extension, such as MyExtension.php.
See also Manual:Extensions#Installing an extension
_Generic:
* creating-page#ql:mw'extension.creating_page#,
* editor#ql:mw'extension.editor#,
* hook,
* installed,
* javascript#ql:mw'extension.javascript#,
* scripts##
* search#ql:mw'extension.search#,
* special-page#ql:mw'extension.SpecialPage#,
* status-stable,
* status-beta,
* status-experimental,
* tag#ql:mw'extension.tag#
Extensions can be categorized based on the programming techniques used to achieve their effect. Most complex extensions will use more than one of these techniques:
[http://www.mediawiki.org/wiki/Manual:Developing_extensions#Extension_types]
_Quantity:
more than 1,800 extensions available for enabling various features to be added or changed.[10]
[http://en.wikipedia.org/wiki/Mediawiki] {2011-10-08}
* http://www.mediawiki.org/wiki/Extension_Matrix,
Last updated: 2011-10-06 00:32 MST. Listing 1874 out of 1968 members of Category:Extensions
name::
* McsEngl.mw'extension.1.18-version@cptIt,
MediaWiki 1.18 bundles:
* ConfirmEdit
* Gadgets
* Nuke
* ParserFunctions
* Renameuser
* Vector
* WikiEditor
name::
* McsEngl.mw'extension.Ajax@cptIt,
Ajax - you can use AJAX in your extension to let your JavaScript code interact with your server side extension code, without the need to reload the page.
[http://www.mediawiki.org/wiki/Manual:Developing_extensions#Extension_types]
name::
* McsEngl.mw'extension.ArticleFeedback@cptIt,
The Article Feedback Tool is a Wikimedia Foundation project designed to engage Wikimedia readers in the assessment of article quality, one of the five priorities defined in the strategic plan. It is currently deployed on a subset of pages on the English Wikipedia.
This extension does not work with the current version of mediawiki 1.17! Versions for 1.18 and later should appear in the usual extension repository.
[http://www.mediawiki.org/wiki/Extension:ArticleFeedback]
name::
* McsEngl.mw'extension.CalcII@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Extension:CalcII,
name::
* McsEngl.mw'extension.CreateAPage@cptIt,
_ADDRESS.WPG:
* http://help.wikia.com/wiki/Archive:CreatePlates,
name::
* McsEngl.mw'extension.CreateRedirect@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Extension:CreateRedirect,
_DESCRIPTION:
* Creates a new "page" which is redirected to current.
* Adds "menu-item" on toolbox-menu.
name::
* McsEngl.mw'extension.Creating-Page@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Category:Page_creation_extensions,
_SPECIFIC:
* CreateArticle: http://www.mediawiki.org/wiki/Extension:CreateArticle,
* MakeArticle#ql:mw'extension.makearticle#: http://www.mediawiki.org/wiki/Extension:MakeArticle,
name::
* McsEngl.mw'extension.Data@cptIt,
_DESCRIPTION:
Data extension is a MediaWiki extension by Nikola Smolenski which enables getting and setting of data in the articles.
Data is described by item/key/value triplets, where 'item' is typically the name of the article, 'key' the name of the data, and 'value' the actual data. Perhaps reading about the Data function will explain it the best.
The extension could be seen in action at http://www.rastko.net/~nikola/
Note that the extension does have some similarity to the Semantic MediaWiki. While coding I took a look at it - it was just a quick look, and I didn't look at actual SMW code - but now when the extension is finished, people tell me that it does much the same thing. But, on the other hand, perhaps attacking the problem from different angles will give a better solution.
[http://www.mediawiki.org/wiki/Extension:Data]
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Extension:Data,
CREATE TABLE /*_*/`data_extension` (
`item` mediumtext NOT NULL,
`key` mediumtext NOT NULL,
`value` mediumtext NOT NULL
);
On page: "Paris"
<setdata>
is a=city
population=2144700
</setdata>
Creates the "raws" on "data_extension"
Paris is a city
Paris population 2144700
On any page:
Paris has population: {{#data:Paris->population}}
==>
Paris has population: 2144700
On any page:
<data condition="is a=country">
* [[{{#data:}}]] population:{{#data:population}}
</data>
shows:
- France population:79milion
- Greece population:11 milion
IF
on France and Greece page:
<setdata>
is a=country
population=nnn
</setdata>
name::
* McsEngl.mw'extension.Database@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Category:Database_extensions,
name::
* McsEngl.mw'extension.DynamicPageList@cptIt,
* McsEngl.mw'extension.DPL@cptIt,
_ADDRESS.WPG:
* http://semeb.com/dpldemo/index.php?title=Dynamic_Page_List,
* http://www.mediawiki.org/wiki/Extension:DynamicPageList_(Wikimedia),
_DESCRIPTION:
DynamicPageList is a MediaWiki extension which allows wiki users to create a list of pages that are listed in a set of categories.
_mode =
mode determines the format of the list. The value can be unordered (bulleted list), ordered (numbered list), none (plain links with line breaks), gallery (image gallery, like <gallery>), inline (comma seperated list)
name::
* McsEngl.mw'extension.Editor@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/WYSIWYG_editor,
_SPECIFIC:
* FCKeditor: http://www.mediawiki.org/wiki/Extension:FCKeditor_(Official),
* MeanEditor: http://www.mediawiki.org/wiki/Extension:MeanEditor,
* VisualEditor#ql:mw'extension.visualeditor#,
* WikiEditor: http://www.mediawiki.org/wiki/Extension:WikiEditor,
* WYSIWYG#ql:mw'extension.wysiwyg#
name::
* McsEngl.mw'extension.Gadgets@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Extension:Gadgets,
_DESCRIPTION:
The Gadgets extension provides a way for users to pick JavaScript or CSS based "gadgets" that other wiki users provide.
Gadgets are made up of JavaScript and/or CSS snippets located on pages in the MediaWiki namespace. Each gadget is defined by a line in MediaWiki:Gadgets-definition, providing a name and description for the gadget, and a list of the JS and CSS snippets that it uses (see the Usage section below).
Since Gadgets reside in the MediaWiki namespace (the list defining the gadgets as well as the actual code snippets), only sysops (aka wiki admins) can edit the code. This is as it should be: only users especially trusted by the wiki community should be able to edit JavaScript code that is used by other users, since JavaScript can easily be used to hijack accounts or spy on people.
[http://www.mediawiki.org/wiki/Extension:Gadgets]
name::
* McsEngl.mw'extension.GRAPHICS@cptIt,
name::
* McsEngl.mw'extension.GraphViz@cptIt,
* McsEngl.GraphViz-mw-extenstion@cptIt, {2012-11-20}
GraphViz is a MediaWiki extension that lets you create and display graphs as inline images on wiki pages, using the open-source Graphviz and Mscgen applications:
Graphviz is a program that allows the creation of numerous types of graphs, using the DOT language.
Mscgen is a small program that parses Message Sequence Chart descriptions. Unlike Graphviz, this program does no clever layout operations or spline routing, as this is not needed.
Automatic graph drawing has many important applications in software engineering, database and web design, networking, and in visual interfaces for many other domains.
Additionally, this extension supports multiple graphs on one page, wiki-links in graphs, and automatic pruning of old images.
[http://www.mediawiki.org/wiki/Extension:GraphViz]
name::
* McsEngl.mw'extension.Halo@cptIt,
* McsEngl.halo-extension@cptIt580i,
_GENERIC:
* smw-extension#ql:smw'extension#
_ADDRESS.WPG:
* http://semanticweb.org/wiki/Halo_Extension,
* http://smwforum.ontoprise.com/smwforum/index.php/Halo_extension,
* http://www.smwplus.com/index.php/Help:Installing_Halo_extension_1.6.0,
_DESCRIPTION:
The Halo extension is an extension to Semantic MediaWiki (SMW) and has been developed as a part of Project Halo in order to facilitate the use of Semantic Wikis for a large community of users. Main focus of the development was to create tools that increase the ease of use of SMW features and advertise the immediate benefits of semantically enriched content. Halo and related extensions are both available as stand alone packages and as a pre-packaged bundle (called SMW+), which can be deployed immediately.
[http://semanticweb.org/wiki/Halo_Extension]
===
Halo extension: Boost the usability of your Semantic MediaWiki installation.
The Halo extension provides an elaborate toolbox to let you gain immediate benefits of semantically enriched (that is annotated) content. It not only improves the usability of standard SMW features remarkably, but also (and first of all) provides exclusive features like the Ontology browser or the Semantic Toolbar.
The intuitive graphical user interfaces of the Halo extension substantially facilitate the authoring, retrieval, navigation and organization of semantic data.
[http://smwforum.ontoprise.com/smwforum/index.php/Halo_extension]
_Human:
* Thomas Schweitzer
* http://www.smwplus.com/index.php/User:Thomas,
* email: schweitzer@ontoprise.de,
name::
* McsEngl.mw'extension.Hook@cptIt,
Hooks: A technique for injecting custom php code at key points within MediaWiki processing. They are widely used by MediaWiki's parser, its localization engine, its extension management system, and its page maintenance system.
[http://www.mediawiki.org/wiki/Manual:Developing_extensions#Extension_types]
name::
* McsEngl.mw'extension.InsertText@cptIt,
_SPECIFIC:
* https://www.mediawiki.org/wiki/Extension:CharInsert,
name::
* McsEngl.mw'extension.Installed@cptIt,
Checking installed extensions
Only someone with administration access to the filesystem on a server can install extensions for MediaWiki, but anyone can check which extensions are active on an instance of MediaWiki by accessing the Special:Version article. For example, these extensions are active in the English Wikipedia.
[http://www.mediawiki.org/wiki/Extensions]
name::
* McsEngl.mw'extension.JavaScript@cptIt,
_SPECIFIC:
* http://www.mediawiki.org/wiki/Extension:HeadScripts, Provides adding scripts to the site's HEAD.
name::
* McsEngl.mw'extension.Language@cptIt,
_DESCRIPTION:
* User-interface language related.
_SPECIFIC:
* http://www.mediawiki.org/wiki/Extension:Polyglot
* http://www.mediawiki.org/wiki/Extension:LanguageSelector
name::
* McsEngl.mw'extension.Lingo@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Extension:Lingo,
_Configuration:
Lingo.php: $wgexLingoPage = "Abbreviation";
===> set the page with the abbreviations.
_Terminology (page format):
;FTP:File Transport Protocol
;AAAAA:American Association Against Acronym Abuse
;ACK:Acknowledge
;AFAIK:As Far As I Know
;AWGTHTGTATA:Are We Going To Have To Go Through All This Again
;HTTP:HyperText Transfer Protocol
name::
* McsEngl.mw'extension.Magic-word@cptIt,
Magic words: A technique for mapping a variety of wiki text string to a single id that is associated with a function. Both variables and parser functions use this technique. All text mapped to that id will be replaced with the return value of the function. The mapping between the text strings and the id is stored in an array passed to each function attached to the LanguageGetMagic hook. The interpretation of the id is a somewhat complex process - see Manual:Magic words for more information.
Variables - Variables are something of a misnomer. They are bits of wikitext that look like templates but have no parameters and have been assigned hard-coded values. Standard wiki markup such as {{PAGENAME}} or {{SITENAME}} are examples of variables. They get their name from the source of their value: a php variable or something that could be assigned to a variable, e.g. a string, a number, an expression, or a function return value.
Parser functions - {{functionname: argument 1 | argument 2 | argument 3...}}. Similar to tag extensions, parser functions process arguments and returns a value. Unlike tag extensions, the result of parser functions is wikitext.
[http://www.mediawiki.org/wiki/Manual:Developing_extensions#Extension_types]
name::
* McsEngl.mw'extension.MakeArticle@cptIt,
_GENERIC:
* create-page--extension#ql:mw'extension.creating_page#,
* tag-extension#ql:mw'extension.tag#
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Extension:MakeArticle,
* \public_html\mw19\phase3\extensions\makearticle,
_Usage:
On a page set the wikitext: <makearticle> Template:Concept </makearticle>
name::
* McsEngl.mw'extension.Map@cptIt,
_SPECIFIC:
* http://www.mediawiki.org/wiki/Extension:Google_Maps,
name::
* McsEngl.mw'extension.MassEditRegex@cptIt,
This extension allows administrators to perform a single edit across multiple pages in one step, by running a regular expression over the content of each page. This is well suited to performing simple edits such as renaming a template, adding pages to a category, or correcting typos (all of which can be done in the same edit operation by supplying multiple regular expressions.)
[http://www.mediawiki.org/wiki/Extension:MassEditRegex]
name::
* McsEngl.mw'extension.Math@cptIt,
* McsEngl.mw'math-extension@cptIt,
_SPECIFIC:
* http://www.mediawiki.org/wiki/Category:Math_extensions,
* http://www.mediawiki.org/wiki/Extension:MathStatFunctions,
* http://www.mediawiki.org/wiki/Extension:Math,
Im working on the LaTeXML feature, that simplifies the rendering by using MathML.
name::
* McsEngl.mw'extension.MathJax@cptIt,
* McsEngl.mw'MathJax@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Extension:MathJax#ql:http://www.mediawiki.org/wiki/Extension:MathJax#
_Installation:
1) Install https://github.com/mathjax/MathJax/ in "public_html"
2) Install MathJax in wiki/extensions
require_once("$IP/extensions/MathJax/MathJax.php");
$wgMathJaxJS = array("/mathjax/MathJax.js" => "$IP/extensions/MathJax/mwMathJaxConfig.js");
3) on "MathJax.php"
Parser::extractTagsAndParams(
===> $parser->extractTagsAndParams(
name::
* McsEngl.mw'extension.Menu@cptIt,
* http://www.mediawiki.org/wiki/Extension:SideBarMenu,
This extension allows the creation of multilevel menus through the tag <sidebarmenu>.
name::
* McsEngl.mw'extension.Namespace@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Category:Namespace_extensions,
mw'HideNamespace_extension (mw'extension.HideNamespace):
* http://www.mediawiki.org/wiki/Extension:HideNamespace,
mw'HNP_extension (mw'extension.HNP):
* http://www.mediawiki.org/wiki/Extension:HNP,
- Provides an hierarchical namespace permissions system (aka "prefixes") to Mediawiki without changes to the base installation nor creation of new database tables.
* http://www.mediawiki.org/wiki/Extension:Hierarchical_Namespace_Permissions,
mw'NamespaceManager_extension:
* http://www.mediawiki.org/wiki/Extension:NamespaceManager,
mw'NamespacePermissions_extension (mw'extension.NamespacePermissions):
* http://www.mediawiki.org/wiki/Extension:NamespacePermissions,
mw'NamespaceProtection_extension (<1.10):
* http://www.mediawiki.org/wiki/Extension:NamespaceProtection,
name::
* McsEngl.mw'extension.Page-creation@cptIt,
_SPECIFIC:
* http://www.mediawiki.org/wiki/Category:Page_creation_extensions,
name::
* McsEngl.mw'extension.Parser@cptIt,
_DESCRIPTION:
Parser extensions change or enhance the way MediaWiki interprets Wiki markup. At a high level they can be grouped into three categories:
adding standard token types: The standard approach to customized MediaWiki markup is to add new markup that looks like the built-in MediaWiki XML tags (<tag>), template ({{...}}), or link markup ([[...]]). For examples, please see
Category:Parser function extensions
Category:Tag extensions
Category:Variable extensions
adding custom token types: Some extensions define new token types. For example, Extension:ParserPhase2, adds several token types: ((%...%)), ((@...@)), and (($...$)). For examples, please see Category:Extended syntax extensions.
fundamental changes to the parser: A few extensions attempt fundamentally change the parsing strategy so that markup from other sorts of wikis and content management can be used (must be used?) instead of the standard wiki markup. Like token changes, one must implement these extensions by adding functions to the parser and page output hooks. For examples, please see Category:Extended syntax extensions.
[https://www.mediawiki.org/wiki/Category:Parser_extensions]
_SPECIFIC:
* parserFunctions,
* wikiScripts,
* winter#ql:mw'extension.winter#
name::
* McsEngl.mw'extension.ParserFunction@cptIt,
_SPECIFIC:
* http://www.mediawiki.org/wiki/Extension:ParserFunctions,
name::
* McsEngl.mw'extension.ParserFunctions@cptIt,
_DESCRIPTION:
Add functionality to pages, through wikiText#ql:mw'wikitext#.
[hmnSngo.2011-10-25]
===
ParserFunctions extension enhances parser with logical functions. New versions (r50997+) also incorporate most (but not all) features of StringFunctions, which can be enabled or disabled (see install instructions below).
[http://www.mediawiki.org/wiki/Extension:ParserFunctions]
===
The ParserFunctions extension provides eleven additional parser functions to supplement the "magic words", which are already present in MediaWiki. All the parser functions provided by this extension take the form:
{{#functionname: argument 1 | argument 2 | argument 3 ... }}
[http://www.mediawiki.org/wiki/Help:Extension:ParserFunctions]
name::
* McsEngl.mw'extension.Replace-text@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Extension:Replace_Text,
name::
* McsEngl.mw'extension.Scribunto@cptIt,
* McsEngl.scribunto@cptIt580i, {2012-06-03}
Scribunto (Latin: "they shall write") is an extension for embedding scripting languages in MediaWiki. Currently the only supported scripting language is Lua.
The extension is incomplete. None of the interfaces are fixed at this time.
Scripts are contained within a new namespace called "Module". Each module has a collection of functions, and the functions can be called using wikitext syntax like:
{{#invoke: Module_name | function_name | arg1 | arg2 | arg3 ... }}
[https://www.mediawiki.org/wiki/Extension:Scribunto]
name::
* McsEngl.mw'extension.Scripting@cptIt,
* McsEngl.mw'extension.scripts@cptIt,
_SPECIFIC:
* http://www.mediawiki.org/wiki/Extension:Lua,
* http://www.mediawiki.org/wiki/Extension:ParserFunctions,
* https://www.mediawiki.org/wiki/Extension:Scribunto,
* http://www.mediawiki.org/wiki/Extension:WikiScripts,
* http://www.mediawiki.org/wiki/Extension:Winter,
* http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Scripting//
name::
* McsEngl.mw'extension.Search@cptIt,
_SPECIFIC:
* InputBox, http://www.mediawiki.org/wiki/Extension:InputBox,
* SearchBox, http://www.mediawiki.org/wiki/Extension:SearchBox, T.Ppascal,
* Sphinx, http://www.mediawiki.org/wiki/Extension:SphinxSearch,
* TitleKey#ql:mw'extension.titlekey#
name::
* McsEngl.mw'extension.Semantic-Forms@cptIt,
_GENERIC:
* smw-extension#ql:smw'extension#
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Extension:Semantic_Forms,
name::
* McsEngl.mw'extension.Semantic-glossary@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Extension:Semantic_Glossary,
name::
* McsEngl.mw'extension.Semantic-mediawiki (SMW)@cptIt,
* McsEngl.conceptIt580.7,
* McsEngl.mw'smw@cptIt,
* McsEngl.smw@cptIt580.7,
_DESCRIPTION:
Semantic MediaWiki (SMW) is a free, open-source extension to MediaWiki – the wiki software that powers Wikipedia – that lets you store and query data within the wiki's pages.
Semantic MediaWiki is also a full-fledged framework, in conjunction with many spinoff extensions, that can turn a wiki into a powerful and flexible “collaborative database”. All data created within SMW can easily be published via the Semantic Web, allowing other systems to use this data seamlessly.
[http://semantic-mediawiki.org//]
name::
* McsEngl.smw'Administering@cptIt,
_GENERIC:
* using-smw#ql:smw'using#
_ADDRESS.WPG:
* http://semantic-mediawiki.org/wiki/Help:Installation,
name::
* McsEngl.smw'Configuring@cptIt,
$smwgPDefaultType Default property type. Undefined properties (those without pages or whose pages have no "has type" statement) will be assumed to be of this type. This is an internal type id. See the file languages/SMW_LanguageXX.php to find what IDs to use for datatpyes in your language. The default corresponds to "Type:Page".
Default: '_wpg' (corresponds to datatype Page)
[http://semantic-mediawiki.org/wiki/Help:Configuration#smwgPDefaultType]
name::
* McsEngl.smw'Application@cptIt,
name::
* McsEngl.smw'Concept@cptIt,
It is possible to store queries in Semantic MediaWiki on dedicated pages, called concepts. These pages can be viewed as "dynamic categories", i.e. as collections of pages that are not created manually, but that are computed by SMW from the description given by a query. An example could be the concept of European cities. In traditional MediaWiki installations, one may have a category called European cities that holds all such cities. In SMW, one would instead define the concept "European cities" by saying that it contains all cities that are located in Europe. No city page needs to be changed, and yet one can create many concepts about cities (such as "capital", "Italian city", or "large coastal city located at a river").
[http://semantic-mediawiki.org/wiki/Help:Concepts]
name::
* McsEngl.smw'Data@cptIt,
* McsEngl.smw'data-application@cptIt,
* McsEngl.smw'data-code@cptIt,
* McsEngl.smw'code.data@cptIt,
_SPECIFIC:
* Annotation,
* EndUser-data,
* mw-data#ql:mw'data#,
* programer-data,
* Property-wikitext,
name::
* McsEngl.smw'data.Annotation@cptIt,
* McsEngl.smw'annotation@cptIt,
* McsEngl.smw'Semantic-fact@cptIt,
* McsEngl.smw'fact@cptIt,
_PART:
* object#ql:smw'object#,
* property#ql:smw'property#,
* value,
_DESCRIPTION:
* Since categories and properties merely emphasize a particular part of an article's content, they are often called (semantic) annotations.
[http://semantic-mediawiki.org/wiki/Help:Editing]
===
A semantic fact is completely specified by its object, property, and value. For instance, it does not matter who specified a fact (in contrast to tagging systems where each user can have individual tags for the same thing).
Facts are either given or not given, but they cannot be given more than once (again in contrast to tagging systems where we count how often a tag has been given to a resource).
[http://semantic-mediawiki.org/wiki/Architecture_guide]
name::
* McsEngl.smw'data.Category@cptIt,
* McsEngl.smw'category@cptIt,
Annotations in Semantic MediaWiki can be viewed as an extension of the existing system of categories in MediaWiki. Categories are a means to classify articles according to certain criteria. For example, by adding [[Category:Cities]] to an article, the page is tagged as describing a city. MediaWiki can use this information to generate a list of all cities in a wiki, and thus help users to browse the information.
[http://semantic-mediawiki.org/wiki/Help:Editing]
_Article:
Every category has its own article, which can be linked to by writing [[:Category:Example category]]. The category's article can be empty, but it is strongly recommended to add a description that explains which articles should go into the category.
[http://semantic-mediawiki.org/wiki/Help:Editing]
name::
* McsEngl.smw'data.Page@cptIt,
* McsEngl.smw'Article-page@cptIt,
* McsEngl.smw'object@cptIt,
* McsEngl.smw'page.article@cptIt,
* McsEngl.smw'subject@cptIt,
_DESCRIPTION:
Data in SMW is represented by property-value pairs that are assigned to objects.
For example:
Dresden (object) has a population (property) of 517,052 (value).
...
"Object" is a very general term, so we often use "subject" when we want to emphasize that a thing is the subject of a property-value assignment in a fact.
[http://semantic-mediawiki.org/wiki/Architecture_guide]
name::
* McsEngl.smw'data.Programer@cptIt,
_SPECIFIC:
* class-SMWSemanticData,
* class-SMWDataItem#ql:smwdataitem_class#,
* class-SMWDIProperty,
* class-SMWDataValue#ql:smwdatavalue_class#,
===
* \includes\SMW_DataValueFactory.php,
* http://semantic-mediawiki.org/doc/classSMWDataItem.html,
===
static private $mDefaultDataItemTypeIds = array(
SMWDataItem::TYPE_BLOB => '_txt', // Text type
SMWDataItem::TYPE_STRING => '_str', // String type
SMWDataItem::TYPE_URI => '_uri', // URL/URI type
SMWDataItem::TYPE_WIKIPAGE => '_wpg', // Page type
SMWDataItem::TYPE_NUMBER => '_num', // Number type
SMWDataItem::TYPE_TIME => '_dat', // Time type
SMWDataItem::TYPE_BOOLEAN => '_boo', // Boolean type
SMWDataItem::TYPE_CONTAINER => '_rec', // Value list type (replacing former nary properties)
SMWDataItem::TYPE_GEO => '_geo', // Geographical coordinates
SMWDataItem::TYPE_CONCEPT => '__con', // Special concept page type
SMWDataItem::TYPE_PROPERTY => '__pro', // Property type
// If either of the following two occurs, we want to see a PHP error:
//SMWDataItem::TYPE_NOTYPE => '',
//SMWDataItem::TYPE_ERROR => '',
);
[\includes\SMW_DataValueFactory.php]
name::
* McsEngl.smw'class.SMWSemanticData@cptIt,
* McsEngl.SMWSemanticData-class@cptIt,
* McsEngl.smw'SMWSemanticData-class@cptIt,
_DESCRIPTION:
Class for representing chunks of semantic data for one given article (subject), similar what is typically displayed in the Factbox.
This is a light-weight data container.
By its very design, the container is unable to hold inverse properties. For one thing, it would not be possible to identify them with mere keys. Since SMW cannot annotate pages with inverses, this is not a limitation.
[http://semantic-mediawiki.org/doc/classSMWSemanticData.html]
_ADDRESS.WPG:
* http://semantic-mediawiki.org/doc/classSMWSemanticData.html,
name::
* McsEngl.smw'class.SMWDataItem@cptIt,
* McsEngl.SMWDataItem-class@cptIt,
* McsEngl.smw'SMWDataItem@cptIt,
_DESCRIPTION:
Objects of this type represent all that is known about a certain piece of data that could act as the value of some property.
Data items only represent the stored data, and are thus at the core of SMW's data model. Data items are always immutable, i.e. they must not be changed after creation (and this is mostly enforced by the API with some minor exceptions).
The set of available data items is fixed and cannot be extended. These are the kinds of information that SMW can process. Their concrete use and handling might depend on the context in which they are used. In particular, property values may be influences by settings made for their property. This aspect, however, is not part of the data item API.
[http://semantic-mediawiki.org/doc/classSMWDataItem.html#_details]
_File:
Definition at line 44 of file SMW_DataItem.php.
_SPECIFIC:
Inherited by SMWDIBlob, SMWDIBoolean, SMWDIConcept, SMWDIContainer, SMWDIError, SMWDIGeoCoord, SMWDINumber, SMWDIProperty, http://semantic-mediawiki.org/doc/classSMWDITime.html, SMWDIUri, and http://semantic-mediawiki.org/doc/classSMWDIWikiPage.html.
[http://semantic-mediawiki.org/doc/classSMWDataItem.html]
===
/// Data item ID that can be used to indicate that no data item class is appropriate
const TYPE_NOTYPE = 0;
/// Data item ID for SMWDINumber
const TYPE_NUMBER = 1;
/// Data item ID for SMWDIString
const TYPE_STRING = 2;
/// Data item ID for SMWDIBlob
const TYPE_BLOB = 3;
/// Data item ID for SMWDIBoolean
const TYPE_BOOLEAN = 4;
/// Data item ID for SMWDIUri
const TYPE_URI = 5;
/// Data item ID for SMWDITimePoint
const TYPE_TIME = 6;
/// Data item ID for SMWDIGeoCoord
const TYPE_GEO = 7;
/// Data item ID for SMWDIContainer
const TYPE_CONTAINER = 8;
/// Data item ID for SMWDIWikiPage
const TYPE_WIKIPAGE = 9;
/// Data item ID for SMWDIConcept
const TYPE_CONCEPT = 10;
/// Data item ID for SMWDIProperty
const TYPE_PROPERTY = 11;
/// Data item ID for SMWDIError
const TYPE_ERROR = 12;
name::
* McsEngl.smw'class.SMWDIContainer@cptIt,
* McsEngl.SMWDIContainer-class@cptIt,
* McsEngl.smw'SMWDIContainer-class@cptIt,
_GENERIC:
* SMWDataItem-class#ql:smw'class.smwdataitem#
_ADDRESS.WPG:
* http://semantic-mediawiki.org/doc/classSMWDIContainer.html,
name::
* McsEngl.smw'class.SMWDIProperty@cptIt,
* McsEngl.SMWDIProperty-class@cptIt,
* McsEngl.smw'SMWDIProperty-class@cptIt,
_WHOLE:
* smw-property#ql:smw'property#
_GENERIC:
* SMWDataItem-class#ql:smw'class.smwdataitem#
This class implements Property data items.
The static part of this class also manages global registrations of predefined (built-in) properties, and maintains an association of property IDs, localized labels, and aliases.
[http://semantic-mediawiki.org/doc/classSMWDIProperty.html]
name::
* McsEngl.smw'class.SMWDIWikiPage@cptIt,
* McsEngl.SMWDIWikiPage-class@cptIt,
* McsEngl.smw'SMWDIWikiPage-class@cptIt,
name::
* McsEngl.smw'class.SMWDataValue@cptIt,
* McsEngl.SMWDataValue-class@cptIt,
* McsEngl.smw'SMWDataValue@cptIt,
_DESCRIPTION:
It might be surprising that not only values but also subjects and properties are represented by the SMWDataValue class.
[http://semantic-mediawiki.org/wiki/Architecture_guide]
===
Objects of this type represent all that is known about a certain user-provided data value, especially its various representations as strings, tooltips, numbers, etc.
Objects can be created as "emtpy" containers of a certain type, but are then usually filled with data to present one particular data value.
Data values have two chief representation forms: the user-facing syntax and the internal representation. In user syntax, every value is (necessarily) a single string, however complex the value is. For example, a string such as "Help:editing" may represent a wiki page called "Editing" in the namespace for "Help". The internal representation may be any numerical array of strings and numbers. In the example, it might be array("Editing",12), where 12 is the number used for identifying the namespace "Help:". Of course, the internal representation could also use a single string value, such as in array("Help:Editing"), but this might be less useful for certain operations (e.g. filterng by namespace). Moreover, all values that are restored from the database are given in the internal format, so it wise to choose a format that allows for very fast and easy processing without unnecessary parsing.
The main functions of data value objects are:
- setUserValue() which triggers parseUserValue() to process a user-level string.
- getDBkeys() which provides an array that represents the current value for internal processing
- setDBkeys() which triggers parseDBkeys() to process an array with the internal representation
In addition, there are a number of get-functions that provide useful output versions for displaying and serializing the value.
[http://semantic-mediawiki.org/doc/classSMWDataValue.html#_details]
_File:
Definition at line 49 of file SMW_DataValue.php.
_SPECIFIC:
Inherited by SMGeoCoordsValue, SMWBoolValue, SMWConceptValue, SMWErrorValue, SMWImportValue, SMWNumberValue, SMWPropertyListValue, SMWPropertyValue, http://semantic-mediawiki.org/doc/classSMWRecordValue.html, SMWStringValue, SMWTimeValue, SMWTypesValue, SMWURIValue, and SMWWikiPageValue.
[http://semantic-mediawiki.org/doc/classSMWDataValue.html]
name::
* McsEngl.smw'data.Value@cptIt,
* McsEngl.smw'Value@cptIt,
_DESCRIPTION:
Values can be of different types (numbers, dates, other wiki pages, ...).
The datatype is part of the value's identity (values of different types are different, even if they are based on the same user input).
Objects can have zero, one, or many values for any property.
[http://semantic-mediawiki.org/wiki/Architecture_guide]
_Code.smw:
* class-SMWDataItem#ql:smw'class.smwdataitem#,
* class-SMWDataValue#ql:smw'class.smwdatavalue#
name::
* McsEngl.smw'EndUser-code@cptIt,
_WHOLE:
* smw-app#ql:smw'application#
_SPECIFIC:
* data--user-code (code),
* mixed,
* processing--user-code,
* smw'content,
* smw'User_code,
* wikitext,
name::
* McsEngl.smw'Evolution@cptIt,
_ADDRESS.WPG:
* http://semantic-mediawiki.org/wiki/Help:SMW_History,
smw'1.7:
* 1.7.0: 2012-01-01
- Jan 1 2012. Semantic MediaWiki 1.7.0, the next major version after 1.6.1, has now been released. This new version brings a significant number of internal changes and fixes. Notable additions are native subobjects, an Ask API and an alpha version of Special:QueryCreator. Upgrading from earlier versions of SMW is easy but needs some additional steps in certain cases, see Installation 1.7.0 for details. Further information can be found on the SMW 1.7.0 page.
[http://www.semantic-mediawiki.org/wiki/Semantic_MediaWiki_1.7.0_released]
- http://www.semantic-mediawiki.org/wiki/Semantic_MediaWiki_1.7.0,
smw'1.5
1.5.6:
Up to SMW 1.5.6, datatypes had individual wiki pages in their own namespace called "Type". This was abolished to reduce the number of extra namespaces. You may still find expressions like "Type:Number" in places in this wiki. Both writings are accepted for assigning a datatype to a property.
[http://semantic-mediawiki.org/wiki/Help:Properties_and_types#Special_properties]
{time.2005}:
Semantic MediaWiki was initially created by Markus Krφtzsch, Denny Vrandecic and Max Vφlkel, and was first released in 2005. Its development was initially funded by the EU-funded FP6 project SEKT, and was later supported in part by Institute AIFB of the University of Karlsruhe (later renamed the Karlsruhe Institute of Technology). Krφtzsch remains the lead developer as of 2011, while other core developers are Jeroen De Dauw and Yaron Koren.[1]
[http://en.wikipedia.org/wiki/Semantic_MediaWiki]
name::
* McsEngl.smw'Extension@cptIt,
_ADDRESS.WPG:
* http://semantic-mediawiki.org/wiki/Help:SMW_extensions,
* http://www.mediawiki.org/wiki/Extension:Semantic_Forms,
Spinoff extensions
A form to edit a page, using the Semantic Forms extension
A variety of open-source MediaWiki extensions exist that use the data structure provided by Semantic MediaWiki.[23] Among the most notable are:
* Semantic Forms - enables user-created forms for adding and editing pages that use semantic data
* Halo#ql:mw'extension.halo# - facilitates creation, retrieval, navigation and organization of semantic data via graphical and intuitive interfaces
* Semantic Drilldown - provides a faceted browser interface for viewing the semantic data in a wiki
* Semantic Compound Queries - provides a parser function for displaying multiple queries at the same time, such as within a calendar or a map
* Semantic Result Formats - provides a large number of display formats for semantic data, including charts, graphs, calendars and mathematical functions
* Semantic Maps - displays geographic semantic data using various mapping services
* Semantic Internal Objects - provides a parser function that allows for flexible storage of so-called "n-ary relations" within pages
[http://en.wikipedia.org/wiki/Semantic_MediaWiki]
name::
* McsEngl.smw'Funding@cptIt,
Semantic MediaWiki has been funded in part by projects of the Framework Programmes (FP) of the European Union, SEKT and ACTIVE and by project Halo.
[http://semantic-mediawiki.org/wiki/Help:Introduction_to_Semantic_MediaWiki]
_PART:
* ACTIVE: (2008-2011) http://active-project.eu//
* Halo-project#ql:halo_project-356i#
name::
* McsEngl.smw'Human@cptIt,
The SMW project was founded by Markus Krφtzsch and Denny Vrandecic during their work at the Institute AIFB at Karlsruhe Institute of Technology (KIT). Further core project members today include Jeroen De Dauw and Yaron Koren.
The principal contact for Semantic MediaWiki is Markus Krφtzsch.
[http://semantic-mediawiki.org/wiki/Help:SMW_Project]
_SPECIFIC:
* developer,
* user,
smw'Krotzsch_Markus:
* The principal contact for Semantic MediaWiki.
- http://semantic-mediawiki.org/wiki/Markus_Kr%C3%B6tzsch,
- Contact him at markus@semantic-mediawiki.org.
smw'Vrandecic_Denny:
* http://semantic-mediawiki.org/wiki/Denny_Vrandecic,
name::
* McsEngl.smw'Koren-Yaron@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/User:Yaron_Koren,
_site:
* http://yaronkoren.com//
* http://wikiworks.com//
* http://www.referata.com/wiki/Main_Page,
name::
* McsEngl.smw'Page@cptIt,
_SPECIFIC:
* Article-page,
* Concept-page#ql:smw'concept#,
* data-page#ql:smw'data.page#,
* processing-page,
* Property-page,
* special-page,
name::
* McsEngl.smw'Page.Special@cptIt,
* McsEngl.smw'special-page@cptIt,
smw'special.Ask:
- Special:Ask:
smw'special.Browse
- Special:Browse/Economy
smw'special.QueryCreator
Added alpha version of a new ask query interface: Special:QueryCreator. This was created by Devayon Das as part of Google Summer of Code 2011.
name::
* McsEngl.smw'Processing-code@cptIt,
_SPECIFIC:
* user-processing-code,
* programmer-processing-code,
name::
* McsEngl.smw'Programer-code@cptIt,
* McsEngl.smw'code@cptIt,
* McsEngl.smw'code.program@cptIt,
* McsEngl.smw'Developing@cptIt,
_ADDRESS.WPG:
* code-doc: http://semantic-mediawiki.org/doc//
* http://semantic-mediawiki.org/wiki/Programmer%27s_guide_to_SMW,
* http://semantic-mediawiki.org/wiki/Architecture_guide,
name::
* McsEngl.smw'API@cptIt,
_API_Ask:
Note: The Ask API is still in alpha, and might see syntax and output changes in the future.
The Ask API allows you to do ask queries against SMW using the MediaWiki API and get results back serialized in one of the formats it supports. There are 2 API modules that differ in how you specify the query, but have identical output of the query results.
[edit] Ask
The ask module supports one parameter, query, which takes the same string you'd feed into an#ask tag, but urlencoded.
Example: api.php?action=ask&query=[[Modification date::%2B]]|%3FModification date|sort%3DModification date|order%3Ddesc&format=jsonfm
[http://www.semantic-mediawiki.org/wiki/Ask_API]
name::
* McsEngl.smw'Class@cptIt,
_ADDRESS.WPG:
* list: http://semantic-mediawiki.org/doc/annotated.html,
* hierarchy: http://semantic-mediawiki.org/doc/hierarchy.html,
* member: http://semantic-mediawiki.org/doc/functions.html,
name::
* McsEngl.smw'class.SMWStore@cptIt,
* McsEngl.smw'SMWStore-class@cptIt,
_DESCRIPTION:
The abstract base class for all classes that implement access to some semantic store.
Besides the relevant interface, this class provides default implementations for some optional methods, which inform the caller that these methods are not implemented.
[http://semantic-mediawiki.org/doc/classSMWStore.html]
name::
* McsEngl.smw'Database@cptIt,
Semantic MediaWiki stores its data via about 10 additional tables within the database that MediaWiki uses (which is usually a MySQL database). SMW can additionally store its data within an RDF triplestore, such as 4store and Virtuoso, although even in such cases the standard database is also used. See Help:Using SPARQL and RDF stores for more information on triplestore storage.
[http://semantic-mediawiki.org/wiki/FAQ]
===
Selected storage engine is "SMWSQLStore2" (or an extension thereof)
Checking table `smw_ids` ...
Checking table `smw_conccache` ...
Checking table `smw_rels2` ...
Checking table `smw_atts2` ...
Checking table `smw_text2` ...
Checking table `smw_spec2` ...
Checking table `smw_subs2` ...
Checking table `smw_subp2` ...
Checking table `smw_inst2` ...
Checking table `smw_redi2` ...
Checking table `smw_conc2` ...
Checking table `sm_coords`
name::
* McsEngl.smw'database'table@cptIt,
Selected storage engine is "SMWSQLStore2" (or an extension thereof)
Checking table `smw_ids` ...
Table already exists, checking structure ...
... field smw_id is fine.
... field smw_namespace is fine.
... field smw_title is fine.
... field smw_iw is fine.
... field smw_subobject is fine.
... field smw_sortkey is fine.
... done.
Checking table `smw_conccache` ...
Table already exists, checking structure ...
... field s_id is fine.
... field o_id is fine.
... done.
Checking table `smw_rels2` ...
Table already exists, checking structure ...
... field s_id is fine.
... field p_id is fine.
... field o_id is fine.
... done.
Checking table `smw_atts2` ...
Table already exists, checking structure ...
... field s_id is fine.
... field p_id is fine.
... field value_xsd is fine.
... field value_num is fine.
... done.
Checking table `smw_text2` ...
Table already exists, checking structure ...
... field s_id is fine.
... field p_id is fine.
... field value_blob is fine.
... done.
Checking table `smw_spec2` ...
Table already exists, checking structure ...
... field s_id is fine.
... field p_id is fine.
... field value_string is fine.
... done.
Checking table `smw_subs2` ...
Table already exists, checking structure ...
... field s_id is fine.
... field o_id is fine.
... done.
Checking table `smw_subp2` ...
Table already exists, checking structure ...
... field s_id is fine.
... field o_id is fine.
... done.
Checking table `smw_inst2` ...
Table already exists, checking structure ...
... field s_id is fine.
... field o_id is fine.
... done.
Checking table `smw_redi2` ...
Table already exists, checking structure ...
... field s_title is fine.
... field s_namespace is fine.
... field o_id is fine.
... done.
Checking table `smw_conc2` ...
Table already exists, checking structure ...
... field s_id is fine.
... field concept_txt is fine.
... field concept_docu is fine.
... field concept_features is fine.
... field concept_size is fine.
... field concept_depth is fine.
... field cache_date is fine.
... field cache_count is fine.
... done.
Checking table `sm_coords` ...
Table already exists, checking structure ...
... field s_id is fine.
... field p_id is fine.
... field lat is fine.
... field lon is fine.
... done.
[upgrade to 1.7]
===========================================================
smw'table.smw_ids:
* field smw_id:
* field smw_namespace:
* field smw_title:
* field smw_iw:
* field smw_subobject:
* field smw_sortkey:
===
{
"smw_id": 106,
"smw_namespace": 14,
"smw_title": "Europe",
"smw_iw": "",
"smw_subobject": "",
"smw_sortkey": "Europe"}
{
"smw_id": 96,
"smw_namespace": 102,
"smw_title": "Property-author",
"smw_iw": "",
"smw_subobject": "",
"smw_sortkey": "Property-author"},
{
"smw_id": 93,
"smw_namespace": 106,
"smw_title": "Form-author",
"smw_iw": "",
"smw_subobject": "",
"smw_sortkey": "Form-author"},
smw'table.smw_conccache:
* field s_id:
* field o_id:
smw'table.smw_rels2:
* field s_id:
* field p_id:
* field o_id:
===
{
"s_id": 99, [Book:_Greek_Grammar]
"p_id": 85, [Relation-author]
"o_id": 97}, [Kaseluris-Nikos]
{
"s_id": 100, [Book:_Language_Ko]
"p_id": 85,
"o_id": 97},
{
"s_id": 101, [Book:_Warfare_1944]
"p_id": 85,
"o_id": 98}
smw'table.smw_atts2:
* field s_id:
* field p_id:
* field value_xsd:
* field value_num:
===
{
"s_id": 101, [Book:_Warfare_1944]
"p_id": 87, [Relation-year-of-publication]
"value_xsd": 1977,
"value_num": 1977},
{
"s_id": 102, [Paris]
"p_id": 29, [_MDAT (modified)]
"value_xsd": "2012/1/19T18:15:18",
"value_num": 2455946.260625},
{
"s_id": 99, [book: GrGr]
"p_id": 86, [Relation-genre]
"value_xsd": "Science",
"value_num": 0},
smw'table.smw_text2:
* field s_id:
* field p_id:
* field value_blob:
===
{
"s_id": 53, [0 Economy]
"p_id": 72, [102 Definition]
"value_blob": "Economy is the system of a society responsible for satisfying needs."
}
smw'table.smw_spec2:
* field s_id:
* field p_id:
* field value_string:
===
{
"s_id": 95, [14 Category-author]
"p_id": 20, [102 _SF_DF]
"value_string": "Form-author"},
{
"s_id": 86, [102 Relation-genre]
"p_id": 14, [102 _PVAL]
"value_string": "Science"},
{
"s_id": 86,
"p_id": 14,
"value_string": "Art"},
{
"s_id": 86,
"p_id": 1, [102 _TYPE]
"value_string": "http://semantic-mediawiki.org/swivt/1.0#_str"},
{
"s_id": 75, [102 Term]
"p_id": 28, [102 _LIST]
"value_string": "Term English;Term Greek"},
smw'table.smw_subs2:
* field s_id:
* field o_id:
===
{
"s_id": 57, [14 EU]
"o_id": 55}, [14 Society]
{
"s_id": 55, [14 Society]
"o_id": 80} [14 Entity]
===
Stores the categories of categories.
[hmnSngo.2012-02-08]
smw'table.smw_subp2:
* field s_id:
* field o_id:
smw'table.smw_inst2:
* field s_id:
* field o_id:
==
{
"s_id": 97, [Kaseluris-Nikos]
"o_id": 95}, [Category-author]
{
"s_id": 53, [Economy]
"o_id": 80}, [14 Entity]
{
"s_id": 56, [Greece]
"o_id": 106} [14 Europe]
===
Contains the "category" of a page.
[hmnSngo.2012-02-08]
smw'table.smw_redi2:
* field s_title:
* field s_namespace:
* field o_id:
===
{
"s_title": "Giannena",
"s_namespace": 0,
"o_id": 65}, [Joannina]
{
"s_title": "Home",
"s_namespace": 0,
"o_id": 51}, [Main_Page]
===
Contains the "synonyms" of a page.
[hmnSngo.2012-02-08]
smw'table.smw_conc2:
* field s_id:
* field concept_txt:
* field concept_docu:
* field concept_features:
* field concept_size:
* field concept_depth:
* field cache_date:
* field cache_count:
smw'table.sm_coords:
* field s_id:
* field p_id:
* field lat:
* field lon:
name::
* McsEngl.smw'Doc-of-code@cptIt,
_doxygen:
* @author Jeroen De Dauw
* @defgroup SMW Semantic MediaWiki
* @defgroup SMWDataValues SMWDataValues
* @deprecated This method will vanish before SMW 1.7.
* @file
* @file SMW_SQLHelpers.php
* @ingroup SMWStore
* @note
* @param array $columns The fields and their types the table should have.
* @return mixed Title or null
* @see SMWDataValue::loadDataItem()
* @since 1.6
* @todo From MW 1.17 on, makeTitleSafe supports
* @var string
===
unordered-list:
- list item
- list item
name::
* McsEngl.smw'File@cptIt,
_ADDRESS.WPG:
* http://semantic-mediawiki.org/doc/files.html,
name::
* McsEngl.smw'Function@cptIt,
_ADDRESS.WPG:
* http://semantic-mediawiki.org/doc/globals_func.html,
name::
* McsEngl.smw'Module@cptIt,
* McsEngl.smw'group-of-programer-code@cptIt,
_ADDRESS.WPG:
* http://semantic-mediawiki.org/doc/modules.html,
_SPECIFIC:
Here is a list of all modules:
* Semantic Drilldown
* Semantic Forms
- Form Inputs
- Special Pages
- Language
* Google Maps v3
* Semantic Maps
- OpenLayers
- Yahoo! Maps
* Semantic MediaWiki
- SMWDataItems
- SMWDataValues
- SWMSparql
- SMWQuery
- SMWStore
- SMWLanguage
- SMWMaintenance
- SMWSpecialPage
* SemanticResultFormats
* Language
* SpecialPage
[http://semantic-mediawiki.org/doc/modules.html]
* SMWDataItems
This group contains all parts of SMW that relate to the processing of dataitems of various types.
* SMWDataValues
This group contains all parts of SMW that relate to the processing of datavalues of various types.
* SWMSparql
This group contains all parts of SMW that relate to communication with storage backends and clients via SPARQL.
* SMWQuery
This group contains all parts of SMW that relate to processing semantic queries.
* SMWStore
This group contains all parts of SMW that relate to storing and retrieving semantic data.
* SMWLanguage
This group contains all parts of SMW that relate to localisation and translation.
* SMWMaintenance
This group contains all parts of SMW that are maintenance scripts.
* SMWSpecialPage
This group contains all parts of SMW that are maintenance scripts.
[http://semantic-mediawiki.org/doc/modules.html]
name::
* McsEngl.smw'module.SMWDataValues@cptIt,
This group contains all parts of SMW that relate to the processing of datavalues of various types.
[http://semantic-mediawiki.org/doc/group__SMWDataValues.html]
name::
* McsEngl.smw'module.SMWStore@cptIt,
This group contains all parts of SMW that relate to storing and retrieving semantic data.
SMW components that relate to semantic querying only have their own group.
[http://semantic-mediawiki.org/doc/group__SMWStore.html]
_ADDRESS.WPG:
* http://semantic-mediawiki.org/doc/group__SMWStore.html,
name::
* McsEngl.smw'Testing@cptIt,
_ADDRESS.WPG:
* http://semantic-mediawiki.org/wiki/SMW_System_Testing_with_Selenium,
name::
* McsEngl.smw'Support-developing@cptIt,
_List:
* https://lists.sourceforge.net/lists/listinfo/semediawiki-devel,
name::
* McsEngl.smw'Property@cptIt,
* McsEngl.smw'data.property@cptIt,
_PART:
* property-page,
* property-wikitext,
_ADDRESS.WPG:
* http://semantic-mediawiki.org/wiki/Property,
* http://semantic-mediawiki.org/wiki/Special:Properties, show all properties.
_Code.smw:
* http://www.semantic-mediawiki.org/doc/classSMWDIProperty.html,
* http://www.semantic-mediawiki.org/doc/classSMWPropertyValue.html,
* http://www.semantic-mediawiki.org/doc/classSMWPropertiesPage.html,
* http://www.semantic-mediawiki.org/doc/classSMWPropertyValue.html,
_DESCRIPTION:
The basic building blocks of any semantic site are the connections between data, which in Semantic MediaWiki are known as properties. A property is used to specify a single piece of information about the topic of this page. Every property should be defined on your wiki, with a page in the "Property:" namespace. Create each property by going to the Special:CreateProperty page.
[http://www.mediawiki.org/wiki/Extension:Semantic_Forms/Quick_start_guide]
===
Properties and types are the basic way of entering semantic data in Semantic MediaWiki. Properties can be viewed as «categories for values in wiki pages». They are used by a simple mark-up, similar to the syntax of links in MediaWiki: property name::value,
This statement defines a value for the property of the given property name. The page where this is used will just show the text for value and not the property assignment.
[http://semantic-mediawiki.org/wiki/Property]
===
Every semantic annotation within SMW is a "property" connecting the page on which it resides to some other piece of data, either another page or a data value of some type, using triples of the form "subject, predicate, object".
As an example, a page about Germany could have, encoded within it, the fact its capital city is Berlin. On the page "Germany", the syntax would be:
... the capital city is [[Has capital::Berlin]] ...
which is semantically equivalent to the statement "Germany" "Has capital" "Berlin". In this example the "Germany" page is the subject, "Has capital" is the predicate, and "Berlin" is the object that the semantic link is pointing to.
[http://en.wikipedia.org/wiki/Semantic_MediaWiki]
===
Every semantic annotation within SMW is a "property" connecting the page on which it resides to some other piece of data, either another page or a data value of some type, using triples of the form "subject, predicate, object".
[http://en.wikipedia.org/wiki/Semantic_MediaWiki]
name::
* McsEngl.smw'property'Article@cptIt,
To simplify this re-use, every property has its own article in the wiki, just as every category has an article. You can see all the properties in use in the wiki with the Special:Properties page. Just as category articles are prefixed with Category:, all property articles are prefixed with Property: to distinguish them from other articles. So you can also also use MediaWiki's Special:Search page to find existing properties. As with categories, a property's article can be empty, but it is strongly recommended to add a description that explains the intent of the property and its proper usage.
[http://semantic-mediawiki.org/wiki/Property]
name::
* McsEngl.smw'property'Creating@cptIt,
_Command:
* http://semantic-mediawiki.org/wiki/Special:CreateProperty,
name::
* McsEngl.smw'property'Markup@cptIt,
* McsEngl.smw'property'wikitext@cptIt,
* McsEngl.smw'property'using@cptIt,
'''Berlin''' is the capital of [[capital of::Germany]] and also its largest city;
[http://www.semantic-mediawiki.org/w/index.php?title=Berlin&action=edit]
Silent annotations using#set
Instead of using the standard double-brackets markup, you can also define semantic data using the#set parser function. This function takes in pairs of property names and values and stores them semantically; but it does not print anything to the screen. An example call would be:
{{#set:Has population=3,396,990|Has country=Germany}}
The#set call is specifically helpful when trying to save a String or Text value that contains square brackets, such as wiki-links; such brackets often don't work with conventional SMW markup.
[http://semantic-mediawiki.org/wiki/Help:Properties_and_types#Special_properties]
name::
* McsEngl.smw'property'Name@cptIt,
As in the case of categories, the name of the property is arbitrary, but users should try to re-use properties that already appear elsewhere.
[http://semantic-mediawiki.org/wiki/Property]
name::
* McsEngl.smw'property'Page@cptIt,
* McsEngl.smw'page.property@cptIt,
name::
* McsEngl.smw'property'Resource@cptIt,
_SPECIFIC:
* http://semantic-mediawiki.org/wiki/Property:Has_type,
name::
* McsEngl.smw'property'Type@cptIt,
* McsEngl.smw'property'datatype@cptIt,
_DESCRIPTION:
Datatypes are very important for evaluating properties. Firstly, the data type determines how tools should handle the given values, e.g. for displaying values and sorting values in search results. Secondly, the data type is required to understand which values have the same meaning, e.g. the values "1532", "1,532", and "1.532e3" all encode the same number. Finally, some data types have special behavior, as will be described below. For these reasons, every property used should be defined with a data type.
[http://semantic-mediawiki.org/wiki/Property]
_ADDRESS.WPG:
* http://www.semantic-mediawiki.org/wiki/Special:Types,
_SPECIFIC:
* The following is a list of all datatypes that can be assigned to properties.
Annotation URI
Boolean
Code
Date
Email
Geographic coordinate
Number
Page
Quantity
Record
String
Telephone number
Temperature
Text
URL
[http://semantic-mediawiki.org/wiki/Special:Types]
* http://localhost/mw19/phase3/index.php/Special:Types,
name::
* McsEngl.smw'Record-type@cptIt,
_DESCRIPTION:
From version 1.0 to 1.4, SMW allowed many-valued properties. Types for these properties are specified by listing multiple types as the value of Has type, separated by semicolons.
Starting with version 1.5, many-valued properties were replaced by the type Record.
[http://semantic-mediawiki.org/wiki/Property:Has_type]
_ADDRESS.WPG:
* http://semantic-mediawiki.org/wiki/Help:Many-valued_properties,
name::
* McsEngl.smw'property.Subproperty@cptIt,
Subproperties
Just like categories, also properties can be more specific than one another. For example, a wiki may have the property «capital of» to relate cities to countries, and a property «located in» that generally describes that some city is located in some country. Now it happens to be the case that every capital city also must be located in the country that it is capital of. In other words, «capital of» is a subproperty of «located in». Whenever a user states that a page is a capital of some country, SMW should then also conclude that the page has an (implicit) «located in» relation to that country as well. To say that in the wiki, the following can be entered on the page Property:Capital of: subproperty of::Property:located in,
Once this has been stated, a query [[located in::Germany]] will also return the capital Berlin even if no «located in» property is given on that page. Similar considerations as in the case of cateogries apply, and detailed descriptions on property pages are a good method for avoiding semantic drift.
[http://semantic-mediawiki.org/wiki/Help:Inferencing]
name::
* McsEngl.smw'property.Special@cptIt,
_DESCRIPTION:
Certain special properties are built-in to Semantic MediaWiki to make the system work. They appear in a page's Factbox in italic. Since SMW 1.4.0, special properties can be used in browsing interfaces and inline queries just like all other properties.
[http://semantic-mediawiki.org/wiki/Category:Special_property]
_ADDRESS.WPG:
* http://semantic-mediawiki.org/wiki/Category:Special_property,
_SPECIFIC:
A
Property:Allows value
C
Property:Corresponds to
Property:Creation date
D
Property:Display units
E
Property:Equivalent URI
H
Property:Has fields
Property:Has improper value for
Property:Has type
Property:Has value
I
Property:Imported from
M
Property:Modification date
P
Property:Provides service
S
Property:Subproperty of
[http://semantic-mediawiki.org/wiki/Special_property]
Undocumented special property
Pages in category "Undocumented special property"
This category contains only the following page.
H
Property:Has value
[http://semantic-mediawiki.org/wiki/Category:Undocumented_special_property]
name::
* McsEngl.smw'Retrieving@cptIt,
* McsEngl.swm'reading@cptIt,
_GENERIC:
* using-smw#ql:smw'using#
name::
* McsEngl.smw'Query@cptIt,
* McsEngl.smw'query-language@cptIt,
Besides annotations, SMW also allows editors to embed semantic queries into articles. Thereby, readers of the wiki can view ready-made query results without having to learn the SMW query language. This feature is explained in the section on inline queries.
[http://semantic-mediawiki.org/wiki/Help:Editing]
_Syntax:
The syntax for asking for pages that satisfy some condition is exactly the syntax for explicitly asserting that this condition holds.
[http://semantic-mediawiki.org/wiki/Help:Selecting_pages]
name::
* McsEngl.smw'Query.Inline@cptIt,
* McsEngl.smw'inline-query@cptIt,
{{#ask: [[Category:City]] [[located in::Germany]]
| ?population
| ?area#km² = Size in km²
| format=ol
}}
name::
* McsEngl.smw'Searching@cptIt,
* McsEngl.smw'semantic-search@cptIt,
* McsEngl.smw'semantic-query@cptIt,
_DESCRIPTION:
The "Semantic search" page, which can be found at Special:Ask, provides an interface that assists users with creating and executing semantic queries.
[http://semantic-mediawiki.org/wiki/Help:Special:Ask]
name::
* McsEngl.smw'Special-PageProperty@cptIt,
Special:PageProperty displays all values some page has for some property. Users enter a page and a property name. The search displays a list of all values of the property on that page. If factboxes are enabled in the wiki, the same information can also be read off the factbox of the page. Since SMW 1.4.3, it is also possible to retrieve all values that a property has been given throughout the wiki, simply by leaving the subject input empty.
name::
* McsEngl.smw'Special-Properties@cptIt,
Special:Properties lists properties that appear in annotations in alphabetical order and indicate the frequency of their usage.
name::
* McsEngl.smw'Special-SearchByProperty@cptIt,
Special:SearchByProperty has a simple search form for finding semantic backlinks. Users enter a property name and target value. The search returns a list of all pages that have that property with that value. If you search for a property of a numeric type, and there are only few results, nearest results will be shown as well. This can be switched off by setting $smwgSearchByPropertyFuzzy to false in your local settings. This service is directly accessible through the link within the factbox or Special:Browse.
[]
name::
* McsEngl.smw'Resource@cptIt,
_ADDRESS.WPG:
* http://semantic-mediawiki.org//
* doc: http://semantic-mediawiki.org/wiki/Category:Semantic_MediaWiki_documentation,
_Wikipedia:
* http://en.wikipedia.org/wiki/Semantic_MediaWiki,
name::
* McsEngl.smw'Support@cptIt,
_SPECIFIC:
* developing,
* using,
_DESCRIPTION:
SMWCon, also known as the Semantic MediaWiki Conference, is a twice-yearly gathering for users, developers and enthusiasts of Semantic MediaWiki, including corporate users, academics and others. SMWCon is held once a year in North America, in the spring, and the other in Europe, in the fall.
The next SMWCon event will be SMWCon Spring 2012, to be held April 25-27 in Carlsbad, California.
[http://semantic-mediawiki.org/wiki/SMWCon]
name::
* McsEngl.smw'Using@cptIt,
name::
* McsEngl.smw'using'Support@cptIt,
_List:
* https://lists.sourceforge.net/lists/listinfo/semediawiki-user,
name::
* McsEngl.mw'extension.SimpleTable@cptIt,
This very simple extension allows tabular data to be easily cut-and-pasted into a Wiki; for example, this allows a CSV export from Excel to be pasted in without having to manually edit it into Wiki table syntax. It's really crude, and doesn't allow any kind of clever formatting; for example, there is no way to set row and cell parameters, including row and cell spanning. On the other hand, it's really simple, and it would be pretty easy to expand the parser (the convertTable() function) to handle more complex input.
[http://www.mediawiki.org/wiki/Extension:SimpleTable]
Installation
Download the extension code:
Version 1.0 (named "TabbedData"): known to work with PHP 4 and MW 1.6. Usage is the same as above, except that the sep and head parameters are not supported.
Version 1.1 (named "TabbedData"): known to work with PHP 5 and MW 1.9; will not work on PHP 4 / MW 1.6.
Version 1.2: added "head=topleft" and "sep=semicolon" and renamed to SimpleTable. Known to work with PHP 5 and MW 1.9; will not work on PHP 4 / MW 1.6.
Version 1.2a: added "applycssborderstyle=true" which adds css style attributes to the table and cells to show a 1px black border around all cells.
Save the code in your wiki's extensions directory as extensions/SimpleTable.php.
[edit]Changes to LocalSettings.php
require_once("$IP/extensions/SimpleTable.php");
name::
* McsEngl.mw'extension.Skin@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Category:Skin_extensions,
mw'extension.vector:
Trevor Parscal tparscal@wikimedia.org
8:54 PM (10 hours ago)
to MediaWiki
Since it doesn't look like you changed any of the IDs or classes around, I
think it's just that you didn't configure it properly yet. The Vector
extension has a global config object that controls which modules are
enabled and how.
See: http://www.mediawiki.org/wiki/Extension:Vector
In your case, you want to add...
$wgVectorFeatures['collapsiblenav']['global'] = true;
... which will enable it for all users.
name::
* McsEngl.mw'extension.SpecialPage@cptIt,
_DESCRIPTION:
Create special-pages.
===
Extensions with usage like special-pages: server/Special:NameOfExtension.
_SPECIFIC:
* CreateAPage: http://www.mediawiki.org/wiki/Extension:CreateAPage,
* CreateRedirect:
* InterwikiLis: http://www.mediawiki.org/wiki/Extension:InterwikiList,
name::
* McsEngl.mw'extension.Tag@cptIt,
* McsEngl.mw'Tag-extension@cptIt,
_DESCRIPTION:
Tag-function associations - XML style tags that are associated with a php function that outputs HTML code. You do not need to limit yourself to formatting the text inside the tags. You don't even need to display it. Many tag extensions use the text as parameters that guide the generation of HTML that embeds google objects, data entry forms, RSS feeds, excerpts from selected wiki articles.
[http://www.mediawiki.org/wiki/Manual:Developing_extensions#Extension_types]
===
Individual projects will often find it useful to extend the built-in wiki markup with additional capabilities, whether simple string processing, or full-blown information retrieval. Tag Extensions allow users to create new custom tags that do just that. For example, one might use a tag extension to introduce a simple <donation /> tag, which injects a donation form into the page. Extensions, along with Parser Functions and Hooks are the most effective way to change or enhance the functionality of MediaWiki. To see existing extensions built by other MediaWiki users see: Extension Matrix. You should always check the matrix before you start work on an extension to make sure someone else hasn't done exactly what you are trying to do.
A simple tag extension consists of a callback function, which is hooked to the parser so that, when the parser runs, it will find and replace all instances of a specific tag, calling the corresponding callback function to render the actual HTML.
[http://www.mediawiki.org/wiki/Manual:Tag_extensions]
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Category:Tag_extensions,
name::
* McsEngl.mw'extension.TitleKey@cptIt,
_GENERIC:
* search-extension#ql:mw'extension.search#
TitleKey extension is a case-insensitive title prefix search plugin by Brion Vibber. It uses a separate table for the keys, so if it works cleanly it can be deployed without an expensive rebuild of core tables, and dumped when Wikimedia gets a nicer backend through Extension:LuceneSearch (pre 1.13) or Extension:MWSearch (1.13+).
For the average site administrator, the benefit of this extension is that it allows search suggestions (enabled through $wgEnableMWSuggest) to be case-insensitive.
[http://www.mediawiki.org/wiki/Extension:TitleKey]
name::
* McsEngl.mw'extension.TreeAndMenu@cptIt,
I've needed to create parser-functions a number of times which allow the rendering of dynamic menus. Each time I've created a specific extension for the job and have used code from TreeView to achieve it, so finally I bit the bullet and merged the best JavaScript dynamic menu I've found (Sons of Suckerfish) into the TreeView code base, and renamed the extension from TreeView5 to TreeAndMenu.
[http://www.mediawiki.org/wiki/Extension:TreeAndMenu]
_HACK_for_1.17.0:
Script line 86 in TreeAndMenu.php which uses addScript-function does not work anymore. Has to be changed to:
$wgOut->addHeadItem( "test","<script type=\"$wgJsMimeType\" src=\"{$this->baseRelDir}/dtree.js\"></script>\n" );
name::
* McsEngl.mw'extension.User@cptIt,
_SPECIFIC:
* http://www.mediawiki.org/wiki/Extension:User_Merge_and_Delete,
* http://www.mediawiki.org/wiki/Extension:Nuke, content
name::
* McsEngl.mw'extension.Variable@cptIt,
* McsEngl.mw'varial-extension@cptIt,
_WHOLE:
* mw-variable#ql:mw'variable#
_DESCRIPTION:
The Variable extensions category contains extensions that define wiki variables. It does not contain articles on configuration variables, nor does it discuss extensions that provide a way to extend template construction with modifiable variables.
[http://www.mediawiki.org/wiki/Category:Variable_extensions]
_SPECIFIC:
* http://www.mediawiki.org/wiki/Extension:MyVariables,
name::
* McsEngl.mw'extension.MyVariables@cptIt,
Sal Quintanilla salquint@gmail.com via lists.wikimedia.org
5:14 PM (2 hours ago)
to MediaWiki
The answer is "it depends", but maybe this will work for you.
Add the extension MyVariables to your installation
http://www.mediawiki.org/wiki/Extension:MyVariables
and then modify it to add a new variable like LOGGEDIN:
Near the top:
$wgCustomerVariables = array(..., 'LOGGEDIN', ...)
In function wfGetCustomVariable(), add
case MAG_LOGGEDIN:
if ($wgUser->isLoggedIn())
$ret = 'Y';
else
$ret = 'N';
break;
On your Mediawiki page, surround the content with something like
{{#ifeq: {{LOGGEDIN}} | N | <div style="display:none">}}
... content ...
{{#ifeq: {{LOGGEDIN}} | N | </div>}}
-----Original Message-----
From: mediawiki-l-bounces@lists.wikimedia.org
[mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of
Sreelaxmi.Alladi@cognizant.com
Sent: Wednesday, January 11, 2012 1:59 AM
To: MediaWiki-l@lists.wikimedia.org
Subject: [Mediawiki-l] I need to Hide a single page from Un-login users
Hi
I need to Hide a single page from Un-login users.. Can u help me regarding
dis.?
Regards
name::
* McsEngl.mw'extension.Widgets@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Extension:Widgets,
name::
* McsEngl.mw'extension.WikEd@cptIt,
* McsEngl.wikEd@cptIt580i,
_ADDRESS.WPG:
* http://en.wikipedia.org/wiki/User:Cacycle/wikEd,
name::
* McsEngl.mw'extension.Wikidata@cptIt,
* McsEngl.mw'wikidata@cptIt,
* McsEngl.wikidata-extension@cptIt580i,
_GENERIC:
* mediawiki-extension#ql:mw'extension#
_DESCRIPTION:
In a standard MediaWiki installation, all the text of a page is entered in one field, and stored in one entry of the database (page_text).
Wikidata allows to configure some namespaces to use several fields of different types (text, Combobox, etc.) on one wikipage and to store these fields in a structured database.
[http://www.mediawiki.org/wiki/Extension:Wikidata]
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Extension:Wikidata,
* http://www.mediawiki.org/wiki/Wikidata, (historical)
* http://meta.wikimedia.org/wiki/Wikidata,
* http://meta.wikimedia.org/wiki/Wikidata_(2),
* http://meta.wikimedia.org/wiki/Category:Wikidata,
* http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/Wikidata//
* http://svn.wikimedia.org/svnroot/mediawiki/branches/wikidata//
name::
* McsEngl.wikidata'Human@cptIt,
Pintscher.Lydia:
Lydia Pintscher lydia.pintscher@wikimedia.de
name::
* McsEngl.mw'extension.WikiEditor@cptIt,
* McsEngl.mw'WikiEditor@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Extension:WikiEditor,
_Configuration:
* TableOfContents: on my-prefrences/editing/show toc
name::
* McsEngl.mw'extension.WikiScripts@cptIt,
_ADDRESS.WPG:
* https://www.mediawiki.org/wiki/Extension:WikiScripts,
name::
* McsEngl.mw'extension.WikiTrust@cptIt,
_DESCRIPTION:
A reputation system for Wikipedia authors and content
WikiTrust is an open-source, on-line reputation system for Wikipedia authors and content. WikiTrust is hosted by the Institute for Scalable Scientific Data Management at the School of Engineering of the University of California, Santa Cruz.
[http://wikitrust.soe.ucsc.edu/home]
name::
* McsEngl.mw'extension.Winter@cptIt,
_ADDRESS.WPG:
* https://www.mediawiki.org/wiki/Extension:Winter,
_GENERIC:
* parser-extension#ql:mw'extension.parser#
_DESCRIPTION:
* Winter (Wiki Interpreter) is an extension which adds an interpreted language to MediaWiki pages. It is intended to enhance the templating system but can be used on any page.
[https://www.mediawiki.org/wiki/Extension:Winter]
name::
* McsEngl.mw'extension.WYSIWYG@cptIt,
_ADDRESS.WPG:
* http://smwforum.ontoprise.com/smwforum/index.php/Help:Installing_the_WYSIWYG_extension_manually_on_top_of_MediaWiki_(v_1.16.x)_1.6.0,
This extension enables a more intuitive WYSIWYG editor when editing pages on a MediaWiki-based site. It uses a special version of the CKeditor that outputs wiki text rather than the usual HTML that caused problems for MediaWiki integrations in the past. When this extension is installed, the tab 'Edit' in the command bar on top of every page leads directly in the wysiwyg editing mode.
[http://www.mediawiki.org/wiki/Extension:WYSIWYG]
_Installation:
Installation
Download WYSIWYG extension from our download page
Extract the zip-file (wysiwyg-1.5.6_0.zip)
Copy the folder wysiwyg-1.5.6_0\extensions\WYSIWYG into the folder ..\htdocs\mediawiki\extensions
Add the following line to your LocalSettings.php to initialize the extension:
require_once("$IP/extensions/WYSIWYG/WYSIWYG.php");
Define the group rights, the easiest is to grant all users access:
$wgGroupPermissions['*']['wysiwyg']=true;
or only for registeres users:
$wgGroupPermissions['registered_users']['wysiwyg']=true;
[http://smwforum.ontoprise.com/smwforum/index.php/Help:Installing_the_WYSIWYG_extension_manually_on_top_of_MediaWiki_(v_1.16.x)]
name::
* McsEngl.mw'Hook@cptIt,
* McsEngl.mw'event-hook@cptIt,
_GENERIC:
* mw-developing#ql:mw'developing#,
* macro#ql:mw'macro#
_DESCRIPTION:
A clump of code and data that should be run when an event happens. This can be either a function and a chunk of data, or an object and a method.
...
A hook is a chunk of code run at some particular event. It consists of:
* a function with some optional accompanying data, or
* an object with a method and some optional accompanying data.
[http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3/docs/hooks.txt]
===
Hooks allow custom code to be executed when one of many defined events (like saving an article or a user logging in) occur. For example: The following code snippet, when added to LocalSettings.php, would call the function ircNotify with a single argument of example every time that an article is saved:
$wgHooks['ArticleSaveComplete'][] = array('ircNotify', 'example');
MediaWiki provides many hooks that can be used to extend the functionality of the MediaWiki software. Assigning a function (known as an event handler) to a hook will cause that function to be called at the appropriate point in the main MediaWiki code, to perform whatever additional task(s) the developer thinks would be useful at that point. Each hook can have multiple handlers assigned to it, in which case it will call the functions in the order that they are assigned, with any modifications made by one function passed on to subsequent functions in the chain.
Hooks should be assigned at the end of LocalSettings.php or in your own extension file at the file scope (not in a $wgExtensionFunctions function or the ParserFirstCallInit hook). The easiest way to assign a function to a hook is:
$wgHooks['event'][] = 'function';
which adds an element to the array $wgHooks. You can also create new hooks in your own extension. Hooks created this way should be added to the Extension Hook Registry.
[http://www.mediawiki.org/wiki/Manual:Hooks]
name::
* McsEngl.mw'hook'Calling@cptIt,
* McsEngl.mw'hook'execution@cptIt,
_DESCRIPTION:
Event handlers are registered by adding them to the global $wgHooks array for a given event. Hooks can be added from any point in the execution before the hook is called, but are most commonly added in LocalSettings.php or its included files. All the following are valid ways to define hooks, with the code that will be executed when 'EventName' happens:
[http://www.mediawiki.org/wiki/Hooks#Writing_an_event_handler]
name::
* McsEngl.mw'hook'Event@cptIt,
_DESCRIPTION:
event
Something that happens with the wiki. For example: a user logs in. A wiki
page is saved. A wiki page is deleted.
Often there are two events
associated with a single action: one before the code is run to make the
event happen, and one after.
Each event has a name, preferably in CamelCase. For example, 'UserLogin', 'ArticleSave', 'ArticleSaveComplete', 'ArticleDelete'.
[http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3/docs/hooks.txt]
name::
* McsEngl.mw'hook'Event-handler@cptIt,
* McsEngl.mw'hook'callback-function@cptIt,
* McsEngl.mw'hook'creation@cptIt,
* McsEngl.mw'hook'definition@cptIt,
* McsEngl.mw'hook'handler@cptIt,
_DESCRIPTION:
An event handler is a function that is assigned to a hook, which will be run whenever the event represented by that hook occurs. It consists of:
* a function with some optional accompanying data, or
* an object with a method and some optional accompanying data.
[http://www.mediawiki.org/wiki/Hooks#Writing_an_event_handler]
===
MediaWiki provides many hooks that can be used to extend the functionality of the MediaWiki software. Assigning a function (known as an event handler) to a hook will cause that function to be called at the appropriate point in the main MediaWiki code, to perform whatever additional task(s) the developer thinks would be useful at that point. Each hook can have multiple handlers assigned to it, in which case it will call the functions in the order that they are assigned, with any modifications made by one function passed on to subsequent functions in the chain.
[http://www.mediawiki.org/wiki/Manual:Hooks]
name::
* McsEngl.mw'hook'Registration@cptIt,
* McsEngl.mw'hook'addition@cptIt,
* McsEngl.mw'wgHooks@cptIt,
Hooks are registered by adding them to the global $wgHooks array for a given
event. All the following are valid ways to define hooks:
$wgHooks['EventName'][] = 'someFunction';# function, no data
$wgHooks['EventName'][] = array('someFunction', $someData);
$wgHooks['EventName'][] = array('someFunction');# weird, but OK
$wgHooks['EventName'][] = $object;# object only
$wgHooks['EventName'][] = array($object, 'someMethod');
$wgHooks['EventName'][] = array($object, 'someMethod', $someData);
$wgHooks['EventName'][] = array($object);# weird but OK
When an event occurs, the function (or object method) will be called with the
optional data provided as well as event-specific parameters. The above examples
would result in the following code being executed when 'EventName' happened:
# function, no data
someFunction($param1, $param2)
# function with data
someFunction($someData, $param1, $param2)
# object only
$object->onEventName($param1, $param2)
# object with method
$object->someMethod($param1, $param2)
# object with method and data
$object->someMethod($someData, $param1, $param2)
[http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3/docs/hooks.txt]
name::
* McsEngl.mw'hook'Resource@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Hooks,
* http://www.mediawiki.org/wiki/Manual:Hooks,
* http://www.mediawiki.org/wiki/Manual:$wgHooks,
* http://www.mediawiki.org/wiki/Manual:$wgSpecialVersionShowHooks,
* http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3/docs/hooks.txt,
* http://www.mediawiki.org/wiki/Extension_hook_registry,
* http://www.mediawiki.org/wiki/Category:Hooks,
* http://www.mediawiki.org/wiki/Category:MediaWiki_hooks,
* http://www.mediawiki.org/wiki/Category:Hook_extensions,
name::
* McsEngl.mw'hook'Usage@cptIt,
Hooks allow us to decouple optionally-run code from code that is run for
everyone. It allows MediaWiki hackers, third-party developers and local
administrators to define code that will be run at certain points in the mainline
code, and to modify the data run by that mainline code. Hooks can keep mainline
code simple, and make it easier to write extensions. Hooks are a principled
alternative to local patches.
[http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3/docs/hooks.txt]
name::
* McsEngl.mw'hook'wfRunHooks@cptIt,
* McsEngl.mw'wfRunHooks@cptIt,
Each hook is represented in the code by a call of function wfRunHooks, which is defined in file Hooks.php. The first argument of wfRunHooks is the name of the hook, the second is the array of arguments of the hook. Function wfRunHooks finds the tasks to be done from the array $wgHooks. It calls the PHP function call_user_func_array with arguments being the function to be called and its arguments.
See also the hook specification in SVN.
In this example from the doEdit function in Article.php, wfRunHooks is used to call the ArticleSaveComplete hook using several arguments:
wfRunHooks( 'ArticleSaveComplete', array( &$this, &$user, $text, $summary, $flags & EDIT_MINOR, &$watchthis, null,
&$flags, $revision, &$status, $baseRevId, &$redirect) );
The core calls many hooks, but extensions can also call hooks.
[http://www.mediawiki.org/wiki/Hooks]
_SPECIFIC:
* http://www.mediawiki.org/wiki/Category:MediaWiki_hooks,
===
* mw'hook.Article_Management,
* mw'hook.Edit_Page,
* mw'hook.Page-Rendering,
* http://www.mediawiki.org/wiki/Manual:Hooks#User_Interface,
* mw'hook.Special_Pages,
* mw'hook.User_Management,
* mw'hook.Logging,
* http://www.mediawiki.org/wiki/Manual:Hooks#Skinning_Templates,
* http://www.mediawiki.org/wiki/Manual:Hooks#API,
* http://www.mediawiki.org/wiki/Manual:Hooks#Miscellaneous,
===
A,
* http://www.mediawiki.org/wiki/Manual:Hooks/AbortAutoAccount,
* mw'hook.AbortAutoblock,
* mw'hook.AbortDiffCache,
* mw'hook.AbortLogin,
* mw'hook.AbortMove,
* mw'hook.AbortNewAccount,
* mw'hook.ActionBeforeFormDisplay,
* mw'hook.ActionModifyFormFields,
* mw'hook.AddNewAccount,
* mw'hook.AfterImportPage,
* mw'hook.AfterUserMessage,
* mw'hook.AjaxAddScript,
* mw'hook.AlternateEdit,
* mw'hook.AlternateUserMailer,
* mw'hook.APIAfterExecute,
* mw'hook.APIEditBeforeSave,
* mw'hook.APIGetAllowedParams,
* mw'hook.APIGetDescription,
* mw'hook.APIGetParamDescription,
* mw'hook.APIQueryAfterExecute,
* mw'hook.APIQueryGeneratorAfterExecute,
* mw'hook.APIQueryInfoTokens,
* mw'hook.APIQueryRecentChangesTokens,
* mw'hook.APIQueryRevisionsTokens,
* mw'hook.APIQuerySiteInfoGeneralInfo,
* mw'hook.APIQueryUsersTokens,
* mw'hook.ApiRsdServiceApis,
* mw'hook.ArticleAfterFetchContent,
* mw'hook.ArticleConfirmDelete,
* mw'hook.ArticleContentOnDiff,
* mw'hook.ArticleDelete,
* mw'hook.ArticleDeleteComplete,
* mw'hook.ArticleEditUpdateNewTalk,
* mw'hook.ArticleEditUpdates,
* mw'hook.ArticleEditUpdatesDeleteFromRecentchanges,
* mw'hook.ArticleFromTitle,
* mw'hook.ArticleInsertComplete,
* mw'hook.ArticleMergeComplete,
* mw'hook.ArticlePageDataAfter,
* mw'hook.ArticlePageDataBefore,
* mw'hook.ArticlePrepareTextForEdit,
* mw'hook.ArticleProtect,
* mw'hook.ArticleProtectComplete,
* mw'hook.ArticlePurge,
* mw'hook.ArticleRevisionUndeleted,
* mw'hook.ArticleRevisionVisibilitySet,
* mw'hook.ArticleRollbackComplete,
* mw'hook.ArticleSave,
* mw'hook.ArticleSave/1.5,
* mw'hook.ArticleSaveComplete,
* mw'hook.ArticleUndelete,
* mw'hook.ArticleUpdateBeforeRedirect,
* mw'hook.ArticleViewCustom,
* mw'hook.ArticleViewFooter,
* mw'hook.ArticleViewHeader,
* mw'hook.ArticleViewRedirect,
* mw'hook.AuthPluginAutoCreate,
* mw'hook.AuthPluginSetup,
* mw'hook.AutoAuthenticate,
* mw'hook.AutopromoteCondition,
B,
* mw'hook.BacklinkCacheGetConditions,
* mw'hook.BacklinkCacheGetPrefix,
* mw'hook.BadImage,
* mw'hook.BaseTemplateToolbox,
* mw'hook.BeforeGalleryFindFile,
* mw'hook.BeforeInitialize,
* mw'hook.BeforePageDisplay,
* mw'hook.BeforeParserFetchFileAndTitle,
* mw'hook.BeforeParserFetchTemplateAndtitle,
* mw'hook.BeforeParserMakeImageLinkObj,
* mw'hook.BeforeParserrenderImageGallery,
* mw'hook.BeforeWatchlist,
* mw'hook.BeforeWelcomeCreation,
* mw'hook.BitmapHandlerTransform,
* mw'hook.BlockIp,
* mw'hook.BlockIpComplete,
* mw'hook.BookInformation,
* mw'hook.BrokenLink,
C,
* mw'hook.CanonicalNamespaces,
* mw'hook.CategoryPageView,
* mw'hook.ChangesListInsertArticleLink,
* mw'hook.Collation::factory,
* mw'hook.ConfirmEmailComplete,
* mw'hook.ContribsPager::getQueryInfo,
* mw'hook.ContributionsLineEnding,
* mw'hook.ContributionsToolLinks,
* mw'hook.CustomEditor,
D,
* mw'hook.DatabaseOraclePostInit,
* mw'hook.Debug,
User:Wikinaut/Books/MediaWiki Developer's Guide,
* mw'hook.DiffViewHeader,
* mw'hook.DisplayOldSubtitle,
* mw'hook.DoEditSectionLink,
E,
* mw'hook.EditFilter,
* mw'hook.EditFilterMerged,
* mw'hook.EditFormInitialText,
* mw'hook.EditFormPreloadText,
* mw'hook.EditPage::attemptSave,
* mw'hook.EditPage::importFormData,
* mw'hook.EditPage::showEditForm:fields,
* mw'hook.EditPage::showEditForm:initial,
* mw'hook.EditPageBeforeConflictDiff,
* mw'hook.EditPageBeforeEditButtons,
* mw'hook.EditPageBeforeEditChecks,
* mw'hook.EditPageBeforeEditToolbar,
* mw'hook.EditPageCopyrightWarning,
* mw'hook.EditPageGetDiffText,
* mw'hook.EditPageGetPreviewText,
* mw'hook.EditPageNoSuchSection,
* mw'hook.EditPageTosSummary,
* mw'hook.EditSectionLink,
* mw'hook.EditSectionLinkForOther,
* mw'hook.EmailConfirmed,
* mw'hook.EmailUser,
* mw'hook.EmailUserCC,
* mw'hook.EmailUserComplete,
* mw'hook.EmailUserForm,
* mw'hook.EmailUserPermissionsErrors,
* mw'hook.ExemptFromAccountCreationThrottle,
* mw'hook.ExtensionTypes,
F,
* mw'hook.FetchChangesList,
* mw'hook.FileDeleteComplete,
* mw'hook.FileUndeleteComplete,
* mw'hook.FileUpload,
* mw'hook.FormatUserMessage,
G,
* mw'hook.GetAutoPromoteGroups,
* mw'hook.GetBlockedStatus,
* mw'hook.GetCacheVaryCookies,
* mw'hook.GetCanonicalURL,
* mw'hook.GetDefaultSortkey,
* mw'hook.GetFullURL,
* mw'hook.GetInternalURL,
* mw'hook.GetIP,
M,
* mw'hook.MonoBookTemplateToolboxEnd,
N,
* mw'hook.NewDifferenceEngine,
* mw'hook.NewRevisionFromEditComplete,
* mw'hook.NormalizeMessageKey,
O,
* mw'hook.OldChangesListRecentChangesLine,
* mw'hook.OpenSearchUrls,
* mw'hook.OtherBlockLogLink,
* mw'hook.OutputPageBeforeHTML,
* mw'hook.OutputPageBodyAttributes,
* mw'hook.OutputPageCheckLastModified,
* mw'hook.OutputPageMakeCategoryLinks,
* mw'hook.OutputPageParserOutput,
P,
* mw'hook.PageContentLanguage,
* mw'hook.PageHistoryBeforeList,
* mw'hook.PageHistoryLineEnding,
* mw'hook.PageHistoryPager::getQueryInfo,
* mw'hook.PageRenderingHash,
* mw'hook.ParserAfterStrip,
* mw'hook.ParserAfterTidy,
* mw'hook.ParserBeforeInternalParse,
* mw'hook.ParserBeforeStrip,
* mw'hook.ParserBeforeTidy,
* mw'hook.ParserClearState,
* mw'hook.ParserFirstCallInit,
* mw'hook.ParserGetVariableValueSwitch,
* mw'hook.ParserGetVariableValueTs,
* mw'hook.ParserGetVariableValueVarCache,
* mw'hook.ParserLimitReport,
* mw'hook.ParserMakeImageParams,
* mw'hook.ParserSectionCreate,
* mw'hook.ParserTestParser,
* mw'hook.ParserTestTables,
* mw'hook.PerformRetroactiveAutoblock,
* mw'hook.PersonalUrls,
* mw'hook.PingLimiter,
* mw'hook.PlaceNewSection,
* mw'hook.PreferencesUserInformationPanel,
* mw'hook.PrefixSearchBackend,
* mw'hook.PrefsEmailAudit,
* mw'hook.PrefsPasswordAudit,
* mw'hook.ProtectionForm::buildForm,
* mw'hook.ProtectionForm::save,
* mw'hook.ProtectionForm::showLogExtract,
R,
* mw'hook.RawPageViewBeforeOutput,
* mw'hook.RecentChange save,
* mw'hook.RenderPreferencesForm,
* mw'hook.ResetPreferences,
* mw'hook.ResourceLoaderGetConfigVars,
* mw'hook.ResourceLoaderGetStartupModules,
* mw'hook.ResourceLoaderRegisterModules,
* mw'hook.ResourceLoaderTestModules,
* mw'hook.RevisionInsertComplete,
S,
* mw'hook.SavePreferences,
* mw'hook.SearchableNamespaces,
* mw'hook.SearchEngineReplacePrefixesComplete,
* mw'hook.SearchGetNearMatch,
* mw'hook.SearchGetNearMatchBefore,
* mw'hook.SearchGetNearMatchComplete,
* mw'hook.SearchUpdate,
* mw'hook.SetupAfterCache,
* mw'hook.SetupUserMessageArticle,
* mw'hook.ShowMissingArticle,
* mw'hook.ShowRawCssJs,
* mw'hook.ShowSearchHitTitle,
* mw'hook.SiteNoticeAfter,
* mw'hook.SiteNoticeBefore,
* mw'hook.SkinAfterBottomScripts,
* mw'hook.SkinAfterContent,
* mw'hook.SkinBuildSidebar,
* mw'hook.SkinCopyrightFooter,
* mw'hook.SkinGetPoweredBy,
* mw'hook.SkinSubPageSubtitle,
* mw'hook.SkinTemplateBuildContentActionUrlsAfterSpecialPage,
* mw'hook.SkinTemplateBuildNavUrlsNav urlsAfterPermalink,
* mw'hook.SkinTemplateContentActions,
* mw'hook.SkinTemplateNavigation,
* mw'hook.SkinTemplateNavigation::SpecialPage,
* mw'hook.SkinTemplateNavigation::Universal,
* mw'hook.SkinTemplateOutputPageBeforeExec,
* mw'hook.SkinTemplatePreventOtherActiveTabs,
* mw'hook.SkinTemplateSetupPageCss,
* mw'hook.SkinTemplateTabAction,
* mw'hook.SkinTemplateTabs,
* mw'hook.SkinTemplateToolboxEnd,
* mw'hook.SoftwareInfo,
* mw'hook.SpecialContributionsBeforeMainOutput,
* mw'hook.SpecialListusersDefaultQuery,
* mw'hook.SpecialListusersFormatRow,
* mw'hook.SpecialListusersHeader,
* mw'hook.SpecialListusersHeaderForm,
* mw'hook.SpecialListusersQueryInfo,
* mw'hook.SpecialMovepageAfterMove,
* mw'hook.SpecialNewpagesConditions,
* mw'hook.SpecialNewPagesFilters,
* mw'hook.SpecialPageExecuteAfterPage,
* mw'hook.SpecialPageExecuteBeforeHeader,
* mw'hook.SpecialPageExecuteBeforePage,
* mw'hook.SpecialPage initList,
* mw'hook.SpecialPasswordResetOnSubmit,
* mw'hook.SpecialRandomGetRandomTitle,
* mw'hook.SpecialRecentChangesFilters,
* mw'hook.SpecialRecentChangesPanel,
* mw'hook.SpecialRecentChangesQuery,
* mw'hook.SpecialSearchCreateLink,
* mw'hook.SpecialSearchGo,
* mw'hook.SpecialSearchNogomatch,
* mw'hook.SpecialSearchNoResults,
* mw'hook.SpecialSearchPowerBox,
* mw'hook.SpecialSearchProfileForm,
* mw'hook.SpecialSearchProfiles,
* mw'hook.SpecialSearchResults,
* mw'hook.SpecialSearchSetupEngine,
* mw'hook.SpecialStatsAddExtra,
* mw'hook.SpecialUploadComplete,
* mw'hook.SpecialVersionExtensionTypes,
* mw'hook.SpecialWatchlistFilters,
* mw'hook.SpecialWatchlistQuery,
T,
* mw'hook.TestCanonicalRedirect,
* mw'hook.TitleArrayFromResult,
* mw'hook.TitleGetRestrictionTypes,
* mw'hook.TitleIsCssOrJsPage,
* mw'hook.TitleIsMovable,
* mw'hook.TitleIsKnown,
* mw'hook.TitleIsWikitextPage,
* http://www.mediawiki.org/wiki/Manual:Hooks/TitleMoveComplete,
U,
* mw'hook.UndeleteForm::showHistory,
* mw'hook.UndeleteForm::showRevision,
* mw'hook.UndeleteForm::undelete,
* mw'hook.UndeleteShowRevision,
name::
* McsEngl.mw'Human@cptIt,
name::
* McsEngl.mw'human'Code@cptIt,
_File:
* includes/User.php [code] Implements the User class for the MediaWiki software
* includes/UserArray.php [code]
* includes/UserMailer.php [code] Classes used to send e-mails
* includes/UserRightsProxy.php [code]
_SPECIFIC:
* extension#ql:mw'extension.user#,
* http://www.mediawiki.org/wiki/Manual:RemoveUnusedAccounts.php,
name::
* McsEngl.mw'file.User.php@cptIt,
_FILE:
\mw19\phase3\includes\User.php">mw'human.php,
_ADDRESS.WPG:
* http://svn.wikimedia.org/doc/User_8php.html,
User.php
The User class is used to represent users on the system. The global $wgUser represents the currently logged in user, and is usually what you will deal with when manipulating users.
[edit]User->isAllowed($right)
Returns true or false depending on whether the user is allowed to do $right.
[edit]User->isBlocked()
Returns true if a user is blocked.
[http://www.mediawiki.org/wiki/Manual:Special_pages]
name::
* McsEngl.mw'human'Contribution@cptIt,
_DESCRIPTION:
The revision table is used for page history and user contributions listings.
[http://www.mediawiki.org/wiki/Manual:Revision_table]
name::
* McsEngl.mw'human'Right@cptIt,
* McsEngl.mw'user-right@cptIt,
* McsEngl.mw'group-permission@cptIt,
* McsEngl.mw'permission@cptIt,
* McsEngl.mw'restriction@cptIt,
_DESCRIPTION:
User rights are specific access and ability permissions that can be assigned to customizable groups. Groups can then be assigned to (or removed from) users through the Special:Userrights interface in the wiki software. See Help:Assigning permissions.
Access to this interface is itself governed by the 'userrights' right, so only users in the 'bureaucrat' group can do it (in a default set-up). See Manual:Setting user groups in MediaWiki for information about managing and the assignment of user groups.
This Special:UserRights interface was introduced in MediaWiki 1.5; see Manual:User rights (older versions) for earlier methods.
[http://www.mediawiki.org/wiki/Help:User_rights]
_Management:
* from: http://localhost/wiki/Special:UserRights,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Security_for_developers,
* http://www.mediawiki.org/wiki/Manual:Security,
* http://www.mediawiki.org/wiki/Manual:Securing_database_passwords,
_Report:
security issues are reported to security@wikimedia.org.
[http://www.mediawiki.org/wiki/Developer_hub]
name::
* McsEngl.mw'right.Editing@cptIt,
How do I stop anonymous users from editing any page?
Set $wgGroupPermissions['*']['edit'] = false; at bottom of LocalSettings.php.
See Manual:Preventing access#Restrict anonymous editing for more information.
[http://www.mediawiki.org/wiki/Manual:FAQ]
name::
* McsEngl.mw'right.Page-single@cptIt,
If you need per-page or partial page access restrictions, you are advised to install an appropriate content management package. MediaWiki was not written to provide per-page access restrictions, and almost all hacks or patches promising to add them will likely have flaws somewhere, which could lead to exposure of confidential data. We are not responsible for anything being leaked, leading to loss of funds or one's job.
For further details, see Security issues with authorization extensions
[http://www.mediawiki.org/wiki/Extension:NamespacePermissions]
_SPECIFIC:
* administrator,
* bot,
* bureaucrat,
* coder,
* creator,
* developer,
* editor,
* importer,
* steward,
* transwiki importer,
* user-anonymous,
* user-autoconfirmed,
* user-registered,
List of Groups
The following groups are available in the latest version of MediaWiki. If you are using an older version then some of these may not be implemented.
Group Description Versions
* all users (including anonymous). 1.5+
user registered accounts. 1.5+
autoconfirmed registered accounts at least as old as $wgAutoConfirmAge and having at least as many edits as $wgAutoConfirmCount. 1.6+
emailconfirmed registered accounts with confirmed email addresses. 1.7 - 1.13
bot accounts with the bot right (intended for automated scripts). 1.5+
sysop users who by default can delete and restore pages, block and unblock users, et cetera. 1.5+
bureaucrat users who by default can change other users' rights. 1.5+
developer A group for the 'siteadmin' right. The group is deprecated by default, as well as the right. 1.5
From MW 1.12, you can create your own groups into which users are automatically promoted (as with autoconfirmed and emailconfirmed) using $wgAutopromote.
[http://www.mediawiki.org/wiki/Help:User_rights]
name::
* McsEngl.mw'Active-user@cptIt,
_DESCRIPTION:
Active users (list of members)
(Users who have performed an action in the last 30 days)
[http://www.mediawiki.org/wiki/Special:Statistics]
name::
* McsEngl.mw'Anonymous-user@cptIt,
* McsEngl.mw'human.Anonymous@cptIt,
name::
* McsEngl.mw'Autoconfirmed-user@cptIt,
Accounts which are more than four days old are automatically promoted to the 'autoconfirmed' group. Autoconfirmed users may move pages, edit semi-protected pages, and upload files or upload a new version of an existing file. They are no longer required to enter a CAPTCHA.
[http://www.mediawiki.org/wiki/Project:Autoconfirmed_users]
name::
* McsEngl.mw'Bureaucrat@cptIt,
* McsEngl.mw'human.Bureaucrat@cptIt,
By default, you will need to be a 'Bureaucrat' (in the 'Bureaucrat' group) before you can access the Special:UserRights page. The first user created when setting up a MediaWiki installation is a bureaucrat. Other users can always contact one of the bureaucrats to request a change of permissions. Find out who these people are at Special:ListUsers/bureaucrat. In a small wiki there might typically be only one such user or maybe two.
[http://www.mediawiki.org/wiki/Help:Assigning_permissions]
name::
* McsEngl.mw'Coder@cptIt,
* McsEngl.mw'human.Coder@cptIt,
A coder is a user who has the technical functions to:
Alter revisions by adding and removing tags (codereview-add-tag; codereview-remove-tag)
Change revisions status (codereview-set-status)
Link commiters to wiki users (codereview-link-user)
In addition, coders can make new coders.
The user group is somewhat tied to Developers (not a wiki user group).
[http://www.mediawiki.org/wiki/Project:Coder]
name::
* McsEngl.mw'Editor-user@cptIt,
* McsEngl.mw'human.Editor@cptIt,
_DESCRIPTION:
Users in editor group can:
Edit semi-protected pages (autoconfirmed)
Have one's own edits automatically marked as "checked" (autoreview)
Mark revisions as being "checked" (review)
View recent changes patrol marks (patrolmarks)
View the list of unreviewed pages (unreviewedpages)
[http://www.mediawiki.org/wiki/Project:Editor]
name::
* McsEngl.mw'Importer@cptIt,
Importers are users with the technical ability to:
* "Transwiki" pages from meta to MediaWiki, preserving page history.
* Import pages via file upload to MediaWiki, preserving page history.
[http://www.mediawiki.org/wiki/Project:Importers]
===
Transwiki Importers are users who have been granted the transwiki importer permission. These users have the technical capability to "transwiki" pages from meta to MediaWiki, preserving the edit history.
[http://www.mediawiki.org/wiki/Project:Transwiki_importers]
name::
* McsEngl.mw'Logged-in-user@cptIt,
* McsEngl.mw'signed-in-user@cptIt,
* McsEngl.mw'human.signed-in@cptIt,
Signed-in privileges
Users with ordinary access, including visitors who haven't "signed in", can still do many things, including the most important: editing pages and helping with maintenance tasks. But only signed-up users can upload files or rename pages.
[http://www.mediawiki.org/wiki/Manual:Administrators]
name::
* McsEngl.mw'Moderator@cptIt,
* McsEngl.mw'human.Moderator@cptIt,
name::
* McsEngl.mw'Oversighter@cptIt,
* McsEngl.mw'human.Oversighter@cptIt,
_DESCRIPTION:
Oversight or suppression refer to hiding revisions, user names in edit histories and logs, or portions of individual log entries. This access is available to oversighters (those in the 'oversight' or 'stewards' user groups). Oversighted data can only be viewed and restored by oversighters.
[http://meta.wikimedia.org/wiki/Oversight]
name::
* McsEngl.mw'Reader@cptIt,
* McsEngl.mw'human.Reader@cptIt,
name::
* McsEngl.mw'Reviewer@cptIt,
* McsEngl.mw'human.Reviewer@cptIt,
Users in editor group can:
Edit semi-protected pages (autoconfirmed)
Have one's own edits automatically marked as "checked" (autoreview)
Mark revisions as being "checked" (review)
View recent changes patrol marks (patrolmarks)
View the list of unreviewed pages (unreviewedpages)
Reviewers additionally can:
Mark revisions as being "quality" (validate)
[http://www.mediawiki.org/wiki/Project:Reviewer]
name::
* McsEngl.mw'Steward@cptIt,
Stewards are users with complete access to the wiki interface on all Wikimedia wikis, including the ability to change any and all user rights and groups. They are tasked with technical implementation of community consensus, and dealing with emergencies (for example, cross-wiki vandalism). Stewards aim to make no decisions as stewards, but are empowered to act as a member of any permissions group on any project with no active member of that permissions group. For example: wikis without administrators may call upon stewards to fulfill that role; stewards will act as a bureaucrat as needed on wikis without bureaucrats.
[http://meta.wikimedia.org/wiki/Stewards]
name::
* McsEngl.mw'SVN-admin@cptIt,
This is a user group for people who manage our CodeReview setup.
[http://www.mediawiki.org/wiki/Project:SVN_admins]
name::
* McsEngl.mw'Sysop@cptIt,
* McsEngl.mw'human.Sysop@cptIt,
Wiki sysops (sometimes called "administrators" too) can edit site-wide gadgets, JavaScript and CSS settings.
[http://www.mediawiki.org/wiki/Manual:MediaWiki_architecture#Levels]
Promoting users to Sysops and Bureaucrats
The Special:UserRights page allows you (if you have access) to set which groups a user is in. A common task would be to put a user into the 'Sysop' group. This will grant the user various extra rights, such as deleting pages, and blocking users. See Help:Sysops and permissions for more details.
Obviously giving a user such rights implies that you trust the user, both in terms of being non-malicious, and also as somebody with sufficient competence in using the wiki software, and in dealing with the wiki community. People hoping to become sysops should read Help:Sysops and permissions. However it should be noted that actions of a sysop user are (almost) entirely reversible, by other sysop users, and so it can be a good idea to dish out these extra permissions to a number of users in order to
spread the workload of day-to-day sysop operations such as blocking vandals and deleting pages.
make things more democratic, and decrease any perception of a single dictator running the community
allow competent users the power they need to make progress with wiki refactoring.
reward valued contributors/community members
[http://www.mediawiki.org/wiki/Help:Assigning_permissions]
MediaWiki can read and apply site-wide or skin-wide JavaScript and CSS using custom wiki pages; these pages are in the MediaWiki: namespace, and thus can only be edited by sysops; for example, JavaScript modifications from MediaWiki:Common.js apply to all skins, CSS from MediaWiki:Common.css applies to all skins, but MediaWiki:Vector.css only applies to users with the Vector skin.
[http://www.mediawiki.org/wiki/Manual:MediaWiki_architecture#JavaScript_and_CSS]
name::
* McsEngl.mw'Administrator@cptIt,
* McsEngl.mw'human.Administrator@cptIt,
Administrators are wiki users who are members of the "sysop" user group. The wiki software has few features whose use is restricted, but they are quite important.
[http://www.mediawiki.org/wiki/Manual:Administrators]
name::
* McsEngl.mw'System-admin@cptIt,
* McsEngl.mw'human.System-admin@cptIt,
name::
* McsEngl.mw'User (non-developer)@cptIt,
* McsEngl.mw'end-user@cptIt,
* McsEngl.mw'human.user@cptIt,
* McsEngl.mw'non-developer@cptIt,
name::
* McsEngl.mw'user'Interface@cptIt,
Users can do the same types of changes, which will only apply to their own interface, by editing subpages of their user page (e.g. User:<Username>/common.js for JavaScript on all skins, User:<Username>/common.css for CSS on all skins, or User:<Username>/vector.css for CSS modifications that only apply to the Vector skin).
[http://www.mediawiki.org/wiki/Manual:MediaWiki_architecture#JavaScript_and_CSS]
name::
* McsEngl.mw'Crocker-Lee-Daniel@cptIt,
* McsEngl.Crocker.Lee.Daniel@cptIt,
* McsEngl.mw'Eloquence-user@cptIt,
_DESCRIPTION:
* He rewrote MediaWiki of Manske in PHP because of loading problems.
_ADDRESS.WPG:
* http://en.wikipedia.org/wiki/User:Lee_Daniel_Crocker,
name::
* McsEngl.mw'Dauw-Jeroen-De@cptIt,
* McsEngl.Daw.Jereon.De@cptIt,
Extensions I've created:
Maps · Semantic Maps · Validator · Awesomeness · Push · Live Translate · SubPageList · Include WP · Semantic Watchlist · Spark · Survey · Contest · Semantic Image Input · Education Program
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/User:Jeroen_De_Dauw,
name::
* McsEngl.mw'Liambotis.Faidon@cptIt,
* McsEngl.Liambotis.Faidon@cptIt,
name::
* McsEngl.mw'Manske.Magnus@cptIt,
* McsEngl.Manske.Magnus@cptIt,
_DESCRIPTION:
Magnus Manske has a PhD in biochemistry, and is currently employed at the Sanger Institute in Cambridge. He is the original author of the PHP script which evolved into the MediaWiki software and was a very active participant on Nupedia, as an author of many biology articles, as a coder, and as one of the first and most active participants on the Nupedia Chalkboard.
[http://en.wikipedia.org/wiki/User:Magnus_Manske]
_ADDRESS.WPG:
* http://en.wikipedia.org/wiki/User:Magnus_Manske,
name::
* McsEngl.mw'Moeller-Eric@cptIt,
_Work:
* Moeller.Eric,
* omegaWiki,
* Wikimedia Foundation,
_Email:
* moeller AT scireview DOT de,
* erik (at) wikimedia (dot) org,
_ADDRESS.WPG:
* http://en.wikipedia.org/wiki/Erik_M%C3%B6ller,
* http://www.humanist.de/erik//
* http://meta.wikimedia.org/wiki/User:Eloquence,
* http://www.omegawiki.org/User:Eloquence,
_DESCRIPTION:
Erik Mφller is a German freelance journalist,[1] software developer,[2] author, and Deputy Director of the Wikimedia Foundation (WMF), based in San Francisco, California.[3] Mφller additionally works as a web designer and previously managed his own web hosting service, myoo.de.
[http://en.wikipedia.org/wiki/Erik_M%C3%B6ller]
===
Erik-Moeller#ql:mw'moeller_eric#, currently lead developer of OmegaWiki and chief architect of Wikidata. I use this administrative account for technical operations related to OmegaWiki development. My account as a regular editor is User:Eloquence, and is subject to whatever community processes and policies are developed here.
[http://www.omegawiki.org/User:Admin]
name::
* McsEngl.mw'Parscal-Trevor@cptIt,
* McsEngl.Parscal.Trevor@cptIt,
_Work:
* WikiEditor,
* Vector skin,
* VisualEditor,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/User:Trevor_Parscal,
* http://www.mediawiki.org/wiki/Special:Code/MediaWiki/author/tparscal,
* http://www.trevorparscal.com//
_DESCRIPTION:
Trevor Parscal has been a software developer at the WikiMedia Foundation since 2008.
[http://www.mediawiki.org/wiki/User:Trevor_Parscal]
name::
* McsEngl.mw'Reed-Sam@cptIt,
* McsEngl.Reed.Sam@cptIt,
name::
* McsEngl.mw'Starling-tim@cptIt,
* McsEngl.Starling.Tim@cptIt580.4i, {2012-03-28}
* McsEngl.tim-starling@cptIt580.4i, {2012-03-28}
_ATTRIBUTE:
name: Tim Starling
email: tstarling@wikimedia.org
url: http://en.wikipedia.org/wiki/User:Tim_Starling
aliases: timstarling
_DESCRIPTION:
Tim Starling, as lead developer, is usually the one to grant commit access.
[http://www.mediawiki.org/wiki/Developers]
name::
* McsEngl.mw'Synagonism-user@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki&author=synagonism,
106431 ok -
/USERINFO/synagonism
minor synagonism 14:11, 16 December 2011
106341 new 1
/trunk/extensions/skins/Synagonism
Add Synagonism skin synagonism 17:28, 15 December 2011
106338 ok 1
/USERINFO/synagonism
Adding my USERINFO file synagonism 17:09, 15 December 2011
name::
* McsEngl.mw'Tsiodras.thanasis@cptIt,
* McsEngl.Tsiodras.Thanasis@cptIt,
_Address:
* https://plus.google.com/100429936881221995531/about,
_Work:
Jonathan Boler galatians@gmail.com via lists.wikimedia.org
I now have the latest dump of the whole English Wikipedia running
locally on my laptop using this:
http://users.softlab.ece.ntua.gr/~ttsiod/buildWikipediaOffline.html
name::
* McsEngl.mw'License@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Project:PD_help,
* http://www.mediawiki.org/wiki/Category:Policy,
name::
* McsEngl.mw'Namespace@cptIt,
* McsEngl.mw'content.namespace@cptIt,
* McsEngl.mw'data.namespace@cptIt,
_GENERIC:
* mw-data#ql:mw'data_content#,
* mw-page-collection#ql:mw'page.collection#
_DESCRIPTION:
A namespace is a collection of pages which have content with a similar purpose, i.e. pages where the intended use is the same. Namespaces can be thought of as partitions of different types of information within the same wiki, and keep "real" content separate from user profiles, help pages, etc.
[http://www.mediawiki.org/wiki/Manual:Namespace]
===
The concept of namespaces is similar to programming language namespaces and more generally computer file folders. Namespaces allow information that would be otherwise disorganized, to be neatly separated into compartments. But the analogy doesn't go very far - there are many things you can do to a folder, which you cannot do to a namespace. You can watch for changes in a namespace, for example, but you cannot easily list its contents. In addition to organizing content for human recognition, there are also machine-driven activities, such as Wikipedia server mirroring, that distinguish among namespaces.
===
The concept of namespaces was used in the UseModWiki era of Wikipedia, where talk pages where at the title "<article name>/Talk". Namespaces were formally introduced in Magnus Manske's first "PHP script". They were reimplemented a few times over the years, but have kept the same function: to separate different kinds of content. They consist of a prefix, separated from the page title by a colon (e.g. Talk: or File: and Template:); the main content namespace has no prefix. Wikipedia users quickly adopted them, and they provided the community with different spaces to evolve. Namespaces have proven to be an important feature of MediaWiki, as they create the necessary preconditions for a wiki's community and set up meta-level discussions, community processes, portals, user profiles, etc.
The default configuration for MediaWiki's main content namespace is to be flat (no subpages), because it's how Wikipedia works, but it is trivial to enable them. They are enabled in other namespaces (e.g. User:, where people can for instance work on draft articles) and display breadcrumbs.
Namespaces separate content by type; within a same namespace, pages can be organized by topic using categories, a pseudo-hierarchical organization scheme introduced in MediaWiki 1.3.
[http://www.mediawiki.org/wiki/MediaWiki_architecture_document/text/revision_2]
name::
* McsEngl.mw'namespace'Code@cptIt,
* McsEngl.mw'ns'code@cptIt,
mw'file.Namespace.php, ../includes/
* mw'class.MWNamespace: http://svn.wikimedia.org/doc/classMWNamespace.html,
mw'file.namespaceDupes.php, ../maintenance/
mw'file.no-namespace.result.php, ../tests/phpunit/data/xmp/
mw'file.MWNamespaceTest.php, ../tests/phpunit/includes/
_Extension:
* namespace-extension#ql:mw'extension.namespace#
_API:
* http://www.mediawiki.org/w/api.php?action=query&meta=siteinfo&siprop=namespaces,
name::
* McsEngl.mw'ns'Configuration@cptIt,
* McsEngl.mw'configuring.namespace@cptIt,
* McsEngl.mw'namespace'configuration@cptIt,
* McsEngl.mw'namespace'configuring@cptIt,
_WHOLE:
* mw-configuration#ql:mw'configuring#
Namespaces
$wgContentNamespaces - Namespaces which are considered to contain real content, or articles.
$wgExtraNamespaces - Additional namespaces.
$wgExtraGenderNamespaces - Same as $wgExtraNamespaces, but for namespaces with gender distinction.
$wgMetaNamespace - The name used for the meta-namespace.
$wgMetaNamespaceTalk - The name used for the meta-namespace talk pages.
$wgNamespaceAliases - Additional names for namespaces.
$wgNamespaceProtection - Default protection levels for namespaces.
$wgNamespacesToBeSearchedDefault - Which namespaces should be searched?
$wgNamespacesToBeSearchedHelp - Namespaces to be searched when user clicks the "Help" tab on Special:Search.
$wgNamespacesToBeSearchedProject (deprecated) - Additional namespaces that will be added to default search for "project".
$wgNamespacesWithSubpages - Which namespaces should support subpages?
$wgNoFollowNsExceptions - Namespaces where the nofollow setting ($wgNoFollowLinks) is overridden.
$wgNonincludableNamespaces - Pages in namespaces in this array can not be used as templates.
$wgPreviewOnOpenNamespaces - Namespaces that have special treatment where they should be preview-on-open.
$wgSitemapNamespaces - Array of namespaces to generate a sitemap or false for all namespaces.
$wgSitemapNamespacesPriorities - Custom namespace priorities for sitemaps.
[http://www.mediawiki.org/wiki/Manual:Configuration_settings#Namespaces]
name::
* McsEngl.mw'namespace'Creating@cptIt,
_DESCRIPTION:
Note that these are only default namespaces. All extensions defining new namespaces should take care to provide the installer with a method of configuring the extension to use a different range of namespaces for it's custom namespaces.
[http://www.mediawiki.org/wiki/Namespace_registration]
name::
* McsEngl.mw'namespace'Detecting@cptIt,
_ADDRESS.WPG:
* http://meta.wikimedia.org/wiki/Help:Namespace#CSS_based_namespace_detection,
name::
* McsEngl.mw'namespace'Evolution@cptIt,
In a future version, namespaces in MediaWiki can be configured, added and deleted using a special page, Special:Namespaces.
[http://www.mediawiki.org/wiki/Namespace_manager]
name::
* McsEngl.mw'namespace'Deleting@cptIt,
Deleting namespaces
Because MediaWiki relies on the presence of system namespaces like "File" and "Category" throughout the code, these cannot be deleted. Only non-system namespaces which do not contain pages can be deleted through the namespace manager. This is to ensure that any deletions are easily reversible.
[http://www.mediawiki.org/wiki/Namespace_manager]
name::
* McsEngl.mw'namespace'Index@cptIt,
* McsEngl.mw'namespace'number@cptIt,
* McsEngl.mw'namespace'id@cptIt,
_DESCRIPTION:
Each namespace has a corresponding namespace index. Within the database, the title is split into namespace index and text title, and this is used for storage in the page.page_namespace and page.page_title columns, among others.
[http://www.mediawiki.org/wiki/Manual:Namespace]
Variables Alternate syntax Name, linked to list of all such pages Nr. of pages
(see note above) Notes
{{ns:-2}} {{ns:media}} "Media" pseudo-namespace for images and other files themselves, as opposed to the image description pages; see also below
{{ns:-1}} {{ns:special}} "Special" pseudo-namespace for special pages (list: Special:SpecialPages)
{{ns:0}} main disabled main namespace, no prefix, or optionally a colon (this is needed when using the page as template)
{{ns:1}} {{ns:talk}} Talk disabled see Help:Talk page for this and the following odd-numbered namespaces
{{ns:2}} {{ns:user}} User disabled registered users (list: Special:ListUsers) have a user homepage User:username (linked to by the system from user names in lists of edits, e.g. on page histories, and from signatures on talk pages); this and subpages of it can be used to present oneself, for project-related bookmarks, and for drafts, tests, and other working material. One can put here material to give oneself one-step access to it from any page in the same project, and one can put here links to give oneself two-step access to the link targets from any page in the same project as the user page. For users who do not log in, the same applies, with the IP as username. Dynamic IPs are a complication.
{{ns:3}} {{ns:user_talk}} User talk disabled
{{ns:4}} {{ns:project}} Meta disabled the project namespace for matters about the project, such as guidelines and discussions; see also the [[Help:|Help:]] namespace
{{ns:5}} {{ns:project_talk}} Meta talk disabled
{{ns:6}} {{ns:file}} File disabled images and other uploaded files, with image description pages (list: Special:ListFiles)
{{ns:7}} {{ns:file_talk}} File talk disabled
{{ns:8}} {{ns:mediawiki}} MediaWiki disabled system messages (list: Special:AllMessages), editable by users, or if protected, by sysops
{{ns:9}} {{ns:mediawiki_talk}} MediaWiki talk disabled
{{ns:10}} {{ns:template}} Template disabled the default namespace for templates: the wikitext code {{name }} refers to and includes the page Template:name
{{ns:11}} {{ns:template_talk}} Template talk disabled
{{ns:12}} {{ns:help}} Help disabled typically used for the MediaWiki User's Guide, with the wikitext a frequently refreshed copy of the master version on Meta-Wikipedia, but with project-specific templates
{{ns:13}} {{ns:help_talk}} Help talk disabled
{{ns:14}} {{ns:category}} Category disabled each page (list: Special:Categories) represents a category of pages, with each category page displaying a list of pages in that category and optional additional text.
{{ns:15}} {{ns:category_talk}} Category talk disabled
...
Custom namespaces are numbered from 100,
[http://meta.wikimedia.org/wiki/Help:Namespace]
Semantic MediaWiki & Semantic Forms
100 Relation: (constant: SMW_NS_RELATION; no longer used, as of version 1.0; support dropped with 1.5.0)
101 Relation_talk: (constant: SMW_NS_RELATION_TALK; no longer used, as of version 1.0; support dropped with 1.5.0)
102 Property: (constant: SMW_NS_PROPERTY)
103 Property_talk: (constant: SMW_NS_PROPERTY_TALK)
104 Type: (constant: SMW_NS_TYPE; no longer used, as of version 1.6.0; still supported)
105 Type_talk: (constant: SMW_NS_TYPE_TALK; no longer used, as of version 1.6.0; still supported)
106 Form: (constant: SF_NS_FORM)
107 Form_talk: (constant: SF_NS_FORM_TALK)
108 Concept: (constant: SMW_NS_CONCEPT)
109 Concept_talk: (constant: SMW_NS_CONCEPT_TALK)
[http://www.mediawiki.org/wiki/Namespace_registration]
_Number:
mw'ns.2minus.Media,
mw'ns.1minus.Special,
mw'ns.0.main.
mw'ns.1.Talk.
mw'ns.2.User#ql:mw'namespace.user#.
mw'ns.4.project|Meta#ql:mw'namespace.project#,
mw'ns.6.File.
mw'ns.8.MediaWiki.
mw'ns.10.Template.
mw'ns.12.Help.
mw'ns.14.Category.
mw'ns.100.Relation:
mw'ns.102.Property:
mw'ns.104.Type: (no longer used, as of version 1.6.0; still supported)
mw'ns.106.Form:
mw'ns.108.Concept:
name::
* McsEngl.mw'namespace'Constant@cptIt,
_SPECIFIC:
-1 Special NS_SPECIAL Holds special pages
-2 Media NS_MEDIA Alias for direct links to media files
0 Main NS_MAIN "Real" content; articles Has no prefix
1 Talk NS_TALK Talk pages of "Real" content
2 User NS_USER User pages
3 User talk NS_USER_TALK Talk pages for User Pages
4 Project NS_PROJECT Info about wiki same as $wgMetaNamespace[1]
5 Project talk NS_PROJECT_TALK
6 File NS_FILE Media description pages
7 File talk NS_FILE_TALK
8 MediaWiki NS_MEDIAWIKI Site interface customisation Protected
9 MediaWiki talk NS_MEDIAWIKI_TALK
10 Template NS_TEMPLATE Template pages
11 Template talk NS_TEMPLATE_TALK
12 Help NS_HELP Help pages
13 Help talk NS_HELP_TALK
14 Category NS_CATEGORY Category description pages
15 Category talk NS_CATEGORY_TALK
100 Relation: (constant: SMW_NS_RELATION; no longer used, as of version 1.0; support dropped with 1.5.0)
101 Relation_talk: (constant: SMW_NS_RELATION_TALK; no longer used, as of version 1.0; support dropped with 1.5.0)
102 Property: (constant: SMW_NS_PROPERTY)
103 Property_talk: (constant: SMW_NS_PROPERTY_TALK)
104 Type: (constant: SMW_NS_TYPE; no longer used, as of version 1.6.0; still supported)
105 Type_talk: (constant: SMW_NS_TYPE_TALK; no longer used, as of version 1.6.0; still supported)
106 Form: (constant: SF_NS_FORM)
107 Form_talk: (constant: SF_NS_FORM_TALK)
108 Concept: (constant: SMW_NS_CONCEPT)
109 Concept_talk: (constant: SMW_NS_CONCEPT_TALK)
name::
* McsEngl.mw'namespace'Name@cptIt,
* McsEngl.mw'namespace'Prefix@cptIt,
_DESCRIPTION:
Pages exist within a namespace, and this can be distinguished using the namespace prefix of a page, which forms part of the title of a page, separated with a colon (:).
For example:
Title Namespace
Foo Main
Project:Foo Project
Help:Foo Help
Namespace prefixes can be translated, and aliases can be configured for each (see $wgNamespaceAliases). All namespaces also have a "canonical" prefix, which works on all wikis regardless of configuration. Aliases and canonical names can be used in links, when performing a search, and in the page title with the help of the {{DISPLAYTITLE}} magic word.
[http://www.mediawiki.org/wiki/Manual:Namespace]
===
Be careful not to choose namespace name identifiers too long as the standard limit in Mediawiki is 16characters long.
[http://www.mediawiki.org/wiki/Extension:HNP]
===
Do not use space
Use underscores instead of spaces in namespace names. 'My Namespace' is an invalid name; use 'My_Namespace' instead.
[http://www.mediawiki.org/wiki/Manual:$wgNamespaceAliases]
- mw'magicword.DISPLAYTITLE:
* mw'DISPLAYTITLE_magicword,
Aliases and canonical names can be used in links, when performing a search, and in the page title with the help of the {{DISPLAYTITLE}} magic word.
* on 1.19 does not work. {2012-02-07}
name::
* McsEngl.mw'namespace'Canonical-name@cptIt,
All namespaces also have a "canonical" prefix, which works on all wikis regardless of configuration.
[http://www.mediawiki.org/wiki/Manual:Namespace]
name::
* McsEngl.mw'namespace'Alias-name@cptIt,
Namespace aliases
On some wikis there are also namespace aliases: alternative names that will also be resolved to the localised names. For instance, a wiki might define "T" as an alias for Template, such that typing T:Foo is equivalent to Template:Foo, saving a few characters and seconds. An actual example would be on the English Wikipedia, where "WP" is an alias for Project, which is the namespace "Wikipedia". By default, "Image" is an alias for File, so [[Image:Wiki.png]] is equivalent to [[File:Wiki.png]].
[http://www.mediawiki.org/wiki/Help:Namespace]
_ mw'wgNamespaceAliases:
To add a single alias:
$wgNamespaceAliases['WP'] = NS_PROJECT;
[http://www.mediawiki.org/wiki/Manual:$wgNamespaceAliases]
name::
* McsEngl.mw'namespace'Localized-name@cptIt,
* McsEngl.mw'namespace'translated-name@cptIt,
name::
* McsEngl.mw'namespace'Page@cptIt,
Pages can be moved between namespaces simply by changing the prefix part of their title.
[http://www.mediawiki.org/wiki/Manual:Namespace]
name::
* McsEngl.mw'namespace'Resource@cptIt,
_SPECIFIC:
* http://www.mediawiki.org/wiki/Manual:Namespace,
* http://www.mediawiki.org/wiki/Manual:Using_custom_namespaces,
* http://www.mediawiki.org/wiki/Help:Namespace,
* http://www.mediawiki.org/wiki/Namespace_manager,
* http://www.mediawiki.org/wiki/Extension:SpecialNamespaces,
* http://www.mediawiki.org/wiki/Extension:CrossNamespaceLinks,
* http://www.mediawiki.org/wiki/Category:Namespace_extensions,
* http://www.mediawiki.org/wiki/Category:Namespace_variables,
name::
* McsEngl.mw'namespace'Usage@cptIt,
* McsEngl.mw'namespace'purpose@cptIt,
_DESCRIPTION:
The namespace-mechanism, classifies pages (not explicited stated) with part-whole-relations.
[hmnSngo.2012-12-24]
===
Generally, namespaces should not be used to categorize content of the same type -- that is what categories are for.
...
So, when should you create a custom namespace? Essentially, if you have a type of content which you feel is substantially different from the content in the existing namespaces, you may want to consider creating a new namespace. In the world of the Wikimedia projects, for example, several wikis have a "Portal" namespace for entry pages to particular topics. In Wikibooks, there is a "Cookbook" namespace, because unlike other Wikibooks, cookbooks consist of many hundreds of separate recipe pages. On Meta, there are "Help" namespaces for the MediaWiki documentation in different languages.
Namespaces are also a core component of the Wikidata project, which is under active development. In the context of Wikidata, they are intended to segregate different types of structured content, such as person data, country information, music albums, etc.
[http://www.mediawiki.org/wiki/Namespace_manager]
===
Namespaces allow, among other things, a separation of content from policy and discussion. They encourage separation of the pages of a wiki into a core set intended for public viewing, and private information intended for the editing community.
[http://meta.wikimedia.org/wiki/Help:Namespaces]
_SPECIFIC:
* built-in--namespace,
* custom-namespace,
===
* talk-namespace,
* non-talk--namespace,
===
* content-namespace#ql:mw'namespace.content#,
* non-content--namespace,
===
Like all wikis using the MediaWiki software, Wikipedia has eighteen built-in namespaces: the main namespace, where page names have no prefix, and seventeen auxiliary types, each with its own prefix. In addition, there are two custom namespaces, with their own prefixes.
1 Basic namespaces
* 1.1 Main
* 1.2 Wikipedia (Project)
* 1.3 Portal
* 1.4 User
* 1.5 Image
* 1.6 MediaWiki
* 1.7 Template
* 1.8 Category
* 1.9 Help
name::
* McsEngl.mw'namespace.Built-in@cptIt,
* McsEngl.mw'built-in-namespace@cptIt,
* McsEngl.mw'defaul-namespace@cptIt,
* McsEngl.mw'namespace.default@cptIt,
* McsEngl.mw'namespace.standard@cptIt,
* McsEngl.mw'standard-namespace@cptIt,
* McsEngl.mw'system-namespace@cptIt,
Built-in namespaces
MediaWiki ships with 18 built-in namespaces.
The following 8 namespaces all have associated discussion namespaces.
Index Name Constant Purpose Comments
0 Main NS_MAIN "Real" content; articles Has no prefix
1 Talk NS_TALK Talk pages of "Real" content
2 User NS_USER User pages
3 User talk NS_USER_TALK Talk pages for User Pages
4 Project NS_PROJECT Information about the wiki Prefix is the same as $wgMetaNamespace[1]
5 Project talk NS_PROJECT_TALK
6 File NS_FILE Media description pages
7 File talk NS_FILE_TALK
8 MediaWiki NS_MEDIAWIKI Site interface customisation Protected
9 MediaWiki talk NS_MEDIAWIKI_TALK
10 Template NS_TEMPLATE Template pages
11 Template talk NS_TEMPLATE_TALK
12 Help NS_HELP Help pages
13 Help talk NS_HELP_TALK
14 Category NS_CATEGORY Category description pages
15 Category talk NS_CATEGORY_TALK
2 other namespaces have negative indexes and have special purposes. You cannot create or delete pages in these namespaces, and there are no corresponding discussion namespaces.
Index Name Constant Purpose
-1 Special NS_SPECIAL Holds special pages
-2 Media NS_MEDIA Alias for direct links to media files
[http://www.mediawiki.org/wiki/Manual:Namespace]
name::
* McsEngl.mw'namespace.Category (14)@cptIt,
* McsEngl.mw'category-namespace@cptIt,
_GENERIC:
* builtIn-namespace#ql:mw'namespace.built_in#
_DESCRIPTION:
the category namespace (for navigation)
[http://meta.wikimedia.org/wiki/Help:Namespaces]
name::
* McsEngl.mw'namespace.Content@cptIt,
* McsEngl.mw'content-namespace@cptIt,
Content namespaces
When building the site statistics page (see Special:Statistics), MediaWiki uses values stored in the database to calculate certain totals. One particular total is the "number of articles" or "number of content pages" figure.
For a page to be considered an article, or proper content, it must:
- Be in the main namespace, or a defined content namespace
- Not be a redirect page
- Contain at least one internal link
When creating custom namespaces to hold additional content, it is a good idea to indicate this in the configuration. This is done via the $wgContentNamespaces configuration directive.
To extend the example above, one might add the following to LocalSettings.php:
$wgContentNamespaces[] = 500;
MediaWiki will now consider pages in the "Foo" namespace to be articles, if they meet the remaining criteria, and will include them when updating the site statistics counters.
[http://www.mediawiki.org/wiki/Manual:Using_custom_namespaces]
name::
* McsEngl.mw'namespace.Custom@cptIt,
* McsEngl.mw'custom-namespace@cptIt,
_CREATION:
To create a custom namespace, add an appropriate line to LocalSettings.php, e.g.
define("NS_FOO", 500);
define("NS_FOO_TALK", 501);
$wgExtraNamespaces[NS_FOO] = "Foo";
$wgExtraNamespaces[NS_FOO_TALK] = "Foo_talk";# underscore required,
$wgNamespaceProtection[NS_FOO] = array( 'editfoo' );#permission "editfoo" required to edit the foo namespace,
$wgNamespacesWithSubpages[NS_FOO] = true;#subpages enabled for the foo namespace,
$wgGroupPermissions['sysop']['editfoo'] = true;#permission "editfoo" granted to users in the "sysop" group,
[http://www.mediawiki.org/wiki/Manual:Using_custom_namespaces]
_Index:
Custom namespaces are numbered from 100,
[http://meta.wikimedia.org/wiki/Help:Namespace]
name::
* McsEngl.mw'namespace.File (6)@cptIt,
* McsEngl.mw'file-namespace@cptIt,
name::
* McsEngl.mw'namespace.Flat@cptIt,
Project:Flat namespace
This is not an official policy and may only be the view of one user. Discussion is encouraged.
Flat namespaces are easier to navigate
The fewer levels of hierarchy the better when dealing with collaboration
People can't collaborate if they can't find what they are looking for
An encyclopedia is a classic flat namespace. So is a dictionary.
The names of pages in MediaWiki.org are not like the entries in an encyclopedia or dictionary because the topic of MediaWiki is narrow and deep, not shallow and wide. That is, it has few general topics and many more sub-topics. Therefore, keeping a flat, easy-to-navigate page namespace on MediaWiki.org is not as easy as for Wikipedia.org or Wiktionary.org. But it still is important to keep the taxonomic hierarchy on MediaWiki.org as simple as possible and as flat as practical; good management of information complexity helps all users.
Subpages can hurt site usability because they can make it (a) difficult for newcomers to guess where in the hierarchy something can be found and (b) difficult for veteran users to remember and to type the path to a page.
Categories and other labels should be kept as short as possible so paths to a page remain easy to read, to navigate at a glance and to type from memory.
[http://www.mediawiki.org/wiki/Project:Flat_namespace]
name::
* McsEngl.mw'namespace.Help (12)@cptIt,
* McsEngl.mw'help-namespace@cptIt,
* McsEngl.mw'page.help@cptIt,
_GENERIC:
* builtIn-namespace#ql:mw'namespace.built_in#
_DESCRIPTION:
the help pages and the preferences page (as far as they concern viewing)
[http://meta.wikimedia.org/wiki/Help:Namespaces]
name::
* McsEngl.mw'namespace.Main (0)@cptIt,
* McsEngl.mw'article-namespace@cptIt,
* McsEngl.mw'main-namespace@cptIt,
* McsEngl.mw'namespace.article@cptIt,
_GENERIC:
* builtIn-namespace#ql:mw'namespace.built_in#
_DESCRIPTION:
The "main namespace" does not have a prefix. Also, pages in the main namespace cannot have names starting with any of the existing namespaces prefixes followed by a colon.
[http://www.mediawiki.org/wiki/Manual:Namespace]
_PART:
But not all pages in the article namespace are considered to be articles; the most notable exceptions are:
the Main Page;
thousands of disambiguation pages, which are used to resolve naming conflicts;
many millions of redirect pages, including soft redirects, which are used to re-route one page to another page;
for wiki-statistical purposes, some extremely short and simple pages are not counted as articles. The criteria have varied over time.
[http://en.wikipedia.org/wiki/Wikipedia:What_is_an_article%3F]
name::
* McsEngl.mw'namespace.Media (-2)@cptIt,
* McsEngl.mw'media-namespace@cptIt,
name::
* McsEngl.mw'namespace.MediaWiki (8)@cptIt,
* McsEngl.mw'mediaWiki-namespace@cptIt,
name::
* McsEngl.mw'namespace.Project (4)@cptIt,
* McsEngl.mw'namespace.meta@cptIt,
* McsEngl.mw'project-namespace@cptIt,
_GENERIC:
* builtIn-namespace#ql:mw'namespace.built_in#
_DESCRIPTION:
This namespace is normally used for meta-discussions related to the operation and development of the wiki. It has no special properties.
[http://www.mediawiki.org/wiki/Help:Namespaces#4:_Project]
name::
* McsEngl.mw'namespace.Subject (non-talk)@cptIt,
* McsEngl.mw'non-talk-namespace@cptIt,
* McsEngl.mw'subject-namespace@cptIt,
_DESCRIPTION:
a subject (non-talk) namespace.
[http://svn.wikimedia.org/doc/classMWNamespace.html]
_Code.mw:
public static function getSubject( $index ) {
# Handle special namespaces
if( $index < NS_MAIN ) {
return $index;
}
return self::isTalk( $index )
? $index - 1
: $index;
}
name::
* McsEngl.mw'namespace.Special (-1)@cptIt,
* McsEngl.mw'special-namespace@cptIt,
The namespace "Special:" consists of "special pages", which are created by the software on demand, for example Special:Recentchanges.
[http://meta.wikimedia.org/wiki/Help:Namespaces]
name::
* McsEngl.mw'namespace.Talk (+1)@cptIt,
* McsEngl.mw'talk-namespace@cptIt,
name::
* McsEngl.mw'namespace.Template (10)@cptIt,
* McsEngl.mw'template-namespace@cptIt,
name::
* McsEngl.mw'namespace.User (2)@cptIt,
* McsEngl.mw'user-namespace@cptIt,
name::
* McsEngl.mw'Page@cptIt,
_GENERIC:
* mw-code,
* web-page#ql:web'page-19i#
_DESCRIPTION:
A page is data-code (user and programer) or processing-code (some special-pages).
[hmnSngo.2012-01-26]
===
In a web-program everything (presentation and processing) is done through web-pages.
[hmnSngo.2012-02-07]
name::
* McsEngl.mw'page'Address@cptIt,
_Example:
* http://meta.wikimedia.org/wiki/Help:Watching_pages,
* http://www.mediawiki.org/w/index.php?title=Manual:Page%20table
= http://www.mediawiki.org/wiki/Manual:Page_table,
name::
* McsEngl.mw'page'Category@cptIt,
_GENERIC:
* category#ql:mw'category#
_DESCRIPTION:
A page COULD be member of a category.
[hmnSngo.2012-02-06]
name::
* McsEngl.mw'page'Code@cptIt,
_Database:
* page-table#ql:mw'table.page#,
* text-table#ql:mw'table.text#,
* revision-table#ql:mw'table.revision#
_Class:
* mw'class.EditPage, mw'EditPage_class: http://svn.wikimedia.org/doc/classEditPage.html,
* mw'class.WikiPage, mw'WikiPage_class,
_File:
* mw'file.WikiPage.php,
_ mw'class.Page:
- mw'Page_class, do nothing
accepts WikiPage, Article, ImagePage, CategoryPage.
name::
* McsEngl.mw'page'title'code@cptIt,
name::
* McsEngl.mw'file.Title.php-in-includes@cptIt,
name::
* McsEngl.mw'class.Title@cptIt,
_FILE:
\mw19\phase3\includes\Title.php">mw'Title_class, http://svn.wikimedia.org/doc/classTitle.html,
_File:
\mw19\phase3\includes\Title.php">includes\Title.php,
_DESCRIPTION:
Represents the title of an article, and does all the work of translating among various forms such as plain text, URL, database key, etc. For convenience, and for historical reasons, it also represents a few features of articles that don't involve their text, such as access rights. See also title.txt.
[/docs/design.txt]
===
* Title represents the name of a page in the wiki. This is useful because MediaWiki does all sorts of fun escaping and special case logic to page names, so instead of rolling your own convert title to URL function, you create a Title object with your page name, and then use escapeLocalURL() to get a URL to that page.
[edit]Title::makeTitle()
[edit]Title->escapeLocalURL()
[http://www.mediawiki.org/wiki/Manual:Special_pages]
===
title.txt
The MediaWiki software's "Title" class represents article titles, which are used
for many purposes: as the human-readable text title of the article, in the URL
used to access the article, the wikitext link to the article, the key into the
article database, and so on. The class in instantiated from one of these forms
and can be queried for the others, and for other attributes of the title. This
is intended to be an immutable "value" class, so there are no mutator functions.
To get a new instance, call Title::newFromText(). Once instantiated, the
non-static accessor methods can be used, such as getText(), getDBKey(),
getNamespace(), etc. Note that Title::newFromText() may return false if the text
is illegal according to the rules below.
The prefix rules: a title consists of an optional interwiki prefix (such as "m:"
for meta or "de:" for German), followed by an optional namespace, followed by
the remainder of the title. Both interwiki prefixes and namespace prefixes have
the same rules: they contain only letters, digits, space, and underscore, must
start with a letter, are case insensitive, and spaces and underscores are
interchangeable. Prefixes end with a ":". A prefix is only recognized if it is
one of those specifically allowed by the software. For example, "de:name" is a
link to the article "name" in the German Wikipedia, because "de" is recognized
as one of the allowable interwikis. The title "talk:name" is a link to the
article "name" in the "talk" namespace of the current wiki, because "talk" is a
recognized namespace. Both may be present, and if so, the interwiki must
come first, for example, "m:talk:name". If a title begins with a colon as its
first character, no prefixes are scanned for, and the colon is just removed.
Note that because of these rules, it is possible to have articles with colons in
their names. "E. Coli 0157:H7" is a valid title, as is "2001: A Space Odyssey",
because "E. Coli 0157" and "2001" are not valid interwikis or namespaces.
It is not possible to have an article whose bare name includes a namespace or
interwiki prefix.
An initial colon in a title listed in wiki text may however suppress special
handling for interlanguage links, image links, and category links. It is also
used to indicate the main namespace in template inclusions.
Once prefixes have been stripped, the rest of the title processed this way:
* Spaces and underscores are treated as equivalent and each is converted to the
other in the appropriate context (underscore in URL and database keys, spaces
in plain text).
* Multiple consecutive spaces are converted to a single space.
* Leading or trailing space is removed.
* If $wgCapitalLinks is enabled (the default), the first letter is capitalised,
using the capitalisation function of the content language object.
* The unicode characters LRM (U+200E) and RLM (U+200F) are silently stripped.
* Invalid UTF-8 sequences or instances of the replacement character (U+FFFD) are
considered illegal.
* A percent sign followed by two hexadecimal characters is illegal
* Anything that looks like an XML/HTML character reference is illegal
* Any character not matched by the $wgLegalTitleChars regex is illegal
* Zero-length titles (after whitespace stripping) are illegal
All titles except special pages must be less than 255 bytes when encoded with
UTF-8, because that is the size of the database field. Special page titles may
be up to 512 bytes.
Note that Unicode Normal Form C (NFC) is enforced by MediaWiki's user interface
input functions, and so titles will typically be in this form.
getArticleID() needs some explanation: for "internal" articles, it should return
the "page_id" field if the article exists, else it returns 0. For all external
articles it returns 0. All of the IDs for all instances of Title created during
a request are cached, so they can be looked up quickly while rendering wiki text
with lots of internal links. See linkcache.txt.
name::
* McsEngl.mw'class.Article@cptIt,
_FILE:
\mw19\phase3\includes\Article.php">mw'Article_class: extends page,
_ADDRESS.WPG:
* http://svn.wikimedia.org/doc/classArticle.html,
_DESCRIPTION:
Encapsulates access to the "page" table of the database. The object represents a an article, and maintains state such as text (in Wikitext format), flags, etc.
[/docs/design.txt]
===
* Class representing a MediaWiki article and history.
name::
* McsEngl.mw'file.Action.php-in-includes@cptIt,
_DESCRIPTION:
Actions are things which can be done to pages (edit, delete, rollback, etc).
[http://svn.wikimedia.org/doc/Action_8php.html]
_Class:
class Action
class FormAction
class FormlessAction
Actions generally fall into two groups: the show-a-form-then-do-something-with-the-input format (protect, delete, move, etc), and the just-do-something format (watch, rollback, patrol, etc).
[http://svn.wikimedia.org/doc/Action_8php.html]
name::
* McsEngl.mw'page'Doing@cptIt,
_SPECIFIC:
* creating,
* editing,
* deleting,
* rollback,
name::
* McsEngl.mw'page'Creating@cptIt,
* McsEngl.mw'creating-page@cptIt,
name::
* McsEngl.mw'page'editing@cptIt,
* McsEngl.mw'editing-page@cptIt,
Am 04.08.2014 11:47 schrieb "Nkansah Rexford" <nkansahrexford@gmail.com>:
> Hi all,
>
> I'm Rexford, and just posting here for the first time. Please inform if
> this place isn't the right area to suggest features. I was encouraged to
> request features here. Please correct me if I'm wrong.
>
> Its about edit conflict on Wikipedia and other projects. It happens when I
> get into an article to edit, but before I could save, someone else goes
> into the article, edits and save. It happens to myself and many out there.
>
> Sometimes many minutes work of changes can be lost.
>
> The feature request is this: When a person starts editing an article, and
> another person tries to edit that same article, he or she gets a message on
> screen that the article is already engaged. This suggestion is similar to
> how WordPress informs the second person who tries to edit a page whiles
> someone else is already editing.
>
> Its likely one wouldn't like to edit a page when he or she knows someone is
> in it editing. I think its much better that way than allowing multiple
> edits on the page but allowing one persons edit to go in per save.
>
> Thanks.
name::
* McsEngl.mw'page'Evolution@cptIt,
* McsEngl.mw'edit-history@cptIt,
* McsEngl.mw'page'History@cptIt,
* McsEngl.mw'page'Revision@cptIt,
* McsEngl.mw'revision-history@cptIt,
_DESCRIPTION:
The revision table is used for page history and user contributions listings.
[http://www.mediawiki.org/wiki/Manual:Revision_table]
name::
* McsEngl.mw'page'ID@cptIt,
Uniquely identifying primary key. This value is preserved across edits and renames, but not deletion and recreation. For example, for this page, page_id = 10501.
[http://www.mediawiki.org/wiki/Page_id#page_id]
===
There are multiple situations where the page id for one page can change.
...
The primary case where a page id changes is deletion. If someone randomly deletes a page (even if they have no valid reason and it's later undeleted) when it's undeleted it usually comes back with a different page_id. Because deletion is done by deleting the page row and inserting revisions into the archive table.
[https://lists.wikimedia.org/mailman/listinfo/mediawiki-l]
_Code.mw:
Title->getArticleId()
_QUERY:
* http://en.wikipedia.org/wiki?curid=2222222
* http://localhost/mw19/phase3/index.php?curid=22
*http://www.mediawiki.org/w/api.php?action=query&prop=info&titles=Manual:Page%20tabl,
* http://www.mediawiki.org/w/api.php?action=query&prop=info&pageids=10501,
name::
* McsEngl.mw'page'Name@cptIt,
_DESCRIPTION:
A page name is broken into a namespace and a title. The namespace keys are UI-language-independent constants, defined in includes/Defines.php.
[http://www.mediawiki.org/wiki/Page_id]
_PART:
* namespace-of-page#ql:mw'page'namespace#,
* title-of-page#ql:mw'page'title#
_ATTRIBUTE:
FullPageName: Category:Entity
PageName: Entity
BasePageName: Entity
SubPageName: Entity
SubjectPageName: Category:Entity
ArticlePageName: Category:Entity
TalkPageName: Category talk:Entity
===
FullPageName: Category:Entity/Attribute
PageName: Entity/Attribute
BasePageName: Entity/Attribute
SubPageName: Entity/Attribute
SubjectPageName: Category:Entity/Attribute
ArticlePageName: Category:Entity/Attribute
TalkPageName: Category talk:Entity/Attribute
name::
* McsEngl.mw'page'Renaming@cptIt,
* McsEngl.mw'page'moving@cptIt,
Moving (renaming) a page means giving it another name. This is done by using the "move" tab at the top. The tab is not visible if you are not logged in. Then simply enter the new name and click "Move page". Normally you would want to leave the "Move associated talk page" option ticked.
If you move page "A" to a new title "B", this operation will do the following:
Renames the title of page "A" as "B"
Renames all the editing history of page "A" as of page "B" as well
Creates a new page "A", whose content is a redirect to page "B"
[http://www.mediawiki.org/wiki/Help:Moving_a_page]
name::
* McsEngl.mw'page'Synonym@cptIt,
Through the "redirect-pages#ql:mw'page.redirect#".
1) create a new page with the "synonym"
2) put as content:#REDIRECT [[pagename]]
3) clicking on "redirected from ..." in pagename, goes to pagesynonym.
name::
* McsEngl.mw'page'Namespace@cptIt,
_GENERIC:
* namespace#ql:mw'namespace#
_DESCRIPTION:
EVERY page is part of a namespace.
[hmnSngo.2012-02-07]
name::
* McsEngl.mw'page'Table@cptIt,
_SPECIFIC:
* page-table#ql:mw'table.page#,
* page-properties-table#ql:mw'table.page_props#,
* page-restrictions-table#ql:mw'table.page_restrictions#,
* text-table#ql:mw'table.text#
name::
* McsEngl.mw'page'Title@cptIt,
* McsEngl.mw'title-of-page@cptIt,
_WHOLE:
* mw-page's-name#ql:mw'page'name#
_DESCRIPTION:
"title" has 2 meanings: a) ns:xxx b) xxx.
[hmnSngo.2012-02-07]
===
Page titles in MediaWiki are composed of two parts: an optional namespace name, and the remainder of the title. For example, this page has the title Help:Namespace, so it is in the Help namespace. A title without a colon, for example Goings-on, is in the main namespace.
[http://meta.wikimedia.org/wiki/Help:Namespaces]
===
We strongly recommend you do not use special characters in URL. Otherwise search engine may not display that URL correctly.
[http://www.mediawiki.org/wiki/Help:Page_name]
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Help:Bad_title,
_Code.mw:
* title-class#ql:mw'class.title#,
===
in table.page:
"page_id": 56,
"page_namespace": 14,
"page_title": "Entity",
_Global:
Just change $wgLegalTitleChars to a subset that pleases you.
name::
* McsEngl.mw'page'name.Alternative@cptIt,
Alternative names for this page (on most projects) are
- help:page name,
- help:Page name,
- Help:page name and
- Help:Page name,
but not Help:Page Name; the alternative names for this page on this project are the bolded ones.
[http://meta.wikimedia.org/wiki/Help:Page_name]
name::
* McsEngl.mw'page'name.Canonical@cptIt,
The canonical form of a full page name is shown in large font as the page header. Another type of canonical form is what is in URLs generated by the system, for this page "Help:Page_name" with an underscore.
[http://meta.wikimedia.org/wiki/Help:Page_name]
name::
* McsEngl.mw'page'name.Full@cptIt,
The terms "full page name" and "full pagename" include the namespace prefix; the terms "page name" and "pagename" are somewhat ambiguous for pages outside the main namespace as they may or may not include the namespace prefix. To avoid ambiguity one can use "full pagename" and "pagename without namespace prefix".
[http://meta.wikimedia.org/wiki/Help:Page_name]
_SPECIFIC: Alphabetically:
* article-page,
* category-page#ql:mw'page.category#,
* content-page,
* disambiguation-page#ql:mw'page.disambiguation#,
* help-page#ql:mw'page.help#,
* mediawiki-page,
* namespace-page,
* project-page,
* special-page#ql:mw'page.special#,
* subject-page#ql:mw'page.subject#,
* subpage#ql:mw'page.subpage#,
* talk-page#ql:mw'page.talk#,
* template-page#ql:mw'page.template#,
* user-page#ql:mw'page.user#
_SPECIFIC:
(Main) Talk
User User talk
WikiCbs WikiCbs talk
File File talk
MediaWiki MediaWiki talk
Template Template talk
Help Help talk
Category Category talk
name::
* McsEngl.mw'page.Archive@cptIt,
Archive
A subpage of a Talk page to which some parts of the discussion are transferred, to reduce the size of the Talk page. Rarely, the term may refer to the an historical archive page, for outdated historical material related to MediaWiki.
[http://www.mediawiki.org/wiki/Manual:Glossary]
name::
* McsEngl.mw'page.Article@cptIt,
* McsEngl.mw'article-page@cptIt,
* McsEngl.mw'endUser-page@cptIt,
* McsEngl.mw'content-page@cptIt,
* McsEngl.mw'page.content@cptIt,
_WHOLE:
* content-namespace#ql:mw'namespace.content#
_GENERIC:
* mw-data#ql:mw'data#
_DESCRIPTION:
Content namespaces
When building the site statistics page (see Special:Statistics), MediaWiki uses values stored in the database to calculate certain totals. One particular total is the "number of articles" or "number of content pages" figure.
For a page to be considered an article, or proper content, it must:
- Be in the main namespace, or a defined content namespace
- Not be a redirect page
- Contain at least one internal link
When creating custom namespaces to hold additional content, it is a good idea to indicate this in the configuration. This is done via the $wgContentNamespaces configuration directive.
To extend the example above, one might add the following to LocalSettings.php:
$wgContentNamespaces[] = 500;
MediaWiki will now consider pages in the "Foo" namespace to be articles, if they meet the remaining criteria, and will include them when updating the site statistics counters.
[http://www.mediawiki.org/wiki/Manual:Using_custom_namespaces]
===
Content pages
At MediaWiki.org, only the main, manual and extension namespaces are counted as content namespaces.
[http://www.mediawiki.org/wiki/Special:Statistics]
===
An article has a couple of definitions in MediaWiki terms, owing to different opinions about what an article is; some maintain that an article is a page in the article namespace, which is a fair assertion. However, MediaWiki uses a specific definition of an "article" when determining whether or not to include a page in the "content pages" statistic on Special:Statistics.
In MediaWiki terms, an article is a page in the main namespace, or a content namespace (see $wgContentNamespaces) that is not a redirect and contains at least one internal link. When there is embedded an image this counts also as an internal link.
The setting $wgUseCommaCount can be used to change the requirement of having a link and to have a comma.
[http://www.mediawiki.org/wiki/Manual:Article]
===
A Wikipedia article, or entry, is a page that has encyclopedic information on it. A well written encyclopedia article identifies a notable encyclopedic topic, summarizes that topic comprehensively, contains references to reliable sources, will have a reading list, and will link to other related topics.
[http://en.wikipedia.org/wiki/Wikipedia:What_is_an_article%3F]
name::
* McsEngl.mw'file.Article.php-in-includes@cptIt,
name::
* McsEngl.mw'page.Collection@cptIt,
_SPECIFIC:
* category#ql:mw'category#,
* namespace#ql:mw'namespace#
name::
* McsEngl.mw'page.CSS@cptIt,
name::
* McsEngl.mw'page.Data@cptIt,
* McsEngl.mw'data-page@cptIt,
_PART:
* heading,
* image,
* link,
* list,
* paragraph,
* table,
* toc,
name::
* McsEngl.mw'page.JS@cptIt,
name::
* McsEngl.mw'page.Menu@cptIt,
_DESCRIPTION:
Page with drop-down menus.
_Extension:
* http://www.mediawiki.org/wiki/Extension:Chrome_Menu,
name::
* McsEngl.mw'page.Presentation@cptIt,
_DESCRIPTION:
Makes a page, presentation for other pages.
_Extension:
* http://www.mediawiki.org/wiki/Extension:Presentation,
name::
* McsEngl.mw'page.Redirect@cptIt,
* McsEngl.mw'redirect-page@cptIt,
* McsEngl.mw'redirecting@cptIt,
name::
* McsEngl.mw'page.Special@cptIt,
* McsEngl.mw'special-page@cptIt,
_GENERIC:
* extension#ql:mw'extension#
_DESCRIPTION:
Special pages are pages that are created by the software on demand to perform a specific function. For example, a special page might show all pages that have one or more links to an external site or it might create a form providing user submitted feedback. Special pages are located in their own namespace (Special:) and are not editable directly like other pages. Developers can also create new special pages. These pages can be user-accessible and will generally show up in the list of all special pages at Special:SpecialPages. Some special pages are only accessible to users with certain permissions and accesses. Other special pages don't show up on the special page list at all and are only used by the wiki internally.
[http://www.mediawiki.org/wiki/Manual:Special_pages]
_Inheritance:
All special pages inherit from a class called SpecialPage which is defined in includes/SpecialPage.php.
[http://www.mediawiki.org/wiki/Manual:Special_pages]
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Help:Special_pages,
* http://www.mediawiki.org/wiki/Manual:Special_pages,
* http://www.mediawiki.org/wiki/Category:Special_pages,
name::
* McsEngl.mw'page.special'Code@cptIt,
_File:
* mw'file.SpecialPageFactory.php,
name::
* McsEngl.mw'SpecialPage.php@cptIt,
_Class:
class SpecialPage
Parent special page class, also static functions for handling the special page list. More...
class FormSpecialPage
Special page which uses an HTMLForm to handle processing. More...
class UnlistedSpecialPage
Shortcut to construct a special page which is unlisted by default. More...
class IncludableSpecialPage
Shortcut to construct an includable special page. More...
class RedirectSpecialPage
Shortcut to construct a special page alias. More...
class SpecialRedirectToSpecial
class SpecialListAdmins
ListAdmins --> ListUsers/sysop. More...
class SpecialListBots
ListBots --> ListUsers/bot. More...
class SpecialCreateAccount
CreateAccount --> UserLogin/signup. More...
class SpecialMypage
SpecialMypage, SpecialMytalk and SpecialMycontributions special pages are used to get user independant links pointing to the user page, talk page and list of contributions. More...
class SpecialMytalk
Shortcut to construct a special page pointing to current user talk page. More...
class SpecialMycontributions
Shortcut to construct a special page pointing to current user contributions. More...
class SpecialMyuploads
Redirect to Special:Listfiles?user=$wgUser. More...
class SpecialPermanentLink
Redirect from Special:PermanentLink/### to index.php?oldid=###. More...
SpecialPage->execute()
This is the function which your child class should overload. It passes a single parameter, usually referred to cryptically as $par. This parameter is the subpage component of the current title. For example, if someone follows a link to Special:MyExtension/blah, $par will contain "blah".
[http://www.mediawiki.org/wiki/Manual:Special_pages]
name::
* McsEngl.mw'page.special'Name@cptIt,
Special pages also have unique names that can be customized on a wiki. The general form is "Special:Pagename" where both "Special" and "Pagename" are customizable. The Special pseudo namespace can be translated in other languages. This translated namespace can be produced with the wikitext {{ns:special}}, on this wiki giving "Special". The name of the special page can also be redefined in a system message, for the site language, with the generic name of the special page as the ID.
[http://www.mediawiki.org/wiki/Manual:Special_pages]
_SPECIFIC:
* http://www.mediawiki.org/wiki/Special:SpecialPages,
* extension#ql:mw'extension#,
---
* mw.Special.CategoryTree,
* mw.Special.ListGroupRights,
* mw.Special.ListUsers,
* mw.Special.LonelyPages,
* mw.Special.MostLinkedPages,
* mw.Special.ProtectedPages,
* mw.Special.ProtectedTitles,
* mw.Special.UncategorizedCategories,
name::
* McsEngl.mw'page.special.All-messages@cptIt,
* McsEngl.mw'All-messages-special-page@cptIt,
[MediaWiki-l] Rename "Category" to "Topic"
Al Johnson <alj62888@yahoo.com>
I have a unique situation and would like to rename the Category functionality and call it "Topic" instead. IOW, everywhere you see a "Category" or "Categories" label on a regular wiki page - such as at the bottom of every page - I would like the label to be "Topic" and "Topics" instead.
Is that possible?
===
Look at Special:AllMessages - all the stuff like this are there and can be
altered.
-----
Yury Katkov, WikiVote
name::
* McsEngl.mw'page.special.Built-in@cptIt,
* McsEngl.mw'Built-in-special-page@cptIt,
All of the ~75 built-in special pages that come with MediaWiki are called SpecialSomename.php and are located in the includes/specials directory.
[http://www.mediawiki.org/wiki/Manual:Special_pages]
name::
* McsEngl.mw'page.special.Contributions@cptIt,
* McsEngl.mw'Contributions-special-page@cptIt,
name::
* McsEngl.mw'page.special.Custom@cptIt,
* McsEngl.mw'Custom-special-page@cptIt,
name::
* McsEngl.mw'page.special.NewPages@cptIt,
* McsEngl.mw'NewPages-special-page@cptIt,
_Address:
* .../Special:NewPages,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Help:New_pages,
name::
* McsEngl.mw'page.special.RecentChanges@cptIt,
* McsEngl.mw'RecentChanges-special-page@cptIt,
The most interesting special page is Special:RecentChanges. It displays all edits, file uploads, page moves, deletions and other actions done in the wiki. In the menu on top it offers a collection of links to customize your display: limit the number of changes shown, the number of days or restrict it to edits to a certain namespace. You can also hide edits marked as minor (don't forget that major changes can be flagged by a user as minor anyway).
[http://www.mediawiki.org/wiki/Help:Tracking_changes]
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Help:Recent_changes,
name::
* McsEngl.mw'page.special.SpecialPages@cptIt,
* McsEngl.mw'SpecialPages-special-page@cptIt,
name::
* McsEngl.mw'page.special.Statistics@cptIt,
* McsEngl.mw'Statistics-special-page@cptIt,
name::
* McsEngl.mw'page.special.UserLogin@cptIt,
* McsEngl.mw'UserLogin-special-page@cptIt,
name::
* McsEngl.mw'page.special.Watchlist@cptIt,
* McsEngl.mw'Watchlist-special-page@cptIt,
_ADDRESS.WPG:
* http://meta.wikimedia.org/wiki/Help:Watching_pages,
name::
* McsEngl.mw'page.Subject@cptIt,
* McsEngl.mw'not-talk-page@cptIt,
* McsEngl.mw'subject-page@cptIt,
_DESCRIPTION:
subject page, that is not a talk page and not a "Special:" page.
[http://meta.wikimedia.org/wiki/Help:Namespace#CSS_based_namespace_detection]
name::
* McsEngl.mw'page.Subpage@cptIt,
* McsEngl.mw'subpage@cptIt,
_DESCRIPTION:
Subpages
In addition to namespaces, content can be ordered using subpages. This simple feature provides automatic breadcrumbs of the pattern [[Page title/Subpage title]] from the page after the slash (in this case, "Subpage title") to the page before the slash (in this case, "Page title").
[http://en.wikipedia.org/wiki/Mediawiki]
In namespaces where the feature is switched off, any slashes (/) within a page name are simply part of the page name and do nothing special.
[http://www.mediawiki.org/wiki/Subpages]
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Subpages,
* http://www.mediawiki.org/wiki/Category:Subpage,
* http://www.mediawiki.org/wiki/User:Karora/ListSubPages,
name::
* McsEngl.mw'subpage'Code@cptIt,
* mw'wgNamespacesWithSubpages:
Enabling for a namespace
The normal way to enable subpages for a given namespace is to edit the LocalSettings.php and insert the following:
# Enable subpages in the main namespace
$wgNamespacesWithSubpages[NS_MAIN] = true;
This adds an item (a 'true' value) to the $wgNamespacesWithSubpages array which is already defined in DefaultSettings.php
[http://www.mediawiki.org/wiki/Manual:$wgNamespacesWithSubpages]
_ mw'SUBPAGENAME_wikimarkup:
{{SUBPAGENAME}} Magic words The subpage title ("foo" on "Title/foo"). 1.6+
name::
* McsEngl.mw'subpage'Extension@cptIt,
* McsEngl.mw'extension.Subpage@cptIt,
_SPECIFIC:
* http://www.mediawiki.org/wiki/Extension:MultiPages,
* http://www.mediawiki.org/wiki/Extension:Subpage_Fun,
* http://www.mediawiki.org/wiki/Extension:SubPageFunctions,
* http://www.mediawiki.org/wiki/Extension:SubPageList,
* http://www.mediawiki.org/wiki/Extension:SubPageList2,
* http://www.mediawiki.org/wiki/Extension:SubPageList3,
name::
* McsEngl.mw'page.Talk@cptIt,
* McsEngl.mw'talk-page@cptIt,
name::
* McsEngl.mw'page.Template@cptIt,
* McsEngl.mw'template@cptIt,
* McsEngl.mw'template-page@cptIt,
_PART:
* template-wikitext#ql:mw'template#
_DESCRIPTION:
Templates are standard wiki pages whose content is designed to be transcluded (embedded) inside other pages. Templates follow a convention that the name is prefixed with "Template:", assigning it to that namespace; besides this, you can create them like any other wiki page.
The simplest use of templates is as follows. If you create a page called "Template:Welcome" with contents:
Hello! Welcome to the wiki.
you'll have created your first template! If you then insert the code:
{{Welcome}}
in any other page, when that page is viewed the text "Hello! Welcome to the wiki." will appear instead of {{Welcome}}. The template content is "transcluded" into the other page, i.e. it is integrated in the page.
You can then insert {{Welcome}} at any point of any page where you wish to welcome someone. Suppose it is used in 100 pages. If you then change the template contents to:
Hi there! Welcome to this wonderful wiki.
and revisit any of the 100 pages where the template was used, you'll see the new text instead of the original one. In this way, you have changed the content of 100 pages without editing them, because the template is transcluded into these pages.
This is the basic mechanism. There are several additional features of transclusion that enrich this mechanism and make templates very useful.
[http://www.mediawiki.org/wiki/Help:Templates]
_With_Parameters:
'''A little thank you...'''
for {{{1}}}.
hugs, {{{2}}}
== named parametes ==
'''A little thank you...'''
for {{{reason}}}.
hugs, {{{signature}}}
== default values ==
'''A little thank you...'''
for {{{reason|everything}}}.
hugs, {{{signature|Me}}}
_noninclude:
Anything between <noinclude> and </noinclude> will be processed and displayed only when the template's page is being viewed directly, and will not be processed and displayed when it is included in another page.
[http://www.mediawiki.org/wiki/Template]
_includeonly:
Anything between <includeonly> and </includeonly> will be processed and displayed only when the page is being included, and will not be processed and displayed when the template page is being viewed directly.
[http://www.mediawiki.org/wiki/Template]
name::
* McsEngl.mw'template'Creating@cptIt,
_CREATION:
You start a new template in the same way you would start a normal page. The only difference is that its title must start with Template:.
Creating, editing and using templates
You start a new template in the same way you would start a normal page. The only difference is that its title must start with Template:.
Once you have made the template, you can add {{templatename}} to the pages you want to use it on. Every page using this template will get the same boilerplate text, each time a user visits it. When the template is updated, all pages containing the template tag will be automatically updated.
Alternatively, you can add {{subst:templatename}} to the pages you want to use the boilerplate text on. The system will fetch a one-time copy of the template text and substitute it into the page, in place of the template tag. If anyone edits the template afterwards, pages that used the subst: keyword will not be updated. Sometimes that's what you want.
If the template you want to edit looks like {{foo}}, you would go to Template:foo to edit it. To get there, type in the URL to your address bar, search for it, or make a link in the sandbox and click on it.
Once you are there, just click "edit" or "edit this page" and edit it in the same way you would any other page. You can add anything you would add to a normal page, including text, images and other templates. Please be aware that your edit might affect many pages, so be cautious.
[http://meta.wikimedia.org/wiki/Help:A_quick_guide_to_templates]
name::
* McsEngl.mw'template'Resource@cptIt,
_SPECIFIC:
* help: http://www.mediawiki.org/wiki/Template,
* http://www.mediawiki.org/wiki/Category:Templates,
* http://www.mediawiki.org/wiki/Template_repository,
* http://meta.wikimedia.org/wiki/Help:Template,
* http://meta.wikimedia.org/wiki/Help:Advanced_templates,
* http://meta.wikimedia.org/wiki/Help:A_quick_guide_to_templates,
* http://meta.wikimedia.org/wiki/Help:Expansion,
* http://meta.wikimedia.org/wiki/Help:Embed_page,
name::
* McsEngl.mw'template'Using@cptIt,
* McsEngl.mw'template'Transclusion@cptIt,
* McsEngl.mw'transclusion@cptIt,
* McsEngl.mw'template-insertion@cptIt,
* McsEngl.mw'template-markup@cptIt,
_DESCRIPTION:
Transclusion is generally the inclusion of the content of a document into another document by reference. In a Wikipedia context, it is the use of the template functionality of MediaWiki to include the same content in multiple documents without having to edit those documents separately. Template transclusion is the common way to use template messages, and is implemented by using a template tag, with the form:
{{template name}}
[http://www.mediawiki.org/wiki/Transclusion]
_Mehtod1:
{{Name}}, described above, 'transcludes' (i.e. includes a copy of) the content of the template (stored in the page [[Template:Name]]) whenever the page containing the template transclusion is fetched and displayed; i.e. if the template is later changed, the displayed transcluding page will automatically change too.
_Method2:
{{subst:Name}} replaces that string with the contents of the template, in the source of the transcluding page, when you save that page; the copy of the template contents can then be edited normally (and separately from the original in the template page). Note: don't use this if you are looking to continually propagate changes from the source template to the page(s) that references it.
_Mehtod3:
{{safesubst:Name}} was introduced in rev:61710 to allow for substitution that doesn't break transclusion, see w:en:Help:Substitution#The safesubst: modifier.
_Method4:
{{msgnw:Name}} includes the template in a form that displays it as raw wiki syntax (the way <nowiki> does) when the page containing it is fetched.
_Method5:
{{:Pagename}}
===> includes any page, in current.
{{subst:Pagename}}
===> substitutes any page, in current.
_Mehtod6 (parameters):
{{Template|param1|param2}}
{{Template|2=param2|1=param1}}
{{Thankyou|signature=Me|reason=being who you are}} ===>named parametes
name::
* McsEngl.mw'template'Wikitext@cptIt,
* McsEngl.mw'template-tag@cptIt,
* McsEngl.mw'template-wikitext@cptIt,
* McsEngl.mw'transclusion@cptIt,
* McsEngl.wiketext.template@cptIt,
* McsEngl.wikitext.transclusion@cptIt,
* McsEngl.mw'wikitext.Template@cptIt,
_WHOLE:
* template-page#ql:mw'page.template#
_GENERIC:
* macro#ql:mw'macro#
_DESCRIPTION:
{{templatename}} you put in any page you want the template-text to appear.
===
Templates are pages in the template namespace. This means any page beginning with "Template:", such as [[Template:Templatename]] can be used as a template. The content of a template can be added to a page by typing {{templatename}}.
Templates are used to add recurring messages to pages in a consistent way, to add boilerplate messages, to create navigational boxes and to provide cross-language portability of texts.
[http://meta.wikimedia.org/wiki/Help:A_quick_guide_to_templates]
===
If you have standard texts you want to include on several pages, the MediaWiki template feature comes into play.
[http://www.mediawiki.org/wiki/Help:Templates]
===
This technique is commonly known as transclusion.
Every article with that tag in it will display the following text
_Future:
Proposed solutions
In order to resolve these issues, we are looking for a scripting solution that will replace our current template system. Options:
* Lua (implemented)
* WikiScripts (implemented)
* Probably some JavaScript backend (Node.JS)
[http://www.mediawiki.org/wiki/Scripting]
mw'includeonly_tag:
anything between <includeonly> and </includeonly> will be processed and displayed only when the page is being included, but not when the template page is being viewed directly,
http://www.mediawiki.org/wiki/Template
mw'noinclude_tag:
Anything between <noinclude> and </noinclude> will be seen only when the template's page is being viewed directly, but not when it is included in another page.
[http://www.mediawiki.org/wiki/Template]
name::
* McsEngl.mw'template.specific@cptIt,
mw'template.Extension:
{{Extension
|name = ...
mw'template.Disambig:
{{Disambig}}:
===> This disambiguation page lists articles associated with the same title. If an internal link led you here, you may wish to change the link to point directly to the intended article.
{{Europe}}:
Sovereign states of Europe[hide]
Albania · Andorra · Armenia2 · Austria · Azerbaijan1 · Belarus · Belgium · Bosnia and Herzegovina · Bulgaria · Croatia · Cyprus2 · Czech Republic · Denmark3 · Estonia · Finland · France3 · Georgia1 · Germany · Greece · Hungary · Iceland · Ireland · Italy3 · Kazakhstan1 · Latvia · Liechtenstein · Lithuania · Luxembourg · Macedonia · Malta · Moldova · Monaco · Montenegro · Netherlands3 · Norway3 · Poland · Portugal3 · Romania · Russia1 · San Marino · Serbia · Slovakia · Slovenia · Spain3 · Sweden · Switzerland · Turkey1 · Ukraine · United Kingdom3 · Vatican City
1 Has majority of its territory in Asia. 2 Entirely in Asia but having socio-political connections with Europe. 3 Has dependencies or similar territories outside Europe.
{{main|Valency (linguistics)}}:
Main article: Valency (linguistics)
{{Mergeto|Namespace (computer science)|date=April 2007}}:
It has been suggested that this article or section be merged into Namespace (computer science). (Discuss)
{{otheruses4|namespaces in general|their use in computing|Namespace (computer science)}}:
This article is about namespaces in general. For their use in computing, see Namespace (computer science).
mw'template.PersonData:
{{Persondata
| NAME = Magellan, Ferdinand
| ALTERNATIVE NAMES = Magalhγes, Fernγo de (Portuguese); Magallanes, Fernando de (Spanish)
| SHORT DESCRIPTION = Sea explorer
| DATE OF BIRTH = Spring 1480
| PLACE OF BIRTH = Sabrosa, Portugal
| DATE OF DEATH = April 27, 1521
| PLACE OF DEATH = Mactan Island, Cebu, Philippines
}}
{{selfref|For the use of the term namespace on Wikipedia, see [[Wikipedia:Namespace]].}}:
For the use of the term namespace on Wikipedia, see Wikipedia:Namespace.
mw'template.Shortcut:
{{Shortcut|CC}}
===> displays a "synonym" (redirect for current-page).
mw'template.stub:
{{stub}}:
This article is a stub. You can help Wikipedia by expanding it.
{{Unreferenced|date=May 2007}}:
This article does not cite any references or sources.
Please help improve this article by adding citations to reliable sources. (help, get involved!)
Any material not supported by sources may be challenged and removed at any time.
This article has been tagged since May 2007.
{{WikipediaSister}}:
shows the selection of sister projects. The result:
Wikipedia is hosted by the Wikimedia Foundation, a non-profit organization that also hosts a range of other projects:
Wiktionary
Dictionary and thesaurus
Wikinews
Free-content news
Wikiquote
Collection of quotations
Wikibooks
Free textbooks and manuals
Wikispecies
Directory of species
Wikisource
Free-content library
Wikiversity
Free learning materials and activities
Commons
Shared media repository
Meta-Wiki
Wikimedia project coordination
name::
* McsEngl.mw'template'table@cptIt,
[Mediawiki-l] How to allow users to put tables inside templates?
Inbox
x
Gerald Grenier roguebfl@cfl.rr.com via lists.wikimedia.org
12:50 AM (8 hours ago)
to MediaWiki
The standard way is to create Template:! that only has | and no spaces or return characters before your <noinclude> tag
and Template:!! that is the same except it has || instead.
Then you have
{{Test|Contenido=
{{{!}} class="wikitable"
{{!}} bla
{{!}} bla bla
{{!}}-
{{!}} hola
{{!}}
hola hola
{{!}}}
}}
or
{{Test|Contenido=
{{{!}} class="wikitable"
{{!}} bla {{!!}} bla bla
{{!}}-
{{!}} hola {{!!}}hola hola
{{!}}}
}}
name::
* McsEngl.mw'page.User@cptIt,
* McsEngl.mw'user-page@cptIt,
name::
* McsEngl.mw'page.Wikitext@cptIt,
* McsEngl.mw'wikitext-page@cptIt,
_DESCRIPTION:
In class Title:
Does that page contain wikitext, or it is JS, CSS or whatever?
public function isWikitextPage()
name::
* McsEngl.mw'Processing-code@cptIt,
_Sibling.Specific:
* data-code#ql:mw'data_code#,
* mixed-code,
_SPECIFIC:
* user-processing-code,
* programmer-processing-code#ql:mw'code#
name::
* McsEngl.mw'Resource@cptIt,
_SPECIFIC:
* home: http://www.mediawiki.org/wiki/MediaWiki,
* conf: http://www.mediawiki.org/wiki/Manual:Configuration,
* doc: http://svn.wikimedia.org/doc/main.html,
* meta:
====
* http://www.mediawiki.org/wiki/Category:MediaWiki_Introduction,
* http://www.mwusers.com/forums/content.php,
* https://lists.wikimedia.org/mailman/listinfo/mediawiki-l,
- wikitech-l@lists.wikimedia.org,
- mediawiki-l@lists.wikimedia.org.
=== IRC
* http://prototype.wikimedia.org/logs/%23wikimedia-dev//
===
* https://www.mediawiki.org/wiki/MVL,
_Functionality:
* http://renareich.com/2010/02/16/adding-navigation-to-your-mediawiki//
_Book:
* http://workingwithmediawiki.com// 2012.
_TEACHING:
There's always Jon Udell's classic Heavy Metal Umlaut
vid<http://jonudell.net/udell/gems/umlaut/umlaut.html>as well as this
one <http://www.youtube.com/watch?v=rNBahdIAzFo> created by the Mises
Institute as an introduction to its wiki. You might model your approach on
one of those. Perhaps Wikiversity's MediaWiki
page<https://en.wikiversity.org/wiki/MediaWiki>could use some
expansion, but I've had trouble figuring out what to write,
given that there are already so many how-tos out there on the topic.
name::
* McsEngl.mw'Security@cptIt,
[Mediawiki-l] faking IP address?
Stip stipen.treublatt@gmx.net via lists.wikimedia.org
1:40 PM (3 hours ago)
to helmut, MediaWiki
Dont bother with the IP-Adresses, install proper Anti-Spam-Extensions.
See http://www.mediawiki.org/wiki/Manual:Combating_spam for a MediaWiki-Helppage (and follow the links on that page to learn more), or have a look at http://www.wiki-aventurica.de/wiki/Wiki_Aventurica:Anti-Spam which is a short summary of measures that work for me.
I highly recommend using the QuestyCaptcha-part of Confirm-Edit to prevent account creation, and installing SpamBlacklist to block those pesky spamlinks.
For this http://arktur.de/Wiki/index.php?title=Kategorie:Whiteboard&curid=2323&diff=6189&oldid=5388 kind of spam you might need to install SpamRegex or AbuseFilter, though.
Greetings
Stip
Am 27.05.2012 12:24, schrieb Helmut Hullen:
Hallo,
is it possible that a bad guy fakes his IP address when he creates a
page?
My wiki (arktur.de/Wiki) suffers from Wiki spam, and sometimes I see IP
addresses from spammers which don't occur in the apache access_log.
Viele Gruesse!
Helmut
______________________________________________
MediaWiki-l mailing list
MediaWiki-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Stip stipen.treublatt@gmx.net via lists.wikimedia.org
1:43 PM (2 hours ago)
to helmut, MediaWiki
Alternatively, think about http://www.mediawiki.org/wiki/Manual:Preventing_access
name::
* McsEngl.mw'Skin@cptIt,
_GENERIC:
* mw-code#ql:mw'code#
_DESCRIPTION:
A 'Skin' in MediaWiki is a PHP class containing functions (or methods) designed to gather the information needed to generate the HTML that your browser displays as each page in the Wiki.
Each skin exists as a separate class that extends the parent 'Skin' class. In other words, each individual skin inherits all methods found in the main 'Skin' class, and may define additional methods specific to that skin needed to draw the page.
[http://meta.wikimedia.org/wiki/Customization:Explaining_skins]
===
Skins allow users to customize the look and feel of MediaWiki. The default skin used on the Wikimedia projects is Vector. A number of other skins also exist in default MediaWiki installations. Users can see which skins are available on their preferences page. To see some examples of skins that other sites using MediaWiki have created, see Sites using MediaWiki/gallery, Gallery of user styles, and Skin projects. It is important to note that optional components, such as JavaScript, only function properly on the default skin.
[http://www.mediawiki.org/wiki/Skins]
name::
* McsEngl.mw'skin'Changing@cptIt,
_Default:
on LocalSettings.php:
$wgDefaultSkin = 'vector';
To change all existing users' skin settings, use the userOptions.php maintenance script. The syntax to use on the command line would be:
$ php userOptions.php skin --old <old skin name> --new <new skin name>
Example:
$ php userOptions.php skin --old "monobook" --new "vector"
[http://www.mediawiki.org/wiki/Manual:Skin_configuration]
name::
* McsEngl.mw'skin'Class@cptIt,
_SPECIFIC:
class Linker
Some internal bits split of from Skin.php. More...
class MediaWiki_I18N
Wrapper object for MediaWiki's localization functions, to be passed to the template engine. More...
class ModernTemplate
class MonoBookTemplate
class QuickTemplate
Generic wrapper for template functions, with interface compatible with what we use of PHPTAL 0.7. More...
class Skin
The main skin class that provide methods and properties for all other skins. More...
class SkinChick
Inherit main code from SkinTemplate, set the CSS and template filter. More...
class SkinCologneBlue
class SkinModern
Inherit main code from SkinTemplate, set the CSS and template filter. More...
class SkinMonoBook
Inherit main code from SkinTemplate, set the CSS and template filter. More...
class SkinMySkin
Inherit main code from SkinTemplate, set the CSS and template filter. More...
class SkinNostalgia
class SkinSimple
Inherit main code from SkinTemplate, set the CSS and template filter. More...
class SkinStandard
class SkinTemplate
Template-filler skin base class Formerly generic PHPTal (http://phptal.sourceforge.net/) skin Based on Brion's smarty skin. More...
class SkinVector
SkinTemplate class for Vector skin. More...
class VectorTemplate
QuickTemplate class for Vector skin. More...
[http://svn.wikimedia.org/doc/group__Skins.html]
mw'class.BaseTemplate:
* http://svn.wikimedia.org/doc/classBaseTemplate.html,
* generic: Inherits QuickTemplate.
* specific: Inherited by LegacyTemplate, MonoBookTemplate, and VectorTemplate.
mw'class.Skin: http://svn.wikimedia.org/doc/classSkin.html,
* file: \public_html\mw19\phase3\includes\Skin.php,
- generic: Inherits ContextSource.
- specific: Inherited by SkinTemplate.
name::
* McsEngl.mw'skin'Code@cptIt,
_ mw'wgDefaultSkin:
* http://www.mediawiki.org/wiki/Manual:$wgDefaultSkin,
name::
* McsEngl.mw'skin'CSS@cptIt,
Site-Wide CSS
MediaWiki allows administrators to specify site-wide CSS rules to be added to every page rendered. These rules can be added by editing the page MediaWiki:Common.css. In addition to a global stylesheet, one can also specify CSS rules to be used in certain skins (see Manual:Interface/Stylesheets).
[http://www.mediawiki.org/wiki/Manual:Skin_configuration]
User CSS:
Users can also specify their own CSS rules by creating the page "User:Username/skinname.css". If a user uses the monobook skin for example, they would edit the page Special:MyPage/monobook.css. This feature can be enabled by setting $wgAllowUserCss to true in LocalSettings.php.
[http://www.mediawiki.org/wiki/Manual:Skin_configuration]
List of stylesheets
Global stylesheets
MediaWiki:Common.css (all skins)
MediaWiki:skinname.css (per skin, for example MediaWiki:Vector.css)
Personal stylesheets
User:Example/common.css (all skins - introduced in MW v1.17)
User:Example/skinname.css (per skin, for example User:Example/vector.css)
[http://www.mediawiki.org/wiki/Manual:Interface/Stylesheets]
name::
* McsEngl.mw'skin'File@cptIt,
mw'skin'file.Skin.php_in_includes:
Class: Skin
file Chick.php
Chick: A lightweight Monobook skin with no sidebar, the sidebar links are given at the bottom of the page instead, as in the unstyled MySkin.
file CologneBlue.php
Cologne Blue: A nicer-looking alternative to Standard.
file Modern.php
Modern skin, derived from monobook template.
file MonoBook.php
MonoBook nouveau.
file MySkin.php
MySkin: Monobook without the CSS.
file Nostalgia.php
Nostalgia: A skin which looks like Wikipedia did in its first year (2001).
file Simple.php
Simple: A lightweight skin with a simple white-background sidebar and no top bar.
file Standard.php
Standard (a.k.a.
file Vector.php
Vector - Modern version of MonoBook with fresh look and many usability improvements.
name::
* McsEngl.mw'skin'Resource@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Skins,
* http://www.mediawiki.org/wiki/Help:Skins,
* manual: http://www.mediawiki.org/wiki/Manual:Skins,
* creation: http://www.mediawiki.org/wiki/Manual:Skinning,
* http://www.mediawiki.org/wiki/Manual:Gallery_of_user_styles,
* http://www.mediawiki.org/wiki/Manual:Skin_configuration,
* drop-down: http://paulgu.com/wiki/Home,
* projects: http://www.mediawiki.org/wiki/Skin_projects,
* http://meta.wikimedia.org/wiki/Help:User_style,
* http://www.mediawiki.org/wiki/Extension:SkinPerNamespace,
* https://gist.github.com/1927993, extend vector.
* http://blog.redwerks.org/2012/02/08/mediawiki-skinning-tutorial//
name::
* McsEngl.mw'skin'Suppressing@cptIt,
Suppression of Skins
The administrator can limit the skin choices that are offered site-wide in user's preferences by listing skin(s) to suppress in the $wgSkipSkins array. To do this, put something like this in LocalSettings.php:
# To remove various skins from the User Preferences choices
$wgSkipSkins = array("chick", "cologneblue", "nostalgia", "simple", "standard", "monobook");
[http://www.mediawiki.org/wiki/Manual:Skin_configuration]
Remove Skin option from User Preferences
1.16 and newer
MediaWiki version: = 1.16
Add a new line containing
$wgHiddenPrefs[] = 'skin';
to LocalSettings.php. This will remove the "Skin" tab from preferences and the possibility to use the useskin parameter in the URL.
[http://www.mediawiki.org/wiki/Manual:Skin_configuration]
name::
* McsEngl.mw'skin.Modern@cptIt,
#mw_main:
= the page, talk, edit tabs.
<div id="p-search" class="portlet">
<h5><label for="searchInput">Search</label></h5>
<div id="searchBody" class="pBody">
<form action="/mw/index.php" id="searchform">
<input type='hidden' name="title" value="Special:Search"/>
<input id="searchInput" title="Search WikiCbs" accesskey="f" type="search" name="search" />
<input type='submit' name="go" class="searchButton" id="searchGoButton" value="Go" title="Go to a page with this exact name if exists" />
<input type='submit' name="fulltext" class="searchButton" id="mw-searchButton" value="Search" title="Search the pages for this text" />
</form>
</div>
</div>
name::
* McsEngl.mw'skin.Monobook@cptIt,
div#column-one:
= the sidebare.
* the left column width is specified in class .portlet
=========================================
#p-cactions: page, talk, edit,
name::
* McsEngl.mw'skin.Synagonism@cptIt,
* McsEngl.mw'synagonism-skin@cptIt580i,
* McsEngl.skinToc@cptIt580i,
* McsEngl.synagonism-skin@cptIt580i,
_ATTRIBUTE:
1) The left sidebar now is a drop-down menu, always visible.
2) The logo, the portlets personal and search and the title of the page are always visible.
3) The table-of-contents (toc) moved on the left in a splittable-pane, always visible.
4) The toc is an expandable tree.
5) There is two-way communication between the toc and the articles.
* By clicking on the toc, goes to that heading and the user can copy the address of any section of an article.
* By clicking on a section of an article, in the toc is highlited this section and its parents are only expanded, giving to the reader the big picture of the position s|he is reading. Thus improves the readability of big articles.
6) If there is no toc in a page (eg less than 3 headings), the toc automatically closes and leaves all the space for the article.
7) Splitbar has a button that closes|opens the toc with one click.
_ToDo:
* internationalization,
_Comm:
* http://www.mediawiki.org/wiki/User_talk:Dantman,
_USAGE:
* http://barbules.fr/index.php/Accueil,
* http://barbules.fr/index.php/Site:Sancerre,
name::
* McsEngl.mw'skin.Synagonism1.18@cptIt,
_File_Structure:
/resources/Resources.php
/skins/common/commonPrint.css
/skins/synagonism/images/
/skins/synagonism/synagonism.css
/skins/synagonism/synagonism.js
/skins/Synagonism.deps.php
/skins/synagonism.php
Resources.php:
'skins.synagonism' => array(
'styles' => array( 'synagonism/synagonism.css' => array( 'media' => 'screen' ) ),
'scripts' => 'synagonism/synagonism.js',
'remoteBasePath' => $GLOBALS['wgStylePath'],
'localBasePath' => $GLOBALS['wgStyleDirectory'],
),
name::
* McsEngl.mw'skin.Vector@cptIt,
The Vector extension adds a few enhancements to the Vector skin. Note that these features are only available in Vector, not in other skins.
[http://www.mediawiki.org/wiki/Extension:Vector]
name::
* McsEngl.mw'Subsitution@cptIt,
_ADDRESS.WPG:
* http://meta.wikimedia.org/wiki/Help:Substitution,
_DESCRIPTION:
Substitution is automatic conversion of wikitext of a page when the page is saved, in the case that the wikitext refers to one or more templates, variables, or parser functions.
In the case of template substitution the template call is replaced by the template content with substitution of the parameters. Thus a template is used as macro and the page is macro expanded when the page is saved rather than, as usually happens, when the page is viewed.
In the case of substitution of a variable or parser function the reference to it is replaced by the resulting value.
Substitution is done by putting the modifier subst: or safesubst: after the double opening braces without intervening spaces like in the examples: {{subst:FULLPAGENAME}} and {{safesubst:FULLPAGENAME}}. The code safesubst: is useful in multilevel substitution, see below.
The result (in the form of the difference with the saved wikitext) can be seen before (or without) saving by pressing "Show changes". However, if the text covers more than one paragraph this diff page is not very suitable for copying the result (e.g. for stepwise substitution without saving every step), because of plus signs in the margin.
[http://meta.wikimedia.org/wiki/Help:Substitution]
name::
* McsEngl.mw'ToC@cptIt,
_WHOLE:
* data-page#ql:mw'data_page#
/** Maximum indent level of toc. */
$wgMaxTocLevel = 999;
But if you want to remove the TOC numbers altogether
Add to MediaWiki:Common.css
Code:
.tocnumber { display: none !important; }
_ mw__FORCETOC__magic:
* mw__TOC_magic
How do I add a table of contents?
A TOC is added automatically as soon as you have more than three headers. To add one with fewer than four headers, type __FORCETOC__ anywhere on the page or __TOC__ at the position where you want to have the TOC.
How do I hide a table of contents?
To remove a table of contents from a page, add __NOTOC__ to anywhere on the page. The __ character before the commands is two _ characters together. See Manual:FAQ#How can I hide the table of contents? for other options.
_ToC_linking:
You can make a link to it with [[#toc]]
name::
* McsEngl.mw'toc'Resource@cptIt,
_ADDRESS.WPG:
* http://en.wikipedia.org/wiki/Template:CompactTOC8,
name::
* McsEngl.mw'Usage@cptIt,
_DESCRIPTION:
MediaWiki is a tool used for very different purposes. Within Wikimedia projects, for instance, it's used to create and curate an encyclopedia (Wikipedia), to power a huge media library (Wikimedia Commons) or to transcribe scanned reference texts (Wikisource); and so on. In other contexts, MediaWiki is used as a corporate CMS, or as a data repository, sometimes combined with a semantic framework. These specialized uses that weren't planned for will probably continue to drive constant adjustments to the software's internal structure. As such, MediaWiki's architecture is very much alive, just like the immense community of users it supports.
[http://www.mediawiki.org/wiki/Manual:MediaWiki_architecture#Future]
===
The first version of the software was deployed to serve the needs of the free content Wikipedia encyclopedia in 2002.[1]
It has been deployed since then by many companies as a content management system for internal knowledge management.[2] Notably, Novell uses it to operate several of its high-traffic websites.[3][4][5]
Thousands of websites use MediaWiki.[6]
Some educators have also assigned students to use MediaWiki for collaborative group projects.[7]
[http://en.wikipedia.org/wiki/Mediawiki]
name::
* McsEngl.mw'Using@cptIt,
* McsEngl.mw'managing@cptIt,
_GENERIC:
* mw-doing#ql:mw'doing#
_SPECIFIC_DIVISION.content:
* content-management#ql:mw'content_managing#,
* non-content-management,
_SPECIFIC:
* administering,
* content-management,
* non-content-management,
name::
* McsEngl.mw'Administering@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Sysadmin_hub,
_SPECIFIC:
* backing-up,
* configuring,
* installing,
* upgrading,
name::
* McsEngl.mw'Backing-up@cptIt,
http://www.mediawiki.org/wiki/Manual:Backing_up_a_wiki provides an overview of
the backup process. You should also refer to the documentation for your
database management system for information on backing up a database, and to
your operating system documentation for information on making copies of files.
[UPGRADE]
I am running a replica of a media wiki (not the images though but I guess I could do that too with a cron job) I use mysqldumper to make a dump and put it on the other server and run a cron job there to restore the dump into the other database. works fine.
[ Henny Savenije webmaster@henny-savenije.pe.kr]
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Manual:Backing_up_a_wiki,
* http://www.mediawiki.org/wiki/Fullsitebackup,
* http://www.mediawiki.org/wiki/MWDumper,
* http://dev.mysql.com/doc/refman/5.0/en/mysqldump.html,
* http://www.siteground.com/tutorials/php-mysql/mysql_export.htm,
name::
* McsEngl.mw'Configuring@cptIt,
* McsEngl.mw'configuration@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Manual:Configuration_settings,
_PART:
* mw-editing-configuration#ql:mw'configuring.editing#,
* mw-global#ql:mw'code.global_variable#,
* mw-namespace-configuration#ql:mw'ns'configuration#
_Quantity:
with more than 700 configuration settings
[http://en.wikipedia.org/wiki/Mediawiki] {2011-10-08}
mw'conf.Short_url:
1) In LocalSettings.php, modify with the following:
$wgScriptPath = '/w';# Path to the actual files.
$wgArticlePath = '/wiki/$1';# Virtual path. This directory MUST be different from the one used in $wgScriptPath
$wgUsePathInfo = true;# Enable use of pretty URLs
2) Edit httpd.conf
<IfModule alias_module>
Alias /wiki C:/public_html/mw/index.php
3) restart apache
[http://www.mediawiki.org/wiki/Manual:Short_URL]
mw'conf.Sidebar:
mw'sidebar,
* http://localhost/wiki/MediaWiki:Sidebar, as admin
* http://localhost/wiki/MediaWiki:Common.js
== width ==
You can change the width of your sidebar by adding the following CSS rules to your MediaWiki:Common.css article (MediaWiki:Monobook.css if pre 1.9), note that this is an article not a file. This changes the width to 15em, the actions position and portlet width should be an em or so less, so I've set them to 14em in this example.
/* increase sidebar width */
#column-content { margin-left: -15em }
#column-content#content { margin-left: 15em }
#p-logo a,#p-logo a:hover { width: 15em }
#p-cactions { left: 14.5em }
.portlet { width: 14em }
div#column-content { margin-left: -14em }
div#content { margin-left: 14em }
[http://www.mediawiki.org/wiki/Manual:Interface/Sidebar]
== toolbar hide ==
on MediaWiki:Common.css:
#p-navigation,#p-tb h5,#p-tb .pBody { display:none }
mw'conf.Suggest:
LocalSettings.php:
$wgEnableMWSuggest= true;
mw'conf.Tidy:
* http://www.mediawiki.org/wiki/Manual:$wgUseTidy,
* http://tidy.sourceforge.net//
- tool that validates html code.
==================================================================
name::
* McsEngl.mw'configuring'GUI@cptIt,
Daniel Barrett danb@vistaprint.com via lists.wikimedia.org
2012-02-05 4:44 PM (26 minutes ago)
to MediaWiki
>Why is there a reliance on manually editing LocalSettings.php and uploading it to the site?
>Why is there not an Admin page that edits this online?
"Config file vs. GUI admin page" is a religious issue for systems in general. If you're running one just one wiki, say, as a hobby, then a GUI would probably be simpler. As the sysadmin of 15+ MediaWiki sites (config file) and 10+ WordPress sites (GUI that saves to a database) at a company, however, I have found MediaWiki's config files much easier to maintain than WordPress's settings GUI & database, to keep the settings of all our sites in sync. (With a GUI you often want a database, not a config file, to support concurrent edits by multiple admins.)
Config files have these advantages:
1. Config changes can easily be tracked, rolled back, diffed, etc., using any off-the-shelf version control system. (Even if your GUI can generate a config file to be version controlled, you don't know that its final form will exactly reflect the change you made: the "save" function might reorder lines, reformat the text, add unwanted commands that set default values, etc. This screws up diffs.)
2. "Undo" is easy, no matter how long ago you made the change. When I change settings in the WordPress GUI and click "OK" or "Save", I sometimes have to work hard to roll back those changes or even remember what they were.
3. You can put anything you want into the MediaWiki config file (arbitrary PHP code) instead of whatever limited functionality that the GUI designers believed would be useful. This is invaluable. Possibly you could factor out the simpler settings into a GUI tool.
4. Config files are easily deployed to multiple targets as part of a formal release process: e.g., rsync to your 10+ wikis. With WordPress, I pull my hair out every time an admin makes a change through the GUI on one site and doesn't document it. It can be hard to identify that change so it can be documented, version-controlled, and deployed to other sites.
5. With config files, you can use your favorite editor (emacs, vi, etc.) instead of whatever the GUI designer gives you, which means I can work faster with fewer errors using familiar tools.
The main advantage of a GUI, if it's designed VERY well, is simplicity, making administration accessible to less technical people. That's not an issue for my team (we're all technical). But I can imagine that a GUI for changing basic MediaWiki settings would be useful for some admins.
DanB
Svip svippy@gmail.com via lists.wikimedia.org
3:15 AM (5 hours ago)
to MediaWiki
On 5 February 2012 10:24, Greg <greg@gajennings.net> wrote:
> I have been messing with mediawiki 1.18 for a while now. I think what it needs is an administration page.
>
> Why is there a reliance on manually editing LocalSettings.php and uploading it to the site? Why is there not an Admin page that edits this online?
>
> I would love to implement this but it might just be out of my ability to do so.
>
> It is so difficult to understand mediawiki settings and the mediawiki online-help is not very helpful.
>
> What do you think?
There are several things to consider for such a tool. Several have
been mentioned here, but besides useability (as in, with complex
configurations beyond just setting values, which are not that
uncommon), the second most important issue is security.
Many have probably noticed that when you finish the installer these
days, it sents you a LocalSettings.php, that you download and then
upload. Why? It used to write it to the configuration-directory in
the olden days; what changed? Simple; security. Allowing the
webserver to write in the configuration file can be considered
dangerous and potentially a big security issue.
You can then imagine the issue one might take with the idea of
allowing MediaWiki to manipulate and control the configuration file.
That will certainly open up the can of worms that is the configuration
writing security issue.
Because even *if* you could manage to craft a GUI tool that was so
sophisticated, yet so simplistic that it was usable by even the least
tech-savvy out there, then it would still be the fact that at least in
*any* 1.18 installation, the LocalSettings.php file is *unwriteable*
by the webserver. And as I gather, there is no intend in changing
that, particularly considering all the work that went into making it
unwriteable when it used to be.
And obviously when it was owned by the wrong user.
Also; as an aside; it may be worth considering whether making an
Administration status page might be a good idea, where Sysops can
verify through the software whether the installation is sane (such as
the LocalSettings.php file having the correct user, etc.).
name::
* McsEngl.mw'configuring.Editing@cptIt,
* How do I stop anonymous users from editing any page?
The recommended method is by changing the value of the $wgGroupPermissions configuration option. Edit LocalSettings.php and add the line:
$wgGroupPermissions['*']['edit'] = false;
See also: Preventing access, Manual:User rights
[http://www.mediawiki.org/wiki/Manual:FAQ#How_do_I_stop_anonymous_users_from_editing_any_page.3F]
* Wiki locking: $wgReadOnly
Disallows editing, displaying the string given as the reason.
Introduced in version: pre 1.1.0
Removed in version: still in use
Allowed values: (string), null/false
Default value: null
false, prior to 1.5.7
[http://www.mediawiki.org/wiki/Manual:$wgReadOnly]
name::
* McsEngl.mw'configuring.Uploading-file@cptIt,
* McsEngl.mw'uploading-file@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Manual:Configuring_file_uploads,
name::
* McsEngl.mw'Content-managing@cptIt,
name::
* McsEngl.mw'Content-editing@cptIt,
* McsEngl.mw'authoring@cptIt,
* McsEngl.mw'editing@cptIt,
* McsEngl.mw'storing@cptIt,
_PART:
* data#ql:mw'data#,
* magic-word,
* parser-function,
* template,
* variable,
* wikitext,
_ADDRESS.WPG:
* http://localhost/mw/index.php?title=CBS&action=edit,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/WYSIWYG_editor,
* http://www.mediawiki.org/wiki/Visual_editor,
name::
* McsEngl.mw'Content-reading@cptIt,
* McsEngl.mw'navigating@cptIt,
* McsEngl.mw'retrieving@cptIt,
name::
* McsEngl.mw'Executing@cptIt,
Start-server:
* \Program Files\PostgreSQL\EnterpriseDB-ApachePhp\installer\ApachePhp
name::
* McsEngl.mw'Installing@cptIt,
3) unzip media-wiki on 'server-dir/wiki-x/ dir
4) configure it from browser: server/wiki-x/
IF you can NOT see the logo, RENAME the wiki-dir.
Warning: Could not find eAccelerator, APC, XCache or WinCache.
Warning: Your default directory for uploads \public_html\mw/images/ is vulnerable to arbitrary scripts execution.
http://www.mediawiki.org/wiki/Manual:Security#Upload_security
Warning: The intl PECL extension is not available to handle Unicode normalization, falling back to slow pure-PHP implementation.
- http://pecl.php.net/package/intl,
- http://www.mediawiki.org/wiki/Unicode_normalization_considerations,
name::
* McsEngl.mw'Requirement@cptIt,
1) Web server such as Apache or IIS
Local or command line access is needed for running maintenance scripts
2) PHP version 5.2.3 or later. PHP 5.3.1 is incompatible with MediaWiki due to a bug.
Due to a security issue with PHP it is strongly advised to use PHP 5.2.17+ or PHP 5.3.5+ (see here for more details).
with Perl Compatible Regular Expressions
with Standard PHP Library
3) Database Server
MySQL 4.0 or later (*)
or PostgreSQL 8.1 or later
MediaWiki 1.15.3 Installation
Please include all of the lines below when reporting installation problems.
PHP 5.3.3 installed
Found database drivers for: PostgreSQL
PHP server API is apache2handler; ok, using pretty URLs (index.php/Page_Title)
Have XML / Latin1-UTF-8 conversion support.
Session save path (\Documents and Settings\HoKoNoUmo\Local Settings\Temp) appears to be valid.
PHP's memory_limit is 128M.
Couldn't find Turck MMCache, eAccelerator, APC or XCache; cannot use these for object caching.
GNU diff3 not found.
Found GD graphics library built-in, image thumbnailing will be enabled if you enable uploads.
Installation directory: \Program Files\PostgreSQL\EnterpriseDB-ApachePhp\apache\www\mediaWiki
Script URI path: /mediaWiki
Installing MediaWiki with php file extensions
Environment checked. You can install MediaWiki.
admin hknu
database: mediawiki
db user: mediawikiuser, mediawikiuser
_Unistallation:
1) go \Program Files\PostgreSQL\EnterpriseDB-ApachePhp
2) run unistall
name::
* McsEngl.mw'Searching@cptIt,
intitle:xxxx:
* Finds the articles that contain the word 'xxxx'
http://en.wikipedia.org/wiki/Special:PrefixIndex:
* Finds the articles that begin with term.
name::
* McsEngl.mw'Upgrading@cptIt,
Can my wiki stay online while it is upgrading?
Yes.
If you are upgrading between minor releases of MediaWiki, all you need to do is update the source files.
Note: the following assumes you have command line access. If you are upgrading between major releases of MediaWiki, the preferred procedure is as follows:
Unpack the new version of MediaWiki into a new directory
Prepare that new directory: copy your current LocalSettings.php from the old directory, copy any installed extensions and custom skins (if any).
In the release notes for the new version, see if any changes need to be made to LocalSettings.php.
Place the database in read-only mode by inserting the following variable into LocalSettings.php in the old directory - users will see this message if they attempt an edit during the upgrade process:
$wgReadOnly = 'Upgrading to MediaWiki 1.18.0';
Run the update script in the new directory.
Copy the images from the images sub-directory from the old directory to the new directory.
Swap the old directory and the new directory.
[http://www.mediawiki.org/wiki/Manual:Upgrading]
Upgrading MediaWiki has also historically been a bit troublesome; only 5 out of the 55 possible upgrades among MediaWiki versions V1.1–V1.11 can be performed online, through a rolling upgrade.[149]
[http://en.wikipedia.org/wiki/Mediawiki]
_Overview:
First read the UPGRADE text file included in MediaWiki.
Check the requirements
Read the release notes
Back up existing files and the database
Unpack the new files
Run the update script to check the database
Upgrade extensions
Test the update
[http://www.mediawiki.org/wiki/Manual:Upgrading]
_migrating: Migration from MW 1.5 (MySQL 3.23) to 1.17 (MySQL 5.1) ?
After much trial and error, I finally succeeded. Here is the process, for comment (and list archive).
Step 1: create a dump of the old wiki tables
MySQL 5 will not work with the tables from a mysqldump that was bundled with MySQL3. Fortunately mysqldump can run on a remote machine. My new machine has MySQL5 installed so I created the dump with the following command on the new machine:
mysqldump --host=<old.machine> -u <userName> -p <databaseName> > <file>.sql
Step 2: create a fresh installation of MW 1.17 on the new machine
(Follow the instructions; if you previously had any tables in the database, DROP them). Download and place your LocalSettings.php You should get to the stage where you have a functioning, but empty MW 1.17
Problem? In my installation, I encountered a problem that the installer had "remembered" the previous installation (where was that information stored? I had untared a fresh download!), then was not able to CREATE tables. Fortunately tables can be created manually:
mysql -u <userName> -p <databaseName> < maintenance/tables.sql
Step 3: upload your old tables, the ones you have previously dumped
mysql -u <userName> -p <databaseName> < <file>.sql
Step 4: run update
php maintenance/update.php
Initially I got an error
RENAME TABLE `ipblocks_newunique` TO `ipblocks` returned error "1050: Table ... already exists
But when I checked, that table did not exist and when I reran update.php it went through.
AND THEN my Wiki was again live.
Step 5: clean up
Indices have to be rebuilt, especially if $wgHashedUploadDirectory was used.
php maintenance/rebuildall.php
That should be all.
name::
* McsEngl.mw'Wikitext@cptIt,
* McsEngl.mw'markup@cptIt,
* McsEngl.mw'wikicode@cptIt580i,
* McsEngl.wikitext'language@cptIt1079,
* McsEngl.wiki-markup@cptIt1079,
* McsEngl.wikitext.mediaWiki@cptIt1079i,
_GENERIC:
* user-code#ql:mw'user_code#,
* mixed-code,
_DEFINITION:
Wikitext language or wiki markup is a markup language that offers a simplified alternative to HTML and is used to write pages in wiki websites such as Wikipedia. Wikitext is text in this language.
There is no commonly accepted standard wikitext language. The grammar, structure, features, keywords and so on are dependent on the particular wiki software used on the particular website. For example, all wikitext markup languages have a simple way of hyperlinking to other pages within the site, but there are several different syntax conventions for these links. Many wikis, especially the earlier ones, use CamelCase to mark words that should be automatically linked. In some wikis (such as Wikipedia and other MediaWiki-based wikis) this convention was abandoned in favor of explicit link markup, which Wikipedia calls "free links",[1] for example with [[…]].
[http://en.wikipedia.org/wiki/Wikitext]
===
Pages use MediaWiki's wikitext format, so that users without knowledge of XHTML or CSS can edit them easily.
[http://www.mediawiki.org/wiki/How_does_MediaWiki_work%3F]
name::
* McsEngl.wikitext'Resource@cptIt,
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Markup_spec,
* http://www.mediawiki.org/wiki/Wikitext_standard,
* http://www.mediawiki.org/wiki/Category:Wikitext,
* http://www.mediawiki.org/wiki/Wikitext.next,
name::
* McsEngl.wikitext'Token@cptIt,
The markup tokens fall into two broad categories:
- unary tokens (like : or * used at the beginning of a line), which stand alone, and
- binary tokens (like those for italic or boldface) which must be used in matched pairs. Unary tokens may only be preceded by comments or whitespace; otherwise, they will not be interpreted.
[http://www.mediawiki.org/wiki/Markup_spec]
name::
* McsEngl.wikitext'WikiDom@cptIt,
* McsEngl.wikiDom@cptIt580.4i,
_DESCRIPTION:
WikiDom is a serialization of Wikitext based on JSON and optimized for transport and adaptive processing. The structure is based on two basic types of nodes, branches and leafs. Branch nodes have child nodes and leaf nodes have content. A node can not be a branch and a leaf. Content objects in leaf nodes use offset annotations for formatting.
[http://www.mediawiki.org/wiki/Visual_editor/WikiDom_Specification]
name::
* McsEngl.wikidom'Content@cptIt,
_WHOLE:
* leaf-node#ql:wikidom'node.leaf#
_DESCRIPTION:
Branch nodes have child nodes and leaf nodes have content. A node can not be a branch and a leaf. Content objects in leaf nodes use offset annotations for formatting.
[http://www.mediawiki.org/wiki/Visual_editor/WikiDom_Specification]
name::
* McsEngl.wikidom'Node.Branch@cptIt,
_DESCRIPTION:
Branch nodes have child nodes and leaf nodes have content. A node can not be a branch and a leaf. Content objects in leaf nodes use offset annotations for formatting.
[http://www.mediawiki.org/wiki/Visual_editor/WikiDom_Specification]
name::
* McsEngl.wikidom'Node.Leaf@cptIt,
_DESCRIPTION:
Branch nodes have child nodes and leaf nodes have content. A node can not be a branch and a leaf. Content objects in leaf nodes use offset annotations for formatting.
[http://www.mediawiki.org/wiki/Visual_editor/WikiDom_Specification]
name::
* McsEngl.mw'wikitext.SPECIFIC@cptIt,
_SPECIFIC:
* audio-wikitext#ql:mw'wikitext.audio#,
* extension-wikitext,
* hook#ql:mw'hook#,
* html,
* link-wikitext#ql:mw'wikitext.link#,
* macro,
* magic-word#ql:mw'magic_word#,
* parser-function#ql:mw'parser_function#,
* shorthand,
* template-markup#ql:mw'template#,
* variable#ql:mw'variable#,
* xml-tag-markup#ql:mw'wikitext.tag#
MediaWiki allows users to quickly edit web pages. Editing is done by modifying an article’s source code directly within the browser. This source code, called Wikitext, is a combination of three distinct kinds of syntax: macros, shorthand, and HTML.
* Macros are either templates or hooks, both referred to by name and optionally given arguments which influence their expanded result.
* Shorthand is a meta syntax for rendering HTML as well as specifying meta information for the page.
* A subset of actual HTML is also allowed to pass through the rendering process, whereas the use of disallowed HTML tags are escaped and rendered as plain text.
[http://www.mediawiki.org/wiki/Visual_editor/Software_design]
name::
* McsEngl.mw'wikitext.Audio@cptIt,
TEMPLATE.AUDIO:
Usage
{{Audio|name of sound file|text to use as link to soundfile}}
Example:
'''Bordeaux''' ({{Audio|Fr-Bordeaux.ogg|pronunciation}}) is a [[Seaport|port]] city in...
gives this:
Bordeaux (pronunciation (help·info)) is a port city in...
Note that a printout of the page will remove the "help·info" bit and give:
Bordeaux (pronunciation ) is a port city in...
[http://en.wikipedia.org/wiki/Template:Audio]
TEMPLATE.LISTEN:
Usage
{{Listen|filename=Name of file.ogg|title=Title of this file|description=The description of this file|format=[[Ogg]]}}
Example:
{{Listen|filename=Accordian chords-01.ogg|title=Accordion chords|description=Chords being played on an accordion — 145 KB|format=[[Ogg]]}}
gives this:
Accordion chords
Play sound
Chords being played on an accordion — 145 KB
Problems listening to the file? See media help.
[http://en.wikipedia.org/wiki/Template:Listen]
name::
* McsEngl.mw'wikitext.Behavior-switch@cptIt,
* McsEngl.mw'Behavior-switch@cptIt,
_GENERIC:
* magic-word#ql:mw'magic_word#
A behavior switch controls the layout or behavior of the page and can often be used to specify desired omissions and inclusions in the content.
[http://www.mediawiki.org/wiki/Help:Magic_words#Behavior_switches]
name::
* McsEngl.mw'wikitext.CSS@cptIt,
You can use CSS styling in HTML elements in your code (see Help:HTML in wikitext for a list of elements supported by MediaWiki) like you would in normal HTML markup.
For example, a "div" element with a green border and its contents floated to the right would be created with
<div style="float:right; border:thin solid green;">
Here comes a short paragraph that is<br />
contained in a "div" element that is<br />
floated to the right.</div>
[http://meta.wikimedia.org/wiki/Help:Cascading_style_sheets]
name::
* McsEngl.mw'wikitext.Heading@cptIt,
== Section headings ==
''Headings'' organize your writing into
sections. The Wiki software can automatically
generate a table of contents from them.
=== Subsection ===
Using more equals signs creates a subsection.
==== A smaller subsection ====
name::
* McsEngl.mw'wikitext.Html@cptIt,
* McsEngl.mw'html-markup@cptIt,
_ADDRESS.WPG:
* http://meta.wikimedia.org/wiki/Help:HTML_in_wikitext,
name::
* McsEngl.mw'wikitext.Footnote@cptIt,
* McsEngl.wikitext.REFERENCES@cptIt,
CREATION:
You can add footnotes to sentences using the ''ref'' tag -- this is especially good for citing a source.
There are over six billion people in the world.<ref>CIA World Factbook, 2006.</ref>
<ref>Zwicky, Arnold (2006). ''What part of speech is "the"?'' Although some would label "the" as an adjective because it tells "which one" about the noun that follows it. By doing so, the word "the" is modifying the noun and, thus, it is quite adjectival. [[Language Log]].</ref>
For two books by the same author, published the same year, using Harvard referencing, this might be:
* Clancy, T. (1996a). Executive Orders. New York: G.P. Putnam's Sons. ISBN 0-399-14218-5
* Clancy, T. (1996b). Marine. New York: Berkley Books. ISBN 0-425-15454-8
[http://en.wikipedia.org/wiki/Wikipedia:Citing_sources]
DISPLAY OF REFERECES:
=== References===
<references/>
==Notes and references ==
{{reflist}}
MANY_TIMES:
<ref name="Wilkinson">Wilkinson, H.R. 1951. Maps and Politics (a review of the ethnographic cartography of Macedonia). Liverpool University Press</ref> (Wilkinson 1951:120). The map area was adopted by Bulgarian geographers V. Kancev, in 1900 and D.M.Brancoff in 1905.{{Failed verification|date=February 2007}}
* <ref name="Wilkinson"/> ==> appears the number of the reference where this is putted and links the same reference.
name::
* McsEngl.mw'wikitext.Format@cptIt,
wikitext.ITALICS:
You can ''italicize text'' by putting 2 apostrophes on each side.
wikitext.BOLD:
3 apostrophes will bold '''the text'''.
wikitext.BOLD&ITALICS:
5 apostrophes will bold and italicize
'''''the text'''''.
(Using 4 apostrophes doesn't do anything
special -- <br> there are just '''' left
over ones'''' that are included as part of the text.)
wikitext.PARAGRAPH:
A single newline generally has no effect on the layout. These can be used to separate sentences within a paragraph. Some editors find that this aids editing and improves the ''diff'' function (used internally to compare different versions of a page).
But an empty line starts a new paragraph.
You can break lines<br>
without a new paragraph.<br>
Please use this sparingly.
wikitext.COMMENT:
Invisible comments to editors (<!-- -->)
only appear while editing the page.
<!-- Note to editors: blah blah blah. -->
wikitext.INDENT:
: A colon (:) indents a line or paragraph.
A newline starts a new paragraph. <br>
Often used for discussion on talk pages.
: We use 1 colon to indent once.
:: We use 2 colons to indent twice.
::: 3 colons to indent 3 times, and so on.
wikitext.LINE'HORIZONTAL:
You can make horizontal dividing lines (----)
to separate text.
----
But you should usually use sections instead,
so that they go in the table of contents.
name::
* McsEngl.mw'wikitext.List@cptIt,
* McsEngl.mw'list@cptIt,
wikitext.list.Unordered:
* ''Unordered lists'' are easy to do:
** Start every line with a star.
*** More stars indicate a deeper level.
*: Previous item continues.
** A newline
* in a list
marks the end of the list.
* Of course you can start again.
wikitext.list.Numbered:
# ''Numbered lists'' are:
## Very organized
## Easy to follow
A newline marks the end of the list.
# New numbering starts with 1.
wikitext.list.Definition:
;Term : Definition of the
; A longer phrase needing definition
: Phrase defined
; A word : Which has a definition
: Also a second one
: And even a third
Begin with a semicolon. One item per line;
a newline can appear before the colon, but
using a space before the colon improves
parsing.
name::
* McsEngl.mw'wikitext.Link@cptIt,
* McsEngl.mw'link@cptIt,
* McsEngl.mw'link-markup@cptIt,
* McsEngl.wikitext.link@cptIt,
_SPECIFIC:
There are four sorts of links in MediaWiki:
- internal links to other pages in the wiki
- external links to other websites
- interwiki links to other websites registered to the wiki in advance
- Interlanguage links to other websites registered as other language versions of the wiki
[http://www.mediawiki.org/wiki/Help:Links]
wikitext.LINK.INTERNAL: Binary numeral system|binary,
= link: http://en.wikipedia.org/wiki/Binnary_numeral_system
= "binary" is the text linked.
The first letter of articles is automatically capitalized, so [[wikipedia]] goes to the same place as [[Wikipedia]]. Capitalization matters after the first letter.
The weather in London, is a page that doesn't exist yet. You could create it by clicking on the link.
wikitext.LINK.EXTERNAL:
You can make an external link just by typing a URL:
http://www.nupedia.com
You can give it a title:
[http://www.nupedia.com Nupedia]
wikitext.LINK.PICTURE: Image:Wiki.png|This Wiki's logo,
= displays the image. Displays alternate-text by putting the mouse on.
Image:Wiki.png|frame|This Wiki's logo,
= displays the image in a frame and its alternate-text.
name::
* McsEngl.mw'wikitext.link.Interwiki@cptIt,
* McsEngl.mw'interwiki-link@cptIt,
An interwiki link links to a page on another website. Unlike the name suggests, the target site need not be a wiki, but it has to be on the interwiki map specified for the source wiki. These links have the associated CSS class "extiw". These are in the same form as wikilinks above but take a prefix which specifies the target site. For example, on Wikimedia projects (except Wikipedias) and many other wikis [[wikipedia:Main Page]] links to the main page of the English Wikipedia. The prefix can be hidden using the same piped syntax as wikilinks.
[http://meta.wikimedia.org/wiki/Help:Link#Interwiki_links]
_SPECIFIC:
* [[m:Oversight]] http://meta.wikimedia.org/wiki/Oversight
name::
* McsEngl.mw'wikitext.link.InterLanguage@cptIt,
_DESCRIPTION:
Interlanguage links are the small navigation links that show up in the sidebar in most Wikipedia skins which connect an article with related articles in other languages within the same Wiki family. This can provide language-specific communities connected by a larger context, with all wikis on the same server or each on its own server.
[http://www.mediawiki.org/wiki/Interlanguage_links]
_Wikitext: el:Φωτεινό Άρτας, en:Foteino, Arta,
_Code.mw:
* http://www.mediawiki.org/wiki/Manual:Langlinks_table,
name::
* McsEngl.mw'wikitext.Macro@cptIt,
* McsEngl.mw'macro@cptIt,
_DESCRIPTION:
MediaWiki allows users to quickly edit web pages. Editing is done by modifying an article’s source code directly within the browser. This source code, called Wikitext, is a combination of three distinct kinds of syntax: macros, shorthand, and HTML.
* Macros are either templates or hooks, both referred to by name and optionally given arguments which influence their expanded result.
* Shorthand is a meta syntax for rendering HTML as well as specifying meta information for the page.
* A subset of actual HTML is also allowed to pass through the rendering process, whereas the use of disallowed HTML tags are escaped and rendered as plain text.
[http://www.mediawiki.org/wiki/Visual_editor/Software_design]
name::
* McsEngl.mw'wikitext.Magic-word@cptIt,
* McsEngl.mw'magic-word@cptIt,
_DESCRIPTION:
Magic words are strings of text that MediaWiki associates with a return value or function, such as time, site details, or page names. This page is about usage of standard magic words; for a technical reference, see Manual:Magic words.
There are three general types of magic words:
* Behavior switches: these are uppercase words surrounded by double underscores, e.g. __FOO__
* Variables: these are uppercase words surrounded by double braces, e.g. {{FOO}}. As such, they look a lot like templates.
* Parser functions: these take parameters and are either of the form {{foo:...}} or {{#foo:...}}. See also Help:Extension:ParserFunctions.
Page-dependent magic words will affect or return data about the current page (by default), even if the word is added through a transcluded template or included system message.
[http://www.mediawiki.org/wiki/Help:Magic_words]
_SPECIFIC:
* behavior-switch#ql:mw'behavior_switch#,
* parser-function#ql:mw'parser_function#,
* variable#ql:mw'variable#
name::
* McsEngl.mw'wikitext.Math@cptIt,
* McsEngl.mw'math@cptIt,
* McsEngl.mw'math-markup@cptIt,
* McsEngl.mw'math-wikitext@cptIt,
_DESCRIPTION:
MediaWiki uses a subset of TeX markup, including some extensions from LaTeX and AMS-LaTeX, for mathematical formulae. It generates either PNG images or simple HTML markup, depending on user preferences and the complexity of the expression. In the future, as more browsers are smarter, it will be able to generate enhanced HTML or even MathML in many cases. (See blahtex for information about current work on adding MathML support.)
[http://en.wikipedia.org/wiki/Help:Formula] 2008-08-28
name::
* McsEngl.mw'wikitext.Misc@cptIt,
wikitext.DISAMBIGUATION_PAGE:
* mw'page.disambiguation,
* {{disambig}}
* generic: page#ql:mw'page#,
* same-name => different concepts.
* http://www.mediawiki.org/wiki/Category:Disambiguation_pages,
* A page is treated as disambiguation page if it uses a template which is linked from MediaWiki:Disambiguationspage
wikitext.LANGUAGE_OTHER:
{{el:Φωτεινό Άρτας}}
widitext.REDIRECTION:
To redirect a page A (the redirecting page) to a different page B (the target page), enter the following redirecting command at the top of the redirecting page.
#REDIRECT [[NAME OF PAGE B]]
To go back and edit your redirect after it is working, add ?redirect=no to the end of the URL for your redirect:
http://en.wikipedia.org/wiki/Cambridge_University?redirect=no
name::
* McsEngl.mw'wikitext.Parser-function@cptIt,
* McsEngl.mw'parser-function@cptIt,
_GENERIC:
* magic-word#ql:mw'magic_word#,
* mw-developing#ql:mw'developing#
_DESCRIPTION:
Parser functions, available since 1.7, provide a way to integrate much more closely than tag extensions with templates and other parser features.
Compare with tag hook extensions, which are expected to take unprocessed text and return HTML: with tag hook extensions there is virtually no integration with the rest of the parser; for example, the output of an extension cannot be used as a template parameter. Expanding templates within extension tags is possible, but must be done manually—an error-prone process, which changes from version to version.
The typical syntax for a parser function is:
{{#functionname: param1 | param2 | param3 }}
Creating a parser function is slightly more complicated than creating a tag hook, because the function name must be a "magic word"—a kind of keyword that supports aliases and localisation.
[http://www.mediawiki.org/wiki/Manual:Parser_functions]
===
Initially MediaWiki templates were pieces of wikitext that were substituted into pages instead of copy-pasting. By 2005, any other use was rare and, to some extent, controversial. In 2006, ParserFunctions were enabled, allowing users to use constructions such as {{#if}} and {{#switch}}, essentially turning wikitext into a purely functional programming language (i.e., a language that has no concept of state at any level and one part of the code may not affect any other part, it can only change its own output). This eventually caused several problems, including performance (some pages are overloaded with templates and require 40 seconds or more to parse/render) and readability (just take a look at this).
[https://www.mediawiki.org/wiki/Scripting]
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Manual:Parser_functions,
* http://www.mediawiki.org/wiki/Help:Extension:ParserFunctions,
name::
* McsEngl.mw'pf'Creating@cptIt,
Creating a parser function is slightly more complicated than creating a tag hook, because the function name must be a "magic word"—a kind of keyword that supports aliases and localisation.
[http://www.mediawiki.org/wiki/Manual:Parser_functions]
name::
* McsEngl.mw'pf.Example@cptIt,
Example parser function extension
Below is an example of an extension that creates a parser function.
<?php
$wgExtensionCredits['parserhook'][] = array(
'path' => __FILE__, // Magic so that svn revision number can be shown
'name' => "Example Extension",
'description' => "A simple example parser function extension", // Should be using descriptionmsg instead so that i18n is supported (but this is a simple example).
'version' => 1,
'author' => "Me",
'url' => "http://www.mediawiki.org/wiki/Manual:Parser_functions",
);
# Define a setup function
$wgHooks['ParserFirstCallInit'][] = 'efExampleParserFunction_Setup';
# Add a hook to initialise the magic word
$wgHooks['LanguageGetMagic'][] = 'efExampleParserFunction_Magic';
function efExampleParserFunction_Setup( &$parser ) {
# Set a function hook associating the "example" magic word with our function
$parser->setFunctionHook( 'example', 'efExampleParserFunction_Render' );
return true;
}
function efExampleParserFunction_Magic( &$magicWords, $langCode ) {
# Add the magic word
# The first array element is whether to be case sensitive, in this case (0) it is not case sensitive, 1 would be sensitive
# All remaining elements are synonyms for our parser function
$magicWords['example'] = array( 0, 'example' );
# unless we return true, other parser functions extensions won't get loaded.
return true;
}
function efExampleParserFunction_Render( $parser, $param1 = '', $param2 = '' ) {
# The parser function itself
# The input parameters are wikitext with templates expanded
# The output should be wikitext too
$output = "param1 is $param1 and param2 is $param2";
return $output;
}
With this extension enabled,
* {{#example:hello | hi }}
produces:
param1 is hello and param2 is hi
[http://www.mediawiki.org/wiki/Manual:Parser_functions]
name::
* McsEngl.mw'wikitext.Scripting@cptIt,
* McsEngl.mw'scripting@cptIt,
* McsEngl.mw'enduser-scripting@cptIt,
_Generic:
* enduser-processing,
_PART:
* extension-scripting#ql:mw'extension.scripting#,
* magic-word#ql:mw'magic_word#,
* template#ql:mw'template#
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/User:Sumanah/Lua_vs_Javascript,
name::
* McsEngl.mw'wikitext.Section@cptIt,
* McsEngl.mw'section-in-wikitext@cptIt,
section
Limits output to a particular section or subsections of the document. Sections are specified with non-negative integers : section 0 being the section before any named sections, section one being the first named section or subsection and so on. The numbering scheme treats sections and subsections as identical. A list of the sections and subsections can be obtained via API with api.php?action=parse&text={{:My_page}}__TOC__&prop=sections.
[http://www.mediawiki.org/wiki/Manual:Parameters_to_index.php]
name::
* McsEngl.mw'wikitext.Signature@cptIt,
You should "sign" your comments
on talk pages: <br>
- Three tildes gives your
signature: ~~~ <br>
- Four tildes give your
signature plus date/time: ~~~~ <br>
- Five tildes gives the
date/time alone: ~~~~~ <br>
name::
* McsEngl.mw'wikitext.Table@cptIt,
* McsEngl.mw'table-wikitext@cptIt,
_DESCRIPTION:
Tables may be authored in wiki pages using either XHTML table elements directly, or using wikicode formatting to define the table. XHTML table elements and their use are well described on various web pages and will not be discussed here. The benefit of wikicode is that the table is constructed of character symbols which tend to make it easier to perceive the table structure in the article editing view compared to XHTML table elements.
As a general rule, it is best to avoid using a table unless you need one. Table markup often complicates page editing.
[http://www.mediawiki.org/wiki/Help:Tables]
_Table_Sortable:
{|class="wikitable sortable"
! data-sort-type="date" | Date!!Name!!Height
|-
|01.10.1977||Smith||1.85
|-
|11.6.1972||Ray||1.89
|-
|1.9.1992||Bianchi||1.72
|}
[http://meta.wikimedia.org/wiki/Help:Sorting]
name::
* McsEngl.mw'wikitext.Tag@cptIt,
* McsEngl.mw'xml-tag-wikitext@cptIt,
wikitext.tag.source:
<source lang="php">
require_once("$IP/extensions/AuthorProtect/AuthorProtect.php");
</source>
name::
* McsEngl.mw'wikitext.Variable@cptIt,
* McsEngl.mw'variable-wikitext@cptIt,
* McsEngl.mw'wtvr@cptIt, {2012-02-05}
_GENERIC:
* magic-word#ql:mw'magic_word#,
* mw-wikitext#ql:mw'wikitext#
_DESCRIPTION:
Variables are bits of wikitext that look like templates but have no parameters and have been assigned hard-coded values. Standard wiki markup such as {{PAGENAME}} or {{SITENAME}} are examples of variables. You can also extend wiki markup by defining your own custom variables.
The term is something of a misnomer because there is nothing variable about a variable. End users cannot change the value of a variable because it is predetermined by a bundle of PHP code that calculates its value. The term "variables" comes from the source of their value: a PHP variable or something that could be assigned to a variable, e.g. a string, a number, an expression, or a function return value.
[http://www.mediawiki.org/wiki/Manual:Variables]
_ADDRESS.WPG:
* http://www.mediawiki.org/wiki/Variables,
* http://www.mediawiki.org/wiki/Manual:Variables,
* http://www.mediawiki.org/wiki/Help:Variables,
* http://www.mediawiki.org/wiki/Category:Variables,
* http://www.mediawiki.org/wiki/Category:Modifiable_variables_extensions,
mw'wtvr.FULLPAGENAME:
"{{FULLPAGENAME}}" gives "Help:Page name"
[http://meta.wikimedia.org/wiki/Help:Page_name]
mw'wtvr.NAMESPASE:
"{{NAMESPACE}}" gives "Help"
[http://meta.wikimedia.org/wiki/Help:Page_name]
mw'wtvr.NUMBEROFARTICLES:
{{NUMBEROFARTICLES}} is a Magic word that returns the number of all articles (not counting Main Page). By default, a new page in the main namespace (the one without a prefix like "User:" or "Talk:") will be counted as an article in the statistics and the {{NUMBEROFARTICLES}} variable (on this project it currently gives 8,610) if it contains at least one wiki link (e.g. the text "[[Main Page]]") or is categorized to at least one category.
[http://www.mediawiki.org/wiki/Manual:Article_count]
name::
* McsEngl.pgmNet.PACKET-SNIFFER@cptIt,
* McsEngl.network-analyzer@cptIt,
* McsEngl.network-protocol-analyzer@cptIt,
* McsEngl.packet-analyzer@cptIt,
* McsEngl.packet-sniffer@cptIt,
_DESCRIPTION:
A packet analyzer (also known as a network analyzer, protocol analyzer or packet sniffer, or for particular types of networks, an Ethernet sniffer or wireless sniffer) is a computer program or a piece of computer hardware that can intercept and log traffic passing over a digital network or part of a network.[1] As data streams flow across the network, the sniffer captures each packet and, if needed, decodes the packet's raw data, showing the values of various fields in the packet, and analyzes its content according to the appropriate RFC or other specifications.
Packet capture is the process of intercepting and logging traffic.
[http://en.wikipedia.org/wiki/Packet_analyzer]
name::
* McsEngl.pgmNet.PROXY-SERVER@cptIt,
* McsEngl.conceptIt334,
* McsEngl.proxy-server@cptIt,
* McsEngl.proxy'server@cptIt334,
* McsElln.ΔΙΑΚΟΜΙΣΤΗΣ-ΜΕΣΟΛΑΒΗΣΗΣ@cptIt,
* McsElln.ΔΙΑΚΟΜΙΣΤΗΣ'ΜΕΣΟΛΑΒΗΣΗΣ@cptIt334,
In computer networks, a proxy server is a server (a computer system or an application) that acts as an intermediary for requests from clients seeking resources from other servers. A client connects to the proxy server, requesting some service, such as a file, connection, web page, or other resource, available from a different server. The proxy server evaluates the request according to its filtering rules. For example, it may filter traffic by IP address or protocol. If the request is validated by the filter, the proxy provides the resource by connecting to the relevant server and requesting the service on behalf of the client. A proxy server may optionally alter the client's request or the server's response, and sometimes it may serve the request without contacting the specified server. In this case, it 'caches' responses from the remote server, and returns subsequent requests for the same content directly.
The proxy concept was invented in the early days of distributed systems[1] as a way to simplify and control their complexity. Today, most proxies are a web proxy, allowing access to content on the World Wide Web.
A proxy server has a large variety of potential purposes, including:
To keep machines behind it anonymous, mainly for security.[2]
To speed up access to resources (using caching). Web proxies are commonly used to cache web pages from a web server.[3]
To apply access policy to network services or content, e.g. to block undesired sites.
To log / audit usage, i.e. to provide company employee Internet usage reporting.
To bypass security / parental controls.
To scan transmitted content for malware before delivery.
To scan outbound content, e.g., for data leak protection.
To circumvent regional restrictions.
To allow a web site to make web requests to externally hosted resources (e.g. images, music files, etc.) when cross-domain restrictions prohibit the web site from linking directly to the outside domains.
A proxy server that passes requests and responses unmodified is usually called a gateway or sometimes tunneling proxy.
A proxy server can be placed in the user's local computer or at various points between the user and the destination servers on the Internet.
A reverse proxy is (usually) an Internet-facing proxy used as a front-end to control and protect access to a server on a private network, commonly also performing tasks such as load-balancing, authentication, decryption or caching.
[http://en.wikipedia.org/wiki/Proxy_server]
Είναι ένα ΠΡΟΓΡΑΜΜΑ που παίζει για τα δεδομένα του internet το ρόλο που παίζει η λανθάνουσα μνήμη στους απλούς, μη δικτυωμένους υπολογιστές. Κάθε φορά που ένας χρήστης ζητά κάποια σελίδα αναλαμβάνει να τη φέρει και ενώ του την προσφέρει την αποθηκεύει στο σκληρό δίσκο. Την επόμενη φορά που θα ξαναζητηθεί η συγκεκριμένη σελίδα ο διακομιστής-μεσολάβησης θα τσεκάρει μήπως η σελίδα έχει τροποποιηθεί από την προηγούμενη φορά που την είχε ζητήσει και στην περίπτωση που όχι, θα τη διαβάσει από τον τοπικό δίσκο ταχύτατα. Αλλά ακόμα και να έχει αλλάξει, θα χρειαστεί να κατεβάσει μόνο τα αντικείμενα εκείνα της σελίδας που έχουν αλλάξει.
[ΠΗΓΗ: ΡΑΜ, 1997ιουλ, 118]
name::
* McsEngl.pgmNet.WEB-SERVICE-w3c@cptIt,
* McsEngl.web-service.w3c@cptIt350i,
The W3C defines a Web service (many sources also capitalize the second word, as in Web Service) as "a software system designed to support interoperable Machine to Machine interaction over a network." Web services are frequently just Web APIs that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services.
The W3C Web service definition encompasses many different systems, but in common usage the term refers to clients and servers that communicate using XML messages that follow the SOAP standard. Common in both the field and the terminology is the assumption that there is also a machine readable description of the operations supported by the server written in the Web Services Description Language (WSDL). The latter is not a requirement of a SOAP endpoint, but it is a prerequisite for automated client-side code generation in the mainstream Java and .NET SOAP frameworks. Some industry organizations, such as the WS-I, mandate both SOAP and WSDL in their definition of a Web service.
[http://en.wikipedia.org/wiki/Web_services]
name::
* McsEngl.pgmNet.WIKI@cptIt,
* McsEngl.conceptIt580.6,
* McsEngl.collaborative-web-program@cptIt580i, {2011-10-25}
* McsEngl.pgmWeb.WIKI@cptIt,
* McsEngl.prgWiki@cptIt580i, {2011-10-04}
* McsEngl.programWiki@cptIt580.6, {2011-12-11}
* McsEngl.wiki-application@cptIt580i, {2011-09-17}
* McsEngl.wiki-engine@cptIt580i, {2011-09-17}
* McsEngl.wiki-program@cptIt580i, {2011-09-17}
* McsEngl.wiki-software@cptIt580i, {2011-09-17}
_GENERIC:
* collaborative-program,
_DESCRIPTION:
Wiki software (also known as a wiki engine or wiki application) is collaborative software that runs a wiki, i.e., a website that allows users to create and collaboratively edit web pages via a web browser. A wiki system is usually a web application that runs on one or more web servers. The content, including all current and previous revisions, is usually stored in either a file system or a database.
Wiki software was invented and first created by programmer Ward Cunningham in 1995. There are currently dozens of actively-maintained wiki engines, in a variety of programming languages, including both open source and proprietary applications.
[http://en.wikipedia.org/wiki/Wiki_software] {2011-09-17}
name::
* McsEngl.prgWiki'Editing@cptIt,
_SPECIFIC:
* wiki-text,
* wysiwyg,
name::
* McsEngl.prgWiki'Resource@cptIt,
_SPECIFIC:
* java-opensource-wiki: http://java-source.net/open-source/wiki-engines,
name::
* McsEngl.prgWiki'Storage@cptIt,
_SPECIFIC:
* database-server,
* flat-file,
* MySQL,
* postgreSQL,
name::
* McsEngl.prgWiki'Wiki-site@cptIt,
* McsEngl.wiki@cptIt580i,
* McsEngl.wiki-site@cptIt580,
* McsEngl.wikisite@cptIt580i,
_DESCRIPTION:
wiki: A collaborative website which can be directly edited using only a web browser, often by anyone with access to it.
[http://en.wiktionary.org/wiki/wiki]
===
A wiki (IPA: [?w?.ki?] or [?wi?.ki?][1]) is a website that allows visitors to add, remove, and edit content.[2] A collaborative technology for organizing information on Web sites, the first wiki (WikiWikiWeb) was developed by Ward Cunningham in the mid-1990s.[3][4] Wikis allow for linking among any number of pages. This ease of interaction and operation makes a wiki an effective tool for mass collaborative authoring.[5] Wikipedia, an online encyclopedia, is probably the best known wiki.[4]
[http://en.wikipedia.org/wiki/Wiki]
_SPECIFIC:
* wkipedia#cptItsoft246#
_SPECIFIC:
* http://www.wikispaces.com//
* http://www.wiki-site.com/index.php/Wiki_Creation_-_Create_A_Wiki_For_Free%21,
name::
* McsEngl.prgWiki.specific@cptIt,
_SPECIFIC:
* DokuWiki, PHP, flat, wysiwyg,
* JAMWiki, java, database,
* JSPWiki, java,
* LocalWiki, python,
* MediaWiki#ql:mediawiki-580i#, PHP, database,
* MoinMoin, python,
* wikkaWiki, http://wikkawiki.org/HomePage/ freeMind support,
name::
* McsEngl.omegaWiki@cptIt580i,
* McsEngl.ow@cptIt580i,
* McsEngl.Ultimate-Wiktionary@cptIt, [http://meta.wikimedia.org/wiki/OmegaWiki]
* McsEngl.WiktionaryZ@cptIt, [http://meta.wikimedia.org/wiki/OmegaWiki]
_GENERIC:
* wiki-program#ql:wiki_program-580i#
_DESCRIPTION:
* OmegaWiki is a wiki-based project. Its aim is to bring together information that is lexicological, terminological or thesaurus-like. The software is opensource and the data is free. The key idea of OmegaWiki is to be based around concepts (which we call DefinedMeaning) rather than around words (which we call Expression). This is what makes it truly multilingual.
Another advantage of OmegaWiki with regard to traditional wikis is that data is stored in a relational database. For a computer, this means that the data is easy to retrieve, analyze and reuse. For a human, it means that the pages showing definitions are not fixed in a given language, but can be easily generated dynamically in any language. If you set the interface to French, you see the definitions in French, but contribute to the same data as e.g. another contributor having the interface in English.
[http://www.omegawiki.org/Meta:About]
===
The key idea of OmegaWiki is to be based around concepts (which we call DefinedMeaning) rather than around words (which we call Expression)
[http://www.omegawiki.org/Help:OmegaWiki]
name::
* McsEngl.ow'Administering@cptIt,
name::
* McsEngl.pwb'Installing@cptIt,
_ADDRESS.WPG:
* http://www.omegawiki.org/Development,
Strict Standards: Only variables should be passed by reference in \public_html\ow\extensions\Wikidata\OmegaWiki\OmegaWikiEditors.php on line 152
name::
* McsEngl.ow'Annotation@cptIt,
* McsEngl.ow'attribute@cptIt,
_DESCRIPTION:
The OmegaWiki software supports annotating arbitrary records in the database with other data. This allows us to implement a variety of lexicological and ontological features, such as example sentences, part of speech, hypernymy relationship, etc. The complete list of annotation attributes available at Omegawiki is explained at http://www.omegawiki.org/Help:List_of_annotations.
[http://www.omegawiki.org/Annotation]
_PART:
* text-attribute-table#ql:ow'table.text_attribute_values#
_ADDRESS.WPG:
* http://www.omegawiki.org/Help:Annotation,
* http://www.omegawiki.org/Help:List_of_annotations,
name::
* McsEngl.ow'annotation'Type@cptIt,
_DESCRIPTION:
* the types of values of the attributes.
[hmnSngo.2012-01-01]
_SPECIFIC:
* definedMeaning,
* link,
* option list,
* plain-text,
* translatable-text,
name::
* McsEngl.ow'annotation.Class-specific@cptIt,
Class specific annotations
City
country: the country where the city is located.
e.g. "France" for the city "Paris"
county: the state/county/province where the city is located
demonym: what the people living in the city are called
former name: the former name(s) of the city
e.g. "Leningrad" and "Petrograd" for the city "Saint Petersburg"
Geonames ID ????
is situated at the: the name of the river(s) that flow through the city, if any
e.g. "Seine" for the city "Paris"
latitude
longitude
[http://www.omegawiki.org/Help:List_of_annotations]
name::
* McsEngl.ow.annotation.CommonsCategory@cptIt,
_GENERIC:
* DM-attribute#ql:ow'annotation.definedmeaning#
Wikimedia Commons (http://commons.wikimedia.org) serves as a media repository for the various Wikipedia. It contains many media (mostly images and audio) which are freely usable. It is organized into categories, where one category usually represents one concept, and is often equivalent to a DefinedMeaning at OmegaWiki.
It is possible with this annotation to link a category at Commons with a DefinedMeaning. When viewing an Expression: page, the link will appear on the side of the screen with the logo of Commons.
[http://www.omegawiki.org/Help:Commons_category]
name::
* McsEngl.ow'annotation.DefinedMeaning@cptIt,
_SPECIFIC:
* Relation:
? Definition
? Alternative definitions
? Synonyms and translations
? Class membership
? Annotation
? Collection membership
? Incoming relations
name::
* McsEngl.ow'annotation.Image-from-commons@cptIt,
_DESCRIPTION:
Wikimedia Commons (http://commons.wikimedia.org) serves as a media repository for the various Wikipedia. It contains many images which are freely usable.
It is possible with this annotation to select one image from Commons to illustrate a concept. When viewing an Expression: page, the image will appear on the side of the screen. See for example Expression:mouse where each concept has a different image. The displayed image provides a link to the image description at Commons, where one can see the image at full resolution and its license information.
Since the annotation is available at the DefinedMeaning level, it means that when the image is added once for the concept, it becomes available for all the languages. In the "mouse" example, see for example Expression:souris, Expression:???, etc.
[http://www.omegawiki.org/Help:Image_from_Commons]
name::
* McsEngl.ow'annotation.Relation@cptIt,
_GENERIC:
* DM-attribute#ql:ow'annotation.definedmeaning#
_SPECIFIC:
Relations between DMs
Antonyms
Hypernyms and hyponyms
Meronyms and holonyms
name::
* McsEngl.ow'annotation.Subject@cptIt,
_GENERIC:
* DM-attribute#ql:ow'annotation.definedmeaning#
Option
agriculture
anatomy
architecture
armed forces
astronomy
biology
botany
Buddhism
chemistry
chess
Christianity
classical mythology
cuisine
economy
electronics
game
geography
geology
grammar
informatics
Islam
Judaism
linguistics
literature
mathematics
medicine
music
mythology
philosophy
physics
psychology
religion
sociology
sport
star divination
trade
zoology
name::
* McsEngl.ow'annotation.SynTrans@cptIt,
_SPECIFIC:
SynTrans grammatical case Option list Options »
SynTrans idiom Link
SynTrans etymology Translatable text
SynTrans hyphenation Plain text
SynTrans Wikipedia article Link
SynTrans number OLD Option list Options »
SynTrans usage Plain text
SynTrans usage Option list Options »
SynTrans grammatical property Option list Options »
SynTrans example sentence Plain text
SynTrans part of speech OLD Option list Options »
SynTrans gender OLD Option list Options »
SynTrans IPA Plain text
===
Annotations at a Syntrans level
* Contextual annotations
- Example sentence
Used to illustrate the proper use of an expression in a sentence.
- Usage
* Grammatical annotations
- Gender
Indicates whether a word is a masculine, feminine, neuter, etc. Genders are different in different languages.
- Grammatical property
- Part of speech
Indicates whether a word is a noun, a verb, an adjective, etc. Parts of speech are different in different languages.
* Pronunciation annotations
- Hyphenation
- International Phonetic Alphabet (IPA)
* Etymology
* Link to Wikipedia
[http://www.omegawiki.org/Help:List_of_annotations]
name::
* McsEngl.ow'Attribute-of-DM@cptIt,
_SPECIFIC:
* annotation-of-DM#ql:ow'annotation.definedmeaning#,
* borders-with,
* definition#ql:ow'definition#,
* syntrans#ql:ow'syntrans#
_SPECIFIC_CLASS_ATTRIBUTE:
Types of attributes
select distinct attribute_type from uw_class_attributes limit 10 ;
+----------------+
| attribute_type |
+----------------+
| TEXT |
| OPTN |
| DM |
| URL |
| TRNS |
+----------------+
a "TEXT" attribute is a simple text (e.g. hyphenation, IPA).
They are defined in the Text Attribute Values table.
a "OPTN" attribute is a list of predefined options (e.g. part of speeches).
The list of possible options for a given attribute are defined in the Option Attribute Options table
The list of options associated with another object will be found in the Option Attribute Values table
a "DM" attribute is a relation to another DM (e.g. antonym, hyperonym).
They are defined in the Meaning Relations table.
a "URL" attribute is a link to an external url (e.g. links to Wikipedia).
They are defined in the Url Attribute Values table
a "TRNS" attribute is a multilingual text that can be translated in several languages (e.g. etymology can be described in several languages).
They are defined in the Translated Content Attribute Values table.
[http://www.omegawiki.org/Help:Class_Attributes_table]
name::
* McsEngl.ow'class-attributes@cptIt,
_Example:
* http://www.omegawiki.org/DefinedMeaning:state_(3609))
name::
* McsEngl.ow'Class@cptIt,
_GENERIC:
* DM#ql:ow'definedmeaning#
A class defines a group of concepts that share common attributes. For instance, Belgium, Italy and Monaco belong to the class country, which makes possible to enter the following class-specific attributes: "capital", "currency", "official language", ...
Often, the elements of a class are hyponyms or instances of that class. However, this should not be mixed with the hypernym relationship which indicates direct hypernymy.
Also, classes should not be mistaken with topics.
[http://www.omegawiki.org/Help:Class]
===
How does the software know which attributes you can add where? For this, we support class membership. The class membership of a DefinedMeaning directly implies the available attributes. A class is a DefinedMeaning which is part of a specially flagged collection. When a DefinedMeaning is in such a class collection, a list of "Class attributes" can be added to it. These attributes can be restricted to a particular element of the data, e.g., the synonyms and translation, or the definitions. When you now make a DefinedMeaning a member of that class, it automatically inherits these attributes.
Any newly created DefinedMeaning is a member of certain default classes which are defined in the OmegaWiki configuration. The default class lexical item, for example, contains the "example sentence" attribute, which is therefore available for all DefinedMeanings. In the future, it will become possible to explicitly negate class membership, so that selected DefinedMeanings can be changed from the default.
[http://www.omegawiki.org/Annotation]
name::
* McsEngl.ow'Code@cptIt,
name::
* McsEngl.ow'SQL@cptIt,
GIVEN: dm=917 FIND: def-text.
SELECT uw_text#ql:ow'table.text#.text_text
FROM uw_text, uw_translated_content#ql:ow'table.translated_content#, uw_defined_meaning#ql:ow'table.defined_meaning#
WHERE uw_defined_meaning.defined_meaning_id = 915
AND uw_defined_meaning.meaning_text_tcid = uw_translated_content.translated_content_id
AND uw_translated_content.language_id = 85
AND uw_translated_content.remove_transaction_id is NULL
AND uw_text.text_id = uw_translated_content.text_id ;
GIVEN: dm=917 FIND: dm-expression.
SELECT uw_expression.spelling
FROM uw_expression#ql:ow'table.expression#, uw_defined_meaning#ql:ow'table.defined_meaning#
WHERE uw_defined_meaning.defined_meaning_id = 916
AND uw_expression.expression_id = uw_defined_meaning.expression_id ;
ORDER:
SELECT *
FROM `uw_class_membership`
ORDER BY `class_mid` DESC , `class_member_mid` DESC
name::
* McsEngl.ow'Collection@cptIt,
A collection is basically a group of concepts for which we have a particular interest in having them defined as a group.it is not very good this introduction
Furthermore, when assigning a concept (i.e. a DefinedMeaning) to a collection, it is possible to give an identifier that identifies this DM inside the collection.
Typically, content that identifies that it is from a particular source is made part of a collection eg Gemet
A collection is not a Class because it does not have an inherent structure
A collection is not a topic, because probably for the same reason...
[http://www.omegawiki.org/Help:Collection]
_ADDRESS.WPG:
* http://www.omegawiki.org/Help:List_of_collections,
name::
* McsEngl.ow'Data@cptIt,
_ADDRESS.WPG:
* http://www.omegawiki.org/User:Kipcool/English/missing,
name::
* McsEngl.ow'Database@cptIt,
_ADDRESS.WPG:
* http://www.omegawiki.org/Help:OmegaWiki_database_layout,
name::
* McsEngl.ow'Table@cptIt,
_SPECIFIC:
Community database tables
* language,
* language_names,
* uw_alt_meaningtexts,
* uw_bootstrapped_defined_meanings,
* uw_class_attributes,
* uw_class_membership,
* uw_collection,
* uw_collection_contents,
* uw_collection_language,
* uw_defined_meaning#ql:ow'table.defined_meaning#,
* uw_expression,
* uw_meaning_relations,
* uw_objects,
* uw_option_attribute_options,
* uw_option_attribute_values,
* uw_syntrans,
* uw_text,
* uw_text_attribute_values,
* uw_transactions,
* uw_translated_content,
* uw_translated_content_attribute_values,
* uw_url_attribute_values,
* wikidata_sets,
[http://www.omegawiki.org/Help:OmegaWiki_database_layout]
===
| translated_content <= not used anymore
| uw_class_attributes
| uw_class_membership
| uw_collection
| uw_collection_ns <= not used anymore
| uw_defined_meaning
| uw_expression
| uw_expression_ns <= not used anymore
| uw_meaning_relations
| uw_option_attribute_options
| uw_option_attribute_values
| uw_syntrans
| uw_text_attribute_values
| uw_translated_content
| uw_translated_content_attribute_values |
| uw_url_attribute_values
name::
* McsEngl.ow'table.Alt-meaningtexts@cptIt,
* McsEngl.ow'uw-alt-meaningtexts@cptIt,
_DESCRIPTION:
The Alt Meaningtexts table defines alternative definitions for
a concept. While the standard definitions are written and modified
by the community, the idea is to also import free resources
from other dictionaries and display them as an alternative definition.
Therefore, compared to the Defined Meaning table, this table
has an additional source_id which identifies the source.
+-----------------------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+---------+------+-----+---------+-------+
| ow'meaning_mid | int(10) | YES | | NULL | |
| ow'meaning_text_tcid | int(10) | YES | | NULL | |
| ow'source_id | int(11) | NO | | 0 | |
| ow'add_transaction_id | int(11) | NO | MUL | NULL | |
| ow'remove_transaction_id | int(11) | YES | MUL | NULL | |
+-----------------------+---------+------+-----+---------+-------+
[http://www.omegawiki.org/Help:Alt_Meaningtexts_table]
name::
* McsEngl.ow'table.Class-attributes@cptIt,
* McsEngl.ow'uw-class-attributes@cptIt,
_DESCRIPTION:
The Class Attributes table defines class attributes...
To understand what are classes and class attributes, have a look at Help:Class.
+-----------------------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+---------+------+-----+---------+-------+
| object_id | int(11) | NO | | NULL | |
| class_mid | int(11) | NO | | 0 | |
| level_mid | int(11) | NO | | NULL | |
| attribute_mid | int(11) | NO | | 0 | |
| attribute_type | char(4) | NO | | TEXT | |
| add_transaction_id | int(11) | NO | MUL | NULL | |
| remove_transaction_id | int(11) | YES | MUL | NULL | |
+-----------------------+---------+------+-----+---------+-------+
Fields
* ow'object_id
An id that identifies the current attribute.
* ow'class_mid
A link to a defined_meaning_id in the Defined Meaning table that
identifies the class (and further gives link to its name).
* ow'level_mid
A link to a defined_meaning_id in the Defined Meaning table that
identifies the level on which the attribute applies
(e.g. 401995 for Syntrans)
- 401988 DM
- 402003 Annotation
* ow'attribute_mid
A link to a defined_meaning_id in the Defined Meaning table that
identifies the attribute that is being defined (and its name, etc.).
* ow'attribute_type
The type of the attribute. See below.
* ow'add_transaction_id
Indicates when and by who the syntrans was added. See Transactions table.
* ow'remove_transaction_id
Indicates when and by who the syntrans was removed. NULL if the syntrans is still valid.
[http://www.omegawiki.org/Help:Class_Attributes_table]
_Example:
732679, 3609(state), 401988(DM), 476516(official-lang), DM, 179437, NULL
name::
* McsEngl.ow'table.Class-mebership@cptIt,
* McsEngl.ow'uw-class-membership@cptIt,
_DESCRIPTION:
The Class Membership table defines which defined meaning (or concept)
is a member of which class. This member can then be annotated with
class attributes (cf. Class Attributes table).
To understand what are classes and class attributes, have a look at
http://www.omegawiki.org/Help:Class.
+-----------------------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+---------+------+-----+---------+-------+
| class_membership_id | int(11) | NO | | NULL | |
| class_mid | int(11) | NO | | 0 | |
| class_member_mid | int(11) | NO | | 0 | |
| add_transaction_id | int(11) | NO | MUL | NULL | |
| remove_transaction_id | int(11) | YES | MUL | NULL | |
+-----------------------+---------+------+-----+---------+-------+
Fields
* ow'class_membership_id
An id that identifies this entry in the table.
* ow'class_mid
A link to a defined_meaning_id in the Defined Meaning table that
identifies the class (e.g. "animal").
* ow'class_member_mid
A link to a defined_meaning_id in the Defined Meaning table that
identifies the member of the class (e.g. "dog").
* ow'add_transaction_id
Indicates when and by who the syntrans was added. See Transactions table.
* ow'remove_transaction_id
Indicates when and by who the syntrans was removed. NULL if the syntrans is still valid.
[http://www.omegawiki.org/Help:Class_Membership_table]
name::
* McsEngl.ow'table.Collection@cptIt,
* McsEngl.ow'uw-collection@cptIt,
_DESCRIPTION:
The Collection table defines which defined meaning (or concept) is a
collection.
+-----------------------+------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+------------------+------+-----+---------+-------+
| ow'collection_id | int(10) unsigned | NO | | NULL | |
| ow'collection_mid | int(10) | NO | | 0 | |
| ow'collection_type | char(4) | YES | | NULL | |
| ow'add_transaction_id | int(11) | NO | MUL | NULL | |
| ow'remove_transaction_id | int(11) | YES | MUL | NULL | |
+-----------------------+------------------+------+-----+---------+-------+
[http://www.omegawiki.org/Help:Collection_table]
name::
* McsEngl.ow'table.Collection-contents@cptIt,
* McsEngl.ow'uw-collection-contents@cptIt,
_DESCRIPTION:
The Collection Contents table defines which defined meaning (or concept)
is a member of which collection. Collections are defined
in the Collection-table#ql:ow'table.collection#.
+------------------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------------------+--------------+------+-----+---------+-------+
| ow'object_id | int(11) | YES | | NULL | |
| ow'collection_id | int(10) | NO | MUL | 0 | |
| ow'member_mid | int(10) | NO | MUL | 0 | |
| ow'internal_member_id | varchar(255) | YES | | NULL | |
| ow'applicable_language_id | int(10) | YES | | NULL | |
| ow'add_transaction_id | int(11) | NO | MUL | NULL | |
| ow'remove_transaction_id | int(11) | YES | MUL | NULL | |
+------------------------+--------------+------+-----+---------+-------+
[http://www.omegawiki.org/Help:Collection_Contents_table]
name::
* McsEngl.ow'table.Collection-language@cptIt,
* McsEngl.ow'uw-collection-language@cptIt,
_DESCRIPTION:
The Collection Language table is a table that is empty.
Therefore, it can probably be deleted without hurting anybody.
+---------------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------+---------+------+-----+---------+-------+
| ow'collection_id | int(10) | NO | | 0 | |
| ow'language_id | int(10) | NO | | 0 | |
+---------------+---------+------+-----+---------+-------+
select * from uw_collection_language ;
Empty set (0.00 sec)
[http://www.omegawiki.org/Help:Collection_Language_table]
name::
* McsEngl.ow'table.Defined-meaning@cptIt,
* McsEngl.ow'uw-defined-meaning@cptIt,
_DESCRIPTION:
The Defined Meaning table tracks the concept and
link to their definitions.
+-----------------------+-----------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+-----------------+------+-----+---------+-------+
| ow'defined_meaning_id | int(8) unsigned | NO | MUL | NULL | |
| ow'expression_id | int(10) | NO | MUL | 0 | |
| ow'meaning_text_tcid | int(10) | NO | | 0 | |
| ow'add_transaction_id | int(11) | NO | MUL | NULL | |
| ow'remove_transaction_id | int(11) | YES | MUL | NULL | |
+-----------------------+-----------------+------+-----+---------+-------+
[http://www.omegawiki.org/Help:Defined_Meaning_table]
name::
* McsEngl.ow'table.Expression@cptIt,
* McsEngl.ow'expression-table@cptIt,
_WHOLE:
* expression#ql:ow'expression#
_DESCRIPTION:
Tracks all existing expressions, as well as expressions that have been deleted.
A expression is a specific word (e.g. "word") in a specific language (e.g. "English").
+-----------------------+------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+------------------+------+-----+---------+-------+
| ow'expression_id | int(10) unsigned | NO | MUL | NULL | |
| ow'spelling | varchar(255) | YES | | NULL | |
| ow'language_id | int(10) | NO | MUL | 0 | |
| ow'add_transaction_id | int(11) | NO | MUL | NULL | |
| ow'remove_transaction_id | int(11) | YES | MUL | NULL | |
+-----------------------+------------------+------+-----+---------+-------+
[http://www.omegawiki.org/Help:Expression_table]
name::
* McsEngl.ow'table.Language@cptIt,
* McsEngl.ow'language-table@cptIt,
_DESCRIPTION:
The Language table defines the languages that are editable in OmegaWiki
(i.e. for which we can add translations and definitions).
The names of the language are to be found in the Language Names table.
+----------------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------+-------------+------+-----+---------+----------------+
| ow'language_id | int(10) | NO | PRI | NULL | auto_increment |
| ow'dialect_of_lid | int(10) | NO | | 0 | |
| ow'iso639_2 | http://en.wikipedia.org/wiki/List_of_ISO_639-2_codes | YES | | NULL | |
| ow'iso639_3 | http://en.wikipedia.org/wiki/List_of_ISO_639-3_codes | YES | | NULL | |
| ow'wikimedia_key | varchar(10) | YES | | NULL | |
+----------------+-------------+------+-----+---------+----------------+
[http://www.omegawiki.org/Help:Language_table]
name::
* McsEngl.ow'table.Language-names@cptIt,
*
_DESCRIPTION:
The Language Names table contains the names of the languages
in several languages. A script contained in a special page takes
data from OmegaWiki itself to fill this table.
+------------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------------+--------------+------+-----+---------+-------+
| ow'language_id | int(10) | NO | PRI | 0 | |
| ow'name_language_id | int(10) | NO | PRI | 0 | |
| ow'language_name | varchar(255) | YES | | NULL | |
+------------------+--------------+------+-----+---------+-------+
[http://www.omegawiki.org/Help:Language_Names_table]
name::
* McsEngl.ow'table.Meaning-relations@cptIt,
* McsEngl.ow'uw-meaning-relations@cptIt,
_DESCRIPTION:
The Meaning Relations table defines relations between two entities
(often two DM, e.g. for antonyms, hyperonyms and the likes, but
could also be a DM related to a Syntrans, or to an expression).
The possible relations are defined in the Class-Attributes-table#ql:ow'table.class_attributes#.
+-----------------------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+---------+------+-----+---------+-------+
| ow'relation_id | int(11) | NO | | NULL | |
| ow'meaning1_mid | int(10) | NO | | 0 | |
| ow'meaning2_mid | int(10) | NO | | 0 | |
| ow'relationtype_mid | int(10) | YES | | NULL | |
| ow'add_transaction_id | int(11) | NO | MUL | NULL | |
| ow'remove_transaction_id | int(11) | YES | MUL | NULL | |
+-----------------------+---------+------+-----+---------+-------+
[http://www.omegawiki.org/Help:Meaning_Relations_table]
name::
* McsEngl.ow'table.Objects@cptIt,
_DESCRIPTION:
The Objects table contains unique identifiers that identify several
types of objects. According to the value of table,
the object_id can correspond to
a defined_meaning_id in the Defined Meaning table
a expression_id in the Expression table
... (See below).
It is particularly useful for relations to know which to types of
objects are linked by the relation.
+-------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+--------------+------+-----+---------+----------------+
| ow'object_id | int(11) | NO | PRI | NULL | auto_increment |
| ow'table | varchar(100) | YES | MUL | NULL | |
| ow'original_id | int(11) | NO | MUL | NULL | |
| ow'UUID | varchar(36) | YES | MUL | NULL | |
+-------------+--------------+------+-----+---------+----------------+
[http://www.omegawiki.org/Help:Objects_table]
name::
* McsEngl.ow'table.Option-attribute-option@cptIt,
* McsEngl.ow'uw-option-attribute-options@cptIt,
_DESCRIPTION:
The Option Attribute Options table gives the list of possible values
that an option attribute can take. Option attributes are defined in
the Class-Attributes-table#ql:ow'table.class_attributes#. The selected values from the list are then
defined in the Option Attribute Values table.
+-----------------------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+---------+------+-----+---------+-------+
| ow'option_id | int(11) | NO | | 0 | |
| ow'attribute_id | int(11) | NO | | 0 | |
| ow'option_mid | int(11) | NO | | 0 | |
| ow'language_id | int(11) | NO | | 0 | |
| ow'add_transaction_id | int(11) | NO | MUL | 0 | |
| ow'remove_transaction_id | int(11) | YES | MUL | NULL | |
+-----------------------+---------+------+-----+---------+-------+
[http://www.omegawiki.org/Help:Option_Attribute_Options_table]
name::
* McsEngl.ow'table.Option-attribute-values@cptIt,
* McsEngl.ow'uw-option-attribute-values@cptIt,
_DESCRIPTION:
The Option Attribute Values table gives the values of the
option attributes defined in the Class-Attributes-table#ql:ow'table.class_attributes#, where
the value is one from a list of possible values defined in the
Option Attribute Options table.
+-----------------------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+---------+------+-----+---------+-------+
| ow'value_id | int(11) | NO | | 0 | |
| ow'object_id | int(11) | NO | | 0 | |
| ow'option_id | int(11) | NO | | 0 | |
| ow'add_transaction_id | int(11) | NO | MUL | 0 | |
| ow'remove_transaction_id | int(11) | YES | MUL | NULL | |
+-----------------------+---------+------+-----+---------+-------+
[http://www.omegawiki.org/Help:Option_Attribute_Values_table]
name::
* McsEngl.ow'table.Syntrans@cptIt,
* McsEngl.ow'uw-syntrans@cptIt,
_DESCRIPTION:
The Syntrans table is the table that links the Expression-table#ql:ow'table.expression# with
the Defined-Meaning-table#ql:ow'table.defined_meaning#. Basically, it defines the links between
words and their definitions. To better understand what a Syntrans is,
have a look at http://www.omegawiki.org/Help:SynTrans.
+-----------------------+------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+------------+------+-----+---------+-------+
| syntrans_sid | int(10) | NO | | 0 | |
| defined_meaning_id | int(10) | NO | MUL | 0 | |
| expression_id | int(10) | NO | MUL | 0 | |
| identical_meaning | tinyint(1) | NO | | 0 | |
| add_transaction_id | int(11) | NO | MUL | NULL | |
| remove_transaction_id | int(11) | YES | MUL | NULL | |
+-----------------------+------------+------+-----+---------+-------+
Fields
* ow'syntrans_sid
A number that identifies the current syntrans
* ow'defined_meaning_id
A reference to an entry in the Defined Meaning table, i.e. one
particular concept.
* ow'expression_id
A reference to an entry in the Expression table, i.e. one
particular word of a particular language.
* ow'identical_meaning
Set to 1 if the given expression is an exact translation for the given
concept (or definedMeaning). It is set to 0 if it is only an
approximate translation. See Help:not identical.
* ow'add_transaction_id
Indicates when and by who the syntrans was added. See Transactions table.
* ow'remove_transaction_id
Indicates when and by who the syntrans was removed. NULL if the syntrans is still valid.
[http://www.omegawiki.org/Help:Syntrans_table]
name::
* McsEngl.ow'table.Text@cptIt,
* McsEngl.ow'uw-text@cptIt,
_DESCRIPTION:
The Text table contains all the texts such as definitions
(but not the expressions which are stored in the Expression-table#ql:ow'table.expression#).
+---------------+-----------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------+-----------------+------+-----+---------+----------------+
| ow'text_id | int(8) unsigned | NO | PRI | NULL | auto_increment |
| ow'text_text | mediumblob | NO | | NULL | |
| ow'text_flags | tinyblob | NO | | NULL | |
+---------------+-----------------+------+-----+---------+----------------+
[http://www.omegawiki.org/Help:Text_table]
name::
* McsEngl.ow'table.Text-attribute-values@cptIt,
* McsEngl.ow'uw-text-attribute-values@cptIt,
_WHOLE:
* annotation#ql:ow'annotation#
_DESCRIPTION:
The Text Attribute Values table gives the values of the text attributes
defined in the Class Attributes table.
+-----------------------+------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+------------+------+-----+---------+-------+
| value_id | int(11) | NO | | NULL | |
| object_id | int(11) | NO | | NULL | |
| attribute_mid | int(11) | NO | | NULL | |
| text | mediumblob | YES | | NULL | |
| add_transaction_id | int(11) | NO | MUL | NULL | |
| remove_transaction_id | int(11) | YES | MUL | NULL | |
+-----------------------+------------+------+-----+---------+-------+
Fields
* ow'value_id
An id that identifies the current table entry.
* ow'object_id
A link to an object to which the annotation is associated.
Can be a syntrans_sid, defined_meaning_id, etc. Cf. Objects table
* ow'attribute_mid
a link to an attribute_mid in the Class Attributes table, i.e. which attribute is being used (e.g. "IPA").
* ow'text
the text itself
* ow'add_transaction_id
Indicates when and by who the syntrans was added. See Transactions table.
* ow'remove_transaction_id
Indicates when and by who the syntrans was removed. NULL if the syntrans is still valid.
[http://www.omegawiki.org/Help:Text_Attribute_Values_table]
name::
* McsEngl.ow'table.Transactions@cptIt,
* McsEngl.mw'uw-transactions@cptIt,
_DESCRIPTION:
The Transactions table records when and by who an object
(expression, syntrans, definedmeaning, definition, etc.)
was added or removed. Typically, when a user makes changes
and click the "save" button, it is one transaction,
even if several changes were made.
+----------------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------+-------------+------+-----+---------+----------------+
| ow'transaction_id | int(11) | NO | PRI | NULL | auto_increment |
| ow'user_id | int(5) | NO | MUL | NULL | |
| ow'user_ip | varchar(15) | YES | | NULL | |
| ow'timestamp | varchar(14) | YES | | NULL | |
| ow'comment | tinyblob | NO | | NULL | |
+----------------+-------------+------+-----+---------+----------------+
[http://www.omegawiki.org/Help:Transactions_table]
name::
* McsEngl.ow'table.Translated-content@cptIt,
* McsEngl.ow'uw-translated-content@cptIt,
_DESCRIPTION:
The Translated Content table is typically used to store
definitions or other texts that are translated in several languages.
+-----------------------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+---------+------+-----+---------+-------+
| ow'translated_content_id | int(11) | NO | | 0 | |
| ow'language_id | int(10) | NO | | 0 | |
| ow'text_id | int(10) | NO | | 0 | |
| ow'add_transaction_id | int(11) | NO | MUL | NULL | |
| ow'remove_transaction_id | int(11) | YES | MUL | NULL | |
+-----------------------+---------+------+-----+---------+-------+
[http://www.omegawiki.org/Help:Translated_Content_table]
name::
* McsEngl.ow'table.Translated-content-attribute-values@cptIt,
* McsEngl.ow'uw-translated-content-attribute-values@cptIt,
_DESCRIPTION:
The Url Attribute Values table gives the values of the
translated content attributes defined in the Class-Attributes-table#ql:ow'table.class_attributes#.
+-----------------------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+---------+------+-----+---------+-------+
| ow'value_id | int(11) | NO | | 0 | |
| ow'object_id | int(11) | NO | | NULL | |
| ow'attribute_mid | int(11) | NO | | 0 | |
| ow'value_tcid | int(11) | NO | | 0 | |
| ow'add_transaction_id | int(11) | NO | MUL | NULL | |
| ow'remove_transaction_id | int(11) | YES | MUL | NULL | |
+-----------------------+---------+------+-----+---------+-------+
[http://www.omegawiki.org/Help:Translated_Content_Attribute_Values_table]
name::
* McsEngl.ow'table.Url-attribute-values@cptIt,
* McsEngl.ow'uw-url-attribute-values@cptIt,
_DESCRIPTION:
The Url Attribute Values table gives the values of the url attributes
defined in the Class Attributes table.
+-----------------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+--------------+------+-----+---------+-------+
| value_id | int(11) | NO | | NULL | |
| object_id | int(11) | NO | | NULL | |
| attribute_mid | int(11) | NO | | NULL | |
| url | varchar(255) | YES | | NULL | |
| label | varchar(255) | YES | | NULL | |
| add_transaction_id | int(11) | NO | MUL | NULL | |
| remove_transaction_id | int(11) | YES | MUL | NULL | |
+-----------------------+--------------+------+-----+---------+-------+
Fields
* ow'value_id
An id that identifies the current table entry.
* ow'object_id
A link to an object to which the annotation is associated. Can be
a syntrans_sid, defined_meaning_id, etc. Cf. Objects table
* ow'attribute_mid
a link to an attribute_mid in the Class Attributes table, i.e. which attribute is being used (e.g. "link to Wikipedia").
* ow'url
the url given as a string.
* ow'label
what will be displayed in the interface. Basically, <a href="$url">$label</a>
* ow'add_transaction_id
Indicates when and by whom the annotation was added. See Transactions table.
* ow'remove_transaction_id
Indicates when and by whom the annotation was removed. NULL if still valid.
[http://www.omegawiki.org/Help:Url_Attribute_Values_table]
name::
* McsEngl.ow'table.Wikidata-sets@cptIt,
*
_DESCRIPTION:
The Wikidata Sets table enumerates the different sets of data that coexist in a Wikidata implementation.
+-------------------+-----------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+-----------------+------+-----+---------+-------+
| set_prefix | varchar(20) | YES | | NULL | |
| set_fallback_name | varchar(255) | YES | | NULL | |
| set_dmid | int(10) | YES | | NULL | |
| virtual_user_id | int(8) unsigned | YES | | NULL | |
+-------------------+-----------------+------+-----+---------+-------+
[http://www.omegawiki.org/Help:Wikidata_Sets_table]
name::
* McsEngl.ow'DefinedMeaning@cptIt,
* McsEngl.ow'concept@cptIt,
A DefinedMeaning is a combination of an Expression and a Definition;
an Expression being a given graphic form (Spelling) associated with a given Language; and a Definition being the concept expressed by this Expression restated in one or several sentences.
[http://www.omegawiki.org/DefinedMeaning]
===
The key idea of OmegaWiki is to be based around concepts (which we call DefinedMeaning) rather than around words (which we call Expression)
[http://www.omegawiki.org/Help:OmegaWiki]
_ATTRIBUTE:
? Definition
? Alternative definitions
? Synonyms and translations
? Class membership
? Annotation
? - Relations
? - Links
? - Option values
? Collection membership
? Incoming relations
[from edit page]
name::
* McsEngl.ow'Definition@cptIt,
A Definition is a paraphrase, using one or several sentences, of the concept expressed by a given Expression. This Definition together with that Expression constitutes the DefinedMeaning. Various forms of the same word will be paired up with the same Definition to constitute their own DefinedMeaning in a manner not yet fixed.
[http://www.omegawiki.org/Help:Definition]
name::
* McsEngl.ow'Expression@cptIt,
* McsEngl.ow'word@cptIt,
_DESCRIPTION:
The Expression table is a table in the database. It is a combination of characters that make up a word or a phrase.
[http://www.omegawiki.org/Expression]
===
The key idea of OmegaWiki is to be based around concepts (which we call DefinedMeaning) rather than around words (which we call Expression)
[http://www.omegawiki.org/Help:OmegaWiki]
Let's consider the example where you want to retrieve all the definitions of DefinedMeaning:dictionary_(915)
select uw_text.text_text, language_id
from uw_text#ql:ow'table.text#, uw_translated_content, uw_defined_meaning
where uw_defined_meaning.defined_meaning_id = 915
and uw_defined_meaning.meaning_text_tcid = uw_translated_content.translated_content_id
and uw_translated_content.remove_transaction_id is NULL
and uw_text.text_id = uw_translated_content.text_id ;
[http://www.omegawiki.org/Help:Translated_Content_table]
name::
* McsEngl.ow'Evolution@cptIt,
{time.2007}:
Around 2007, the first prototype version of OmegaWiki came online (at the time, it was called WiktionaryZ, but renamed later on because it is not a WMF project).
Concerns were expressed such as:
I contributed so much data to Wiktionary, I want this data to be automatically imported before I come to OmegaWiki
it lacks a lot of features that I'd like to see before I come from Wiktionary (e.g. inflexions table which we still don't have)
discussions on such a multilingual project will be obviously mainly held in English, and my English is not good enough, so I prefer to stay on my language version of Wiktionary
Then, we had no programmer anymore to implement new features.
[http://omegawiki.blogspot.com/2011/10/omegawiki-wiktionary-and-wikimedia.html]
Important dates during the life of the project
-- 2007 --
October 12, 2007 It's now possible to add links to a Wikipedia article on expressions
June 3, 2007 We have reached 250,000 Expressions.
-- 2006 --
December 12, 2006 WiktionaryZ is being renamed to OmegaWiki. This is to prevent confusion between this project and the WMF Wiktionary projects.
October 3, 2006 Start of the OLPC Children's Dictionary project.
approx. August 2006 version 1.0
April 30 2006 a first editable prototype (for a restricted number of people) came online
end of February 2006 a second read-only prototype is online
January 2006 the name of Ultimate Wiktionary is changed to WiktionaryZ
January 2006 the WiktionaryZ Committee starts working
-- 2005 --
December 26 2005 first read-only prototype
March 2005 first database design
-- 2004 --
August 30 2004 first discussions
[http://en.wikipedia.org/wiki/Wikipedia:OmegaWiki]
name::
* McsEngl.ow'Feature-request@cptIt,
I think that the part-of-speech annotation, in the syntrans table, because of its importance, should be moved in a new column, after "identical meaning?". --~~~~
name::
* McsEngl.ow'Human@cptIt,
_SPECIFIC:
User:Admin, Erik-Moeller#ql:mw'moeller_eric#, currently lead developer of OmegaWiki and chief architect of Wikidata. I use this administrative account for technical operations related to OmegaWiki development. My account as a regular editor is User:Eloquence, and is subject to whatever community processes and policies are developed here.
- moeller AT scireview DOT de,
* erik (at) wikimedia (dot) org,
* http://meta.wikimedia.org/wiki/User:Eloquence,
===
* Kipcool#ql:ow'kipcool# (Talk | contribs)?? (bureaucrat, Check user, administrator, wikidata-omega) [874 edits in the last 30 days]
* Malafaya (Talk | contribs)?? (bureaucrat, administrator, wikidata-omega) [5 edits in the last 30 days]
* Tosca (Talk | contribs)?? (bureaucrat, administrator, wikidata-omega) [168 edits in the last 30 days]
===
Ascαnder (Talk | contribs)?? (administrator, wikidata-omega) [41 edits in the last 30 days]
Fiable.biz (Talk | contribs)?? (administrator, wikidata-omega) [77 edits in the last 30 days]
Fulup (Talk | contribs)?? (administrator, wikidata-omega) [30 edits in the last 30 days]
Hiong3.eng5 (Talk | contribs)?? (administrator, wikidata-omega) [3 edits in the last 30 days]
McDutchie (Talk | contribs)?? (administrator, wikidata-omega) [1 edit in the last 30 days]
Ortografix (Talk | contribs)?? (administrator, wikidata-omega) [1 edit in the last 30 days]
Patio (Talk | contribs)?? (administrator, wikidata-omega) [2 edits in the last 30 days]
Rappo (Talk | contribs)?? (administrator, wikidata-omega) [116 edits in the last 30 days]
Roggy (Talk | contribs)?? (administrator, wikidata-omega) [3 edits in the last 30 days]
Veeven (Talk | contribs)?? (administrator, wikidata-omega) [2 edits in the last 30 days]
===
Conlanger (Talk | contribs)?? (wikidata-omega) [4 edits in the last 30 days]
Mikemoral (Talk | contribs)?? (wikidata-omega) [4 edits in the last 30 days]
Minh Nguyen (Talk | contribs)?? (wikidata-omega) [1 edit in the last 30 days]
Robin Lionheart (Talk | contribs)?? (wikidata-omega) [20 edits in the last 30 days]
===
JisaruDobiye (Talk | contribs) [1 edit in the last 30 days]
Maxeyre (Talk | contribs) [1 edit in the last 30 days]
RovemeCewete (Talk | contribs) [1 edit in the last 30 days]
Synagonism (Talk | contribs) [1 edit in the last 30 days]
VumubeLowigu (Talk | contribs) [1 edit in the last 30 days]
_ADDRESS.WPG:
* http://www.omegawiki.org/User:SabineCretella,
name::
* McsEngl.ow'Meijssen-Gerard@cptIt,
* McsEngl.ow'GerardM@cptIt,
name::
* McsEngl.ow'Mellet-Christophe@cptIt,
* McsEngl.ow'kipcool@cptIt,
* McsEngl.ow'Christophe-Millet@cptIt,
_IRC:
Kipcool on#wiktionary,#omegawiki,#wiktionary-fr,#wiktionary-de,#wikcionario.
_ADDRESS.WPG:
* http://www.omegawiki.org/User:Kipcool,
* http://meta.wikimedia.org/wiki/User:Kipmaster,
name::
* McsEngl.ow'Resource@cptIt,
_SPECIFIC:
* http://omegawiki.blogspot.com//
* http://meta.wikimedia.org/wiki/Ultimate_Wiktionary_data_design,
* http://meta.wikimedia.org/wiki/Category:Wikidata,
* http://meta.wikimedia.org/wiki/Category:Ultimate_Wiktionary,
* http://meta.wikimedia.org/wiki/OmegaWiki,
* http://en.wikipedia.org/wiki/Wikipedia:OmegaWiki,
* feature-reguest: http://www.omegawiki.org/Functionality_wanted_..,
* bugs: https://bugzilla.wikimedia.org//
name::
* McsEngl.ow'SynTrans@cptIt,
_GENERIC:
* attribute-of-DM#ql:ow'attribute_of_dm#
A SynTrans is one particular DefinedMeaning of one particular expression. Expressed differently, the association of one word with one definition is a SynTrans.
[edit] Examples
For example, let's consider "mouse".
"mouse" is an expression E1 (i.e. the five letter word m-o-u-s-e in English)
There are (at least) two definitions of "mouse" in English:
"an animal", this concept is one DefinedMeaning D1
"a device", this concept is another DefinedMeaning D2
In that case, we have the following SynTrans:
A first SynTrans S1 is the association of the expression E1 with the DefinedMeaning D1
A second SynTrans S2 is the association of the expression E1 with the DefinedMeaning D2
If we consider that "computer mouse" is a second expression E2, then we have a third SynTrans S3 which is the association of the expression E2 with the DefinedMeaning D2.
[http://www.omegawiki.org/Help:SynTrans]
name::
* McsEngl.ow'Topic@cptIt,
What is a topic
A topic, or subject, in OmegaWiki is used to indicate the field of knowledge to which a particular DefinedMeaning belongs. For example: Biology, Chemistry, Linguistic, Mathematics, ....
Often, the definition is ambiguous, and sometimes useless, if the topic is not indicated (for example: "derivative"). Therefore it is important to indicate a topic.
In general, one DefinedMeaning should have one and only one topic. If a word seems to belong to two topics, maybe it should be divided into two distinct definitions.
The list of topics is a limited set that has to be discussed and agreed by the community. It is always possible to add new topics. You can propose them there.
[edit] A topic is not a class
The aim of a class is to allow to add specific attributes. For example:
Paris belongs to the class "city" which could allow us to indicate that it is in the country "France".
Paris has the topic "geography"
[http://www.omegawiki.org/Help:Topic]
name::
* McsEngl.pgmNet.WIRESHARK@cptIt,
* McsEngl.etherreal@cptIt,
* McsEngl.wireshark@cptIt,
* McsEngl.wsk@cptIt,
_DESCRIPTION:
What is Wireshark?
A: Wireshark® is a network protocol analyzer. It lets you capture and interactively browse the traffic running on a computer network. It has a rich and powerful feature set and is world's most popular tool of its kind. It runs on most computing platforms including Windows, OS X, Linux, and UNIX. Network professionals, security experts, developers, and educators around the world use it regularly. It is freely available as open source, and is released under the GNU General Public License version 2.
It is developed and maintained by a global team of protocol experts, and it is an example of a disruptive technology.
Wireshark used to be known as Ethereal®. See the next question for details about the name change. If you're still using Ethereal, it is strongly recommended that you upgrade to Wireshark.
For more information, please see the About Wireshark page.
[http://www.wireshark.org/faq.html#q1.1]
===
Wireshark is a free and open-source packet analyzer. It is used for network troubleshooting, analysis, software and communications protocol development, and education. Originally named Ethereal, in May 2006 the project was renamed Wireshark due to trademark issues.[3]
Wireshark is cross-platform, using the GTK+ widget toolkit to implement its user interface, and using pcap to capture packets; it runs on various Unix-like operating systems including Linux, OS X, BSD, and Solaris, and on Microsoft Windows. There is also a terminal-based (non-GUI) version called TShark. Wireshark, and the other programs distributed with it such as TShark, are free software, released under the terms of the GNU General Public License.
[http://en.wikipedia.org/wiki/Wireshark]
===
1.1.8. What Wireshark is not
Here are some things Wireshark does not provide:
Wireshark isn't an intrusion detection system. It will not warn you when someone does strange things on your network that he/she isn't allowed to do. However, if strange things happen, Wireshark might help you figure out what is really going on.
Wireshark will not manipulate things on the network, it will only "measure" things from it. Wireshark doesn't send packets on the network or do other active things (except for name resolutions, but even that can be disabled).
[file:///D:/pgmNET/wireshark/wsug_html/user-guide.html#h5o-6]
name::
* McsEngl.wsk'code@cptIt,
Wireshark is implemented in ANSI C, which is vulnerable to security problems like buffer overflows (compared to more securely designed languages like Java or C#). ANSI C is used for several reasons; the main reason is performance, as Wireshark is often used to work with huge amounts of data. Another reason is that implementations of other languages might not be as commonly available on all the platforms Wireshark supports.
[http://wiki.wireshark.org/Security#Why_is_Wireshark_so_buggy.3F]
name::
* McsEngl.wsk'error@cptIt,
name::
* McsEngl.wsk'checksum@cptIt,
What are checksums for?
Checksums are used to ensure the integrity of data portions for data transmission or storage. A checksum is basically a calculated summary of such a data portion.
Network data transmissions often produce errors, such as toggled, missing or duplicated bits. As a result, the data received might not be identical to the data transmitted, which is obviously a bad thing.
Because of these transmission errors, network protocols very often use checksums to detect such errors. The transmitter will calculate a checksum of the data and transmits the data together with the checksum. The receiver will calculate the checksum of the received data with the same algorithm as the transmitter. If the received and calculated checksums don't match a transmission error has occurred.
Some checksum algorithms are able to recover (simple) errors by calculating where the expected error must be and repairing it.
If there are errors that cannot be recovered, the receiving side throws away the packet. Depending on the network protocol, this data loss is simply ignored or the sending side needs to detect this loss somehow and retransmits the required packet(s).
Using a checksum drastically reduces the number of undetected transmission errors. However, the usual checksum algorithms cannot guarantee an error detection of 100%, so a very small number of transmission errors may remain undetected.
There are several different kinds of checksum algorithms; an example of an often used checksum algorithm is CRC32. The checksum algorithm actually chosen for a specific network protocol will depend on the expected error rate of the network medium, the importance of error detection, the processor load to perform the calculation, the performance needed and many other things.
Further information about checksums can be found at: http://en.wikipedia.org/wiki/Checksum.
[file:///D:/pgmNET/wireshark/wsug_html/user-guide.html#h5o-202]
name::
* McsEngl.wsk'evoluting@cptIt,
{time.2006}:
[file:///D:/pgmNET/wireshark/wsug_html/user-guide.html#h5o-28]
{time.2008}:
=== VERSION 1.0:
In 2008, after ten years of development, Wireshark finally arrived at version 1.0. This release was the first deemed complete, with the minimum features implemented. Its release coincided with the first Wireshark Developer and User Conference, called SharkFest.
[file:///D:/pgmNET/wireshark/wsug_html/user-guide.html#h5o-28]
{time.2006}:
=== NEW NAME WIRESHARK:
In 2006 the project moved house and re-emerged under a new name: Wireshark.
[file:///D:/pgmNET/wireshark/wsug_html/user-guide.html#h5o-28]
{time.1998}:
=== INITIAL RELEASE ETHEREAL 0.2.0:
In late 1997, Gerald Combs needed a tool for tracking down networking problems and wanted to learn more about networking, so he started writing Ethereal (the former name of the Wireshark project) as a way to solve both problems.
Ethereal was initially released, after several pauses in development, in July 1998 as version 0.2.0. Within days, patches, bug reports, and words of encouragement started arriving, so Ethereal was on its way to success.
[file:///D:/pgmNET/wireshark/wsug_html/user-guide.html#h5o-28]
name::
* McsEngl.wsk'filtering@cptIt,
Wireshark has two filtering languages: One used when capturing packets, and one used when displaying packets.
[file:///D:/pgmNET/wireshark/wsug_html/user-guide.html#h5o-147]
name::
* McsEngl.wsk'pane@cptIt,
name::
* McsEngl.wsk'pane.PACKET-LIST@cptIt,
_DESCRIPTION:
The packet list pane (see Section 3.18, “The "Packet List" pane”) displays a summary of each packet captured. By clicking on packets in this pane you control what is displayed in the other two panes.
[file:///D:/pgmNET/wireshark/wsug_html/user-guide.html#h5o-65]
name::
* McsEngl.wsk'pane.PACKET-DETAILS@cptIt,
_DESCRIPTION:
The packet details pane (see Section 3.19, “The "Packet Details" pane”) displays the packet selected in the packet list pane in more detail.
[file:///D:/pgmNET/wireshark/wsug_html/user-guide.html#h5o-65]
name::
* McsEngl.wsk'pane.PACKET-BYTES@cptIt,
_DESCRIPTION:
The packet bytes pane (see Section 3.20, “The "Packet Bytes" pane”) displays the data from the packet selected in the packet list pane, and highlights the field selected in the packet details pane.
[file:///D:/pgmNET/wireshark/wsug_html/user-guide.html#h5o-65]
name::
* McsEngl.wsk'resourceInfHmn@cptIt,
_ADDRESS.WPG:
* https://www.wireshark.org//
* https://www.wireshark.org/docs//
* http://wiki.wireshark.org//
* http://wiki.wireshark.org/WinPcap,
* https://blog.wireshark.org//
* http://ask.wireshark.org//
_ADDRESS.WPG:
* file:///D:/pgmNET/wireshark/wsug_html/user-guide.html,
name::
* McsEngl.wsk'statusbar@cptIt,
The statusbar (see Section 3.21, “The Statusbar”) shows some detailed information about the current program state and the captured data.
[file:///D:/pgmNET/wireshark/wsug_html/user-guide.html#h5o-65]
name::
* McsEngl.conceptIt10,
* McsEngl.Cmrpgm.APPLICATION-GENERATOR@cptIt,
* McsEngl.FvMcs.Cmrpgm.APPLICATION-GENERATOR@cptIt,
* McsEngl.application-generator@cptIt,
* McsEngl.application'generator@cptIt10,
* McsEngl.program.system.applicationgenerator@cptIt10,
* McsElln.ΓΕΝΝΗΤΡΙΑ-ΕΦΑΡΜΟΓΩΝ@cptIt,
APPLICATION GENERATOR is an system program that create application programs, function 444-4.
PROGRAMS#ql:[Field program:application'generator]# {|4| Application'generator}
name::
* McsEngl.conceptIt373,
* McsEngl.Cmrpgm.COMMUNICATION@cptIt,
* McsEngl.FvMcs.Cmrpgm.COMMUNICATION@cptIt,
* McsEngl.communication-program@cptIt,
* McsEngl.program.communication@cptIt373,
* McsElln.ΠΡΟΓΡΑΜΜΑ-ΕΠΙΚΟΙΝΩΝΙΑΣ@cptIt,
_GENERIC:
* PROGRAM#cptIt59#
communication technology#cptIt244#
PROGRAMS#ql:[Field program:communication]# COMMUNICATION
_CREATED: {1994} {1992} {1990} {1985}
name::
* McsEngl.conceptIt356,
* McsEngl.Cmrpgm.ModelConceptStructured-Manager-(Mcsm)@cptIt,
* McsEngl.FvMcs.Cmrpgm.ModelConceptStructured-Manager-(Mcsm)@cptIt,
* McsEngl.Mcsm@cptIt, {2020-06-17}
* McsEngl.Mcsmgr@cptIt,
* McsEngl.programModelConceptStructured@cptIt, {2016-08-23}
* McsEngl.programConcept@cptIt,
* McsEngl.artificial-brainepto-model-integrator@cptIt,
* McsEngl.bb-management@cptIt,
* McsEngl.bbm@cptIt,
* McsEngl.bbmanager@cptIt,
* McsEngl.bbp@cptIt,
* McsEngl.bbpp@cptIt, {2007-12-08}
* McsEngl.bbpp@cptIt,
* McsEngl.BBprogram@cptIt,
* McsEngl.bmdi@cptIt,
* McsEngl.bmdm@cptIt,
* McsEngl.bmm@cptIt, {2006-01-01}
* McsEngl.brain-model-management-program@cptIt,
* McsEngl.brainepto-base-purification-program@cptIt,
* McsEngl.brainepto-base-management-program@cptIt,
* McsEngl.brainepto-base-program@cptIt, {2007-12-01}
* McsEngl.brainepto-base-manager@cptIt, {2007-11-27}
* McsEngl.brainepto-base-management@cptIt, {2007-11-26}
* McsEngl.brainepto-model--integrator@cptIt, {2007-01-30}
* McsEngl.breinepto-model--management@cptIt,
* McsEngl.cbscms@cptIt, {2013-04-03}
* McsEngl.cbs-cms@cptIt, {2013-04-03}
* McsEngl.cbs-management-system@cptIt, {2013-03-30}
* McsEngl.cbsMgr@cptIt, {2011-05-27}
* McsEngl.cbsms@cptIt, {2013-03-30}
* McsEngl.cbsPrg@cptIt, {2012-03-18}
* McsEngl.cmsCbs@cptIt, {2013-04-03}
* McsEngl.cms.cbs@cptIt, {2013-04-03}
* McsEngl.ConceptBrainualSensorialManager@cptIt, {2011-05-27}
* McsEngl.concept-editor, {2016-03-15}
* McsEngl.concept-processor, {2016-03-12} [//in contrast 'word-processor']
* McsEngl.kcsProgram@cptIt,
* McsEngl.kms.scs@cptIt,
* McsEngl.KNBprogram@cptIt, {2007-12-19}
* McsEngl.KNprogram@cptIt, {2007-12-18}
* McsEngl.Knowledge-Management-System@cptIt, {1999-02-08}
* McsEngl.knowledge-system-management@cptIt, {2007-11-25}
* McsEngl.knowledge-integrator@cptIt, {2007-06-22}
* McsEngl.koncesto-program@cptIt, {2008-01-19}
* McsEngl.kognepto-base-program@cptIt,
* McsEngl.ksm@cptIt,
* McsEngl.info-system-management@cptIt,
* McsEngl.integruolo@cptIt, {2007-07-30} [=> I want to emphasize its integration function and NOT just the management which is more generic]
* McsEngl.mcs-manager@cptIt,
* McsEngl.mcs'program@cptIt,
* McsEngl.Mcs-pgm@cptIt, {2017-10-15} (emphais on mcs)
* McsEngl.mdbm@cptIt, {2006-06-01}
* McsEngl.mdbm@cptIt,
* McsEngl.model-breinepto--management@cptIt, {2006-06-01}
* McsEngl.model-breinepto's--management@cptIt,
* McsEngl.model-breinepto-management@cptIt,
* McsEngl.prgCbs@cptIt, {2013-03-27}
* McsEngl.pgmCmr.ConceptBrainSensorial-Manager@cptIt,
* McsEngl.sbcMgr@cptIt, {2011-05-28}
* McsEngl.SBViewManager@cptIt, {2011-01-29}
* McsEngl.Science-Support-System@cptIt, {1990}
* McsEngl.SciMgr@cptIt, {2011-01-28}
* McsEngl.SCprogram@cptIt, {2008-01-13}
* McsEngl.scs@cptIt,
* McsEngl.SCS@cptIt, {1999-05-13}
* McsEngl.scs-creator@cptIt, {1997-05-06}
* McsEngl.scs-editor/browser@cptIt, {1997-10-05}
* McsEngl.scs-kms@cptIt, {1997-11-09}
* McsEngl.scs-program@cptIt, {1997-11}
* McsEngl.scs-sss@cptIt, {1999-08-27}
* McsEngl.scs-science-support-system@cptIt,
* McsEngl.scs-tool@cptIt,
* McsEngl.scsc-program@cptIt, {1997-05-09}
* McsEngl.SCSC@cptIt,
* McsEngl.SensorialBrainualViewManager@cptIt, {2011-01-29}
* McsEngl.SensorialConceptProgram@cptIt,
* McsEngl.Structured-Concept-System-KMS@cptIt, {1997-11-09}
* McsEngl.structured-concept-manager@cptIt, {2016-08-23}
* McsEngl.structured-concept-system-editor/browser@cptIt, {1997-10-05}
* McsEngl.structured-concept-system-creator-program@cptIt,
* McsEngl.sss@cptIt, {1990}
* McsEngl.pgmMcs@cptIt, {2016-08-23}
* McsEngl.pgmCpt@cptIt,
* McsEngl.cbsmgr@cptIt, {2013-07-31}
* McsEngl.cbscms-it356@cptIt, {2013-04-04}
====== lagoSinago:
* McsEngl.integruolo-modilo-brainepto@lagoSngo, {2007-01-30}
* McsEngl.imdb@lagoSngo,
====== lagoGreek:
* McsElln.ΔΟΜΗΜΕΝΩΝ-ΕΝΝΟΙΩΝ-ΣΥΣΤΗΜΑ-ΔΙΑΧΕΙΡΙΣΗΣ-ΓΝΩΣΗΣ@cptIt, {1999feb08}
* McsElln.ΠΡΟΓΡΑΜΑ-ΔΗΜΙΟΥΡΓΙΑΣ-ΣΥΣΤΗΜΑΤΩΝ-ΔΟΜΗΜΕΝΩΝ-ΕΝΝΟΙΩΝ@cptIt,
* McsElln.ΣΥΣΤΗΜΑ-ΔΟΜΗΜΕΝΩΝ-ΕΝΝΟΙΩΝ@cptIt,
_SENSORIAL_CONCEPT_PROGRAM:
This program has many features. To name it I must found the most "important": integrated, multiauthor, sensorial_concept, multilanguage, etc. I think "sensorial_concept" is the attribute that makes the difference with any other entity people used until now. SCP then is a good name for it in english.
[KasNik, 2008-01-13]
===
bbpp:
I use the "purification" word because creates symmetricity. The word "management" is also a good word to express what this is all about.
[KasNik, 2007-12-10]
===
In my internet-page I use the name "bmm breinepto-model--management" because I don't use in that page the "specific-name-convention" I use in my writings, in which in a specific name first I use the name the generic-concept and then the attribute-concept.
[nikkas 2006-06-01]
===
I avoid to use the name 'kms' because today with this name THEY mean a system to manage corporate knowledge!!!
[nikkas 1999may13]
Mcs-pgm is a-knowledge-management-program.
Knowledge is system-of-concepts.
A-concept is a-model of an-entity of our environment and resides in our brains.
The-mcs-pgm uses structured-concepts-(mcs) as a-model of a-concept and are-strored in a-computer.
The-mcs-pgm manages knowledge as a-system-of-mcs.
[hmnSngo.2017-10-25]
BBmanager is a INFORMATION-MANAGEMENT-TOOL that help us to create and manage integrated__artificial_brainepto_bases#cptCore0# and consequently integrated--brainepto-bases.
[KasNik, 2007-11-28]
A Structured-Concept--SYSTEM is a TOOL (mainly a computer-program) that help us to MANAGE a Structured-Concept--MODEL.
[hmnSngo.2003-10-25]
SC-Model--Management-System is a Conceptual-Model--Management-System#cptCore402# that manages Structured-Concept--Models.
[nikkas 2003-02-14]
SCS is a Mental-Model#cptCore985.1# Management System that is mainly comprised with Structured-Concepts.
[hmnSngo.2001-12-21]
SCS is a Conceptual-Information Management System that creates Integrated-Concept-Bases#cptCore0.1# using STRUCTURED-CONCEPTS to represent a concept#cptCore383.1#.
(this definition emphasizes the 'integrated' aspect of the created concept-bases.)
[hmnSngo.{2001-04-29}]
SCS is a ConceptBase Management System that uses STRUCTURED-CONCEPTS to represent a concept#cptCore383.1#.
[hmnSngo.{2001-04-26}]
SCS-KMS is a KMS#cptIt497# that uses STRUCTURED-CONCEPTS as a mean to organize knowledge.
[nikos, {1997-11-09}]
name::
* McsEngl.Mcsm'ENVIRONMENT@cptIt,
* BRAIN#cptCore21#
A mdbm "resembles" a brain because a brain manages a model-breinepto.
[hmnSngo.2006-06-16]
name::
* McsEngl.Mcsm'Project-Halo@cptIt,
* McsEngl.Halo-project@cptIt356i,
_GENERIC:
* related-project#ql:cbsmgr'related_project#
_DESCRIPTION:
Project Halo is a staged, long-range research effort by Vulcan Inc. towards the development of a "Digital Aristotle"—a reasoning system capable of answering novel questions and solving advanced problems in a broad range of scientific disciplines and related human affairs. The project focuses on creating two primary functions: a tutor capable of instructing and assessing students in those subjects, and a research assistant with broad, interdisciplinary skills to help scientists and others in their work.
[http://projecthalo.com//]
===
Project Halo[7] is a project that has run since October 2002, with the goal of creating a "digital Aristotle" that can correctly answer queries about scientific information, using artificial intelligence technology. The project is managed by Mark Greaves. Project Halo has led to a number of spinoff technologies, including the wiki software bundle SMW+, the Semantic Inferencing on Large Knowledge (SILK) project[8] and the Automated User-Centered Reasoning and Acquisition System (AURA).[9]
[http://en.wikipedia.org/wiki/Project_Halo#Project_Halo]
_ADDRESS.WPG:
* http://projecthalo.com//
name::
* McsEngl.AURA@cptIt356i,
_DESCRIPTION:
Module-centered knowledge acquisition: AURA features a novel document-centric knowledge acquisition interface. This interface is an application of the concept of graphical assembly of knowledge from components and is based on the hypothesis that circumscribed knowledge fragments, in particular paragraphs from a textbook, can indeed be formulated by subject matter experts in a modular fashion using self-contained and well-packaged components. If successful, this will substantially reduce the cost of knowledge formation as compared to what we saw during Halo Pilot Phase. The success of this hypothesis will also set the stage for the large scale construction of a knowledge base that is central for realizing the dream of Digital Aristotle.
[http://www.ai.sri.com/project/aura]
Jesse Wang:
* http://semantic-mediawiki.org/wiki/User:Jesse,
name::
* McsEngl.Semantic-Inferencing-on-Large-Knowledge@cptIt,
* McsEngl.SILK@cptIt356i,
name::
* McsEngl.Mcsm'Relation-to-HYPERTEXT@cptIt,
Clearly hypertext is a stage of development before the SSS. Their main diference is that hypertext structure chunks of information and the SSS will structure ALL the information.
[NIKOS, JUNE 1991]
name::
* McsEngl.Mcsm'RELATED-ORGANIZATION@cptIt,
USA:
Center for Research on Concepts and Cognition at Indiana University
CRCC research focuses mainly on emergent computational models of creative analogical thinking and its subcognitive substrate -- namely, fluid concepts. Link up to people, papers, and publications.
http://www.cogsci.indiana.edu/
name::
* McsEngl.Mcsm'Related-Project@cptIt,
_SPECIFIC:
* halo-project#ql:cbsmgr'project_halo#
4Suite:
http://sourceforge.net/projects/foursuite/
4Suite is a platform for XML processing and knowledge-management, consisting of a library of integrated tools for XML processing, and an XML data repository and server with a rules-based engine.
Exteca
http://sourceforge.net/projects/exteca/
The Exteca platform is an ontology-based technology written in Java for high-quality knowledge management and document categorisation. It can be used in conjunction with search engines.
Knowledge-Management-Systems:
CODE4#cptIt2023# (represent statements. every concept has a unique number for identification, so its name can change.)
CYC-PROJECT#cptIt502# (represent statements)
DocKMan#cptIt2031# (It stores every sentence or knowledge base fact as a record in a dbms - Each sentence or fact is structured and indexed in various ways e.g. by subject, verb, source, author)
GALEN#cptIt2032# (GRAIL is a knowledge representation (KR) language; it has lots of features similar to KR languages(sometimes also known as 'description logics') such as KL-ONE, CLASSIC and BACK. )
ICARUS#cptIt2025# (** οργανώνει τη ΒΑΣΗ-ΓΝΩΣΕΩΝ με μορφή frames (τα ονομάζει SUBJECT). A value of a slot can be an UNSTRUCTURED-STATEMENT or a structured one, δηλώνοντας χαρακτηριστικά για τις οντότητες που αντιπροσωπεύει.)
START#cptIt521# (statement representation)
VHG#cptIt2029# (an example of collaboration).
WordNet#cptIt2030# (good, but for terminology).
name::
* McsEngl.Mcsm'rel'Principia-Cybernetica-Web@cptIt,
This is the website of the Principia Cybernetica Project (PCP), an international organization. The Project aims to develop a complete philosophy or "world-view", based on the principles of evolutionary cybernetics, and supported by collaborative computer technologies. To get started, there is an introduction with background and motivation, and an overview, summarizing the project as a whole.
Francis Heylighen was born in 1960 in Vilvoorde, near Brussels, in Belgium.
Email: fheyligh at vub.ac.be
[http://pespmc1.vub.ac.be/HEYBIO.html]
name::
* McsEngl.Mcsm'rel'EuroKnowledge@cptIt,
_DESCRIPTION:
http://www.aiai.ed.ac.uk/project/euroknow//
EuroKnowledge is a European IT initiative which aims to co-ordinate and encourage standardisation activities in the area of knowledge technology. EuroKnowledge views its role as a focal point for the consolidation of common views and best practice from knowledge technology users, theorists, and tool vendors. More than 150 organisations, from both industry and academia, have expressed interest in and/or volunteered effort to EuroKnowledge.
The current focus of the initiative is on establishing recommendations on standards for modelling knowledge at a conceptual level, independent of implementation concerns - this is often referred to as knowledge-level modelling.
{1997sep}
name::
* McsEngl.Mcsm'rel.JOON@cptIt,
About JOONE
Joone is a FREE neural net framework to create, train and test neural nets. ( What is a neural network? ) The aim is to create a powerful environment both for enthusiastic and professional users, based on the newest Java technologies. Joone is composed by a central engine that is the fulcrum of all applications that already exist or will be developed .
name::
* McsEngl.Mcsm'rel'Protege/Win@cptIt,
_DESCRIPTION:
Protege provides a tool called the OntologyEditor to assist in this modeling. This program is a graphical editor for a modeling language. This language allows a user to describe the structure of a domain (that is, to construct an ontology) as a hierarchy of classes.
name::
* McsEngl.Mcsm'rel'SEMANTIC-NETWORK@cptIt,
An example of a semantic network is WordNet, a lexical database of English.
name::
* McsEngl.Mcsm'rel'Stanford'Digital'Libraries Project@cptIt,
_DESCRIPTION:
The Stanford Digital Libraries project is one participant in the 4-year, $24 million Digital Library Initiative, started in 1994 and supported by the NSF, DARPA, and NASA. In addition to the ties with the five other universities that are part of the project, Stanford also has a large number of industrial partners. Each university project has a different angle of the total project, with Stanford focusing on interoperability.
Our collection is primarily computing literature. However, we also have a strong focus on networked information sources, meaning that the vast array of topics found on the World Wide Web are accessible through our project as well. At the heart of the project is the testbed running the "InfoBus" protocol, which provides a uniform way to access a variety of services and information sources through "proxies" acting as interpreters between the InfoBus protocol and the native protocol.
With the InfoBus protocol running under the hood, a variety of user level applications provide powerful ways to find information, using cutting-edge user interfaces for direct manipulation or through Agent technology. A second area of focus for the Stanford Digital Library Project is the legal and economic issues of a networked environment.
[http://www-diglib.stanford.edu/diglib/]1997oct
name::
* McsEngl.Mcsm'Bug@cptIt,
* McsEngl.Mcsm'error@cptIt,
name::
* McsEngl.Mcsm'Code-program@cptIt,
name::
* McsEngl.Mcsm'Computer-system@cptIt,
* McsEngl.conceptIt356.2,
* McsEngl.sccs@cptIt356.2, {2009-03-21}
* McsEngl.SensorialConcept-ComputerSystem@cptIt356.2,
* McsEngl.koncesto-system@cptIt356.2, {2008-01-21}
* McsEngl.knbsystem@cptIt356.2, {2007-12-20}
* McsEngl.KogneptoBase-system@cptIt356.2,
_DEFINITION:
Kognepto_Base__System is the system of
- knbProgram,
- the computer/computers it is installed
- the kognepto_bases manages and
- the users of this system.
[KasNik, 2007-12-20]
name::
* McsEngl.Mcsm'Data-representation-method#cptIt501#@cptIt,
* McsEngl.Mcsm'data@cptIt, {2011-12-29}
* McsEngl.data-representation-method-of-koncesto-program@cptIt356i, {2008-01-21}
* McsEngl.knowledge-representation-method-of-koncesto-program@cptIt356i,
* McsEngl.artificial'brainepto'model'knowledge'representation@cptIt501, {2007-12-01}
* McsEngl.abmd'representation'scheme@cptIt559, {2007-08-08}
* McsEngl.knprogram'krl@cptIt,
* McsEngl.bbpp'METHODOLOGY@cptIt,
_DEFINITION:
ΤΟ ΣΥΣΤΗΜΑ ΘΑ ΕΚΤΕΛΕΙ "ΝΟΗΤΙΚΕΣ ΕΡΓΑΣΙΕΣ". ΓΙΑΥΤΟ ΟΠΩΣΔΗΠΟΤΕ ΘΑ ΕΧΕΙ ΕΣΩΤΕΡΙΚΑ ΜΙΑ ΜΟΡΦΗ "ΑΝΑΠΑΡΑΣΤΑΣΗΣ ΣΗΜΑΣΙΩΝ" ΑΝΕΞΑΡΤΗΤΗ ΑΠΟ ΦΥΣΙΚΗ-ΓΛΩΣΣΑ.
[ΝΙΚΟΣ, ΝΟΕΜ 1993]
_GENERIC
* language.computer.representation#cptItsoft501#
name::
* McsEngl.Mcsm'kr.KasNik@cptIt,
I'm using the OBJECT-RELATION methodology. Any concept is an object, and it is comprised with relations with other objects.
[nikos, 1998may24]
Using chunks of 'information' in my representations means that I represent (for the machine) portions of 'knowledge' and leave the 'information' for humans.
To have complete control I must represent and this information.
[hmnSngo.2000jul25]
As Methodology to represent knowledge (conceptual-models of the world), I'm using the 'systems-theory' approach: A Concept is a system of concepts.
[hmnSngo.2000jul25]
From the above definition 'a concept is a system (or a relation) of concepts' come the PARADOXES (like Russel's) such as the 'concept' is subgeneral of 'entity' and the 'entity' is subgeneral of 'concept'.
[hmnSngo.2000jul27]
Before computers, human knowledge was stored in textbooks. With computers we began to create electronic-textbooks. First just transfering the knowledge from paper means to electronic ones (word processing). Then adding functionality (Hypertext, Expert Systems, Knowledge management Systems).
This process will continue, humans will add and add functionality in computer-representations of human knowledge.
With sss I'm describing this process.
[nikos 1998aug13]
The 'structured concept' methodology is the right one, because in order to manipulate the knowledge we must analyze it. And when we analyze the knowledge we stop infront of two things: the concept (structured-concept) and the statement (which I don't know yet how to deal with).
[nikos, 1998aug11]
Except of the 'structured concept', I must implement a statement-representation (as DockMan does but not in a database) in order to have absolute management of all the information.
[nikos, 1998aug08]
STRUCTURED-CONCEPT#cptCore356# is the entity I'm using to represent knowledge. I BELIEVE this approach will help us to integrate (to form into a unified whole) our knowledge.
[NIKOS, {1998-03-25}]
I'm using the OBJECT-RELATION methodology. Any concept is an object, and it is comprised with relations with other objects.
[nikos, 1998may24]
My conceptual model graphically is this:
#img.ITSCSCM.BMP#
An older model:
#img.EP-2-SINFO.BMP#
name::
* McsEngl.Mcsm'CONCEPT'FORMAL'NAME@cptIt,
The notation below will facilitate formal-reading:
Hard-Disk: a name with two words.
Hard-Disk'Capacity: Capacity is attribute of Hard Disk.
Hard-Disk.Removable: Removable Hard Disk is subgeneral concept of Hard Disk.
I can't use this notation in my Folio Views application because the program does not see Hard-Disk as ONE word.
[Nikos, 1999jan10]
name::
* McsEngl.Mcsm'data.Collection@cptIt,
* McsEngl.Mcsm'Collection@cptIt,
_DESCRIPTION:
Many "attributes" are lists of "data".
- term, text,
- specific, concepts
- evolution, date:text
...
[hmnSngo.2011-10-18]
name::
* McsEngl.Mcsm'data.Text@cptIt,
* McsEngl.Mcsm'text@cptIt,
name::
* McsEngl.Mcsm'data.Time@cptIt,
* McsEngl.Mcsm'time@cptIt,
name::
* McsEngl.Mcsm'Licence@cptIt,
name::
* McsEngl.WordNet Release 1.6@cptIt,
This software and database is being provided to you, the LICENSEE, by Princeton University under the following license. By obtaining, using and/or copying this software and database, you agree that you have read, understood, and will comply with these terms and conditions.: Permission to use, copy, modify and distribute this software and database and its documentation for any purpose and without fee or royalty is hereby granted, provided that you agree to comply with the following copyright notice and statements, including the disclaimer, and that the same appear on ALL copies of the software, database and documentation, including modifications that you make for internal use or for distribution. WordNet 1.6 Copyright 1997 by Princeton University. All rights reserved.
THIS SOFTWARE AND DATABASE IS PROVIDED "AS IS" AND PRINCETON UNIVERSITY MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, PRINCETON UNIVERSITY MAKES NO REPRESENTATIONS OR WARRANTIES OF MERCHANT- ABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE LICENSED SOFTWARE, DATABASE OR DOCUMENTATION WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
The name of Princeton University or Princeton may not be used in advertising or publicity pertaining to distribution of the software and/or database. Title to copyright in this software, database and any associated documentation shall at all times remain with Princeton University and LICENSEE agrees to preserve same.
name::
* McsEngl.Mcsm'ModelConceptStructured@cptIt,
* McsEngl.conceptIt356.13,
_GENERIC:
* data-concept#ql:data.concept#,
* concept.brain.sensorial#cptCore50.28#
_WHOLE:
* cbsmgr-worldview#ql:cbsmgr'worldview#
_SPECIFIC:
* aaj-cbs#ql:aaj'concept-1047.1#,
* folioviews-cbs#ql:cbs.folio_views#,
* html-cbs#ql:cbshtml@cptCore356.11#,
* wikiconcept-cbs#ql:wcpt'cbs#
name::
* McsEngl.cbs'ATTRIBUTE@cptIt,
_SPECIFIC:
* Definition,
* Term,
* Generic,
* Specific,
* Whole,
* Part,
* Environment,
* Other_view,
name::
* McsEngl.cbs'Other-view-attr@cptIt,
* McsEngl.Mcs'attr.Other-view@cptIt,
name::
* McsEngl.Mcsm'ModelWorld@cptIt,
* McsEngl.conceptIt356.10,
* McsEngl.worldview.cbsmgr@cptIt356.10,
* McsEngl.wv-of-cbsmgr@cptIt356.10,
_WHOLE:
* cbsmgr--knowledge-base#ql:cbsmgr'knowledge_base#
_PART:
* cbsmgr-subWorldview#ql:cbsmgr'subworldview#
name::
* McsEngl.Mcsm'wv'Holder@cptIt,
* McsEngl.conceptIt356.15,
* McsEngl.holder-worldview@cptIt,
_DEFINITION:
It is any human or group of humans that "hold", have, contain this worldview.
[hmnSngo.2011-12-04]
name::
* McsEngl.Mcsm'wv'ID@cptIt,
_DESCRIPTION:
A unique entity per knowledge-base#ql:cbsmgr'knowledge_base#.
[hmnSngo.2012-02-08]
name::
* McsEngl.Mcsm'wv'Number@cptIt,
_DESCRIPTION:
Every worlview must have and number as ID.
[hmnSngo.2012-02-08]
name::
* McsEngl.Mcsm'wv'Subworldview@cptIt,
* McsEngl.conceptIt356.11,
* McsEngl.Mcsm'Subworldview@cptIt,
* McsEngl.subworldview-cbsmgr@cptIt356.11,
_SPECIFIC:
* AAj-worldview#ql:aaj'worldview#,
* ww-worldview#ql:ww'worldview#
name::
* McsEngl.Mcsm'ModelKnowledge-Base@cptIt,
* McsEngl.conceptIt356.14,
* McsEngl.CollectionKnowledge-cbsmgr@cptIt,
* McsEngl.science-base@cptIt,
* McsEngl.Knowledge-Base@cptIt,
* McsEngl.kognesto-base-of-koncesto-program@cptIt,
* McsEngl.abb'of'bbpp@cptIt356i,
_DEFINITION:
Contains all the ScienceViews of scientists.
[hknu, 2011-01-28]
_GENERIC
* Knowledgebase-ConceptBrainualSensorial#cptCore50.28.16#
_PART:
* cbs#ql:cbsmgr'cbs###
* subworldview#ql:cbsmgr'subworldview###
* worldview##
_SPECIFIC:
* ABB.paper (1984)#cptIt#
* ABB.dbaseiv (1990)#cptIt#
* ABB.FolioViews21 (1992)#cptIt#
* ABB.FolioViews301 (1994)#cptIt#
* ABB.AAj-(1997)#ql:aaj'knowledge_base##cptItsoft1047i#
name::
* McsEngl.Mcsm'kb'ID@cptIt,
_DESCRIPTION:
A kb must have an ID unique in the world.
[hmnSngo.2012-02-08]
name::
* McsEngl.Mcsm'SystemSoftware@cptIt,
* McsEngl.conceptIt356.1,
* McsEngl.Mcsm'Application@cptIt,
* McsEngl.cbs-software-system@cptIt,
_PART:
* cbsmgr-endUser-code,
* cbsmgr-program,
_WHOLE:
* cbsmgr--computer-system##
_DESCRIPTION:
It comprises the program and the knowledge-collection.
[hmnSngo.2011-09-04]
name::
* McsEngl.Mcsm'SystemTechData@cptIt,
* McsEngl.cbs-worldview-computer-system@cptIt356i, {2012-02-22}
_GENERIC:
* cbs-system#ql:cbs'system###
* entity.whole.system.it_human#cptItsoft180#
name::
* McsEngl.Mcsm'Technology-to-be-used@cptIt,
_TECHNOLOGY:
* language.computer.representation#cptItsoft501#
* MACHINE_LEARNING#cptIt358#
* MACHINE_TRANSLATION#cptItsoft497.15#
* NATURAL_LANGUAGE_PROCESSING#cptItsoft497.12#
name::
* McsEngl.Mcsm'User@cptIt,
SUBGENERAL:
We'll have two users of the system: the reader and the author.
THE READER will retrieve the system's knowledge. Anyone who knows to use a computer can be reader. That's why the simplest the retrieval process the better.
THE AUTHOR will be the person who stores knowledge into the system. The author must be a SCIENTIST in a domain and to have a good knowledge of computer usage. The author must NOT be an infotech specialist.
[hmnSngo.{1999-04-17}]
name::
* McsEngl.Mcsm'User-interface@cptIt,
name::
* McsEngl.Mcsm'PresentationConcept@cptIt,
_DESCRIPTION:
The program must have the capasity to present the ATTRIBUTES of a concept
- alphabetically, but showing the type of each one, part, whole, etc
- per class: part-attributes, whole-att, specific-att, etc.
[hmnSngo.2011-06-12]
name::
* McsEngl.Mcsm'INTERFACE'LANGUAGE@cptIt,
A global-program (like my java scs) can represent the information in any natural-language.
[nikos, 1998aug09]
sss:
ΤΟ ΣΥΣΤΗΜΑ, ΕΠΕΙΔΗ ΘΑ ΕΧΕΙ ΚΑΠΟΙΟ ΒΑΘΜΟ ΑΝΑΠΑΡΑΣΤΑΣΗΣ ΤΗΣ ΚΑΤΑΧΩΡΗΜΕΝΗΣ ΓΝΩΣΗΣ, ΘΑ ΜΠΟΡΕΙ ΝΑ ΕΚΦΡΑΣΕΙ ΑΥΤΗ ΤΗ ΓΝΩΣΗ ΣΕ ΟΠΟΙΑΔΗΠΟΤΕ ΓΛΩΣΣΑ ΤΟΥ ΚΟΣΜΟΥ.
[ΝΙΚΟΣ, ΝΟΕΜ 1993]
name::
* McsEngl.Mcsm'website.WikiCbs@cptIt,
* McsEngl.wikiCbs@cptIt356i,
_DESCRIPTION:
WikiCbs is a wiki-website (= collaborative) that uses the cbsmgr program.
[hmnSngo.2011-10-16]
name::
* McsEngl.wikiCbs'Data@cptIt,
_SPECIFIC:
* Strongly True,
* True,
* Weakly True,
* Unknown,
* Weakly False,
* False,
* Strongly False,
name::
* McsEngl.wikiCbs'User-interface@cptIt,
_Ideas:
* http://www.greatschools.org//
_First_horizondal_line_pane:
- on the right, search-box.
- to have a selection-list of the "worldview" to search. "ALL" default.
- to have a selection-list of the "sub-worldview" to search. "ALL" default. It will hold the major sciences.
_Second_horizondal_line_pane:
- drop menus. On the right-most the login.
- Logo will cover both lines.
_Third_horizondal_pane:
- will have 2 vertical panes.
- first vertical on the left the toc.
- second vertical on the rigth the cbs.
- Tabs on this vertical panes will add functionality.
name::
* McsEngl.Mcsm'DOING@cptIt,
* McsEngl.function'of'bbpp@cptIt,
* McsEngl.function'of'scs@cptIt,
_GENERIC:
* krp-function#ql:krp'function#
_SPECIFIC:
* administering,
* editing,
* evolution-managing
* main-doing,
* reading#ql:cbsmgr'reading#,
* reasoning,
* term-managing,
* translating,
* user-managing,
name::
* McsEngl.Mcsm'Goal@cptIt,
* McsEngl.Mcsm'func.GOAL@cptIt,
THE MAIN GOAL
is Knowledge-Integration (make Human-Knowledge a consistent whole) per view.
All other tasks are consequencies of this.
[hmnSngo.2000-07-26]
GOAL:
1. To improve our knowledge.
2. To enhance our learning.
3. To improve the teaching.
[nikkas 2000-01-02]
NEEDS:
* knowledge improvement/SYSTEMATIZATION](ambiquities, contradictions, inconsistencies,)
* knowledge development, acquisition,
* knowledge dissemination,
** systematization of national and international law
** systematization of medical information
** unique terminology. 1998aug23
IMMEDIATE GOAL:
Create the scs that manipulates the general-subgeneral and whole-part concept-relations.
[nikos, 1998aug11]
MEDIUM GOAL:
Science integration.
[nikos, 1998aug11]
LONG-TERM GOAL:
Concept Integration in all Sciencies.
[nikos, 1998aug11]
name:
** Our language uses the words with many senses. Just look at WordNet lexical database. This is an advantage, "language economy". But in regard to our knowledge it is a disadvantage. It's the main cause for infinite ambiquities and misunderstandings. The scs will help in this aspect. Anyone will PATENT his concepts with a unique name in all natural-languages.
[nikos, 1998aug23]
** It will be a mean for stadardization of TERMINOLOGY.
[NIKOS, MARCH 1991]
The objective is to help individuals to accomodate an amount of knowledge (through the system) that would be imposible to do in their life without the help of the system.
[NIKOS, SEP 1991]
I want a system to write well-structured knowledge. I define the 'STRUCTURED-CONCEPT' and then everything I am writing consists of structured-concepts.
[nikos, 1998feb04]
SSS PAPER:
There is general consensus about the importance of information in our "information age." Already, since the 17th century Francis Bacon, British philosopher, said that knowledge and power are the same thing (Getmanova 1989, 7).
The general need. In the most abstract terms, the existing need is to enhance the productivity of sciences. More specificly there are three needs:
the need for improvement,
the need for development, and
the need for acquisition and dissemination of our knowledge.
Need for improvement. One of the main characteristics of our knowledge is its quantity. "The total amount of scientific information available in the world doubles every twenty months" (Mondy et al 1988,180). This fact created one of the main needs for our society. The need for systematization and integration, in other words improvement of our knowledge. This need is apparent to everyone who is enrolled in our teaching and knowledge producing organizations. Articles as "the management theory jungle" also show this need (Ibid,26). To systematize terminology (Slocum 1989, 29), to resolve ambiguities, to eliminate inconsistencies and contradictions are some needs in this category.
Need for development. Despite the existing quantity of knowledge, the need to expand the frontiers of our knowledge are obvious. And here lies the potential use of the new tools, the CSs, that give us new possibilities (Info..., 12).
Need for acquisition and dissemination. Finally there is the need for acquisition and dissemination existing knowledge. Translation of knowledge from one language to another is a major limit to acquire knowledge (Slocum 1989,24). Creation of abstracts that help to acquire more knowledge and rapidly are another example. Improving teaching methods is another. Finally, improving the dissemination of information, will result in the elimination of duplications an impediment in the productivity of research.
[nikos, sss paper, 1990dec03]
name::
* McsEngl.Mcsm'Main-doing@cptIt,
* McsEngl.Mcsm'func.MAIN@cptIt,
_DESCRIPTION:
Write DEFINED knowledge. With the support of "worldviews", on every text will exist a link to the concrete-author definition and thus everything will be defined.
[hmnSngo.2012-01-11]
===
Like todays wikipedia the system will work collaborativelly.
But it will not allow a user to add knowledge inconsistent with the previous knowledge.
Also the system will create ONE CONSISTENT artificial-brainepto-model AND will store and any one others ABM.
Because knowledge/terminology is constantly evolving, the system must have the ability to present its status on every time-point. This means that when we read a TEXT, the system must know the definitions of the text's terms at the time the text was written and not the latest only definitions of these terms. Time will show if we manage to do this!!!
[kas-nik, 2007-07-05]
===
Η ΒΑΣΙΚΗ ΤΟΥ ΛΕΙΤΟΥΡΓΙΑ ΣΕ ΠΡΩΤΗ ΦΑΣΗ ΘΑ ΕΙΝΑΙ Η "ΤΥΠΟΠΟΙΗΣΗ" ΤΗΣ ΟΡΟΛΟΓΙΑΣ ΤΩΝ ΕΠΙΣΤΗΜΩΝ.
ΜΕΤΑ ΘΑ ΓΙΝΕΙ ΤΟ ΜΕΣΟ ΤΗΣ ΟΛΟΚΛΗΡΩΣΗΣ ΤΩΝ ΕΠΙΣΤΗΜΩΝ, ΑΛΛΑ ΚΑΙ Η ΟΛΟΚΛΗΡΩΣΗ ΤΩΝ ΕΠΙΣΤΗΜΩΝ.
ΤΕΛΟΣ, ΘΑ ΕΧΕΙ ΤΙΣ ΒΑΣΕΙΣ, ΑΠΟ ΚΑΤΑΣΚΕΥΗΣ, ΓΙΑ ΠΕΡΑΙΤΕΡΩ ΑΝΑΠΤΥΞΗ-ΤΟΥ.
[ΝΙΚΟΣ, ΟΚΤΩ 1993]
name::
* McsEngl.Mcsm'usage@cptIt,
MAIN:
The artificial-braineptobases created by bbpp will be used by BOTH people and machines.
[KasNik, 2007-12-08]
TRANSLATION:
With a next generation cell-phone, a user could speak in his/her native language and the phone will translate in another through a server-connection.
[hmnSngo.2001-11-23]
name::
* McsEngl.Mcsm'building-base-view@cptIt,
* McsEngl.Mcsm'func.Building-KnowledgeBase@cptIt,
* McsEngl.Mcsm'Building-function@cptIt,
* McsEngl.Mcsm'Stroring@cptIt,
* McsEngl.Mcsm'editing@cptIt,
_SPECIFIC:
* attribute-generalizing,
* integrating#ql:cbsmgr'func.integration#
name::
* McsEngl.Mcsm'Attribure-generalizing@cptIt,
* McsEngl.Mcsm'func.Attribute-generalizing@cptIt,
* McsEngl.Mcsm'Attribute-generalizing@cptIt,
_DESCRIPTION:
GENERALIZE-SELECTED-ATTRIBUTE is a jSCS-Storage-Function that takes a NotInherited-Attribute of a concept and set it as attribute in one of its GENERALS.
[nikkas {2000-03-14}]
===
IF the attribute has subgenerals we must generalize and its subs.
eg: jscs'user has subs the 'reader' and the 'author'. Generalizing it id creating the concept "scs'user" we must create and the "scs reader" and "scs author".
[nikkas {2000-04-06}]
name::
* McsEngl.Mcsm'Attribute-overriding@cptIt,
* McsEngl.Mcsm'func.Attribute-overriding@cptIt,
* McsEngl.Mcsm'Attribute-overriding@cptIt,
_DESCRIPTION:
* Is the function of setting a specific-value in this attribute and not holding the value this attribute has in the generic-concept.
[hmnSngo.2011-12-19]
===
ATTRIBUTE-OVERRIDING is the function that subgenerals/specializes an inherited-general-attribute.
[nikkas {2000-04-06}]
name::
* McsEngl.Mcsm'Natural-language-storing@cptIt,
* McsEngl.Mcsm'func.Natural-language-storing@cptIt,
* McsEngl.Mcsm'Natural-language-in-storing@cptIt,
_DEFINITION:
The ability to "understands" and stores knowledge FROM texts|speeches.
[hmnSngo.2012-01-20]
===
The ability of the system to store the knowledge in MANY natural-langauges.
[hmnSngo.2007-09-15]
name::
* McsEngl.Mcsm'Term-managing@cptIt,
* McsEngl.Mcsm'func.Term-managing@cptIt,
_DESCRIPTION:
Τhe system must have the ability to automatically change a concepts'name in all of its uses.
===
ΠΑΡΑΔΕΙΓΜΑ: τον απρίλιο του 1995 άλλαξα το στάνταρ όνομα της 'ΔΟΜΗΜΕΝΗΣ ΠΛΗΡΟΦΟΡΙΑΣ' σε 'ΔΟΜΗΜΕΝΗ ΕΝΝΟΙΑ'. Το σύστημα έπρεπε να έχει τη δυνατότητα να αλλάξει σε όλες τις πληροφορίες ΜΟΥ που χρησιμοποίησα το όνομα δομημένη-πληροφορία σε δομημένη έννοια.
[hmnSngo.1995-03]
name::
* McsEngl.Mcsm'Retrieving-Knowledge@cptIt,
* McsEngl.Mcsm'retriveing@cptIt,
_GENERIC:
* doing#ql:cbsmgr'doing#
_DESCRIPTION:
πρέπει να διαβάζεται σειριακά όπως και ένα χάρτινο βιβλίο.
να έχει ΑΛΦΑΒΗΤΙΚΟ ΕΥΡΕΤΗΡΙΟ ΕΝΝΟΙΩΝ, με συνδέσεις στις αντίστοιχες έννοιες. Δεν είναι άσχημο να υπάρχουν και οι γεννήτορες έννοιες κάθε μιας.
FOLIO: Η σύνδεση οδηγεί σε παράθυρο που πάντα στη αρχή έχει τη σχέση της έννοιας με άλλες υποσύνολά της. Μετα ακολουθεί η σχετική πληροφορία.
Πάντα στη αρχή αρχή του παράθυρου υπάρχει σύνδεση στις γονικές έννοιες. Ενας μη αυτόματος τροπος δημιουργείας αμφίδρομης σύνδεσης.
πρέπει να εχει ΣΧΕΣΙΑΚΟ ΠΕΡΙΕΧΟΜΕΝΟ ΕΝΝΟΙΩΝ και παντα συνδέσεις στις αντίστοιχες έννοιες.
name::
* McsEngl.Mcsm'Reading@cptIt,
* McsEngl.Mcsm'presenting@cptIt,
* McsEngl.Mcsm'READING@cptIt,
name::
* McsEngl.Mcsm'SEARCING@cptIt,
The user must quickly and easily find the entity s/he wants by writing or pronouncing its name. From there s/he must find easily any other related knowledge. My java system does SMART searching, id can search related concepts. My folio-views system can easily find the entity I want.
QUESTIONS: The system must have the ability to answer to user's questions.
[nikos 1999] 1999aug24
AΝΑΖΗΤΗΣΗ:
- ΚΑΘΕ ΛΕΞΗΣ.
- ΣΗΜΑΣΙΑΚΟ ΨΑΞΙΜΟ.
- ΠΕΡΙΕΧΟΜΕΝΑ.
MEANINGFULL'INFORMATION'RETRIEVAL
Σημασιολογικό ψάξιμο σημαίνει να ψάχνει για μία ΣΗΜΑΣΙΑ, με όλα τα ονόματα που εμφανίζεται αυτή η σημασία.
[KasNik, ?]
Να μπορεί να ψάχνει για μια ΓΕΝΙΚΗ-ΠΛΗΡΟΦΟΡΙΑ και για όλες τις ΜΕΡΙΚΕΣ-ΤΗΣ.
[hmnSngo.1995-01]
name::
* McsEngl.Mcsm'CONCEPT-DISPLAY@cptIt,
DYNAMIC LAYOUT OF CONCEPTS:
The SAME entity,
- to have an ATTRIBUTE'LAYOUT when we look at the concept where the entity is an attribute and
- to have a CONCEPT'LAYOUT when we look at the entity as a concept.
[NIKOS, 1997aug]
name::
* McsEngl.Mcsm'ALL-RELATED-INFORMATION@cptIt,
* McsEngl.Mcsm'Retriving-function@cptIt,
The system must have the ability from any concept to access ALL RELATED concepts.
[KasNik, 2007-12-20]
CONCEPT_RELATIONS:
οι συνδέσεις πρεπει να είναι αμφίδρομες για να μπορεί κάποιος να πηγαίνει και στις άλλες σχετιζόμενες έννοιες απο μια τυχαία.
LINKS_AMONG_SERVERS:
Το σύστημα δομημένης-πληροφορίας ΔΕΝ θα βρίσκεται μόνο σε ένα μηχάνημα και σε ένα ΑΡΧΕΙΟ μιας αποθήκης, αλλά σε διαφορετικά μηχανήματα και σε διαφορετικα αρχεία.
Ετσι συστημα υποστήριξης-επιστημών πρέπει να έχει τη δυνατότητα ΑΥΤΟΜΑΤΑ να δημιουργει συνδέσεις και μεταξυ διαφορετικών αρχειων/μηχανημάτων.
πχ το χαρακτηριστικο 53 στην epistem βαση, θα γίνεται 'epistem-53' σε οποιαδήποτε άλλη βάση δομημένης πληροφορίας.
[hmnSngo.1995-01]
Οταν δημιουργούμε μια έννοια, το σύστημα αυτόματα να φτιάχνει και όλες τις δυνατές συνδέσεις που συνεπάγονται απο την έννοια με όλες τις υπάρχουσες έννοιες.
[ΝΙΚΟΣ, ΙΟΥΛ. 1994]
ΠΑΡΑΔΕΙΓΜΑ1:
Στην οικονομία, για κάθε έννοια υπάρχει το χαρακτηριστικό δίκαιο. Αυτό που θέλουμε είναι το σύστημα να μπορεί να φτιάξει ΚΑΙ τις συνδέσεις εκείνες που όταν έχεις πρόσβαση στην έννοια <ΔΙΚΑΙΟ ΟΙΚΟΝΟΜΙΑΣ> να μπορείς να έχεις προσβαση και σε όλο το δίκαιο ΜΟΝΟ όλων των εννοιών.
[hmnSngo.1994-08]
name::
* McsEngl.Mcsm'GRAFICAL-REPRESENTATION OF INFORMATION STRUCTURE@cptIt,
Ενα άλλο βασικό χαρακτηριστικό που πρέπει να έχει το σύστημα είναι να μπορεί να παρουσιάζει ΓΡΑΦΙΚΑ τη δομή του εννοιακού συστήματος σε επίπεδα αφαίρεσης.
name::
* McsEngl.Mcsm'LOGO-GENERATION@cptIt,
The system must have the ability to present its knowledge to any natural-language the user wants.
[hmnSngo.2001-03-19]
name::
* McsEngl.Mcsm'collaborating@cptIt,
* McsEngl.Mcsm'func.Collaborating@cptIt,
* McsEngl.Mcsm'func.COLLABORATION@cptIt,
* McsEngl.Mcsm'collaborating@cptIt,
_DESCRIPTION:
The power of the system will be on collaboration.
But unlike (eg wikipedia) the author will be prevented by the system on adding inconsistences.
[KasNik, 2007-11-25]
===
The program must have the ability to help collaborators first DISCUSS concepts before their INTEGRATION into the bb.
[KasNik, 2007-11-26]
name::
* McsEngl.Mcsm'validating@cptIt,
* McsEngl.Mcsm'Integrating@cptIt,
* McsEngl.Mcsm'consistency-checking@cptIt,
* McsEngl.Mcsm'func.INTEGRATION@cptIt,
* McsEngl.Mcsm'validating@cptIt,
* McsEngl.consistency'in'knprogram@cptIt356i,
* McsEngl.integration'in'bbpp@cptIt356i,
_GENERIC:
* reasoning#ql:cbsmgr'reasoning#
_DEFINITION:
INTEGRATION is a SCS-Storage-Function that checks the relations of a concept with its related one.
* CONSISTENCY:
Modifications in the KB must leave it consistent.
- truth maintenance
INCONSISTENCIES:
- redundant pieces of knowledge
- similar
- misspelling
[nikos, {1998-04-22}]
1. The system must ensure that every concept is stored once.
[1998may12]
FOR SPEED it is better CONCISTENCY-CHECKING to do it when we modify the 'knowledge-base' than when we view the knowledge-base.
[nikos, 1999jan17]
name::
* McsEngl.Mcsm'integration.PART@cptIt,
* McsEngl.Mcsm'computing.part@cptIt,
* McsEngl.Mcsm'Part-computing@cptIt,
ATTRIBUTE-INTEGRATION checks the relations:
a) IF the current has as ATTRIBUTE the cpt-x THEN the cpt-x has as WHOLE the current.
name::
* McsEngl.Mcsm'integration.WHOLE@cptIt,
* McsEngl.part'whole'consistencey@cptIt356i,
* McsEngl.whole'part'management@cptIt356i,
* McsEngl.whole-integration@cptIt356i,
WHOLE-INTEGRATION checks the relations:
a) IF current has as Whole cpt-x THEN cpt-x has as Attribute current.
b) IF current has no 'whole' but its general has THEN current's whole is its general. [{2000-03-14}]
c) IF current has subs THEN all subs have as whole the current's-whole. [{2000-03-18}]
IF cpt-x has as ATTRIBUTE cpt-y, THEN cpt-y has as whole-cpt the cpt-x.
[nikos, 1999jan17]
IF cpt-x has as WHOLE cpt-y THEN cpt-y has cpt-x as attribute.
[nikos, 1999jan17]
Part-Whole consistency. A concept must find the concept which is and part and whole of another one.
[1998may12]
name::
* McsEngl.Mcsm'integration.GENERIC@cptIt,
* McsEngl.general'subgeneral'management@cptIt356i,
* McsEngl.general'specific'consistency@cptIt356i, {1998-05-12}
GENERAL-INTEGRATION checks the relations:
a) IF current has as GENERAL cpt-y THEN the ATTRIBUTES of cpt-y are attributes of current. [1999jan17]
b) IF current has as GENERAL cpt-y THEN cpt-y has as SUBGENERAL current. [1999feb28]
IF cpt-x has as GENERAL cpt-y THEN the attributes of cpt-y are attributes and cpt-x.
[nikos, 1999jan17]
IF cpt-x has as SUBGENERAL cpt-y THEN attributes of cpt-x are attributes of cpt-y.
[nikos, 1999jan17]
IF cpt-x has as SIBLING cpt-y THEN the attributes of the general of cpt-x are attributes of cpt-y.
[nikos, 1999jan17]
ΚΑΘΕ ΜΕΤΑΒΟΛΗ ΣΤΑ ΧΑΡΑΚΤΗΡΙΣΤΙΚΑ ΜΙΑΣ "ΓΕΝΙΚΗΣ" ΕΝΝΟΙΑΣ, ΤΟ ΣΥΣΤΗΜΑ ΑΥΤΟΜΑΤΑ ΘΑ ΚΑΝΕΙ ΑΥΤΕΣ ΤΙΣ ΑΛΛΑΓΕΣ ΚΑΙ ΣΕ ΟΛΕΣ ΤΙΣ "ΥΠΟΓΕΝΙΚΕΣ" ΕΝΝΟΙΕΣ και αντίστροφα.
name::
* McsEngl.Mcsm'integration.SPECIFIC@cptIt,
SUBGENERAL-INTEGRATION checks the relations:
a) IF current has as SUBGENERAL cpt-y
THEN the attributes of current are attributes of cpt-y. [nikos, 1999jan17]
b) IF current has as SUBGENERAL cpt-y
THEN cpt-y has as GENERAL current [nikos, 1999feb22]
c) The SUBGENERAL has as whole the whole of its general. [nikkas {2000-04-06}]
d) IF current has as sub cpt-x and cpt-y
THEN any attribute of current has cpt-x and cpt-y analogous subs.
eg. (scs) has (jscs) and (fvscs) subs.
then (scs'kb) has (jscs'kb) and (fvscs'kb) subs. [nikkas {2000-04-09}]
name::
* McsEngl.Mcsm'integration.SIBLING@cptIt,
* McsEngl.Mcsm'computing.sibling@cptIt,
* McsEngl.Mcsm'Sibling-computing@cptIt,
_SPECIFIC:
* partial-sibling,
* specific-sibling,
SIBLING-INTEGRATION checks the relations:
a) IF current has as SIBLING cpt-y THEN both concepts have a common general-concept. [1999feb09]
b) IF current has as sibling cpt-y in relation to general cpt-w AND cpt-y has as sibling cpt-z in relation to general cpt-w THEN current has as sibling cpt-z. [{1999-03-13}]
c) IF current has as GENERAL cpt-y THEN check if ALL the subgenerals of cpt-y are siblings of current.
(except current!). [{1999-04-17}]
name::
* McsEngl.Mcsm'integration.ENVIRONMENT@cptIt,
There is NO environment_integration. What I mean here is part of generic-specific integration.
[KasNik, 2007-12-20]
ENVIRONMENT-INTEGRATION checks the relations:
a) IF current is NOT a relation THEN then the env is a relation and
1) the objects of the env must be >= 2 and
2) the env must be an env on its objects. [1999feb22]
eg: current=HardDisk has as env 'HardDisk and CDROM' THEN
1)'HardDisk and CDROM' has as env the 'HardDisk' and 'CDROM', ie. >=2 objects.
2)) 'HardDisk and CDROM' is and env of object 'CDROM'.
b) IF current is a relation (phil-1) THEN the objects of its environment must have the current in their environment. [1999feb28]
eg: current = HardDisk and CDROM THEN the 'HardDisk' and 'CDROM' cpts have current in their environment.
c) IF att has env THEN and the whole of this att has the same env.
eg.
(meaning) has (meaning and referent) as env then and the
(concept) that has (meaning) as att has (meaning and referent) as env.
[nikkas {2000-04-10}]
name::
* McsEngl.Mcsm'integration.COMPLEMENT@cptIt,
* McsEngl.Mcsm'computing.complement@cptIt,
* McsEngl.Mcsm'complement-computing@cptIt,
SPECIFIC_COMPLEMENT_INTEGRATION:
* When creating a divizospesifepto, its elements must have its specific-complements.
[KasNik, 2007-09-23]
PARTIAL_COMPLEMENT_INTEGRATION:
* When creating a divizopartepto, its elements must have its partial-complements.
[KasNik, 2007-09-23]
name::
* McsEngl.Mcsm'integration.DEFINITION@cptIt,
* McsEngl.Mcsm'computing.definition@cptIt,
* McsEngl.Mcsm'Definition-computing@cptIt,
_DEFINITION:
The DEFINITION is the relations that uniquely distiguish a concept from others. The system could check if the "defining-relations" are unique for every concept.
[hmnSngo.2007-09-24]
CIRCULAR-DEFINITION-CHECKING:
* Every konsepto must have a unique node per hierarchy. In ONE hierarchy a konsepto can be defined in two ways analytic (top=>down) or synthetic (down=>top).
[KasNik, 2007-09-30]
* The definitions will stored as analytic or synthetic.
* The definufulo (the new-concept) MUST NOT BE any previous definufelo.
[KasNik, 2007-09-26]
cbsmgr'func.ADDING'CONCEPT:
The system must guarantee that, when someone register a concept, this concept will not conflict with ALL the existing concepts.
[NIKOS, 1997apr]
name::
* McsEngl.Mcsm'integration.RELATIONS-INTEGRATION@cptIt,
Creating a relation of the current-cpt with concept2, the program must create the same relation in concept2 with the current-cpt.
[KasNik, 2008-01-20]
name::
* McsEngl.Mcsm'integration.TOTAL@cptIt,
Total-Integration is SCS-Storage-Functions that do ALL types of integration ie: attribute, whole, general, sibling, subgeneral, environment.
IF the result is positive then the concept is checked as 'INTEGRATED'. Otherwise the concept is checked as 'NOT-INTEGRATED'.
ANY_ATTRIBUTE_INTEGRATION:
Every attribute of a concept, is the argument (codomain) of a relation with domain the current-concept.
The definition of this relation, denotes what entities must be in its domain and codomain.
The program must check this consistensy.
EXAMPLE: colorness-relation:
a) the domain must be a material-object (ideas does not have color)
b) the codomain must be a color.
[KasNik, 2007-09-20]
name::
* McsEngl.Mcsm'Evolution-managing@cptIt,
* McsEngl.Mcsm'func.Evolution-managing@cptIt,
* McsEngl.Mcsm'func.EVOLUTION@cptIt,
* McsEngl.Mcsm'Version-controlling@cptIt,
* McsEngl.Mcsm'Version-control-management@cptIt,
* McsEngl.evolution'function'of'bbpp@cptIt,
* McsEngl.history'function'of'bbpp@cptIt,
_DEFINITION:
The system must have the ability to store and present its knowledge EVOLUTIONARILY. At every time-point the state of its knowledge.
[kas-nik, 2007-07-07]
The ability of the system to store the evolution of itself.
[hmnSngo.2007-09-15]
The system must have the ability to show the evolution of its knowledge-base.
It must show its state any time in the past.
[nikos, 1998aug21]
Να βάζει σε κάθε πληροφορία που προστίθεται/αλλάζει ημερομηνία. Κάτι τέτοιο έκανα στο σύστημα των ντοσιε.
[ΝΙΚΟΣ, ΙΟΥΛ. 1994]
DEFINITION_EVOLUTION:
The system can store every new definition and preserve the olds, as diferent xml-elements.
Every definition will have its creation date.
Then when some information referes to this definition, the information-date >= definition-date. The definition-date can NOT be newer (greater) than that of the information-date.
[KasNik, 2007-09-24]
DEZIGNEPTERO_EVOLUTION:
The system must know the term used for a concept at any time in its lifetime.
[KasNik, 2007-11-30]
Dezignepteros are dynamic. New are created, others change meaning (concepts) and others are died (no more used).
Dezignepteros must have its usage-date.
The information-date >= newer dezigneptero-date.
[KasNik, 2007-09-24]
ATRIBO_EVOLUTION:
We chage the attributes of a koncepto. This must be stored and viewed.
[KasNik, 2007-12-01]
IMPLEMENTEINO:
KONSEPTO_EVOLUTION:
Entity@bbKasNik.simb-7(2007-09-24).xml
Entity@bbKasNik.simb-24(2007-09-24).xml
<DZR ESTR="atributeino" AKNS="relation.Atribeino@bbKasNik.simb-20" NAR="atributeino" TTYPE="nor.nnr1"/>
ΤΟ ΣΥΣΤΗΜΑ ΑΠΟ ΚΑΤΑΣΚΕΥΗΣ ΘΑ ΕΧΕΙ ΜΗΧΑΝΙΣΜΟΥΣ ΠΟΥ ΘΑ ΒΟΗΘΟΥΝ ΣΤΗΝ ΕΞΕΛΙΚΗ ΤΟΥ ΟΛΟΚΛΗΡΩΜΕΝΟΥ ΕΝΝΟΙΑΚΟΥ ΣΥΣΤΗΜΑΤΟΣ.
[ΝΙΚΟΣ, ΝΟΕΜ 1993]
UPDATING:
It must have a CONTINOUS updating mechanism.
[NIKOS, MARCH 1991]
name::
* McsEngl.Mcsm'name-managing@cptIt,
* McsEngl.Mcsm'name-managing@cptIt,
_DESCRIPTION:
Writing a-sentence, the-program will connect the-names of the-sentence with its definitions.
[hmnSngo.2017-10-26]
====
Changing the abbreviation of a concept, to change it in all its uses:
* query-link: abn'term.
[hmnSngo.2013-07-31]
name::
* McsEngl.Mcsm'Natural-language-managing@cptIt,
* McsEngl.Mcsm'func.Natural-language-managing@cptIt,
* McsEngl.Mcsm'Natural-language-processing@cptIt,
_GENERIC:
* building,
* retrieving,
_DEFINITION:
The ability of the system to store the knowledge in MANY natural-langauges.
[hmnSngo.2007-09-15]
name::
* McsEngl.Mcsm'Logal-to-Brainual@cptIt,
* McsEngl.Mcsm'func.LANGERO-TO-KOGNEPTO@cptIt,
* McsEngl.langero-to-kognepto-and-vice-versa@cptIt356i,
* McsEngl.text'to'brainepto'and'vice'versa@cptIt356i,
* McsEngl.STRUCTURING'UNSTRUCTURED'INFORMATION@cptIt356i,
_DEFINITION:
* The program must NOT store text, as does for example wikipedia today.
It must have the ability to map any text to its brainepto_model (= its konceptos with its relations) and vice-versa.
When the stored-info is represented this way, then the program can finds its contradictions.
[KasNik, 2007-11-26]
===
ΤΟ ΣΥΣΤΗΜΑ ΠΡΕΠΕΙ ΑΥΤΟΜΑΤΑ ΝΑ ΠΑΙΡΝΕΙ ΚΑΠΟΙΟ ΚΕΙΜΕΝΟ ΚΑΙ ΝΑ ΤΟ ΔΟΜΕΙ ΣΥΜΦΩΝΑ ΜΕ ΤΗΝ ΗΔΗ ΥΠΑΡΧΟΥΣΑ ΑΝΤΙΠΡΟΣΩΠΕΥΣΗ, ΚΑΙ ΝΑ ΔΕΙΧΝΕΙ ΤΑ ΛΑΘΗ-ΤΟΥ.
[ΝΙΚΟΣ, ΟΚΤΩ 1993]
name::
* McsEngl.Mcsm'Computing@cptIt,
* McsEngl.Mcsm'computing@cptIt, {2012-01-19}
* McsEngl.Mcsm'func.Reasoning@cptIt,
* McsEngl.Mcsm'Inferencing@cptIt,
* McsEngl.Mcsm'Reasoning@cptIt,
* McsEngl.reasoning'in'knprogram@cptIt356i,
* McsEngl.reasoning'in'bbpp@cptIt356i,
* McsEngl.inference'in'aaj@cptIt,
_DEFINITION:
REASONING is the retrieval or storage functions the tool "entails" from the knowledgebase.
[hmnSngo.2007-09-14]
_IMPLEMENTATION:
Cyc implements the inference of the system with the same language that builds the BraineptoBase. AAj implements it with the language that builds the system (= java). The drawback of the latter is that the bb_author can not change it at runtime.
[KasNik, 2007-09-23]
_SPECIFIC:
* consistency-checking,
===
* ww-inferencing#ql:ww'inferencing#
name::
* McsEngl.0Mcsm'computing.Retrieving@cptIt,
* McsEngl.Mcsm'func.REASONING-IN-RETRIEVAL@cptIt,
name::
* McsEngl.Mcsm'computing.Storing@cptIt,
* McsEngl.Mcsm'func.REASONING-IN-STORAGE@cptIt,
name::
* McsEngl.Mcsm'computing.Comparing@cptIt,
* McsEngl.Mcsm'func.VIEW-COMPARISON-MERGING@cptIt,
In order to compare diferent BB (atomic or social) we need a common storage methodology. BBM must provide it.
[KasNik, 2007-11-29]
IF all the existing BBs will be stored with the same tool (AAj), THEN the tool can manage to compare them.
[KasNik, 2007-11-30]
Because information is something subjective, the system must present the CONTRADICITONS in knowledge.
[NIKOS, MARCH 1991]
name::
* McsEngl.Mcsm'computing.Logo-analysis@cptIt,
* McsEngl.Mcsm'Lingo-understanding@cptIt,
* McsEngl.Mcsm'Longo-analysis@cptIt,
* McsEngl.Mcsm'func.LANGERO-ANALYSIS@cptIt,
_DESCRIPTION:
The system must have the ability to take any logos (written/oral, eg a law-system) and analyze it, ie it will COMPARE this logos against its CONCEPT-BASES and will present the incosistences of logos. We assume that the concept-bases of the system are correct and have the maximun consensus.
Also the concept-bases of the system a) will have the 3 hierarchies (whole/part, generic/specific and environment) and b) the program itself will have checked them for incosistences.
[hmnSngo.{2001-03-19}]
name::
* McsEngl.Mcsm'computing.Truth@cptIt,
* McsEngl.Mcsm'func.TRUTHVALUE-EVALUATOR@cptIt,
The program must present for every koncepto its truthvalue.
These values will be the result of a PROOF.
[KasNik, 2007-11-26]
name::
* McsEngl.Mcsm'WorldView-managing@cptIt,
* McsEngl.Mcsm'func.WorldView-managing@cptIt,
* McsEngl.Mcsm'Worldview-managing@cptIt,
_DESCRIPTION:
* ONE knowledgeBase, MANY worldivews.
[hmnSngo.2011-12-19]
===
The system will store many KogneptoBases.
Each KNB will represent a model of the universe AND its view about the other KNBs.
[KasNik, 2007-12-20]
===
The program must can help us to store integrated AND non_integrated info. Because in order to integrate info, first we must collect info, THEN the program must have the ability to store and views (info_on_entepto) that are not integrated, inconsistent, contradictory, using non standard terminology, any kind of info.
BUT created views, we must clearly define the entepto on which the views are created. Otherwise the views will be a source of ambiguity.
[KasNik, 2008-01-08]
===
The ability of the system to store NOT only one KB but many.
[hmnSngo.2007-09-15]
name::
* McsEngl.Mcsm'DIRECT-INDIRECT-DISTINCTION@cptIt,
All the stored information will be original (info of the brain-organism presented) or replica (info of other brain-organisms)
[KasNik, 2007-11-26]
FOR A KONCEPTO:
1) knows all the dezignepteros used by current BB and all others (dezignosets)
2) For the his-dezignepteros must know what the other BBs mean (sensesets).
3) For the same referento of the koncepto, must know what the other BBs think (infoviews)
[KasNik, 2007-11-30]
CONTEXT_OF_TERM:
it is any kognepto_model or kognepto_base uses the term.
[KasNik, 2007-12-28]
name::
* McsEngl.Mcsm'administering@cptIt,
_GENERIC:
* doing#ql:cbsmgr'doing#
name::
* McsEngl.Mcsm'EVOLUTING@cptIt,
* McsEngl.Mcsm'evoluting@cptIt,
see and Mcs_evolution#ql:Mcs'evoluting#
Η ανάπτυξη του 'κεντρικού' συστήματος-δομημένων-εννοιών (ΣΔΕ) θα γίνεται ως εξείς.
- Μεμονομένοι χρήστες ή ομάδες, με τη βοήθεια του προγράμματος δημιουργίας ΣΔΕ, θα δημιουργούν συστήματα 'συμβατά' με το κεντρικό.
- Ομάδα εμπειρογνομόνων θα ελέγχουν τη συμβατότητα και τότε θα γίνεται η ολοκλήρωση.
- Πάντα μιλάμε για online σύστημα.
- Ο τελικός χρήστης θα έχει στην οθόνη του ένα παράθυρο που θα ψάχνει την 'search engine' του κεντρικού (κάτι ανάλογο με τη synonyma.nfo που έχω εγώ τώρα), και από κεί θα έχει πρόσβαση στην κατανεμημένη δομημένη-πληροφορία που τον ενδιαφέρει.
[ΝΙΚΟΣ 1997μαιο06]
name::
* McsEngl.Mcsm'HISTORY@cptIt,
{time.2007-11-29}::
=== WEB_BROWSER_KCSP:
I began to write the html-files of my AAj-page as KONCESTOS.
{time.2002-05-19}::
=== conceptual-model vs descriptive-information:
Now I have realized that:
** 'concept' is a system-organization and the outermost-concept I call "conceptual-model".
** each man has one conceptual-model.
** 'descriptive-information' is any outermost-system-of-statements that describe concepts.
** 'logos' is a representation of descriptive-information using a human-language.
** 'structured-concept' is a textual-representation of a concept.
** jSCS uses xml-structured-concepts that include representations of descriptive-information.
** jSCS must have a data-type, the jCpt, that are representations of xml-sc for a decent concept-management.
{time.{2001-04-28}}::
=== Integrated-ConceptBase:
I treat as SAME the names 'conceptual-information' and the 'concept-base'. Then identify as the goal of a scs the creation of an 'INTEGRATED-CONCEPTBASE'.
{time.2001-03-05}::
=== Synonym:
"SC SYNONYM is ANY noun/verb/adjective/adverb/operator form (lexeme) of the SC in any language".
{time.1999-02-07}::
=== Whole-Part Integration:
The system check for the whole-part relations of the current concept and give messages on that.
[nikos] 1999feb08
{time.1997-12-21}::
=== XML:
My first java program, that uses structured-concepts in xml format, and the aelfred parser to read it.
[nikos] 1998dec30
{time.1997-05-12}::
=== Java:
My first java program, that shows how the user-interface will be.
[nikos] 1998dec30
{time.1997}::
=== Giannena: ATTRIBUTES
I began to treat every concept-attribute as a concept with definition, attributes, subgeneral in my folio'views'scs.
[nikos] 1998feb24
{time.1994-1995}::
=== Poros Island: DEFINITIONS
I eliminated the vicious-cycles in my definitions with the use of analytical and synthetical definitions. We can define a concept ONLY in one way.
[nikos] 1998feb24
{time.1994}::
=== FOLIO_VIEWS_WIN:
I started a new system with folio Views 3 (windows). My new system, with the 11.000 koncestos, proved one thing to me. We CAN use the "koncesto" approach to write scientific knowledge. Also became apparent to me that I had to write my own program.
{time.1993forcast}::
ΣΕ ΠΡΩΤΗ ΦΑΣΗ ΘΑ ΥΠΑΡΞΕΙ ΤΟ ΣΥΣΤΗΜΑ ΕΚΕΙΝΟ ΠΟΥ ΚΑΠΟΙΟΣ ΘΑ ΓΡΑΦΕΙ ΕΝΑ ΒΙΒΛΙΟ, ΟΠΟΥ ΟΛΗ Η ΠΛΗΡΟΦΟΡΙΑ ΘΑ ΕΙΝΑΙ ΔΟΜΗΜΕΝΗ. 2000.
ΣΕ ΔΕΥΤΕΡΗ ΦΑΣΗ ΘΑ ΔΟΜΗΘΟΥΝ ΕΠΙΣΤΗΜΕΣ. 2010.
ΣΕ ΤΡΙΤΗ ΦΑΣΗ ΘΑ ΟΛΟΚΛΗΡΩΘΟΥΝ ΟΛΕΣ ΟΙ ΕΠΙΣΤΗΜΕΣ. 2033.
[ΝΙΚΟΣ, ΟΚΤΩ 1993]
{time.1992}::
=== FOLIO_VIEWS_DOS:
I made a system with the hypertext program Folio Views 2.1 (DOS).
{time.1990}::
=== WORD_PROCESSOR, DBASE_IV:
My first try to implement my "paper_koncesto_system" with "word-perfect".
In a week I abandoned my try.
My second try was the DBASE_IV relational-database program. I spent a lot of work-hours for nothing.
{time.1990-08-30}::
=== sss-terminology:
SSS/SCIENCE SUPPORT SYSTEM: support the evolution of a science. An example is my dbase system.
[NIKOS, AUG. 30 1990]
{time.1987-06-13}::
=== "ΒΙΒΛΙΟ ΣΕ ΚΟΜΠΙΟΥΤΕΡ"
- Θα παίρνει υπόψη του τη διαφορετικότητα κάθε αναγνώστη. Ετσι θάχει πρόσβαση στις έννοιες από πολλές πλευρές (επαναληπτικά). Η χρησιμότητα του Η/Υ θα βρίσκεται στην εκμετάλευση χώρου.
- Θα είναι συγχρόνως και ΛΕΞΙΚΟ πχ των εννοιών και θα έχει και την σύνθεση σε διάφορα επίπεδα-αφαίρεσης της θεωρίας.
- Θα μπορεί να σου δίνει το πλήθος των εννοιών στο βιβλίο και τις συσχετίσεις βάσει των ορολογιών τους με σχήματα.
- Τότε θα φανούν τα χαρακτηριστικά έννοιας (ορολογία, σημασία, συμβολισμός, παράσταση).
[ΝΙΚΟΣ]
name::
* McsEngl.Mcsm'FUTURE@cptIt,
{time.1993oct}::
=== Back in 1993 I focecasted this:
By the year 2000, we gonna have a system where someone can write a book in which all information will be structured.
By the year 2010, we will see a structured-science.
By the year 2033, we will see ALL sciencies structured.
ΣΕ ΠΡΩΤΗ ΦΑΣΗ ΘΑ ΥΠΑΡΞΕΙ ΤΟ ΣΥΣΤΗΜΑ ΕΚΕΙΝΟ ΠΟΥ ΚΑΠΟΙΟΣ ΘΑ ΓΡΑΦΕΙ ΕΝΑ ΒΙΒΛΙΟ, ΟΠΟΥ ΟΛΗ Η ΠΛΗΡΟΦΟΡΙΑ ΘΑ ΕΙΝΑΙ ΔΟΜΗΜΕΝΗ. 2000.
ΣΕ ΔΕΥΤΕΡΗ ΦΑΣΗ ΘΑ ΔΟΜΗΘΟΥΝ ΕΠΙΣΤΗΜΕΣ. 2010.
ΣΕ ΤΡΙΤΗ ΦΑΣΗ ΘΑ ΟΛΟΚΛΗΡΩΘΟΥΝ ΟΛΕΣ ΟΙ ΕΠΙΣΤΗΜΕΣ. 2033.
[ΝΙΚΟΣ, ΟΚΤΩ 1993]
_GENERIC:
* worldview-management-system#cptCore402#
* program-knowledge#cptItsoft497#
name::
* McsEngl.Mcsm.specific#cptCore768#@cptIt,
_SPECIFIC:
* PAPER (not program) (1985)##
* WORD_PERFECT (1990)##
* DBASE_IV (1990)##
* FOLIO_VIEWS_DOS (1992)##
* FOLIO_VIEWS_WIN (1994)##
* AAj-(1997)#cptItsoft1047: attSpe#
* WEB_BROWSER (2007)##
* WikiConcept (2011)
* REAL-mdbm-(sss1)#cptIt522: attSpe#
* Medium-Term-mdbm-(sss2)#cptIt520: attSpe#
* Long-Term-mdbm-(sss3)#cptIt519: attSpe#
name::
* McsEngl.Mcsm.DBASE-IV (1990)@cptIt,
* McsEngl.conceptIt356.5,
name::
* McsEngl.Mcsm.FOLIO-VIEWS-DOS (1992)@cptIt,
* McsEngl.conceptIt356.4,
name::
* McsEngl.Mcsm.FOLIO-VIEWS-WIN (1994)@cptIt,
* McsEngl.conceptIt356.3,
* McsEngl.fvw-cbsmgr@cptIt356.3,
_DEFINITION:
It is a primitive Koncesto-Program using the Folio Views hypertext program. This program uses a proprietary markup language. I created a workable system with a Knowledge-base of about 12.000 koncestos. I'm holding in this system much of the knowledge I know and I consult it any time I have my computer open. (In contrast the java system have functions a real scs must have but it is not yet a workable one)
FUNCTIONS:
Knowledge-Retrieval: Searching is the notable dufino. I have a file (Infobase in folio-views terms) with all synonyms of my konceptos. With a simple notation I find easily the koncepto I want. Then from the synonyms-infobase I have links to the actual konceptos. For example: writing the yordero "computer" I have 220 hits. This means that I have 220 konceptos which have in its name the yordero 'computer'. But writing "computer-" I see on the left "computer-227". Then I fill up the number 227 and then I have ONE hit, the koncepto 'computer'.
Koncepto Relatinos: I'm duino inheritance semi-manually. The program finds the general-attributes and then I copy them!!
Definition's Vicious-Circle Problem: We always encounter this problem in todays encyclopedias and dictionaries. I solved it in this system by dividing the definitions into analytical and synthetical ones.
_CREATED: {2011-11-29} {1997-11-09}
name::
* McsEngl.Mcsm.AAj (1997)@cptIt,
* McsEngl.conceptIt356.12,
* McsEngl.aaj-sensorial-concept-program@cptIt1047, {2008-09-29}
* McsEngl.aaj-koncesto-program@cptIt1047, {2008-01-27}
* McsEngl.aaj-bbpp@cptIt1047, {2007-12-15}
* McsEngl.aaj-brainepto'base'purification'program@cptIt,
* McsEngl.AAj@cptIt, {2004-08-08}
* McsEngl.aaj@cptIt1047,
* McsEngl.aaj@cptIt356.12,
* McsEngl.aa@cptIt, {2003-01-06}
* McsEngl.aa@cptIt1047,
* McsEngl.java-BMM@cptIt,
* McsEngl.jBMM@cptIt1047,
* McsEngl.BMM.java@cptIt1047,
* McsEngl.jv'app.BMM@cptIt,
* McsEngl.java'BMM@cptIt1047,
* McsEngl.AAj-knowledge-integrator@cptIt,
* McsEngl.jv'app.MMM@cptIt,
* McsEngl.jv'app.scs@cptIt,
* McsEngl.jvp.scs@cptIt,
* McsEngl.java'SCSC@cptIt1047,
* McsEngl.SCSC.java@cptIt1047,
* McsEngl.java-sss@cptIt,
* McsEngl.sss.java@cptIt1047,
===
* McsEngl.java'MMM@cptIt1047, {2004-03-26}
* McsEngl.jMMM@cptIt1047,
* McsEngl.MMM.java@cptIt1047,
* McsEngl.java-MMM@cptIt,
* McsEngl.jMMM@cptIt,
* McsEngl.java-structured-concept-knowledge-management-system@cptIt, {1999-02-08}
* McsEngl.java'sc'kms@cptIt1047,
* McsEngl.java'scs'kms@cptIt1047, {1997-11-09}
* McsEngl.java-scs@cptIt, {1997-10-28}
* McsEngl.java'scs@cptIt1047,
* McsEngl.SCS.java@cptIt1047,
* McsEngl.jSCS@cptIt1047,
====== lagoGreek:
* McsEngl.AAj-ΟΛΟΚΛΗΡΩΤΗΣ-ΓΝΩΣΗΣ@cptIt,
_aa:
I'm considering to give it the name "aa" in dedication to my sons Apostolos and Aristotelis.
[hknu_2003-01-06]
AAj is a Knowledge-System--Management program, written in java.
[KasNik, 2007-11-23]
jSCS is a SCS written in java.
[hknu_2003-10-25]
Java--Structured-Concept-Model--Management-System is a Structured-Concept-Model--Management-System written in java.
[hknu_2003-02-14]
name::
* McsEngl.aaj'GENERIC@cptIt,
GENERAL'OBJECTS,
* java app and applet
* SENSORIAL_CONCEPT__PROGRAM#cptItsoft356#
name::
* McsEngl.aaj'ENVIRONMENT@cptIt,
name::
* McsEngl.aaj'PEOPLE@cptIt,
name::
* McsEngl.aaj'USER@cptIt,
aaj'AUTHOR (aaj'EDITOR):
The person who edits a BB.
[KasNik, 2007-09-23]
name::
* McsEngl.aaj'PROFESSIONAL@cptIt,
* McsEngl.creator'of'aaj@cptIt1047,
name::
* McsEngl.aaj'Abbreviation@cptIt,
* McsEngl.aaj'abbreviation@cptIt,
_ALPHABETICALLY:
======================================
- Ekogo = brain-info EkogoSeo = sensorial-brain
- Ego = perceptual EgoSeo = sensorial-perceptual
- Eko = conceptual EkoSeo = sensorial-conceptual
- Edo = semasia-info EdoSeo = sensorial-semasia
- Eto = logo-info
- EtoFo = logo-gestural
- EtoQo = logo-spoken
- EtoTo = logo-textual
======================================
- kogn-ePTo, kogn-eSPTo
- kogn-eTo, kogn-eSTo.
- kogn-ePo, kogn-eSPo.
- lang-eNo, lang-eSNo.
- lang-eRo (-eGRo, -eSRo, -eTRo),
======================================
* ABR = abrevi-eptero.
* ANR = adnoun-ero.
* ANIR = adnounero-instrumentero.
* ANJR = adnounero-jenitivero.
* ANKR = adnounero-akuzativero.
* ANMR = adnounero-nominativero
* ANPR = adnounero-pozesivero.
* ANTR = adnounero-dativero
* ANVR = adnounero-vokativero.
* ANT = adnoun-eto.
* ATP = ATrib-ePo.
* ATM = ATrib-eNo = attribute of koncepteto. (ATN)
* auxNnAj = AuxiliaryNounAdjective.
* auxNnAv = AuxiliaryNounAdverb.
* auxNnCj = AuxiliaryNounConjunctive.
* auxNn = AuxiliaryNoun.
* auxSpNnAj = AuxiliarySpecialNounAdjective
* auxSpNnAv = AuxiliarySpecialNounAdverb
* auxSpNnCj = AuxiliarySpecialNounConjunctive
* auxSpNn = AuxiliarySpecialNoun.
* auxVrb = AuxiliaryVerb.
* AVR = adverb-ero.
* AVT = adverb-eto.
* BPT = brain-epto.
* cnj = Conjunction.
* DEN = DEano.
* DNM = DeaNeMo.
* DNR = DeaNeRo.
* DZR = dezign-eptero.
* ELN = greek language.
* EPL = eksamplo.
* EPO = esperanto.
* ESR = ekspres-ero.
* ETR = ekspres-eto.
* FDK = FoEdoKonco=semasia_concept,
* FDo= FoEdo=semasia_info,
* FDRe= FoEdoRinoReino = SEMASIA_VERB_REINO
* FDRi= FoEdoRino = SEMASIA_VERB
* FDRu= FoEdoRinoRuino = SEMASIA_VERB_RUINO
* FEM = feminine.
* FKg = FoEkogo=brain_info,
* FKgS = FoEkogoSeo =s_brain_info,
* FKgSS = FoEkogoSeoSimbo =S_BRAIN_WORLDVIEW,
* FKK = FoEkoKonco=concept,
* FKo= FoEko=conceptual
* FKSK = FoEkoSeoKonco=s_concept.
* FLR = formalero (FOR = FOrm-eRo, FMR)
* FOR = formero (= term without name)
* FTK = FoEtoKonco=logo_concept,
* FTR = fat-ero.
* FTo = FoEto=logo_info,
* FTQ = FoEtoQo=spoken_info,
* FTT = FoEtoTo=textual+info,
* GNP = GeNer-ePo, GENeral. (GEN)
* IDP = InDivid-ePo.
* IDR = InDivid-eRo.
* IJR = interjektero.
* ISR = instansero.
* KCM = konC-eMo=semasia-concept. (KCN, KNT)
* KCP = konC-ePo=concept. (KNC)
* KCR = konC-eRo=logo-concept. KNR old
* KMN = komono language.
* KPT = kognePTo=brain-info. 2008-03-09. KGP 2008-02-10. KNP old
* KRN = korelateino. (deino)
* KRR = koRelat-eRo.
* KRT = koRelat-eTo.
* KSP = konceSPo=sensorial-concept. (KCS)
* KSPT = kogneSPTo=sensorial-brain-info. KGS 2008-02-10. KNP old
* LGR = lang-eGRo. GESTURAL
* LGO = Logo (subworldview)
* LNC = lang-eCto. S_SEMASIA
* LNR = laNg-eRo. LOGO
* LNT = laNg-eTo. SEMASIA
* LSR = lang-eSRo. SPOKEN
* LTR = lang-eTRo. TEXTUAL
*
* MAS = masculin.
* MDB = modlo-brainepto.
* MDL = modlo-logero.
* MDT = modlo-logetro.
* MDP = modlo-logepro.
* MNT = mineto.
* NAR = namero. (= name)
* NDM = nodemo.
* NDR = nodero.
* NDR = nounodeanero. 2008-02-20
* NDIR = nounodeanero-instrumentero.
* NDJR = nounodeanero-jenitivero.
* NDKR = nounodeanero-akuzativero.
* NDMR = nounodeanero-nominativero
* NDPR = nounodeanero-pozesivero.
* NDTR = nounodeanero-dativero
* NDVR = nounodeanero-vokativero.
* NMR = namero. (NAR)
* NMR1 = first-namero.
* NMR2 = nonfirst-namero.
* NMRGNP = nameroGenerepo
* NMRIDP = nameroIndividepo
* NMKCR = namoKoncero.
* NMNNR = namoNounero
* NMANR = namoAdnounero
* NMAVR = namoAdverbero
* NMVBR = namoVerbero
* NMDER = namoDeanero
* NMLTR = namoLongotliero
* NMFLR = namoFormalero
* NMSBR = namoSimbolero
* nn = Noun.
* nnAj = nounAdjective.
* nnAv = nounAdverb.
* nnCj = nounConjunctive.
* NNM = nounemo.
* NNR = nounero.
* NNT = nouneto.
* NOR = nonimero.
* ONR = onomero.
* ONT = onometo.
* PLU = plural.
* PRR = pronomero.
* PRT = pronometo.
* PONR = onomantero.* PRR = pronomero.
* PRT = periodetro.
* PTR = partero.
* SBP = vudoSimBanepo.
* SBR = simbolero.
* SCPT = sensorial_concept
* SIN = singular.
* SKT = strukturo.
* SLBR = silabero.
* SLR = specialero-konceptero. [2008-02-20]
* SLR = subjektelero.
* SLT = specialeto-koncepteto.
* SMA = Semasia (subwroldview) SMS = semasia.
* SNR = sentensero.
* SNM = sentensemo. (SNT)
* spNn = specialNoun.
* spNnAj = specialNounAdjective.
* spNnAv = specialNounAdverb.
* spNnCj = specialNounConjunctive.
* SPR = specialero.
* SPT = vudoSibanePTo.
* SSMA = SensorialSemasia (subworldview)
* SSPT = vudoSibaneSPTo.
* SSR = special-structures of logeros. [2008-02-20]
* STR = simboleptero.
* SWV = Subworldview.
* TNR = tokenero.
* TMR = TerMerRo. [2008-03-22]
* TRM = term [2008-09-28]
* TRMNL = terminal.
* trmCnj = TermConjunction.
* trmNn = TermNoun.
* trmNnAj = TermNounAdjective
* trmNnAv = TermNounAdverb
* trmNnC = TermNounConjunctive.
* trmSpNn = TermSpecialNoun.
* trmSpNnAj = TermSpecialNounAdjective
* trmSpNnAv = TermSpecialNounAdverb
* trmSpNnC = TermSpecialNounConjunctive.
* trmVrb = TermVerb.
*
* TRR = terminero.
* TXT = text (subworldview)
* VAN = verbaleno. =SVERB'S_ARGUMENT
* VAR = verbalero (any). =VERB'S_ARGUMENT
* VBN = verbeno. =SVERB
* VBR = verbero. (VRB)
* VBS = verbero-strukturo.
* VER = verbelero. (OJR = objektero) =VERB'S_OBJECT
* VDM = vudeto (VDT, VDN) = vudeno =SEMASIA_SUBWORLDVIEW
* VDP = vudepo =CONCEPTUAL_SUBWORLDVIEW
* VDPT = vudepto =BRAIN_SUBWORLDVIEW
* VDR = vudero = LOGO_SUBWORLDVIEW
* VDSM = vudesmo (VST). * VSN = vudesno. =S_SEMASIA_SUBWORLDVIEW
* VDSP = vudespo. =S_CONCEPTUAL_SUBWORLDVIEW
* VDSPT = vudespto. =S_BRAIN_SUBWORLDVIEW
* VOR = verbolero. (SJR = subjektero). =VERB'S_SUBJECT.
* VRB = verb.
* VRBA = verb's_arguement.
* VRBO = verb's_object.
* VRBS = verb's_subject.
* WVW = worldview.
=================================================
* NONIMEROS (NOR): NAMERO (NAR), FORMERO (FOR):
* KONSEPTERO (KNR):
* NOUNEROS (NNR): NMR, NJR, NKR, NDR, NVR, NPR, NIR,
* VERBEROS (VBR),
* ADNOUNEROS (ANR),
* ADVERBEROS (AVR),
* PRONOMEROS (PRR),
* KORELATEROS (KRR),
* INSTANSEROS (ISR): articles, auxiliaries, ...
* INTERJEKTEROS (IJR):
* FATEROS (FTR):
* SPECIAL-EXPRESIONS/LOGEROS (SLR):
* VERBERO (VBR):
* VERBERO-STRUCTURE (VBR): Where#vbs:_sxtVrb:{do [we] go} _stxArg:from here?
* SUBJEKTERO (SJR):
* OBJEKTERO (OBJ):
* VERBERO'S-ARGUMENT (VBA):
* SUBJEKTERO-COMPLEMENT (SJC):
* PONR = Pronomero
* PNNR = Pronounero
* PNMR = Pronounero-nominativero
* PNKR = Pronounero-akuzativero
* PNPR = Pronounero-pozesivero
* PNDR = Pronounero-dativero
* PNJR = Pronounero-jenitivero
* PNVR = Pronounero-vokativero
* PNIR = Pronounero-instrumentero
* PANR = Proadnounero
* PAVR = Proadverbero
* MINETO (MNT):
* LOGERO (LGR):
* TEKSTERO (TKR):
* PAROLERO (PLR)
AKPT'S-DEZIGNEPTERO:
* NOUNERO TXTR RULE
* ADNOUNERO TXTR RULE
* ADVERBERO TXTR RULE
* VERBERO TXTR RULE
* PRONOMERO TXTR RULE
* KORELATERO TXTR
* ABREVIEPTERO TXTR
* AKRONIMEPTERO TXTR
* SIMBOLEPTERO TXTR
** The english-adverbero has no rule, because all instances are created uniquely.
INDEX-DEZIGNEITO:
* DZGT = dezigneito.
* TXTR = textero
* AKPT = artificial-konsepto denoted.
* DTYPE = dezigneito's type:
* nmn?: nonimero of naunero with number x.<LI>
* nmv?: nonimero of verbero with number x.<LI>
* nman?: nonimero of adnaunero with number x.<LI>
* nmav?: nonimero of adverbero with number x.<LI>
* nmp?: pronomero with many nonimeros.
* prr?: pronomero with number x.<LI>
* krr?: korelatero with number x.<LI>
* srn: short-name of a konsepto.<LI>
* sbl: sibolo of a konsepto.<LI>
* akr: akronimo of a konsepto.t;/OL>
** the english adverbero has 1 nonimero, but 3 instances.
The greek has more than one. Then we need numbers.
** Korelateros, shortnames, sibolos and akronimos = ONE INSTANCE.
YORDERO-ABREVIATIONS:
* ANR = adnaunero#ql:adnaunero#.
* AVR = adverbero#ql:adverbero@cptCore554#.
* FMR = formero#ql:formero-22.1#. (word forms)
* FTR = fateros#ql:fatero@cptCore610.7#. (phatic word)
* IJR = interjekteros#ql:interjektero#.
* ISR = instanseros. (non auxiliary)
* KRR = korelatero. (conjunction)
* NAR = naunero-akuzativero. (accusative)
* NDR = naunero-dativero.
* NER = neimero.
* NIR = naunero-instrumentero.
* NJR = naunero-jenitivero.
* NMR = naunero-nominativero
* NNR = naunero.
* NOR = nonimero. (auxiliaryNo)
* NPR = naunero-pozesivero.
* NVR = naunero-vokativero.
* PRR = pronomero.
* SLR = special-logeros|expresions
* VBR = verbero.
ADNAUNEROS (ANR),
ADVERBEROS (AVR),
FATEROS (FTR):
FORMERO (FMR):
INSTANSEROS (ISR): articles, auxiliaries, ...
INTERJEKTEROS (IJR):
KORELATEROS (KRR),
NEIMERO (NER),
NAUNEROS (NNR): NMR, NJR, NPR, NAR, NDR, NIR, NVR,
NONIMEROS (NOR):
PRONOMEROS (PRR),
SPECIAL-EXPRESIONS/LOGEROS (SLR):
VERBEROS (VBR),
_LANGUAGES:
* el = greek
* ela = greek ancient
* en = english
* ep = esperanto
* km = komo
name::
* McsEngl.aaj'API@cptIt,
* McsEngl.aaj'package@cptIt,
_DEFINITION:
* It is the system of classes and interfaces the program uses in order to manange a sc-mental-model.
[hknu_2003-10-31]
name::
* McsEngl.aaj'api.pk-Html@cptIt,
* McsEngl.htmlmgr-1047i@cptIt,
* McsEngl.aaj'HM@cptIt,
* McsEngl.aaj'HtmlMgr@cptIt,
* McsEngl.aaj'pk-Html@cptIt,
* McsEngl.aaj'HtmlViewr@cptIt,
hm'DEFINITION:
It is a browser and a wysiwyg-and-source editor of LocDoc-html-files which
a) creates automatically the table-of-contents
b) shows in ToC the location of mouse-clicks and
c) supports full-text search
[hknu_2010-07-07]
name::
* McsEngl.hm'ToDo:@cptIt,
hm'Todo.FEATURE_REQUEST:
* [2010-09-01] SYN_INDEX:
- when save to create this index.
- from a property, to setup the syn_index.
* INDEX_COMMAND:
- the capability to ADD any file we are viewing, to a new or an existing index.
* INDEX_SEARCH:
- to search and from any stored-index.
* [2010-08-24] SEARCH:
- searching "other member-states" to search:
a) "other member-states"
b) "other" & "member-states"
c) "other"
d) "member-states"
e) "member"
f) "states"
* [2010-08-22] INSERT-CHARACTER:
Insert-Character NonBreakingSpace, Unicode, Math, any by choosing the right font.
* [2010-08-14] BACKUP:
Like jEdit.
* IF an element has no structure-LocDoc, THEN we assume to have the same with the last previous structure-LocDoc [2010-08-01]
when clicking in a non-heading-element without LocDoc, to go to previous heading with LD.
[2010-07-13]
* Bookmarks menu. 2010-05-03
* merge with lucene search, or jEdit HyperSearch. 2010-04-28
* merge with Lucene/DynaQ textfield that shows the words of the index
hm'Todo.BUG_FIX:
* [2010-08-12] EdWw-SFI:
At the begining of an SFI-element java puts the SFI as hidden. Cursor has there 2 positions. If we delete 2 times, we delete the SFI, as we can see in EdSrc.
* [2010-08-12] H2 without H1, MISSING-HEADING
throws a java.lang.NullPointerException and nothing more.
* [2010-08-11] UndoManager: When we change EDITORS, we loose undos, if we remove and then add undoListeners. BUT if we did not remove listener, then sets as undoEdit and the synchronization step. (solution? extend UndoManager, implements UndoableEditListener (already done) add event-source variable)
* [2010-08-03] on ToC to present and <p class=center> elements.
* [2010-07-13] WHEN the link is not a LocDoc, clicking on links, does not show on TOC the target locator, but the source-locator.
name::
* McsEngl.hm'Done:@cptIt,
FEATURE-REQUEST:
* [2010-09-20] Open File And Add
- add toc to existing toc.
* [2010-09-12][2010-08-30] LOAD ICONS FROM JAR:
JarResources jar = new JarResources ("pkHtml/Images.jar");
Image imgLogo = Toolkit.getDefaultToolkit().createImage (jar.getResource ("logo.gif");
ImageIcon ii= new ImageIcon(imgLogo);
* [2010-09-12][2010-08-12] SAVE:
When save a file, 1) sets the version inside 2) to set the version (date) in the name of file and 3) save and another file with name without date. Thus, the current-version will have 2 files.
* [2010-08-28][2010-08-25] JAVA_DEVELOPERS:
- import pk_Html.HtmlMgr;
- new HtmlMgr("path");
- developer, modify
- user, annotate.
* on search resuls, HIGHLIGHT search-token. 2010-06-03
* [2010-08-15] [2010-08-14] ToC-TREE-ICONS:
counting the points in the SFI of heading elements, we can found its level. Then we can have different icons H0,H1,H2, ... for each level.
* 2010-08-12:
When hit ENTER, always insert paragraph-html-element. [2010-08-09]
- when goes to a file, not in the toc, to create the ToC of this file. 2010-06-03
* 2010-08-10:
JEditorPane to become a TabPane with Viewer, Editor-Wysiwyg, Editor-Html. [2010-06-26]
- merge with Ekit free open source Java HTML editor. 2010-04-28
* 2010-08-04: SFI & IFI
LocDocs in EVOLUTION: by modifing a LocDoc-file, we must change the LocDocs.
- then links to previous LocDocs will show different information. What we could do for that?
- Relative and Absolute LocDocs?
[2010-07-28]
- Version and Permanent LocDocs?
#h0.1p2-plGetmanova#
PERMANENT-ADDRESS: index-2010-07-29.html#h0.1p2
* 2010-07-29:
create the parser which will add DOC-LOCATIONS. 2010-05-19.
* 2010-05-19:
createToCXml.
* 2010-05-03:
When, creates the ToC to create and the index, and to store titles of docs.
* 2010-05-03:
merge with InfoViewer plugin. 2010-04-28
BUG-FIX:
* [2010-08-25] <p class=...>
UpdateSFI does not give p-sfi.
* when create a ToC, initializes: history, pairs. 2010-05-19
* html-parser-for-headings, does not works if there are tags inside headings. 2010-04-28
* (bug) the position for heading it is not real, because counts and the previous tags.
name::
* McsEngl.hm'API@cptIt,
hm'FILES_ALPHABETICALLY:
* HistoryModel
* HistoryModelSaver
* HistoryText
* HistoryTextField
* HtmlFileFilter
* HtmlHistoryButton
* HtmlHistoryModel
* HtmlIndex
* HtmlSearchPanel
* HtmlTOCPanel
* HtmlViewer
* ListModelEditor
* RolloverButton
* XMLUtilities
name::
* McsEngl.hm'ADD-ACTION@cptIt,
* McsEngl.hm'Action@cptIt,
1) create the action-class
* class ActionHome extends HtmlMgrAction
2) choose name:
* htmlmgr.actHome
3) create the variable:
* private HtmlMgrAction actHome; //GoTo
4) add in method: createActions():
* actHome = new ActionHome(); //GoTo
5) add in method: createMenu():
* jmnHelp.add(actAbout);
6) add values in properties:
htmlmgr.actHome=Home
htmlmgr.actHome.icon=22x22/go-home.png
htmlmgr.actHome.shortcut=A+HOME
htmlmgr.actHome.description=Go to Homepage
========================================
ToggleAction:
1) in properties:
- htmlmgr.actWrap.toggle=true
2) in action-class:
- uses the boolean: actWrap.isSelected()
name::
* McsEngl.hm'EVOLUTION@cptIt,
2010-04-28: toc from a directory with html files.
name::
* McsEngl.hm'INDEX@cptIt,
NAME:
- index-hknu-synEnglish.txt: all english synonyms
- index-hknu-it.txt:
FORMAT:
- TERM §(167) PREVIOUS § NEXT § URL ¦ URL ¦(166)
- CaseSensitive.
name::
* McsEngl.hm'MENU@cptIt,
hm'menu.FILE:
New-SFI-File
OpenFile ToC
Open-And-Add
Open-Url
Open-Dir
----------
Save
SaveAs
----------
Exit
hm'menu.EDIT:
Copy
Paste
----------
Select
hm'menu.VIEW:
Toolbars
Wrap-Lines
hm'menu.GoTo:
Back
Forward
Home
Reload
----------
Advanced-Search
Find
Replace
----------
List-Directory
----------
History
name::
* McsEngl.hm'OPEN-DIRECTORY@cptIt,
1) HtmlMgr.ActionOpenDir:
Choose a directory of html-files to open.
name::
* McsEngl.hm'ShortCuts@cptIt,
F:
F1= help
F2= Advanced-Search
F3=
F4=
F5= reload.
F6=
F7=
F8=
F9=
F10=
F11=
F12=
ENTER= paragraph
hm'ctrl+:
A= open file and Add
B=
C=
D= open-Directory
E=
F= Find
G=
H=
I=
J= View Java Element-Structure
K=
L= List-directory
M=
N= New-LocDoc-file
O= Open-file
P= (Print)
Q= Exit
R= File: Open Url.
S=
T=
U= Edit: Update SFI
V=
W= Wrap-lines.
X=
Y=
Z=
hm'alt+:
LeftAr= Back
RightAr= Forward
Home= Home
A=
B=
C=
D=
E=
F=
G=
H=
I=
J=
K=
L=
M=
N=
O=
P=
Q=
R=
S=
T=
U=
V=
W=
X=
Y=
Z=
hm'shift+:
A=
B=
C=
D=
E=
F=
G=
H=
I=
J=
K=
L=
M=
N=
O=
P=
Q=
R=
S=
T=
U=
V=
W=
X=
Y=
Z=
ENTER= insert break
name::
* McsEngl.hm'HTML-FILE (LocDoc-file)@cptIt,
* McsEngl.hm'LocDocFile-1047i@cptIt,
_DEFINITION:
The html-files which contain LocDocs and displayed with HtmlMgr.
name::
* McsEngl.hm'DOCTYPE-ELEMENT@cptIt,
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
name::
* McsEngl.hm'HEAD-ELEMENT@cptIt,
<head>
<title>AAj-SBCCS [version: 2010-07-27]</title>
<link href="AAj.css" rel="stylesheet" type="text/css"/>
</head>
name::
* McsEngl.hm'BODY-ELEMENT@cptIt,
* McsEngl.hm'Record@cptIt,
_DEFINITION:
The inner-most parts of html-text.
[hknu_2010-05-07]
RULES (hm'rules_for_files):
* the <p> must contain some TEXT-content.
* The first <p> after <h> must contain LocDoc.
* IF <b> includes ALL text-content, At leat '.' must be out of text-content.
END_OF_FILE:
<h1>
<a name="h1"/>
Table-of-Contents of AAj-Site
</h1>
<ul>
<li><span class="red"><b>Home</b></span></li>
...
</ul>
<p class="last">
LAST-MODIFIED: <b>2010-06-03</b>
<br/>PUBLISHED:
<br/>CREATED: <b>2007-09-14</b>
<br/>URL: http://aaj.sourceforge.net/index.html
<br/>MAIL: userid@domain, where userid=nikkas and domain=otenet.gr
</p>
<p class="center">
<a href="http://sourceforge.net">
<img src="http://sflogo.sourceforge.net/sflogo.php?group_id=324598&type=1" width="88" height="31" alt="SourceForge.net Logo" /></a>
</p>
name::
* McsEngl.hm'SFI-ELEMENT@cptIt,
* McsEngl.sfi-element-1047i@cptIt, {2010-08-12}
_SPECIFIC:
1) Heading_Element
2) Paragraph_Element
1) RECORD-HEADING: h1, ... h6, p.h0, p.h7, p.h8, p.h9
2) RECORD-CONTENT: <p> which will contain <ol>, <ul>, <dl>, <table>, <br>
- The paragraphs <p> will contain sentences.
- The <br> </br> will contain one sentence
- <br/> can be inside sentences.
name::
* McsEngl.hm'SFI-HEADING-ELEMENT (BODY-TITLE-ELEMENT)@cptIt,
* McsEngl.hm'Heading-element@cptIt,
_RULE:
1) The SEQUENCE denotes the structure.
2) ONLY "descending" order is allowed:
h0
h1 h2 h3
h1 h2 h3 h4
h1 h2
h1 h2 h3 h4 h5 h6
=================
h0
h1 h2 h3
h1 h4 h3 h4 <=== not allowed
h1 h2
h1 h2 h3 h4 h5 h6
3) After any heading, we can have content.
[hknu_2010-05-10]
HEADING_0:
<p class="h0">
(Consolidated_versions ::of the_Treaties) (OJ_2008-05-09_C115)
<a class="hide"> hd0: treaties2009</a>
</p>
HEADING_X:
<h3>
<a name="h6.2.7" />
...
<a class="hide">#@h6.2.7-hd3#</a>
</h3>
name::
* McsEngl.hm'SFI-PARAGRAPH-ELEMENT (BODY-NON-TITLE-ELEMENT)@cptIt,
* McsEngl.hm'Content-Element@cptIt,
* McsEngl.hm'Paragraph-Element@cptIt,
FORMAT:
<p>
<a name="h6.2.7c1" />
....
<a class="hide">#@h6.2.7c1#</a>
</p>
XHTML does not accept <ol> inside <p>.
I'll put them AFTER <p>, and I will consider them part of previous <p>.
[hknu_2010-05-13]
<p> will be the outer-most content-records.
- A "sentence" ALWAYS resides IN a paragraph.
- LISTS and TABLES exist inside paragraps.
[hknu_2010-05-09]
<div> ==> sub-contents.
[hknu_2010-05-10]
<span> ===> sentences and part of sentences.
.verb
.asubject
.aobject
.aobject2
.atime
.aplace
.aif
.a
[hknu_2010-05-10]
RULE:
<p class="notoc">
Now, p-elements with class-attribute are NOT shown in ToC.
[hknu_2010-07-27]
name::
* McsEngl.hm'FRAGMENT-IDENTIFIER@cptIt,
* McsEngl.hm'fragmentIdentifier@cptIt,
* McsEngl.hm'LocDoc@cptIt,
* McsEngl.hm'Fragment-Identifier@cptIt,
* McsEngl.hm'Part-Address@cptIt,
* McsEngl.hm'Address-of-parts-of-document@cptIt,
* McsEngl.hm'Identifier-of-parts-of-document@cptIt,
* McsEngl.hm'Unique-name-of-parts-of-document@cptIt,
* McsEngl.hm'Destination-Anchor@cptIt,
* McsEngl.hm'Name-Anchor@cptIt,
_DEFINITION:
LocDoc I call the FragmentIdentifiers I use in html-files.
[hknu_2010-07-29]
_SPECIFIC:
== TITLE-DIVISION of LOCATION-LocDoc ==
* HEADING-LocDoc: h0.2
* PARAGRAPH-LocDoc: h0.2p1
[hknu_2010-07-29]
== ENTITY_DENOTED-DIVISION ==
* INFO-LocDoc: ifiGetmanova (denotes same info, for ALL versions)
* STRUCTURE-LocDoc: h0.2p (denotes structure of doc, in ONE version)
[hknu_2010-07-30]
* INFO-LocDoc: ifiGetmanova (the same info, for all versions)
* LOCATION-LocDoc: h0.2p (location, in a version)
[hknu_2010-07-29]
== RELATIVENESS-DIVISION ==
* PERMANENT-LocDoc ("same"-info in any version, specific-info in specific-version): index.html#ifiGetmanova(info-fi), index-2010-07-29.html#h0.2p1(loc-fi),
* RELATIVE-LocDoc: index.html#h0.2p (loc-fi), index-2010-07-29.html#ifiGetmanova(info-fi)
[hknu_2010-07-29]
All records will have "markers" which will hold:
- its position (offset) in the file.
- the title="names" of records.
- the id="unique-names" of records.
By adding <a name="unique-names"> into to document, java can handle name-links.
_UNIQUE_NAMES:
* h0c1, h0c2, ...
* h1.2c1, h1.2c3,
* h1.3.1c1, h1.3.2c1, ...
* h4.1c1, h4.2c1, ...
_UNIQUE_NAMES:
* h0c1, h0c2, ...
* h12c1, h12c3,
* h131c1, h132c1, ...
* h41c1, h42c1, ...
name::
* McsEngl.hm'SFI (StructureFragmentIdentifier)@cptIt,
name::
* McsEngl.Tim Berners-Lee timbl@w3.org,
PROPOSALon Html Fragment-Identifiers
Today's standards (inclunding html-5), define fragment-identifiers only as UNIQUE strings inside an html-file. I extend this concept, because of the advantages it gives to us.
I propose 2 types of Fragment-Identifiers:
1) STRUCTURE--FRAGMENT-IDENTIFIERS (denote|name the specific structure per version of an html-file) and
2) INFO--FRAGMENT-IDENTIFIERS (denote the same information in ALL versions of a file)
STRUCTURE--FRAGMENT-IDENTIFIERS (SFI):
The SEQUENCE of heading-elements is the necessary and sufficient condition to know the structure of an html-file. Then all the other (body) elements denote information inside the parts denoted by the heading-elements.
The unique-names for the parts (headings and non-headings) are:
* h0, h0p1, h0p2, ...
* h0.1, h0.1p1, h0.1p2, ...
* ...
* h0.1.3.1, h0.1.3.1p1, h0.1.3.2p2, ...
* ...
* h0.4, h0.4p1, h0.4p2, ...
* ...
INFO--FRAGMENT-IDENTIFIERS (IFI):
It is a string of the form "ifiName" that denotes the location of information.
VERSIONING:
- The name of the file denotes its version:
foo.html current-version
foo-2010-08-02.html previous version of 2010-08-02
foo-2010-07-29.html previous version of 2010-07-29, ...
if we have more than one versions per day, we add numbers, after the date: foo-2010-08-02-1.html, foo-2010-08-02-2.html, ...
- foo.html#h0.4.3p2: denotes paragraph2 of 3rd h2 of 4th h1 of CURRENT version.
- foo-2010-08-02.html#h0.4.3p2: denotes paragraph2 of 3rd h2 of 4th h1 of version-2010.08.2 and this is a PERMALINK.
- foo.html#ifiName= denotes specific-information in current-version.
- foo-2010-08-02.html#ifiName= denotes the same specific-information at it was in version-2010-08-02, another PERMALINK.
ADVANTAGES:
I have created the java open-source program HtmlMgr (http://htmlmgr.sourceforge.net/) that demonstrates the advatages of SFIs.
IMPLEMENTATION:
I used the existing standards to implement SFI.
Temporarily, I am using the deprecated name-anchor-element to define the fragment-identifiers, because Java supports only html-3.2 and not the id-global-attributes which is the right way.
SEMANTIC-WEB:
SFIs also is a step towards the semantic-web, because with them machines will understand the structure of html-docs, which is a prerequisite to understand the meaning of the documents.
To this end, the next element html5 must have is the sentence-element: <s>....</s>.
LAST:
Of course, we could wright html with or without SFIs, but the browsers will understand the files and will create automatically the ToC of SFI-files.
name::
* McsEngl.hm'JEditorPane@cptIt,
_DEFINITION:
The text-component we use to manage HTML-TEXT.
EDITOR-TO-TOC:
To SELECT the appropriate node in tree, FROM the editor
1) FROM the location of mouse
AND TreeSet<position, location>
we get the location of the part of html-txt.
2) FROM the location-of-txt
AND Hashtable<StringLoc, DefaultMutableTreeNode> htUrlNode;
we select the appropriate node in the tree.
[hknu_2010-05-11]
name::
* McsEngl.hm'LOCATION@cptIt,
* McsEngl.url-of-belement-1047i@cptIt,
* McsEngl.location-of-records-1047i@cptIt,
_DEFINITION:
A Unique_Name for each body-element.
[hknu_2010-05-10]
It is the ID of the parts of the html-txt.
name::
* McsEngl.hm'POSITION@cptIt,
_DEFINITION:
It is the offset of the DISPLAYED-TEXT in the jEdtrPane.
name::
* McsEngl.hm'TOC-TREE@cptIt,
TOC-TO-EDITOR:
From each NODE we get its file, file-title and marker to display.
DefaultMutableTreeNode node = new DefaultMutableTreeNode(
new HtmlNode(href,title,pos),true);
NODES_DISPLAYED CREATION:
* HtmlParser.processElementContentText
ToC_SPECIFIC:
1) From opening a directory with html files.
2) From opening a single html file.
3) From opening an xml-toc, with a structure of html files from anywhere in the globe.
[hknu_2010-05-11]
HEADINGS:
0) Aqua:
1) Blue:
2) Green:
3) Yellow:
4) ΚιτρινοΠορτοκαλι:
5) Πορτοκαλί:
6) Red:
name::
* McsEngl.hm'WORD-INDEX@cptIt,
We need A hashtable of <word, vector-of-urls-it-appears>.
WORDINDEX-CREATION:
1) HtmlSearchPanel.ActionHandler: start
2) HtmlSearchPanel.getHelpIndex(): creates an HtmlIndex.
3) HtmlIndex.indexHtmlFiles(): specifies which dir/jars to index
4) HtmlIndex.indexDirectory:
5) HtmlIndex.indexFile:
HtmlIndex.indexJar:
6) HtmlIndex.indexStream: indexes the input-stream of a url.
- creates a word-index, a HashMap that holds the word and an object with the word, the index of the file it occurs and an appearance-counter for its file, increased by 10 if it is a word inside of a title.
INDEX:
* HtmlIndex (class): holds functionality
* HtmlFile (class in HIndex): holds the filename and title.
* wordIndex (HashMap<String, Object> in HIndex): holds <word, IGNORE> for non-searchables and <word, Word> for searchable
* files (ArrayList<HtmlFile> in HIndex): holds a list of files as HtmlFiles
* Word (class in HIndex):
name::
* McsEngl.hm'HOW-WORKS@cptIt,
ToC_to_LOCATION:
The ToC-TrNodes contain as object the URLs of files and file-locations.
A Hashtable <strUrl, strTitle>
- kvpHtUrlTitle
- give us what to display in the toc-tree.
POSTION_to_TREE_NODE:
1) We get the block-element (p,h), where the mouse clicks.
2) From the offsets of this element, we get its text.
3) Substring the hidden-location#@h2.3c1#
4) Select the node from pairUrlNode
[hknu_2010-05-19]
======================================
1) the method tmPosUrl
TreeMap <intPos, strUrl> The pair position-url for EACH-FILE.
- kvpHtUrlFilePosTM;
2) A Hastable <strUrl, tmPosUrl>
- kvpHtUrlFilePosTM
- to find the treemap with the position of a file.
3) A Hashtable <strUrl, TreeNode>
- kvpHtUrlNode
- help us to select the toc-node FROM a position in the editor.
WORD_to_LOCATION:
A Hashtable<strWord, treesetUrl>
- htWordUrl
- gives the locations that contain a searched-term.
- Map<String, Object> wordIndex;
- A term (words with - or _) will be added. Also the words of the term will be added with the same urls.
name::
* McsEngl.hm'IMPORT@cptIt,
name::
* McsEngl.hm'FolioViews-Import@cptIt,
SynonymEnlish:
hm'ImportFolioViews,
1)
SAVE FILE AS sfi|hsbc-name.html with enconding:UTF-8, linux-line.
REMOVE folio-definition part, <GR:empty>, <RD:OBJECT>[ ]*#
from DEF fv-file, write the path of images: /img/img-aaa-1....png
MgPol: replace this text with unicode with macro
check for < >
IF we run many times this macro, THEN the & MULTIPLIED
3)
run pkHtml.HtmlMapFolioViews
run pkHtml.HtmlUpdateSFI (not allow GAPS in headings)
<span class="size-x-large">
* no </span>
Font-Arial:
* has western-letters. ==> Macro maps to Unicode.
name::
* McsEngl.hm'PUBLISH@cptIt,
2) createJarHtml.bat:
- last icon file
- last css file
3) index.html:
- set version
- download
-#h0.toc#
name::
* McsEngl.hm'JAVA-WEB-START@cptIt,
1) HtmlMgr: search javaws and change.
3) create jnlp(set inside last files) and jar files.
4) sign jar: jarsigner -keystore hknuKeystore jnlp-Icons-2010-08-30.jar HoKoNoUmo
jarsigner -keystore hknuKeystore jnlp-HtmlMgr-2010-09-12.jar HoKoNoUmo
6) upload: index, jnlp-HtmlMgr-date.*, new-images.
7) delete cach when testing:
\Documents and Settings\HoKoNoUmo\Application Data\Sun\Java\Deployment\cache
name::
* McsEngl.hm'FromAAjToIndependent@cptIt,
HtmlMgr.java: (search: iii)
1) delete: import pk_Util.Util;
2) constructor:
strDirHome= Util.AAj_sDir;//
==> strDirHome= System.getProperty("user.dir") + File.separator;
createToCXml("file:g:/file1/aajworking/toc.xml");
==>createToCDir(strDirHome+"doc/");
3) method loadIcon:
String iconPath="file:"+strDirHome+"resources/icons/";
==> String iconPath="file:"+strDirHome+"pk_Html/icons/";
4) class ActionFrameClose:
hmgrJFrame.dispose();
==> System.exit(0);
propertyHtmlMgr.props:
1) different directories:
2) htmlmgr.version
wordIgnored.txt:
1) different directories:
hm'PublishCheck:
1) HtmlMgr.java: version, file to display
2) the latest docs to be in 2 forms: date and nodate.
3) remove the backups of source files
name::
* McsEngl.aaj'api.vsEditor@cptIt,
* McsEngl.aaj'editor@cptIt,
* McsEngl.aaj'vsEditor@cptIt,
* McsEngl.aaj'mdbeditor@cptIt,
name::
* McsEngl.aaj'api.FrameNameroGenerepoMgt@cptIt,
* McsEngl.aaj'FrameNameroGenerepoMgt@cptIt,
TODO:
1) Add, the ability to insert and ONE individual namoKoncero.
[HokoYono, 2008-04-21]
name::
* McsEngl.aaj'api.vsViewer@cptIt,
* McsEngl.aaj'Viewer@cptIt,
* McsEngl.aaj'vsViewer@cptIt,
* McsEngl.aaj'mdbviewer@cptIt,
name::
* McsEngl.aaj'api.FrameFindNamoKonceros@cptIt,
* McsEngl.aaj'FrameFindNamoKonceros@cptIt,
TODO:
1) After inserting knowledge, FIRST to search for existing namokonceros and then to try to find them.
[HokoYono, 2008-04-21]
name::
* McsEngl.aaj'api.vudero@cptIt,
* McsEngl.aaj'vudero@cptIt,
* McsEngl.aaj'mdlogero@cptIt,
name::
* McsEngl.aaj'api.vudero.MapuoloVudetroToVudemoEng@cptIt,
* McsEngl.aaj'MapuoloVudetroToVudemoEng@cptIt,
name::
* McsEngl.aaj'api.vudero.NamoNounoDeanetroEln@cptIt,
* McsEngl.aaj'NamoNounoDeanetroEln@cptIt,
NamoNounero:
έννοια, nmNnrb1
έννοιας, nmNnrb2
έννοια, nmNnrb3
έννοιες, nmNnrb5
εννοιών, nmNnrb6
έννοιες, nmNnrb7
name::
* McsEngl.aaj'api.vudero.NamoVerbetroEln@cptIt,
* McsEngl.aaj'NamoVerbetroEln@cptIt,
NamoVerbetros:
δέρνω, nmVbr1,
δέρνεις, nmVbr2,
δέρνει, nmVbr3,
δέρνουμε|δέρνομε, nmVbr4,
δέρνετε, nmVbr5,
δέρνουν|δέρνουνε, nmVbr6,
δέρνε, nmVbr7,
έδερνα, nmVbr8,
έδερνες, nmVbr9,
έδερνε, nmVbr10,
δέρναμε, nmVbr11,
δέρνατε, nmVbr12,
έδερναν|δέρνανε, nmVbr13,
έδειρα, nmVbr14,
έδειρες, nmVbr15,
έδειρε, nmVbr16,
δείραμε, nmVbr17,
δείρατε, nmVbr18,
έδειραν|εδείρανε|δείρανε, nmVbr19,
δείρω, nmVbr20,
δείρεις, nmVbr21,
δείρει, nmVbr22,
δείρουμε|δείρομε, nmVbr23,
δείρετε, nmVbr24,
δείρουν|δείρουνε, nmVbr25,
δείρε, nmVbr26,
δέρνοντας|δείροντας, nmVbr27,
δέρνομαι, nmVbr28,
δέρνεσαι, nmVbr29,
δέρνεται, nmVbr30,
δερνόμαστε, nmVbr31,
δέρνεστε, nmVbr32,
δέρνονται, nmVbr33,
δέρνου, nmVbr34,
δερνόμουνα, nmVbr35,
δερνόσουν, nmVbr36,
δερνόταν|δερνότανε, nmVbr37,
δερνόμαστε, nmVbr38,
δερνόσαστε, nmVbr39,
δέρνονταν|δερνόντανε, nmVbr40,
δάρθηκα, nmVbr41,
δάρθηκες, nmVbr42,
δάρθηκε, nmVbr43,
δαρθήκαμε, nmVbr44,
δαρθήκατε, nmVbr45,
δάρθηκαν|δαρθήκανε, nmVbr46,
δαρθώ, nmVbr47,
δαρθείς, nmVbr48,
δαρθεί, nmVbr49,
δαρθούμε, nmVbr50,
δαρθείτε, nmVbr51,
δαρθούν, nmVbr52,
δάρσου, nmVbr53,
δαρμένος, nmVbr54,
====================
ονομάζω, nmVbr1
ονομάζεις, nmVbr2
ονομάζει, nmVbr3
ονομάζουμε, nmVbr4a
ονομάζομε, nmVbr4b
ονομάζετε, nmVbr5
ονομάζουν, nmVbr6a
ονομάζουνε, nmVbr6b
ονόμαζε, nmVbr7
ονόμαζα, nmVbr8
ονόμαζες, nmVbr9
ονόμαζε, nmVbr10
ονομάζαμε, nmVbr11
ονομάζατε, nmVbr12
ονόμαζαν, nmVbr13a
ονομάζανε, nmVbr13b
ονόμασα, nmVbr14
ονόμασες, nmVbr15
ονόμασε, nmVbr16
ονομάσαμε, nmVbr17
ονομάσατε, nmVbr18
ονόμασαν, nmVbr19
ονομάσω, nmVbr20
ονομάσεις, nmVbr21
ονομάσει, nmVbr22
ονομάσουμε, nmVbr23a
ονομάσομε, nmVbr23b
ονομάσετε, nmVbr24
ονομάσουν, nmVbr25a
ονομάσουνε, nmVbr25b
ονόμασε, nmVbr26
ονομάζοντας, nmVbr27
ονομάζομαι, nmVbr28
ονομάζεσαι, nmVbr29
ονομάζεται, nmVbr30
ονομαζόμαστε, nmVbr31
ονομάζεστε, nmVbr32
ονομάζονται, nmVbr33
ονομάζου, nmVbr34
ονομαζόμουνα, nmVbr35
ονομαζόσουν, nmVbr36
ονομαζόταν, nmVbr37a
ονομαζότανε, nmVbr37b
ονομαζόμαστε, nmVbr38
ονομαζόσαστε, nmVbr39
ονομάζονταν, nmVbr40a
ονομαζόντανε, nmVbr40b
ονομάστηκα, nmVbr41
ονομάστηκες, nmVbr42
ονομάστηκε, nmVbr43
ονομαστήκαμε, nmVbr44
ονομαστήκατε, nmVbr45
ονομάστηκαν, nmVbr46a
ονομαστήκανε, nmVbr46b
ονομαστώ, nmVbr47
ονομαστείς, nmVbr48
ονομαστεί, nmVbr49
ονομαστούμε, nmVbr50
ονομαστείτε, nmVbr51
ονομαστούν, nmVbr52a
ονομαστούνε, nmVbr52b
ονομάσου, nmVbr53
ονομασμένος, nmVbr54
name::
* McsEngl.aaj'api.vudero.NamoVerbetroEng@cptIt,
* McsEngl.aaj'NamoVerbetroEng@cptIt,
NamoVerbero:
call, nmVbr1,
calls, nmVbr2,
called, nmVbr3,
calling, nmVbr4,
called, nmVbr5,
==============
write
writes
written
writing
wrote
name::
* McsEngl.aaj'api.vudesmo@cptIt,
* McsEngl.conceptIt356.12.6,
* McsEngl.aaj'vudesmo@cptIt,
* McsEngl.aaj'vudemo@cptIt,
* McsEngl.aaj'mdmineto-1047.6@cptIt,
* McsEngl.aaj'mmeaning-1047.6@cptIt,
* McsEngl.aaj'scsmodel'package@cptIt,
_DEFINITION:
* contains the java-classes that map sc-descriptive-information.
CLASS-GENERIC-SPECIFIC-HIERARCHY:
* The real gs-corelations are:
* jSNode:
* jSNodeArgument: any node that can be an argument of a corelation-node.
* jSSentenceStructure
* jSSentence (2nd unit)
* jSNounStructure
* jSUVerb:
* jSUNoun:
* jSNodeCorelation:
* jSUnit: denotes a SC of a scmm, the 1st unit.
* jSUVerb:
* jSUNoun:
* jSNodeCorelation: any corelation of nodes, not hierarchy-corelation.
* Because java does support multiple inheritance, I have this gs-hierarchy:
* jSNode:
* jSSentenceStructure
* jSSentence (2nd unit)
* jSNounStructure
* jSUnit: denotes a SC of a scmm, the 1st unit.
* jSUVerb:
* jSUNoun:
* jSNodeCorelation: any corelation of nodes, not hierarchy-corelation.
- and I exclude manually the jSNodeCorelation from argument-node functionality.
[hknu_2003-11-16]
* jSNode:
* jSSentenceStructure
* jSSentence (2nd unit)
* jSNounStructure
* jSUnit: denotes a SC of a scmm, the 1st unit.
* jSUVerb:
* jSUNoun:
* jSUCorelation: any corelation of nodes, not hierarchy-corelation.
[hknu_2003-11-10]
* jSCSMNode:
* jSCSMSentence
* jSCSMSentenceStructure
* jSCSMNounStructure
* jSCSMConcept: denotes a SC of a scmm.
* jSCSMVerb:
* jSCSMNoun:
* jSCSMCorelation: any corelation of scsm.
[hknu_2003-11-01]
* jNode: any node of sc--descriptive-information,
* jNodeWhole (has parts)
* jNodeStatement extends jNodeWhole
* jSC extends jNodeWhole
* jSCPredicate extends jSC
* jSCStructure extends jNodeWhole
* jNodeCorelation: any corelation-node
_CLASSES:
* public class jSNode = Denotes ANY node of a SCSM.
* public class CoreferenceSet = CoreferenceSet is a Set that contains the dummy-nodes of a defining-node and the defining-node. 2001-06-26
* public class LabelFactory = A class for generating labels to use as DEFINING-LABELS of nodes.
***************************************************************
* public class ExceptionOperation extends Exception
* public class ExceptionParser extends ExceptionTranslation
* public class ExceptionTranslation extends ExceptionOperation
aaj'MNode:
* SPECIFIC:
- defining-node: a node with a defining-label.
- bound-node: with a bound-label such as a dummy-node or an argument. 2001-06-26
name::
* McsEngl.aaj'api.vudemso.MapuoloVudesmoToVudesmo@cptIt,
name::
* McsEngl.aaj'api.vudesmo.MapuoloVudesmoToVudetro@cptIt,
name::
* McsEngl.aaj'api.vudesmo.ParsuoloVudesmo@cptIt,
* McsEngl.aaj'ParsuoloVudesmo@cptIt,
* McsEngl.aaj'VudesmoToVudetro@cptIt,
* McsEngl.aaj'api'smodel'smtolm@cptIt,
_ALGORITHM:
1) creates a javaVudesmo:
ParsuoloVudesmo parsor = new ParsuoloVudesmo();
Nodemo vdsmJ = parsor.parseFromString(vdsmXml);
2) translates the javaVudesmo to output-lang:
StringWriter wr = new StringWriter();
MapuoloVudesmoToVudesmo mmm = new MapuoloVudesmoToVudesmo(vdsmJ,lag);
3) translates the javaVudesmoLang to Vudetro:
MapuoloVudesmoToVudetro mm = new MapuoloVudesmoToVudetro(mmm.jVdsmOut, lag, wr);
return wr.toString();
_CLASS:
* GeneratorLogo extends Generator
* ParserScsm
* TransEnv
* TransScsmToLogo
******** Generated by Jcc ****************
* final class ASCII_UCodeESC_CharStream
* ParseException extends Exception
* ParserScsmJcc implements ParserScsmJccConstants
* ParserScsmJccTokenManager implements ParserScsmJccConstants
* Token
* TokenMgrError extends Error
**********************************************
* public interface ParserScsmJccConstants
name::
* McsEngl.aaj'Bug@cptIt,
* McsEngl.aaj'error@cptIt,
tmp file not renamed:
* a bufer reader|writer is oppend, and the previous file have not deleted.
[2008-12-08]
<TRM TxEXP=" more conceptual">
in adjective terms.
[2008-10-11]
logo.TermTxConjunctivenounEng.getTxConceptTermsIfRuleOnly:
IF the name is multiword, it assums " " and not "-" among the words.
[2008-10-06]
SYNAMER-MANAGEMENT:
- when updates synamers with a new filename does not update the attributes FLN of CONCEPT.
[hknu_2004-03-30]
name::
* McsEngl.aaj'Directory@cptIt,
* McsEngl.conceptIt356.12.11,
aaj'directory.home.MDBRAINEPTO:
* aaj'directory.home.MDBRAINEPTO.info: could contain all the dezignepteros
* aaj'directory.home.MDBRAINEPTO.mdbKomo:
* aaj'directory.home.MDBRAINEPTO.mdbNikkas.aaainfo:
* aaj'directory.home.MDBRAINEPTO.mdbNikkas.LANGUAGE:
* aaj'directory.home.MDBRAINEPTO.mdbNikkas.SIMBANO:
name::
* McsEngl.aaj'Doing@cptIt,
_MAIN:
To MANAGE a STRUCTURED-CONCEPT-BASE.
To MANAGE an Artificial_Brainepto_Base (= the thought of a brain_organism a) direct: about the world and b) indirect: about the thought of the other brain_organism for the world).
[KasNik, 2007-11-30]
_SPESIFEPTO:
======== divizospesifepto on storage ==========
* STORAGE_FUNCTION
* RETRIEVAL_FUNCTION
============ misc ===================
* REASONING
name::
* McsEngl.aaj'RETRIEVAL-FUNCTION@cptIt,
name::
* McsEngl.aaj'ACCESS-RETRIEVAL@cptIt,
name::
* McsEngl.aaj'NAVIGATION-RETRIEVAL@cptIt,
aaj'function.retrieval.navigation,
name::
* McsEngl.aaj'USER-INTERFACE-NAVIGATION@cptIt,
* McsEngl.user'interface'of'aaj-1047@cptIt,
* McsEngl.aaj'function.retrieval.navigation.UserInterface@cptIt,
_DESCRIPTION:
the reader intuitively must easily understand what to do to find knowledge.
The user must can choose the natural-language of the user-interface.
WORLDVIEW_LIST:
* On the line where the user searches concepts, we can put a choice with the WorldViews to search on.
[2009-03-27]
LIST OF LANGUAGE and WORLDVIEW:
on menu or as a tool.
On the TOOLS-BAR, at the end to be a LIST_OF_BRAINEPTOBASES from which a user can choose on which to work.
[KasNik, 2007-09-23]
LANGUAGE_LIST:
On the tools-bar must be and a language-list to choose the natural-language a user wants to see a braineptobase.
[KasNik, 2007-09-23]
STORAGE:
* many natural-langauges,
* written form
* spoken form
ARTIFICIAL_KONSEPTO_ATRIBOS:
Part-Dezignepteros
Part-Inherited
Part-NonInherited
Whole-Konseptos
Part-Complements
Generic-Konseptos
Specific-Complements
Specific-Konseptos
Environment (other)
Definition (important env)
Atribos (not in any category)
[KasNik, 2007-10-04]
The order of the components of a structured-concept must be:
(name)
synonyma
definition
attributes
whole concepts
general concepts
sibling concepts
subgeneral concepts
environment.
[Nikos, 1999jan01]
name::
* McsEngl.aaj'TABLE-OF-CONTENTS-NAVIGATION@cptIt,
* McsEngl.aaj'function.retrieval.navigation.TableOfContents@cptIt,
name::
* McsEngl.aaj'ALPHABETICAL-LIST-NAVIGATION@cptIt,
* McsEngl.aaj'function.retrieval.navigation.Alphabetical-list@cptIt,
name::
* McsEngl.aaj'FINDING-NAVIGATION@cptIt,
* McsEngl.aaj'searching@cptIt,
* McsEngl.aaj'function.retrieval.navigation.Finding@cptIt,
The program, in order to have eficient search mechanism, must search LINKING concepts AND not the entire knowledge-base.
[hknu_2010-03-13]
The reader must quickly and easily find the entity s/he wants by writing or pronouncing its name. From there s/he must find easily any other related knowledge. My AAj does SMART searching, id can search related concepts.
name::
* McsEngl.aaj'ASKING-NAVIGATION@cptIt,
aaj'function.retrieval.navigation.Asking,
The program must have the ability to answer to reader's questions.
- natural-language question answering.
- spoken question answering.
name::
* McsEngl.aaj'PRESENTATION-RETRIEVAL@cptIt,
* McsEngl.aaj'function.Presentation@cptIt,
* McsEngl.aaj'function.Attribute@cptIt,
* McsEngl.aaj'ATTRIBUTE-FUNCTION@cptIt,
name::
* McsEngl.aaj'TABLE-OF-CONTENTS-PRESENTATION@cptIt,
aaj'function.presentation.TableOfContents,
Presentation: knowledge-presentation is the first thing a reader encounters in any computer-system. Reading in a computer screen is very different from reading a paper book. On a computer we are loosing the position in the text we are reading. That's why we must display in the same screen the whole picture of what we are reading. My AAj presents every concept with ALL its relations in a tree. From there also the reader can navigate to any other related entity.
Presentation: The viewer displays one concept at a time AND all its first-level attributes.
The window is divided in two parts. On the left, there is a tree with all the related concepts. From the tree you can navigate to all related concepts. On the right, the definition of the concept and the definitions of the part_concepts are displayed.
_DESCRIPTION:
a) a tree with the structure of attributes.
b) a panel with info about the attributes.
On the tree we can have only the attributes a specific concept has and not all the standard attributes.
[2009-03-16]
name::
* McsEngl.aaj'NATURAL-LANGUAGE-PRESENTATION@cptIt,
The program must "know" all natural-languages and must know to present its KnowledgeBase in every language.
name::
* McsEngl.aaj'TRANSLATION@cptIt,
* McsEngl.aaj'function.Translation-1047i@cptIt,
TRANSLATION:
With a next generation cell-phone, a user could speak in his/her native language and the phone will translate in another through a server-connection.
[hknu_2001-11-23]
Logo-translation: The system must can translate and any other text/speech to any other language. For example, a user with a mobile-phone could speak in his/her native language and the phone will translate the speech in another language through a server-connection.
name::
* McsEngl.aaj'LOGO-COMPARISON-PRESENTATION@cptIt,
aaj'function.presentation.LogoComparison,
The system must have the ability to COMPARE|analyze any other text/speech against its stored-KnowledgeBase.
name::
* McsEngl.aaj'WORLDVIEWS-PRESENTATION@cptIt,
aaj'function.presentation.WorldViews,
The program must can show all attributes or only one with data.
[nikos, 1998jan02]
The system must present the different VIEWS that exist about an entity.
name::
* McsEngl.aaj'EVOLUTION-PRESENTATION@cptIt,
aaj'function.presentation.Evolution,
The system must have the ability to present the evolution of an entity AND the evolution of our knowledge about this entity.
name::
* McsEngl.aaj'ABSTRACTION-PRESENTATION@cptIt,
aaj'function.presentation.Abstraction,
The system must have the ability to present its knowledge in different LEVELS-OF-ABSTRACTION. Like the zoom-in, zoom-out functions in the map-software, it should present the same knowledge-area with more or less details.
name::
* McsEngl.aaj'BUILDING-FUNCTION@cptIt,
* McsEngl.aaj'building-function@cptIt,
* McsEngl.aaj'StorageFunction@cptIt,
name::
* McsEngl.aaj'ACQUISITION-BUILDING@cptIt,
* McsEngl.aaj'function.acquisition@cptIt,
SPECIFIC:
* COLLABORATION
* AUTOMATION
name::
* McsEngl.aaj'TEXT-UNDERSTANDING@cptIt,
* McsEngl.aaj'text-understanding@cptIt,
Because the system does not have a SENSORY-MECHANISM to understand the real-world, it can ONLY supports us in text undertanding. We will give it text to understand it, BUT we are the ones who will take the last decision if the meaning understood is correct for us.
[hknu_2010-03-13]
name::
* McsEngl.aaj'COLLABORATION-ACQUISITION@cptIt,
* McsEngl.aaj'function.building.acquisition.Collaboration@cptIt,
_DESCRIPTION:
Like wikipedia, the power of the system will be the collaboration of the authors of the system. But unlike wikipedia the system will prevent the authors from adding inconsistences AND will help them to add a different subworldview on a same subject.
name::
* McsEngl.aaj'AUTOMATION-ACQUISITION@cptIt,
* McsEngl.aaj'function.building.acquisition.Automation@cptIt,
_DESCRIPTION:
Despite the power of author-collaboration, the amount of information will force us to automate the procedures. For example, in a future networked-economy the computers of the companies and households will automatically feed the servers with new data.
- mechanical learning.
- Sensor-support: Brain-organisms have sensory-systems to acquire information in order to create|update|improve their Brain-Worldviews. Today computers have not sensors. In the future they will have.
name::
* McsEngl.aaj'ADDITION-BUILDING@cptIt,
* McsEngl.aaj'function.building.Addition@cptIt,
name::
* McsEngl.aaj'SIMPLE-ADDITION@cptIt,
* McsEngl.aaj'function.building.addition.Simple@cptIt,
Simple-Entrance:
The Author must enter the information in natural-language form (as statements) and not in any kind of knowledge-representation-language. This way, AUTHOR can be anyone and NOT an infotech expert.
name::
* McsEngl.aaj'NATURAL-LANGUAGE-ADDITION@cptIt,
* McsEngl.aaj'function.building.addition.NaturalLanguage@cptIt,
The program must "know" all natural-languages, understand speech and store knowledge by transforming speech to sensorial-brain-worldviews.
name::
* McsEngl.aaj'WORLDVIEW-ADDITION@cptIt,
* McsEngl.aaj'function.building.addition.Worldview@cptIt,
Because information is a REFLECTION of the universe, it is a SUBJECTIVE entity. Then we don't try to create ONE integrated worldview but many. But the program must have the ability to find inconsistencies and contradictions FIRST inside each brain-worldview and SECOND among brain-worldviews.
name::
* McsEngl.aaj'EVOLUTION-ADDITION@cptIt,
* McsEngl.aaj'function.EVOLUTION@cptIt1047,
* McsEngl.evolution'function'of'aaj@cptIt1047,
* McsEngl.aaj'function.building.addition.Evolution@cptIt,
_DEFINITION:
The universe and our knowledge about it both are constantly EVOLVING. Then the program must have the ability to store and present its information evolutionarily. It must be able to present its state of knowledge at every previous time-point.
The ability of the system to store the evolution of itself.
[hknu_2007-09-15]
IMPLEMENTEINO:
KONSEPTO_EVOLUTION:
Entity@bbKasNik.simb-7(2007-09-24).xml
Entity@bbKasNik.simb-24(2007-09-24).xml
<DZR ESTR="atributeino" AKNS="relation.Atribeino@bbKasNik.simb-20" NAR="atributeino" TTYPE="nor.nnr1"/>
DEFINITION_EVOLUTION:
The system can store every new definition and preserve the olds, as diferent xml-elements.
Every definition will have its creation date.
Then when some information referes to this definition, the information-date >= definition-date. The definition-date can NOT be newer (greater) than that of the information-date.
[KasNik, 2007-09-24]
DEZIGNEPTERO_EVOLUTION:
Dezignepteros are dynamic. New are created, others change meaning (concepts) and others are died (no more used).
Dezignepteros must have its usage-date.
The information-date >= newer dezigneptero-date.
[KasNik, 2007-09-24]
name::
* McsEngl.aaj'VALIDATION-ADDITION@cptIt,
* McsEngl.aaj'consistency@cptIt,
* McsEngl.aaj'integration@cptIt1047,
* McsEngl.aaj'function.building.addition.Validation@cptIt,
We never manage to store coherent, consistent, integrated information, if the program will have no reasoning capabilities, such as:
Consistency-Checking:
It must guarantee that the stored-knowledge is a consistent whole. The program must find the violations among the relations of the concepts.
Definition-integration:
The definition is the relations that uniquely distiguish a concept from others. The program must check if the "defining-relations" are unique for every concept.
Generic-integration:
The attributes of the generic-cpts of the current-cpt must be attributes of the current-cpt. If not, the program must report and fix the error. Also, changing the attributes of a generic, the program must change the attributes and in its specifics.
Specific-integration:
The specific-cpts must have as attributes the attributes of the current-cpt. Also a specific of current-cpt must have as generic the current.
Part-integration:
The parts of the current-cpt must have as whole the current-cpt.
Whole-integration:
The wholes of the current-cpt must have as parts the current-cpt.
Specific-complement-integration:
Every concept of a specific-division must have the others in its specific-complement-attribute. Also the specifics of a concept must form complete-divisions on an attribute.
Partial-complement-integration:
Every concept of a partial-division must have the others in its partial-complement-attribute.
Relation-integration:
Creating a relation of the current-cpt with concept2, the program must create the same relation in concept2 with the current-cpt.
name::
* McsEngl.aaj'ATTRIBUTE-INTEGRATION@cptIt,
* McsEngl.aaj'integration.attribute@cptIt,
Every attribute of a concept, is the argument (codomain) of a relation with domain the current-concept.
The definition of this relation, denotes what entities must be in its domain and codomain.
The program must check this consistensy.
EXAMPLE: colorness-relation:
a) the domain must be a material-object (ideas does not have color)
b) the codomain must be a color.
[KasNik, 2007-09-20]
name::
* McsEngl.aaj'GENERIC-INTEGRATION@cptIt,
* McsEngl.aaj'integration.generic@cptIt,
General_Integration:
The attribute-cpts of the general-cpts of the current-cpt must be attribute-cpts of the current-cpt. If not my system fixes the error.
IF general is none, THEN specific-complement is also "none".
GENERAL_CONCISTENCY:
The s-concept must have as attributes, the attributes of its general-concept.
I can have 2 hashtables with these attributes and compare them throwing 'errors'.
code example (SimpleAttributeSet.java jdk1.2)
/**
* Checks whether the attribute list contains all the specified name/value pairs. * * @param attributes the attribute list * @return true if the list contains all the name/value pairs */
public boolean containsAttributes(AttributeSet attributes)
{
boolean result = true;
Enumeration names = attributes.getAttributeNames();
while (result && names.hasMoreElements())
{
Object name = names.nextElement();
result = attributes.getAttribute(name).equals(getAttribute(name));
}
return result;
}
[1999jan21]
name::
* McsEngl.aaj'SPECIFIC-INTEGRATION@cptIt,
* McsEngl.aaj'integration.specific@cptIt,
Subgeneral_Integration:
The subgeneral-cpts of the current-cpt must have as attribute-cpts the attribute-cpts of the current-cpt. Also a subgeneral of current-cpt must have as general the current. If not my system fixes the error.
The specifics of a concept must form complete-divisions on an attribute.
[KasNik, 2008-01-20]
name::
* McsEngl.aaj'WHOLE-INTEGRATION@cptIt,
* McsEngl.aaj'integration.whole@cptIt,
Whole_Integration:
The whole-cpts of the current-cpt must have as part-cpts the current-cpt. If not my system fixes the error.
* If whole is none, THEN partial-complement is none.
[2009-09-13]
name::
* McsEngl.aaj'PART-INTEGRATION@cptIt,
* McsEngl.aaj'integration.part@cptIt,
Part_Integration:
The part-cpts of the current-cpt must have as whole-cpt the current-cpt. If not my system fixes the error.
* All the PARTS of current, must belong in the same subWorldView.
[2009-05-29]
name::
* McsEngl.aaj'ENVIRONMENT-INTEGRATION@cptIt,
* McsEngl.aaj'integration.environment@cptIt,
Environment_Integration:
An environment relation with another 'object' must be environment relation also to that 'object' and any environment relation must be related at least to two objects. If not my system fixes the error.
MAPING_INTEGRATION:
* the source and the target must have "analogous" attributes.
[2009-03-30]
name::
* McsEngl.aaj'COMPLEMENT_INTEGRATION@cptIt,
SPECIFIC_COMPLEMENT_INTEGRATION:
* Every concept of a specific-division must have the others in its specific-complement-attribute.
[KasNik, 2008-01-20]
* When creating a divizospesifepto, its elements must have its specific-complements.
[KasNik, 2007-09-23]
PARTIAL_COMPLEMENT_INTEGRATION:
* When creating a divizopartepto, its elements must have its partial-complements.
[KasNik, 2007-09-23]
name::
* McsEngl.aaj'DEFINITION-INTEGRATION@cptIt,
* McsEngl.aaj'integration.definition@cptIt,
* McsEngl.aaj'definement-validation@cptIt,
* McsEngl.aaj'validation.definement@cptIt,
_DEFINITION:
The DEFINITION is the relations that uniquely distiguish a concept from others. The system could check if the "defining-relations" are unique for every concept.
[hknu_2007-09-24]
CIRCULAR_DEFINITION_CHECKING:
* more general: the system must check IF any definition, IS a definition: ie uniquely identifies the concept.
[hknu_2009-10-25]
* Every konsepto must have a unique node per hierarchy. In ONE hierarchy a konsepto can be defined in two ways analytic (top=>down) or synthetic (down=>top).
[KasNik, 2007-09-30]
* The definitions will stored as analytic or synthetic.
* The definufulo (the new-concept) MUST NOT BE any previous definufelo.
[KasNik, 2007-09-26]
RULE:
* IF there is a DEFINEMENT_SPECIFIC_START,
THEN mus also exist and a DEFINEMENT_GENERIC_END.
hknu_[2009-04-02]
RULE:
* IF there is a DEFINEMENT_GENERIC_START,
THEN mus also exist and a DEFINEMENT_SPECIFIC_END.
[hknu_2009-04-02]
RULE:
* IF there is a DEFINEMENT_PART_START,
THEN mus also exist and a DEFINEMENT_WHOLE_END.
[hknu_2009-04-02]
RULE:
* IF there is a DEFINEMENT_WHOLE_START,
THEN mus also exist and a DEFINEMENT_PART_END.
[hknu_2009-04-02]
RULE:
* The name of the concept in a definition, must be also in the name-relation of the concept.
[hknu_2009-09-20
name::
* McsEngl.aaj'TIME-INTEGRATION@cptIt,
* McsEngl.aaj'validation.time@cptIt,
_DESCRIPTION:
The LASTmOD of XCONCEPT element must be the newest date in the file.
name::
* McsEngl.aaj'CHANGE-BUILDING@cptIt,
* McsEngl.aaj'function.building.Change@cptIt,
name::
* McsEngl.aaj'ATTRIBUTE-CHANGE@cptIt,
* McsEngl.aaj'function.building.change.Attribute@cptIt,
_DESCRIPTION:
To change the type of an attribute, eg from "part" to become an "environment".
But to take into account and its consequences.
[2009-04-13]
name::
* McsEngl.aaj'TERMINOLOGY-CHANGE@cptIt,
* McsEngl.aaj'function.building.change.Terminology@cptIt,
Any change in the name of a concept must take effect all over the system's KnowledgeBase.
name::
* McsEngl.aaj'VALIDATION-CHANGE@cptIt,
* McsEngl.aaj'function.building.change@cptIt,
The system must detect the affected concepts when we change one AND must integrate the new with the existing KnowledgeBase. For example, adding an attribute in a generic-concept, then the program adds the new attribute in all its specifics.
name::
* McsEngl.aaj'UPDATE-CHANGE@cptIt,
* McsEngl.aaj'function.building.change@cptIt,
The world always is changing. The system must follow this change.
- automatic update is a goal.
name::
* McsEngl.aaj'MISC-FUNCTION@cptIt,
name::
* McsEngl.aaj'WORLD-VIEW-FUNCTION@cptIt,
* McsEngl.aaj'function.WorldView@cptIt,
_DEFINITION:
The ability of the system to store NOT only one KB but many.
[hknu_2007-09-15]
name::
* McsEngl.aaj'HUMAN-LANGUAGE@cptIt,
* McsEngl.aaj'function.human-language@cptIt,
_DEFINITION:
The ability of the system to store the knowledge in MANY natural-langauges.
[hknu_2007-09-15]
name::
* McsEngl.aaj'DEZIGNEPERO-MANAGEMENT@cptIt,
* McsEngl.aaj'terminology-management@cptIt,
LANGO_KOMONO:
* Validates any komono-yordero against its system of suffixes.
* Create new yorderos.
name::
* McsEngl.aaj'KOMONO-YUORDERO-MANAGEMENT@cptIt,
* McsEngl.aaj'function.KomoWordManagement@cptIt,
* McsEngl.aaj'function.yuordero-komono-management@cptIt,
API:
class FrameYuorderoKomonoManagement extends JFrame
VALIDATES_YUORDETRO:
* It finds if a leksetro can be a komono yuordetro:
* 1) It finds if uses a reserved prefiksetro.
* 2) It finds if uses a reserved sufiksetro.
* 3) It finds if the leksero is already a komono yuordero.
* 4) It finds if it has valid silabetros.
name::
* McsEngl.aaj'DEFINITION-FUNCTION@cptIt,
* McsEngl.aaj'function.Definition@cptIt,
_DESCRIPTION:
The program will store:
1) a concept's-definement: its creation process in a specific WorldView, eg as part, whole, ... of another concept.
2) a concept's-identifinements: the part, whole, generic, ... ways we can IDENTIFY (= uniquely distiguish it from other concepts) it.
[2009-03-16]
name::
* McsEngl.aaj'REASONING@cptIt,
* McsEngl.inference'in'aaj@cptIt1047,
_DEFINITION:
REASONING is the retrieval or storage functions the tool "entails" from the knowledgebase.
[hknu_2007-09-14]
Cyc implements the inference of the system with the same language that builds the BraineptoBase. AAj implements it with the language that builds the system (= java). The drawback of the latter is that the bb_author can not change it at runtime.
[KasNik, 2007-09-23]
name::
* McsEngl.aaj'LANGESNO-to-LANGETRO@cptIt,
Util.mapMdmaToTextero(mdmeaning, Language){
1. A MParsor maps the mdm-char to mdm-java:
MParsor parsor = new MParsor();
MNode mdmj = parsor.parseFromString(mdmeaning);
2. A MMaporToMeaning maps the mdm-j to the output language:
MMaporToMeaning mmm = new MMaporToMeaning(mdmj,language);
3. A MMaporToTextero maps the mdm-j to textero:
MMaporToTextero mm = new MMaporToTextero(mmm.jmdmOut, language, wr);
}
name::
* McsEngl.aaj'File@cptIt,
name::
* McsEngl.aaj'file.JAVA@cptIt,
* McsEngl.aaj'source-file-1047i@cptIt,
* McsEngl.source-file-of-aaj-1047i@cptIt,
name::
* McsEngl.aaj'file.CLASS@cptIt,
* McsEngl.aaj'class-file-1047i@cptIt,
* McsEngl.source-file-of-aaj-1047i@cptIt,
DIRECTORY:
* home/help
* home/vsEditor
* home/vsViewer
* home/vudemo
* home/vudero
* home/util
name::
* McsEngl.aaj'file.KONCESPO@cptIt,
* McsEngl.aaj'koncespo-file-1047i@cptIt,
* McsEngl.koncespo-file-of-aaj-1047i@cptIt,
DIRECTORY:
* home/aajKB/VudoSimbanepto/Vudepto
_ENTRY:
<NOUNERO TXR="Notion" RULE="enn11" LASTMODIFIED="2001-05-14" CREATED="2001-05-14" AUTHOR="nikkas"/>
<ADNOUNERO TXR="Conceptual" RULE="enan42" LASTMODIFIED="2001-06-29" CREATED="2001-06-29" AUTHOR="nikkas"/>
<ABREVIEPTERO TXR="knc" LASTMODIFIED="2000-02-19" CREATED="2000-02-19" AUTHOR="nikkas"/>
name::
* McsEngl.aaj'file.TERM@cptIt,
* McsEngl.conceptIt356.12.13,
* McsEngl.TermFile-of-aaj-1047.18@cptIt,
* McsEngl.aaj'file.NAMERO-1047.13@cptIt,
* McsEngl.aaj'namero-file-1047.13@cptIt,
* McsEngl.dezigneptero'file-1047.13@cptIt,
* McsEngl.term-lng-index.xml@cptIt,
_DEFINITION:
* DEZIGNATO.LANG.INDEX.XML are files that contain all the NONIMEROS of the dezignatos of the artificial-konseptos of the aaj.
[hknu_2006-06-08]
_DIRECTORY:
* home/aajKB/TERMINAL/lag
* home/aajKB/TERMERO/lag
_ENTRY:
* <TERM TxEXP="attributes" TRMTYPE="trmNnC2" SrCPT="Attribute@HoKoNoUmo.simb-21" NAME="attribute"/>
- this way I use less storage.
[2008-11-11]
* <TRM TxEXP="atributes">
<SYNTAX TxEXP="attributes" TRMTYPE="trmNnC2" SrCPT="Attribute@HoKoNoUmo.simb-21" NAME="attribute"/>
</TRM
* <NMR
ESTR="call"
KSP="Calling@vsHokoYonko.simb-17"
NMR1="call"
TMtYPE="nmVbr1"/>
* verberos, nouneros:
<DZGT TXTR="called" AKNS="Calling@simb-17" DTYPE="nor.vbr3,nor.vbr5" />
* pronomeros:
<DZGT TXR="every" AKNS="Quantity@simb-" DTYPE="pnmr1" MATTR="type=;countness=" SINTAKS="yes" />
* IF a dezigneptero has sintakseros, THEN the attribute "SINTAKS" denotes that we can go to the kpt-file to finnd it.
[hknu_2006-10-06]
<SINTAKS ESTR="call" VBO="strukturoOnr;dutolo" VRB="eneryero" VBA1="namepo;" VBE=";what" EPL="#vbo=dutolo:I _stxVrb:call#name:concept#vbe=what:every node of a concept-model."/>
<SINTAKS ESTR="call" VBE="strukturoOnr;what" VBO="strukturoOnr;dutolo" VRB="eneryero" VBA1="namepo;" EPL="#vbe:Any node of a concept-model,#vbo:I _stxVrb:call#how:concept."/>
<SINTAKS ESTR="call" VBO="namepo;" VRB="pashero" VBE=";what" VBA1="?by strukturoOnr;dutolo" EPL="#vbo:Concept _stxVrb:is called#vbe:any node of a concept-model."/>
<SINTAKS ESTR="call" VBO="strukturoOnr;what" VRB="pashero" VBA1="namepo;" VBA1="?by strukturoOnr;dutolo" EPL="#vbo:Any node of a concept-model _stxVrb:is called#how:concept#a:by me"/>
name::
* McsEngl.namero.index.xml@cptIt,
_DISCUSION:
* SINTAKS: we can add sintaks-entries in the nameros, especially for verberos.
[hknu_2008-03-23]
* EFICIENCY: For eficiency reasons we could have and a dezigneptero-file with the most used dezignepteros (pronomeros, korelateros, adverberos, adnouneros, ...).
[hknu_2006-10-05]
name::
* McsEngl.aaj'file.MostUsedTermero@cptIt,
* McsEngl.conceptIt356.12.12,
* McsEngl.terminal-file-of-aaj-1047.12@cptIt,
* McsEngl.aaj'MostUsedTermero-File-1047.12@cptIt,
* McsEngl.yordero'file-1047.12@cptIt,
_DEFINITION:
TERMINAL FILE
* 1. mostused terms (conjunctions, pronouns, prepositions, ..)
* 2. LG-CONCEPT-AUXILIARIES: articles, auxiliaries, ..
* 3. Interjections
* 4. Phatic-words.
* [2008-10-23]
* YORDERO.LANG.XML are files that contain yorderos used by a language other than the dezignatos.
[hknu_2006-06-08]
_DIRECTORY:
* homeDir\AAjKB\TERMINAL\lag
* homeDir/aajKB/TERMERO/lag
name::
* McsEngl.mostUsedTermero.xml@cptIt,
_ENTRY:
<TRMNL TXeXP="every" TRMNLtYPE="trmNnAj1" SRcPT="Number_every@hknu.simb-22#1" NAME="every"/>
<ISR ESTR="la" USG="nonvagueness">
<SINTAKS ESTR="la" TMtYPE="isrNnr" KCR="nmr3" ESR1A="nmNnr1" EPL="la homo"/>
<SINTAKS ESTR="la" TMtYPE="isrNnr" KCR="nmr4" ESR1A="nmNnr2" EPL="la homi"/>
</ISR>
name::
* McsEngl.aaj'Hardware-needed@cptIt,
name::
* McsEngl.aaj'License@cptIt,
This software is being provided to you, the LICENSEE, by Nikos-Kasselouris under the following license. By obtaining, using and/or copying this software, you agree that you have read, understood, and will comply with these terms and conditions.:
Permission to use, copy, modify and distribute this software for any purpose and without fee or royalty is hereby granted, provided that you agree to comply, IN RESPECT TO MY 15-YEARS-WORK TO MAKE IT, with the following copyright notice and statements, including the disclaimer, and that the same appear on ALL copies of the software, including modifications that you make for internal use or for distribution. jSCS 00.01.09 Copyright 2000 by Nikos-Kasselouris. All rights reserved.
THIS SOFTWARE IS PROVIDED "AS IS" AND NIKOS-KASSELOURIS MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, NIKOS-KASSELOURIS MAKES NO REPRESENTATIONS OR WARRANTIES OF MERCHANT- ABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE LICENSED SOFTWARE WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
The name of Nikos-Kasselouris may not be used in advertising or publicity pertaining to distribution of the software. Title to copyright in this software, shall at all times remain with Nikos-Kasselouris and LICENSEE agrees to preserve same.
(from wordnet 6.1)
[hknu_2000oct02]
name::
* McsEngl.aaj'Knowledge-base@cptIt,
* McsEngl.conceptIt356.12.14,
* McsEngl.aaj'kb@cptIt,
* McsEngl.knowledge-base-of-aaj@cptIt1047.14,
* McsEngl.abb@cptIt1047i,
* McsEngl.aaj'artificial'brainepto'model@cptIt1047,
* McsEngl.aaj'brainepto'base@cptIt1047,
* McsEngl.aaj'ontology@cptIt1047,
* McsEngl.aaj'knowledgebase@cptIt1047,
* McsEngl.aaj'ConceptBase@cptIt,
* McsEngl.aaj'scb@cptIt, {2001-04-28}
* McsEngl.aa-structured-concept-mental-model@cptIt, {2003-11-15}
* McsEngl.jscs-structured-concept-mental-model@cptIt,
* McsEngl.jscs-scbase@cptIt,
* McsEngl.jscs-structured-concept-base@cptIt,
* McsEngl.scb.jscs@cptIt,
* McsEngl.jscs-knowledge-base@cptIt,
====== lagoSinago:
* McsEngl.KonoBaso@lagoSngo,
====== lagoEsperanto:
* McsEngl.KonaBaso@lagoEspo,
* McsEspo.KonaBaso@cptIt,
_DEFINITION:
* jSCS SCBASE is the structured-concept-base created with the jSCS.
[hknu_{2001-04-28}]
SCS-KNOWLEDGE-BASE will be the applications written with the scs. Because information is something subjective, we'll have MANY SCS-KBs, but in all of them the knowledge will be consistent. Anyone will trust the knowledge-base which he trust its assumptions.
[nikos, 1999jan13]
_SIZE:
Having an xml-file for each attribute the size of the knowledge-base will be enourmous.
To avoid that we could have <CONINC> element for 'incorporated-concepts' concepts in the same file, especially for small ones or ones with litle information.
[nikos, 1999jan21]
_GENERIC
* Knowledgebase-ConceptBrainualSensorial#cptCore50.28.16#
* KNOWLEDGE_BASE#cptItsoft497.1#
name::
* McsEngl.aaj'XWORLDVIEW@cptIt,
* McsEngl.worldview-of-aaj@cptIt,
* McsEngl.aaj'WorldView@cptIt, {2010-09-02}
* McsEngl.aaj'xBrainWorldview@cptIt,
* McsEngl.aaj'VUDOSIMBANESPTO@cptIt,
name::
* McsEngl.aaj'XSUBWORLDVIEW@cptIt,
* McsEngl.aaj'view@cptIt,
* McsEngl.aaj'VUDESPTO@cptIt,
name::
* McsEngl.aaj'xWorldview.HoKoNoUmo@cptIt,
* McsEngl.aaj'HoKoNoUmo-XWorldview@cptIt,
aaj'StartConcepts.HoKoNoUmo:
* entity's-relation@hknu.symb.1@
aaj'Bootstraping:
* "REFINO": in defining a relation in attribute-relation
* "REFINO_DEFINITION": in an XCONCEPT
* "REFINO_NAME": in an XCONCEPT
* "REFINO_WHOLE": in an XCONCEPT
* "REFINO_PART": in an XCONCEPT
* "REFINO_GENERIC": in an XCONCEPT
* "REFINO_SPECIFIC": in an XCONCEPT
* "REFINO_ENVIRONMENT": in an XCONCEPT
* "REFINO_ENTITY": in an XCONCEPT
* "REFINO_ATTRIBUTE": in an XCONCEPT
* "REFINO_ARGUMENT": in an XCONCEPT relation
* "refino_betweenAnd" in entity's-relation@hknu.symb-1@
* "refino_eitherOr" in entity's-relation@hknu.symb-1@
* "refino_generic": in relation@hknu.symb-16@
* "refino_inside" in entity's-relator@hknu.symb-25@
* "refino_non" in entity's-relation@hknu.symb-1@
* "sensory" in entity's-relation@hknu.symb-1@
name::
* McsEngl.aaj'XML-CONCEPT@cptIt,
* McsEngl.conceptIt356.12.1,
* McsEngl.xcpt-356.12i@cptIt,
* McsEngl.aaj'xcpt-1047.1@cptIt, {2009-11-12}
* McsEngl.aaj'cpt-1047.1@cptIt,
* McsEngl.aaj'SrCpt-1047.1@cptIt,
* McsEngl.aaj'concept-1047.1@cptIt,
* McsEngl.aaj's-concept-1047.1@cptIt,
* McsEngl.aaj'xmlKONCESPO-1047.1@cptIt,
* McsEngl.aaj'scpt-1047.1@cptIt,
* McsEngl.aaj'ksp-1047.1@cptIt,
* McsEngl.koncespo-aaj-1047.1@cptIt,
* McsEngl.knca-1047.1@cptIt,
* McsEngl.aaj's'knca-1047.1@cptIt,
* McsEngl.aaj'aknc-1047.1@cptIt,
* McsEngl.aaj'konsepto-1047.1@cptIt,
* McsEngl.aaj'sc-1047.1@cptIt,
* McsEngl.aaj'bmsc-1047.1@cptIt,
* McsEngl.scpt@cptIt,
* McsEngl.SrCpt-of-aaj-1047.1@cptIt,
xcpt'_DEFINITION:
* In my jSCS, I implemented a SC as an XML file, or an element of an XML file. I chose this implementatin because an xml-file is a text entity (and not a binary one) so humans can read it.
[hknu_2001-12-30]
* A SC in this system is an XML file.
[{1999-03-16}]
xcpt'_GENERIC
* CBS#ql:cbsmgr'cbs#,
* concept.brain.sensorial#cptCore50.28#
xcpt'NOTE:
* I could use in the definition instead of a meaning-model in en, a text-model in en and the program to translate it in other languages.
[hknu_2005-09-03]
* The meaningmodel form is prefered because is less ambiguous than text.
[hknu_2006-01-07]
name::
* McsEngl.aaj'XELEMENT-of-XCPT@cptIt,
* McsEngl.aaj'element@cptIt,
* McsEngl.aaj'element-of-scpt-1047i@cptIt,
* McsEngl.element-of-aaj's-srcpt-1047i@cptIt,
* McsEngl.xml'element-of-ksp-1047i@cptIt,
* McsEngl.aaj'attribute'of'sc@cptIt,
====== lagoSinago:
* McsEngl.atribespo-1047.1i@lagoSngo,
aaj'element'ORDER:
- XCONCEPT
- REFINO_DEFINITION
- DEFINITION_GENERIC_END
- EngMainName
- Description_eng
- DEFINITION_SPECIFIC_START
- REFINO_NAME
- kml
- Name_NounCase
- REFINO_WHOLE
- XCPT
- REFINO_PART
- XCPT
- REFINO
- REFINO_PARTcOMPLEMENT
- REFINO_GENERIC
- REFINO_SPECIFIC
- REFINO_SPECIFICdIVISION
- REFINO_SPECIFICcOMPLEMENT
- REFINO_ENVIRONMENT
- REFINO_ENTITY
- REFINO_ATTRIBUTE
- REFINO
- REFINO_REFINOdIVISION
_DISPLAY:
01) PART: DEZIGNEPTEROS
02) PART: INHERITED
03) PART: NOT-INHERITED
04) WHOLES
05) PARTIAL-COMPLEMENTS
06) JENEREPTOS
07) SPECIFIC-COMPEMENTS
08) SPESIFEPTOS
09) ENVIRONMENT
10) ENV: DEFINITION
11) OTHER-ATRIBOS
[KasNik, 2007-10-11]
- Synonyma
- Definition
- General
- Whole
- Referent
- Funtion
- Structure
- Evolution
- Views
- Environment
- Subgeneral
- Evaluation
- Popularity
- Application
_RULE:
IF an element has value "none" THEN we can omit this element, in order to have less amount of storage.
[hknu_2009-09-13]
name::
* McsEngl.aaj'AttributeOfXConcept@cptIt,
* McsEngl.aaj'attribute@cptIt,
aaj'ATTRIBUTE'GENERIC_CPT:
* The "generic-cpt" of an entity's-attribute, is an attribute of the entity's-generic.
[hknu_2009-11-05]
aaj'ATTRIBUTE'INHERITOR_CPT:
It is the generic-scpt of the attribute's-entity.
[hknu_2009-09-27]
aaj'ATTRIBUTE.GENERIC:
* generic_attribute_of_xcpt is an attribute of an xcpt that it is attribute and xcpt's specifics.
[hnku_2009-11-26]
aaj'ATTRIBUTE.INHERITED:
* inherited_attribute_of_xcpt is an attribute of an xcpt that it is attribute and xcpt's generic.
[hnku_2009-11-26]
<XCPT FRnAME="Entity's-structure@hknu.simb-8@" GENERICiNHERITOR="Entity's-structure@hknu.simb-8@/Entity@hknu.simb-7@" CREATED="2009-10-26" AUTHOR="HoKoNoUmo"/>
<XCPT FRnAME="Process-or-relation@hknu.simb-14@" GENERICiNHERITOR="Entity@hknu.simb-7@" LASTmOD="2001-07-17" CREATED="2001-07-17" AUTHOR="HoKoNoUmo"/>
<SRcPTeXT FLN="Entity_s_interdependence@hknu.simb-8.xml" GENEREFINO="Entity_s_interdependence@hknu.simb-8.xml/Process@hknu.simb-15.xml" LASTmOD="2001-07-17" CREATED="2001-07-17" AUTHOR="HoKoNoUmo"/>
GENEREFINO="generic/inheritor"
aaj'ATTRIBUTE.INHERITED.OVERRIDEN:
IF "formalName" and "genericInheritor" are different, THEN it is overridden.
IF "FLN" and "generic" are different, THEN the attribute is overriden.
aaj'ATTRIBUTE.INHERITED.NONOVERRIDEN:
>>>IF<<< FLN=generic ===> NonOverriden.
aaj'ATTRIBUTE.NON_INHERITED:
IF there is no "genericInheritor" xml-attribute.
TYPES OF ATTRIBUTES:
** NotInherited - Inherited (Overridden - NotOverridden)
** Inline - NotInline
[{1999-04-02}]
** Concrete -NotConcrete:
concrete I call the unique att a cpt has ie the notInherited and the inherited-overridden.
notConcrete are the inherited-notoverridden.
[hknu_{2000-03-11}]
_EXAMPLES:
NONiNHERITED:
** NotInherited-NotInternal:
<CPTREF ID="it-17" FILE="it-17" GENERAL="no" ...
** NotInherited-Internal:
<CPTIN ID="it-17#22" FILE="no" GENERAL="no" ...>
INHERITED:
** Inherited-NonOverridden:
<CPTREF ID="phil-2" FILE="no" GENERAL="phil-2" ...
<CPTREF ID="phil-3#2" FILE="no" GENERAL="phil-3#2" ...
** Inherited-Overridden:
<CPTREF ID="it-2" FILE="it-2" GENERAL="phil-2" ...
An INHERITED-OVERRIDDEN is always a file-cpt because has attributes the attributes of its general.
[hknu_{2000-03-30}]
An Inherited-NotOverridden att is NOT a new concept. That's why the 'general' must not have it as sub.
[hknu_{2000-03-22}]
Threre are 2 kinds of attributes: Inherited and Non-Inherited.
ALL the attributes have a UNIQUE ID.
BUT we create a new FILE only If there is important information that distiquishes this concept fron the inherited one.
When we don't have FILE for the attribute, we display the inherited parent file continually until we reach a file.
EXAMPLE1:
<CONREF
ID= "it2"
INHERITED= "IT1'IT20"
FILE= "IT2_HARDDISK'CAPACITY.XML"
...
This attribute inherited from it20 and we have a file for it.
EXAMPLE2:
<CONREF
ID= "it2"
INHERITED= "it1'it20" (tbd: only anchestor with existing file)
FILE= "no"
...
We gonna display the it20 file-definition.
EXAMPLE3:
<CONREF
ID= "it2"
INHERITED= "no"
FILE= "IT2_HARDDISK'CAPACITY.XML"
...
This is a non inherited attribute.
[1999feb08]
IF we use elements for every concept then we will be lost on a sea of tag names.
BUT if we use attributes then we need very few elements for describing concepts.
[1997dec01]
name::
* McsEngl.aaj'xelement.XCONCEPT@cptIt,
* McsEngl.aaj'XConcept-element-1047i@cptIt,
* McsEngl.SrConcept-element-of-aaj-1047i@cptIt,
aaj'notation.XCONCEPT:
* In the xconcept-element I always write ALL the attributes, because I modify this line frequently and this way I need less code to do it.
[hknu_2009-10-06]
<XCONCEPT LASTiNTFrNUMBER="1" INTEGRATED="no" LASTmOD="2008-12-10" CREATED="2008-12-10" AUTHOR="HoKoNoUmo">
<XCONCEPT INTEGRATED="no" LASTmOD="2009-09-27" CREATED="2000-04-04" AUTHOR="HoKoNoUmo">
<SrCONCEPT FLN="Concept@HoKoNoUmo.simb-1.xml" LASTINTID="1" INTEGRATED="no" LASTMOD="2008-11-11" CREATED="2000-03-14" AUTHOR="HoKoNoUmo">
name::
* McsEngl.aaj'xelement.REFINO-NAME@cptIt,
* McsEngl.aaj'refino-name-element-1047i@cptIt,
* McsEngl.nameino-element-of-aaj-1047i@cptIt,
* McsEngl.srCpt'NAME-OF-LgCONCEPT@cptIt,
* McsEngl.namokoncero-of-aaj'ksp-1047i@cptIt,
* McsEngl.srCpt'NAMERO-GENEREPO@cptIt,
* McsEngl.aaj'namerordomo-1047i@cptIt, {2008-03-26}
* McsEngl.namerordomo-of-aaj'ksp-1047.i@cptIt,
* McsEngl.aaj'firstNamero-1047i@cptIt,
* McsEngl.firstNamero-of-aaj'ksp-1047.i@cptIt,
_DEFINEANO:
Any firstNamero of any koncero of a koncespo in any language.
[hknu_2008-03-26]
Namokoncero is ANY namero of ONE koncero of a aaj's koncespo.
[hknu_2008-03-24]
_SPECIFIC:
NameNounCase
NameNounAdjective
NameNounAdverb
NameVerb
NameConjunction
NameShort
NameSymbol
NameNounSpecialCase
NameNounSpecialAdjective
NameNounSpecialAdverb
ORDER:
- NamoNounero:
- NamoAdnounero:
- NamoAdverbero:
- NamoVerbero:
- NamoDeanero:
- NamoLongotliero:
- NamoSimbolero:
- NamoSpecialoNounero:
- NamoSpecialoAdnounero:
- NamoSpecialoAdverbero:
* NOUNER
* ADNOUNER
* ADVERBER
* PRONOMER
* VERBER
* CORELATER
The synonyms can be divided per language: english, greek, ... synonyms.
Also can be divided per lexeme: noun, verb, ... synonyms.
[hknu_{2001-03-05}]
CONVENSION:
The ORDER of synonyms shows its usage.
[hknu_{2001-03-06}]
name::
* McsEngl.aaj'xelement.LNG@cptIt,
* McsEngl.aaj'lng-element-1047i@cptIt,
* McsEngl.lng-element-of-srCpt-1047i@cptIt,
* McsEngl.srCpt'NAMERO-LANGO@cptIt,
* McsEngl.aaj'nameroLango-1047i@cptIt, {2008-03-26}
* McsEngl.nameroLango-of-aaj'ksp-1047.i@cptIt,
DEFINEANO:
Any Namero of any koncero of a koncespo in ONE language.
[hknu_2008-03-26]
_NOTATION:
<kml LASTMOD="2008-03-27" CREATED="2006-11-14" AUTHOR="HokoYono">
<NamoKoncero>
</kml>
_ORDER:
* kml
* eng
-------
* eln
* epo
name::
* McsEngl.aaj'xelement.NAME@cptIt,
* McsEngl.aaj'name-element-1047i@cptIt,
* McsEngl.name-element-of-srCpt-1047i@cptIt,
_SPECIFIC:
* NameNone
* NameNounCase
* NameNounAdjective
* NameNounAdverb
* NameVerb
* NameConjunction
* NameShort
* NameSymbol
name::
* McsEngl.aaj'xelement.SYNTAX@cptIt,
* McsEngl.syntax-element-of-srCpt-1047i@cptIt,
_USAGE:
We can include this element in the name element. On multiple syntax we can have many elements with the same name as we do for the terms.
[2009-01-19]
We need the syntax-element, when we map CONCEPTUAL_SUBWORLDVIEW or semasia to TEXT.
TERMINAL_FILES need to contain links to this syntax, when we map TEXT to CONCEPTUAL_SUBWORLDVIEW.
[2009-01-19]
_EXAMPLE:
<NameNone CREATED="2009-01-19" AUTHOR="HoKoNoUmo">
<SYNTAX ARGS="1:Entity@HoKoNoUmo.simb-7,2:Quantity@HoKoNoUmo.simb-18" TxEXP1_B="2,nnAj01" TxEXP1_A="1,nnCsNm01" EXMPL="5 man"/>
</NameNone
name::
* McsEngl.aaj'xelement.NameNone@cptIt,
* McsEngl.aaj'NameNone-element-1047i@cptIt,
* McsEngl.NameNone-element-of-srCpt-1047i@cptIt,
_USAGE:
Relations can be expressed with the position of its arguments, without using conjunctions. Then, inside this element we store the previous syntax.
[2009-01-19]
_EXAMPLE:
<NameNone ARGS="1:Entity@HoKoNoUmo.simb-7,2:Quantity@HoKoNoUmo.simb-18" TxEXP1_B="2,nnAj01" TxEXP1_A="1,nnCsNm01" EXMPL="5 man" CREATED="2009-01-19" AUTHOR="HoKoNoUmo"/>
name::
* McsEngl.aaj'xelement.NameNounCase@cptIt,
* McsEngl.NameNounCase-element-of-srCpt-1047i@cptIt,
<NameNounCase TxEXP="FoEkoKonco" MOSTUSED="1" CREATED="2006-11-14" AUTHOR="HoKoNoUmo"/>
<NameNounCase TxEXP="Definitness" TRMRULE="rlEngTrmNnCs13" CREATED="2006-10-01" AUTHOR="HoKoNoUmo"/>
<NAMONOUNERO ESTR="Έννοια" MOSTUSED="1" NMRULE="eln2a3" DELETED="" CREATED="2000-02-19" AUTHOR="HokoYonko"/>
<NOUN LOGOS="Concept" GENERIC="en1" LASTMODIFIED="2000-02-19" CREATED="2000-02-19" AUTHOR="nikkas"/>
[{2000-03-08}]
<ABJECTER NAMER="Concept" RULE="en1" LASTMODIFIED="2000-02-19" CREATED="2000-02-19" AUTHOR="nikkas"/>
[hknu_2004-03-30]
name::
* McsEngl.aaj'xelement.NameNounAdjective@cptIt,
* McsEngl.NameNounAdjective-element-of-srCpt-1047i@cptIt,
<NameNounAdjective TxEXP="Conceptual" TRMRULE="rlEngTrmNnAj31" CREATED="2008-04-06" AUTHOR="HoKoNoUmo"/>
<SPECOADNOUNERO ESTR="every" ATN="type=idefAllOne" CREATED="2006-10-06" AUTHOR="HokoYono">
<SINTAKS NDA1="nounetro.count|mass"/>
</SPECOADNOUNERO>
<ADJECTIVE LOGOS="Concept" GENERIC="" LASTMODIFIED="2000-02-19" CREATED="2000-02-19" AUTHOR="nikkas"/> [{2000-03-08}]
name::
* McsEngl.aaj'xelement.NameNounAdverb@cptIt,
* McsEngl.NameNounAdverb-element-of-srCpt-1047i@cptIt,
name::
* McsEngl.aaj'xelement.NameNounSpecialCase@cptIt,
* McsEngl.NameNounSpecialCase-element-of-srCpt-1047i@cptIt,
name::
* McsEngl.aaj'xelement.NameNounSpecialAdjective@cptIt,
* McsEngl.NameNounSpecialAdjective-element-of-srCpt-1047i@cptIt,
name::
* McsEngl.aaj'xelement.NameNounSpecialAdverb@cptIt,
* McsEngl.NameNounSpecialAdverb-element-of-srCpt-1047i@cptIt,
name::
* McsEngl.aaj'xelement.NameVerb@cptIt,
* McsEngl.NameVerb-element-of-srCpt-1047i@cptIt,
<NameVerb TxEXP="Call" TRMRULE="rlEngTrmVrb11" CREATED="2001-07-17" AUTHOR="HoKoNoUmo"/>
aaj'notation.SYNTAX_OF_VERB:
* aaj'VERB'S_SYNTAX:
We could add here and the syntax of a verb:
<SYNTAX SBJ="rutinolo;NounStructure" VRB="active" OBJ="rutinelo;NounStructure" ...
NODE1="place;lgNode"
NODE2="time=in;Noun" //the conjunction use to denote the argument.
/>
[2008-12-16]
name::
* McsEngl.aaj'xelement.NameConjunction@cptIt,
* McsEngl.NameConjunction-element-of-srCpt-1047i@cptIt,
<NamoDeanero ESTR="of" CREATED="2006-10-22" AUTHOR="HokoYono"/>
<SINTAKS NDB1="StrukturoOnr;Entity@vsHokoYono.simb-7"
NDA1="StrukturoOnr;Attribute@vsHokoYono.simb-21" EPL=""/>
</DEANERO>
name::
* McsEngl.aaj'xelement.NameShort@cptIt,
* McsEngl.NameShort-element-of-srCpt-1047i@cptIt,
* McsEngl.srCpt'NAME-SHORT@cptIt,
* McsEngl.ShortName-of-srCpt-1047i@cptIt,
* McsEngl.namoLongotliero-of-aaj'ksp-1047i@cptIt,
* McsEngl.aaj'short'name'of'sc@cptIt,
_DEFINITION:
ShortName:
In cases where the 'name' of a sc is comprised of many or big word we use short alphanumerics instead, these are the 'shortnames' of the cpt. They can be abreviations or not.
[hknu_{2001-03-05}]
<SHORTNAME LOGOS="cpt" LASTMODIFIED="2000-02-19" CREATED="2000-02-19" AUTHOR="nikkas"/>
* 'shortname' doen't have a 'generic' xml-attribute. [{2000-03-08}]
name::
* McsEngl.aaj'xelement.NameSymbol@cptIt,
* McsEngl.NameSymbol-element-of-srCpt-1047i@cptIt,
name::
* McsEngl.aaj'xelement.REFINO-DEFINITION@cptIt,
* McsEngl.aaj'refino-definition-element-1047i@cptIt,
* McsEngl.aaj'definefino-element-1047i@cptIt,
* McsEngl.defineino-element-of-aaj-1047i@cptIt,
aaj'notation.REFINO_DEFINITION:
<REFINO_DEFINITION>
<DEFINITION_X CREATION="y" CREATED="2009-11-12" AUTHOR="HoKoNoUmo">
</DEFINITION_X>
<DEFINITION_Y CREATED="2009-11-12" AUTHOR="HoKoNoUmo">
</DEFINITION_Y>
</REFINO_DEFINITION>
[hknu_2009-11-14]
=================================================
<DEFINEANO LASTMOD="2004-09-19" AUTHOR="HokoYono">
aaj'notation.DEFINITION_X:
<DEFINITION_X CREATION="y" CREATED="2009-11-12" AUTHOR="HoKoNoUmo">
<EngMainName TxEXP="Entity's relation" TRMrULE="rlEngTrmNnCs4b11" CREATED="2009-11-12" AUTHOR="HoKoNoUmo"/>
<REFINO FrNAME="fn1">
<XCPT FrNAME="fn2"/>
<REFINO FrNAME="fn3">
<XCPT FrNAME="fn4"/>
<XCPT FrNAME="fn5"/>
</REFINO>
</REFINO>
<Description_eng CREATED="2009-11-12" AUTHOR="HoKoNoUmo">
The presense or not of any COMMONNESS between the entity and any other-enity.
</Description_eng>
</DEFINITION_X>
[hknu_2009-11-14]
_IDEA:
<DEFINUFEANO CREATED="..." AUTHOR="...">
<DEFINUFEPO_ANALIZUFEPO_SPECIFEPO_MIDLUEPO
GENEREPO="computer"
ATRIBEPO="..."
CREATED="..." AUTHOR="..."/>
<KOMENTO>
Portable-Computer is a computer with a small size we can take together.
</KOMENTO>
</DEFINUFEANO>
* The comment is displayed in quick-access
* The kognepo (definufulo) is translated in any language.
* The program can validate any koncespo against its definitions.
[HokoYono, 2008-04-07]
<DEFINEINO CREATED="..." AUTHOR="...">
<ANALIZO_SPESIFEPTO
DEFINUFULO="inflectional-suffix"
GENEREPTO="suffix"
ATRIBO="???" />
<KOMENTO>
INFLECTIONAL-SUFFIX is a 'suffix' a language uses to create word-forms for inflections. [hknu_2000oct15]
</KOMENTO>
</DEFINEINO>
aaj'xelement.DEFINITION:
<REFINO FrNAME="fn1">
<XCPT FrNAME="fn2"/>
<REFINO FrNAME="fn3">
<XCPT FrNAME="fn4"/>
<XCPT FrNAME="fn5"/>
</REFINO>
</REFINO>
([fn1] (fn2) ([fn3](fn4)(fn5)))
[hknu_2009-10-08]
<DEFINITION_ENG LASTMOD="2004-03-23" CREATED="2001-09-30" AUTHOR="HoKoNoUmo">
Concept is every tree network node of a conceptual-subworldview.
</DEFINITION_ENG>
When we create a concept, the computer from the definition, will create this element. This way, it will have access to the definition without to have always to map the brain to logo. Also any time we will change the definition, the computer will change and this element.
[2008-12-22]
IF the "creation" attribute exists, THEN and a name element must exist.
[hknu_2009-09-17]
name::
* McsEngl.aaj'xelement.DEFINITION-GENERIC@cptIt,
* McsEngl.aaj'Definition.Generic-1047i@cptIt,
aaj'notation.DEFINITION_GENERIC:
<DEFINITION_GENERIC CREATION="y" CREATED="2009-11-02" AUTHOR="HoKoNoUmo">
<EngMainName TxEXP="Relation" TRMrULE="rlEngTrmNnCs22"/>
<RELATION FrNAME="refino_generic">
<XCPT FrNAME="Entity's-attribute-relation@hknu.symb-20@"/>
<XCPT FrNAME="Entity's-non-attribute-relation@hknu.symb-19@"/>
</RELATION>
<Description_eng CREATED="2009-11-02" AUTHOR="HoKoNoUmo">
RELATION is any entity's-attribute or entity's-nonattribute relation.
</Description_eng>
</DEFINITION_GENERIC>
name::
* McsEngl.aaj'xelement.DEFINITION-GENERIC-END@cptIt,
* McsEngl.aaj'Definition.Generic.End-1047i@cptIt,
aaj'notation.DEFINITION_GENERIC_END:
<DEFINITION_GENERIC_END CREATION="1" CREATED="2009-08-14" AUTHOR="HoKoNoUmo">
<EngMainName TxEXP="Entity" MOSTUSED="1" TRMrULE="rlEngTrmNnCs22" CREATED="2000-11-12" AUTHOR="HoKoNoUmo"/>
<Description TXT="..."/>
</DEFINITION_GENERIC_END>
[hknu_2009-09-29]
<DEFINEMENT_GENERIC_END CREATION="1" CREATED="2009-08-14" AUTHOR="HoKoNoUmo"/>
- the "CREATION" attribute denotes that this definement is part of concept-creation process.
[hknu_2009-08-25]
name::
* McsEngl.aaj'xelement.DEFINITION-PART@cptIt,
* McsEngl.aaj'Definition.Part-1047i@cptIt,
aaj'notation.DEFINITION_PART:
<DEFINEMENT_PART CREATED="2008-04-18" AUTHOR="HoKoNoUmo">
<TEXTeNG LASTmOD="2004-03-23" CREATED="2001-09-30" AUTHOR="HoKoNoUmo">
Concept is every tree-network's node of a conceptual-subworldview.
</TEXTeNG>
<NameNounCase LNG="eng" TXeXP="Concept" TRMrULE="rlEngTrmNnCs11"/>
<SOURCE FRMLnAME="Subworldview_conceptual@hknu.simb-6.xml"/>
<PRODUCT>
<SRcPT LABEL="b1" FRMLnAME="Tree-network's-node@hknu.simb-11.xml"/>
<SRcPT LABEL="b2" FRMLnAME="Number_every@hknu.simb-22#1.xml"/>
<SRcPT LABEL="b3" FRMLnAME="Quantiteino@hknu.simb-23.xml" ARGS="b1,b2"/>
</PRODUCT>
</DEFINEMENT_PART>
name::
* McsEngl.aaj'xelement.DEFINITION-ATTRIBUTE@cptIt,
* McsEngl.aaj'Definition.Attribute-1047i@cptIt,
aaj'notation.DEFINITION_ATTRIBUTE:
<DEFINEMENT_ATTRIBUTE CREATION="1" CREATED="2009-09-17" AUTHOR="HoKoNoUmo">
<TEXTeNG LASTmOD="2004-03-23" CREATED="2001-09-30" AUTHOR="HoKoNoUmo">
Evolution-of-entity is the process-of-entity with time the time-of-the-entity.
</TEXTeNG>
<NameNounCase LNG="eng" TxEXP="Evolution-of-entity" TRMRULE="rlEngTrmNnCs11"/>
<REFINO_GENERIC SrCPT="Process@..."/>
<REFINO FrNAME="Time-of-Process@...">
<SrCPT FrNAME="Time-of-entity@..."/>
</REFINO>
</DEFINEMENT_ATTRIBUTE>
[hknu_2009-09-20]
<DEFINEMENT_ATTRIBUTE CREATION="1" CREATED="2009-09-17" AUTHOR="HoKoNoUmo">
<TEXTeNG LASTmOD="2004-03-23" CREATED="2001-09-30" AUTHOR="HoKoNoUmo">
Evolution-of-entity is the process-of-entity with time the time-of-the-entity.
</TEXTeNG>
<NameNounCase LNG="eng" TxEXP="Evolution-of-entity" TRMRULE="rlEngTrmNnCs11"/>
<GENEREFINO>
<SrCPT FrNAME="..."/>
</GENEREFINO>
</DEFINEMENT_ATTRIBUTE>
[hknu_2009-09-16]
name::
* McsEngl.aaj'xelement.DEFINITION-RELATOR@cptIt,
* McsEngl.aaj'Definition.RELATOR-1047i@cptIt,
aaj'notation.DEFINITION_RELATOR:
<DEFINITION_RELATOR CREATION="y" CREATED="2009-11-12" AUTHOR="HoKoNoUmo">
<EngMainName TxEXP="Entity's relation" TRMrULE="rlEngTrmNnCs4b11" CREATED="2009-11-12" AUTHOR="HoKoNoUmo"/>
<REFINO FRnAME="refino_betweenAnd">
<XCPT FRnAME="Entity@hknu.symb-7@">
<XCPT FRnAME="Entity(2)@hknu.symb-7@" NEWNAME="Entity's-relator@hknu.symb-25@">
<REFINO FRnAME="refino_eitherOr">
<XCPT FRnAME="sensory" NEWNAME="Commonness@hknu.symb-26@">
<REFINO FRnAME="refino_non">
<XCPT FRnAME="sensory" NEWNAME="Commonness@hknu.symb-26@">
</REFINO>
</REFINO>
</REFINO>
<Description_eng CREATED="2009-11-12" AUTHOR="HoKoNoUmo">
The presense or not of any COMMONNESS between the entity and any other-enity.
</Description_eng>
</DEFINITION_RELATOR>
[hknu_2009-11-16]
name::
* McsEngl.aaj'xelement.DEFINITION-NAME@cptIt,
* McsEngl.aaj'Definition.NAME-1047i@cptIt,
aaj'notation.DEFINITION_NAME:
<DEFINITION_NAME CREATION="y" CREATED="2009-11-12" AUTHOR="HoKoNoUmo">
<EngMainName TxEXP="Entity's relator" TRMrULE="rlEngTrmNnCs4b11" CREATED="2009-11-12" AUTHOR="HoKoNoUmo"/>
<XCPT FrNAME="Entity(2)@hknu.symb-7@">
<REFINO FrNAME="inside">
<XCPT FrNAME="Entity(2)@hknu.symb-7@">
<REFINO FrNAME="part">
<XCPT FrNAME="Entity's-relation@hknu.symb-1@">
<XCPT FrNAME="Creation-definition@hknu.symb-...@">
</REFINO>
</REFINO>
<Description_eng CREATED="2009-11-12" AUTHOR="HoKoNoUmo">
Relator-of-entity I call the argument(2) IN entity's-relation's creation-definition.
</Description_eng>
</DEFINITION_NAME>
[hknu.2009-11-15]
name::
* McsEngl.aaj'xelement.DEFINITION-DESCRIPTION@cptIt,
* McsEngl.aaj'Definition.Description-1047i@cptIt,
aaj'notation.DEFINITION_DESCRIPTION:
<DEFINITION_DESCRIPTION CREATION="y" CREATED="2009-11-18" AUTHOR="HoKoNoUmo">
<EngMainName TxEXP="Entity's relation" TRMrULE="rlEngTrmNnCs4b11"/>
<Description_eng CREATED="2009-11-12" AUTHOR="HoKoNoUmo">
The presense or not of any COMMONNESS between the entity and any other-enity.
</Description_eng>
</DEFINITION_DESCRIPTION>
[hknu_2009-11-18]
name::
* McsEngl.aaj'xelement.DEFINITION-SENSORY@cptIt,
* McsEngl.aaj'Definition.Sensory-1047i@cptIt,
_DESCRIPTION:
There is NOT "sensory-definition". ALL definitions are divided on the "attribute" they define. Then on this attribute, they are sensory, whithout-input, or any other characteristic.
[hknu_2009-11-15]
aaj'notation.DEFINITION_SENSORY:
<DEFINITION_SENSORY CREATION="y" CREATED="2009-11-12" AUTHOR="HoKoNoUmo">
<EngMainName TxEXP="Entity's relation" TRMrULE="rlEngTrmNnCs4b11" CREATED="2009-11-12" AUTHOR="HoKoNoUmo"/>
<REFINO FrNAME="betweenAnd">
<XCPT FrNAME="Entity@hknu.symb-7@">
<XCPT FrNAME="Entity(2)@hknu.symb-7@" NEWNAME="Entity's-relator@hknu.symb-25@">
<REFINO FrNAME="eitherOr">
<XCPT FrNAME="sensory" NEWNAME="Commonness@hknu.symb-26@">
<REFINO FrNAME="not">
<XCPT FrNAME="sensory" NEWNAME="Commonness@hknu.symb-26@">
</REFINO>
</REFINO>
</REFINO>
<Description_eng CREATED="2009-11-12" AUTHOR="HoKoNoUmo">
The presense or not of any COMMONNESS between the entity and any other-enity.
</Description_eng>
</DEFINITION_SENSORY>
[hknu_2009-11-14]
name::
* McsEngl.aaj'xelement.EngMainName@cptIt,
* McsEngl.aaj'EngMainName-Element-1047i@cptIt,
aaj'notation.EngMainName:
<EngMainName TxEXP="Entity" MOSTuSED="1" TRMrULE="rlEngTrmNnCs22" CREATED="2000-11-12" AUTHOR="HoKoNoUmo"/>
[hknu_2009-09-29]
<ANALYTIC_PART_MIDDLE CREATED="2008-04-18" AUTHOR="HoKoNoUmo">
<!-- Concept I call every node of a conceptual-subworldview -->
<NameNounCase LNG="eng" TxEXP="Concept" TRMRULE="rlEngTrmNnCs11"/>
<WHOLE FrNAME="Subworldview_conceptual@HoKoNoUmo.simb-6"/>
<PART>
<SrCPT LABEL="b1" FrNAME="Tree-network_s_node@HoKoNoUmo.simb-11"/>
<SrCPT LABEL="b2" FrNAME="Quantity.every@HoKoNoUmo.simb-18"/>
<SrCPT LABEL="b3" FrNAME="Quantiteino@" ARGS="b2,b3"/>
</PART>
</ANALYTIC_PART_MIDDLE>
<ANALYTIC_PART_MIDDLE LNG="eng" CREATED="2008-04-18" AUTHOR="HoKoNoUmo">
<!-- Concept I name every node of a conceptual-subworldview -->
<SSMA LNG="eng">
<SmVerb001 LABEL="x1" SrCPT="Naming@HoKoNoUmo.simb-17"/>
<NameNounCase LABEL="x7" TxEXP="Concept" TRMRULE="rlEngTrmNnCs11"/>
<SmNounStructure LABEL="x6">
<SmNoun LABEL="x5" SrCPT="Subworldview_conceptual@HoKoNoUmo.simb-6" SmATTR="idef,sin"/>
<SmNounStructure LABEL="x4">
<SmNoun1 LABEL="x2" SrCPT="Tree-network_s_node@HoKoNoUmo.simb-11"/>
<SmNoun1 LABEL="x3" SrCPT="Number_every@HoKoNoUmo.simb-19#1"/>
<SmConjunction SrCPT="Quantiteino@HoKoNoUmo.simb-23" ARGS="x2,x3"/>
</SmNounStructure>
<SmConjunction SrCPT="Parteino@HoKoNoUmo.simb-24" ARGS="x5,x4"/>
</SmNounStructure>
<SmConjunction SrCPT="SmObjekteino@" ARGS="x1,x7"/>
<SmConjunction SrCPT="SmObjekteino2@" ARGS="x1,x6"/>
</SSMA>
</ANALYTIC_PART_MIDDLE>
<ANALYTIC_PART_MIDDLE CREATED="2008-04-18" AUTHOR="HoKoNoUmo">
<!-- Concept I call every node of a conceptual-subworldview -->
<NameNounCase LNG="eng" TxEXP="Concept" TRMRULE="rlEngTrmNnCs11"/>
<SrCPT LABEL="b1" FrNAME="Tree-network_s_node@HoKoNoUmo.simb-11"/>
<SrCPT LABEL="b2" FrNAME="Quantity.every@HoKoNoUmo.simb-18"/>
<SrCPT LABEL="b3" FrNAME="Quantiteino@" ARGS="b2,b3"/>
<SrCPT LABEL="b4" FrNAME="Subworldview_conceptual@HoKoNoUmo.simb-6"/>
<SrCPT LABEL="b5" FrNAME="Parteino@" ARGS="b1,b4"/>
</ANALYTIC_PART_MIDDLE>
name::
* McsEngl.aaj'xelement.TEXTeNG@cptIt,
<DEFINEMENT_PART CREATED="2008-04-18" AUTHOR="HoKoNoUmo">
<TEXTeNG LASTmOD="2004-03-23" CREATED="2001-09-30" AUTHOR="HoKoNoUmo">
Concept is every tree-network's node of a conceptual-subworldview.
</TEXTeNG>
...
name::
* McsEngl.scpt.element.PRODUCT@cptIt,
<DEFINEMENT_PART CREATED="2008-04-18" AUTHOR="HoKoNoUmo">
<TEXTeNG LASTmOD="2004-03-23" CREATED="2001-09-30" AUTHOR="HoKoNoUmo">
Concept is every tree-network's node of a conceptual-subworldview.
</TEXTeNG>
<NameNounCase LNG="eng" TXeXP="Concept" TRMrULE="rlEngTrmNnCs11"/>
<SOURCE FRMLnAME="Subworldview_conceptual@hknu.simb-6.xml"/>
<PRODUCT>
<SRcPT LABEL="b1" FRMLnAME="Tree-network's-node@hknu.simb-11.xml"/>
<SRcPT LABEL="b2" FRMLnAME="Number_every@hknu.simb-22#1.xml"/>
<SRcPT LABEL="b3" FRMLnAME="Quantiteino@hknu.simb-23.xml" ARGS="b1,b2"/>
</PRODUCT>
</DEFINEMENT_PART>
name::
* McsEngl.scpt.element.SRcPT@cptIt,
<DEFINEMENT_PART CREATED="2008-04-18" AUTHOR="HoKoNoUmo">
<TEXTeNG LASTmOD="2004-03-23" CREATED="2001-09-30" AUTHOR="HoKoNoUmo">
Concept is every tree-network's node of a conceptual-subworldview.
</TEXTeNG>
<NameNounCase LNG="eng" TXeXP="Concept" TRMrULE="rlEngTrmNnCs11"/>
<SOURCE FRMLnAME="Subworldview_conceptual@hknu.simb-6.xml"/>
<PRODUCT>
<SRcPT LABEL="b1" FRMLnAME="Tree-network's-node@hknu.simb-11.xml"/>
<SRcPT LABEL="b2" FRMLnAME="Number_every@hknu.simb-22#1.xml"/>
<SRcPT LABEL="b3" FRMLnAME="Quantiteino@hknu.simb-23.xml" ARGS="b1,b2"/>
</PRODUCT>
</DEFINEMENT_PART>
name::
* McsEngl.scpt.element.NameNounCase@cptIt,
<DEFINEMENT_PART CREATED="2008-04-18" AUTHOR="HoKoNoUmo">
<TEXTeNG LASTmOD="2004-03-23" CREATED="2001-09-30" AUTHOR="HoKoNoUmo">
Concept is every tree-network's node of a conceptual-subworldview.
</TEXTeNG>
<NameNounCase LNG="eng" TXeXP="Concept" TRMrULE="rlEngTrmNnCs11"/>
<SOURCE FRMLnAME="Subworldview_conceptual@hknu.simb-6.xml"/>
<PRODUCT>
<SRcPT LABEL="b1" FRMLnAME="Tree-network's-node@hknu.simb-11.xml"/>
<SRcPT LABEL="b2" FRMLnAME="Number_every@hknu.simb-22#1.xml"/>
<SRcPT LABEL="b3" FRMLnAME="Quantiteino@hknu.simb-23.xml" ARGS="b1,b2"/>
</PRODUCT>
</DEFINEMENT_PART>
name::
* McsEngl.aaj'xelement.REFINO-PART@cptIt,
* McsEngl.aaj'refino-part-element-1047i@cptIt,
* McsEngl.parteino-element-of-aaj-1047i@cptIt,
aaj'notation.REFINO_PART:
<PARTEANO LASTMOD="2000-04-04" CREATED="2000-04-04" AUTHOR="HokoYono">
name::
* McsEngl.aaj'xelement.REFINO-PATRIALdIIVIZION@cptIt,
* McsEngl.divizopartefino-element-of-aaj-1047i@cptIt,
name::
* McsEngl.aaj'xelement.REFINO@cptIt,
* McsEngl.aaj'refino-element-1047i@cptIt,
aaj'notation.REFINO:
<REFINO FRnAME="Entity's-relation@hknu.symb-1@" CREATED="2009-11-12" AUTHOR="HoKoNoUmo">
<XCPT FRnAME="Entity's-relator@hknu.symb-25@" CREATED="2009-11-12" AUTHOR="HoKoNoUmo"/>
</REFINO>
_DESCRIPTION:
* In the main-attribute-relation (refino_part, refino_environment, ...) we put ARGUMENTS of these relations. IF we want to put a relation, we use this xelement. IF we DON'T have a relation for an argument AND we have only the argument, THEN we can put in the formal-name of the refino-xelement the argument's-name. This way we decrease the size of the worldview by not creating non-important, obvious concepts.
[hknu_2009-11-23]
name::
* McsEngl.aaj'xelement.REFINO-PARTIALcOMPLEMENT@cptIt,
* McsEngl.aaj'refino-partialComplement-element-1047i@cptIt,
* McsEngl.partokompletefino-element-of-aaj-1047i@cptIt,
<PARTOKOMPLETEFINO LASTmOD="2009-09-06" CREATED="2009-09-06" AUTHOR="HoKoNoUmo">
<SRcPTeXT FLN="none" LASTmOD="2009-09-06" CREATED="2009-09-06" AUTHOR="HoKoNoUmo"/>
</PARTOKOMPLETEFINO>
name::
* McsEngl.aaj'xelement.REFINO-WHOLE@cptIt,
* McsEngl.aaj'refino-whole-element-1047i@cptIt,
* McsEngl.wholeino-element-of-aaj-1047i@cptIt,
_NOTATION:
<TUTEANO LASTMOD="2000-05-23" CREATED="2000-05-23" AUTHOR="HokoYono">
name::
* McsEngl.aaj'xelement.REFINO-GENERIC@cptIt,
* McsEngl.aaj'refino-generic-element-1047i@cptIt,
* McsEngl.genereino-element-of-aaj-1047i@cptIt,
aaj'notation.REFINO_GENERIC:
<GENEREANO LASTMOD="2000-04-14" CREATED="2000-04-14" AUTHOR="HokoYono">
name::
* McsEngl.aaj'xelement.REFINO-SPECIFIC@cptIt,
* McsEngl.aaj'refino-specific-element-1047i@cptIt,
* McsEngl.specifeino-element-of-aaj-1047i@cptIt,
aaj'notation.REFINO_SPECIFIC:
* ORDER:
- FIRST the divisions and THEN the MISC concepts, order by formal-name.
xcpt and intxcpt are treated the same.
[hknu_2009-11-22]
<SPECIFEANO LASTMOD="2000-04-04" CREATED="2000-04-04" AUTHOR="HokoYono">
name::
* McsEngl.aaj'xelement.REFINO-SPECIFICdIVISION@cptIt,
* McsEngl.aaj'refino-specificDivision-element-1047i@cptIt,
* McsEngl.divizospecifino-element-of-aaj-1047i@cptIt,
aaj'notation.REFINO_SPECIFICdIVISION:
<DIVIZOSPECIFEANO ATR="Referent@vsHokoYono.simb-10.xml" LASTMOD="2000-04-13" CREATED="2000-04-13" AUTHOR="HokoYono">
name::
* McsEngl.aaj'xelement.REFINO-SPECIFICcOMPLEMENT@cptIt,
* McsEngl.aaj'refino-specificComplement-element-1047i@cptIt,
* McsEngl.specokompletefino-element-of-aaj-1047i@cptIt,
name::
* McsEngl.aaj'xelement.REFINO-ENVIRONMENT@cptIt,
* McsEngl.aaj'refino-environment-element-1047i@cptIt,
* McsEngl.envieino-element-of-aaj-1047i@cptIt,
_NOTATION:
<ENVIEINO LASTMOD="2000-04-10" CREATED="2000-04-10" AUTHOR="HokoYono">
name::
* McsEngl.aaj'xelement.REFINO@cptIt,
* McsEngl.relationefino-element-of-aaj-1047i@cptIt, {2009-09-13}
* McsEngl.refino-element-of-aaj-1047i@cptIt,
_NOTATION:
<REFINO FrNAME="TruthValue@..." SPECIFIC="true@..." CREATED=...>
<SrCPT .../>
</REFINO>
[hknu_2009-03-29]
<REFINO FLN="Mapeino@" GENEREFINO="" LASTMOD="2008-12-11" CREATED="2000-04-25" AUTHOR="HoKoNoUmo">
<SrCPT_EXT FLN="Sensorial-Concept@HoKoNoUmo.it-1.xml" CREATED="2000-04-25" AUTHOR="HoKoNoUmo"/>
</REFINO>
_USAGE:
To denote specific attribute-relations and the concepts they connect.
[hknu_2009-03-29]
name::
* McsEngl.aaj'xelement.REFINO-ATTRIBUTE@cptIt,
* McsEngl.aaj'refino-attribute-element-1047i@cptIt,
* McsEngl.attributefino-element-of-aaj-1047i@cptIt,
_NOTATION:
<ATTRIBUTEINO LASTMOD="2006-10-25" CREATED="2006-10-25" AUTHOR="HoKoNoUmo">
<SrCPTEXT FLN="Attribute@HoKoNoUmo.simb-21.xml" GENEREINO="no" LASTMOD="2006-10-25" CREATED="2006-10-25" AUTHOR="HoKoNoUmo"/>
</ATTRIBUTEINO>
name::
* McsEngl.aaj'xelement.REFINO@cptIt,
* McsEngl.aaj'refino-element-1047i@cptIt,
aaj'notation.REFINO:
<REFINO CREATED="2009-11-12" AUTHOR="HoKoNoUmo">
<REFINO FRnAME="Entity's-relation@hknu.symb-1@" CREATED="2009-11-12" AUTHOR="HoKoNoUmo">
<XCPT FRnAME="Entity's-relator@hknu.symb-25@" CREATED="2009-11-12" AUTHOR="HoKoNoUmo"/>
</REFINO>
<REFINO_REFINOdIVISION ATR="" CREATED="2009-11-12" AUTHOR="HoKoNoUmo">
<XCPT FRnAME="Entity's-attribute-relation@hknu.symb-20@" CREATED="2009-11-12" AUTHOR="HoKoNoUmo"/>
<XCPT FRnAME="Entity's-non-attribute-relation@hknu.symb-19@" CREATED="2009-11-12" AUTHOR="HoKoNoUmo"/>
</REFINO_REFINOdIVISION>
</REFINO>
_DESCRIPTION:
Only "entity" has this xelement.
[hknu_2009-11-23]
name::
* McsEngl.aaj'xelement.XCPT@cptIt,
* McsEngl.aaj'xcpt-element-1047i@cptIt,
* McsEngl.aaj'element.SrCPT@cptIt,
* McsEngl.aaj'SRcPTeXT-1047i@cptIt,
* McsEngl.SRcPTeXT-element-of-aaj-1047i@cptIt,
aaj'notation.XCPT:
* a specific-xcpt does NOT has GENERICiNHERITOR xattribute. It is obvious.
[hknu_2009-11-23]
<XCPT FRnAME="Entity's-structure@hknu.simb-8@" GENERICiNHERITOR="Entity's-structure@hknu.simb-8@/Entity@hknu.simb-7@" CREATED="2009-10-26" AUTHOR="HoKoNoUmo"/>
<XCPT FRnAME="Process-or-relation@hknu.simb-14@"
GENERIC="Entity@hknu.simb-7@" CREATED="2001-07-17" AUTHOR="HoKoNoUmo"/>
<XCPT FRnAME="Entity's-structure@hknu.simb-8@" CREATED="2009-10-26" AUTHOR="HoKoNoUmo"/>
<SRcPTeXT
FLN="Entity_s_interdependence@hknu.simb-8.xml"
GENEREFINO="Entity_s_interdependence@hknu.simb-8.xml/Process@hknu.simb-15.xml"
LASTmOD="2001-07-17"
CREATED="2001-07-17"
AUTHOR="HoKoNoUmo"/>
aaj'ToDo.XCPT:
* A specific has xmlElement "GENERIC". An attribute has xmlElement "GENERICiNHERITOR".
[hknu_2009-11-05]
name::
* McsEngl.aaj'xelement.SRcPTiNT@cptIt,
* McsEngl.aaj'SRcPTiNT-1047i@cptIt,
* McsEngl.SRcPTiNT-element-of-aaj-1047i@cptIt,
_NOTATION:
<SRcPTiNT FLN="Concept's-attribute@hknu.meta-1#1.xml" INHERITEINO="Entity@hknu.simb-7" LASTmOD="2008-12-07" CREATED="2000-04-14" AUTHOR="HoKoNoUmo">
<DEFINEFINO LASTmOD="2000-04-14" AUTHOR="HoKoNoUmo">
*** Object (HoKoNoUmo.simb-10).
</DEFINEFINO>
<NAMEFINO LASTmOD="2009-05-10" CREATED="2000-03-14" AUTHOR="HoKoNoUmo">
<eng LASTmOD="2008-10-08" CREATED="2000-10-25" AUTHOR="HoKoNoUmo">
<NameNounCase TXeXP="Concept" TRMrULE="rlEngTrmNnCs11" CREATED="2008-04-06" AUTHOR="HoKoNoUmo"/>
<NameNounAdjective TXeXP="Conceptual" TRMrULE="rlEngTrmNnAj31" CREATED="2008-04-06" AUTHOR="HoKoNoUmo"/>
</eng>
<eln LASTmOD="2001-06-13" CREATED="2000-10-25" AUTHOR="HoKoNoUmo">
<NameNounCase TXeXP="Συσχετισμός έννοιας" TRMrULE="rlElnTrmNnCs51d1" CREATED="2000-02-19" AUTHOR="HoKoNoUmo"/>
</eln>
</NAMEFINO>
</SRcPTiNT>
<SRcPTiNT
FLN="Concept's-attribute@hknu.meta-1#1.xml"
VALUE="8"
GENEREFINO="Number@hknu.simb-8.xml"
LASTmOD="2008-12-07"
CREATED="2000-04-14"
AUTHOR="HoKoNoUmo"/>
[hknu_2009-06-08]
name::
* McsEngl.aaj'NAME@cptIt,
* McsEngl.aaj'namero@cptIt1047i,
* McsEngl.namero-of-aaj'ksp@cptIt1047i,
_DEFINITION:
* The dezigneptero (xml element) of the aaj's akpt contains ONLY the namepteros AND the sinameros (not the sinonimeros) of the akpt. In aaj, all the dezignepteros of the stored artificial-konseptos are stored in the dezigneptero-files which are created by the machine.
[hknu_2006-08-08]
* DESIGNEITO OF AN AKPT is any neimero of its sinkonsepteros and any akronimo, shortname (abreviation) or simbolo a language uses for this akpt.
[hknu_2006-02-04]
* This is a BREIN-EPTO and a LOG-ERO concept. Then its name must reflect this situation.
[hknu_2006-06-08]
_CONVENSION:
* FolioViews-NOTATION:
- xxxYyyy = one yuordero with 2 accents.
- xxx_yyy = one namero with 2 yuorderos.
- xxx'yyy = one namero with 2 yuorderos and yyy attribute of xxx
- xxx.yyy = one namero with 2 yuorderos and yyy specific of xxx
[hknu_2008-03-26]
* AAj-NOTATION:
- xxxYyyy = one yuordero with 2 accents.
- xxx_yyy = one yuordero with 2 accents.
- xxxos-yyy = one namero with 2 yuorderos and yyy attribute of xxx
- xxxo-yyy = one namero with 2 yuorderos and yyy specific of xxx
[hknu_2008-03-26]
_SPECIFIC:
* NAMEPTERO
* NAMEPTERO AKRONIMEMPTERO
* NAMEPTERO FORMALEPTERO#cptItsoft1047.5: attSpe#
* NAMEPTERO ABREVIEPTERO
* NAMEPTERO SIMBOLEPTERO
*
* IDENTIFEPTERO#cptItsoft1047.7: attSpe#
* SINONIMERO#cptItsoft1047.3: attSpe#
name::
* McsEngl.aaj'NAME@cptIt,
* McsEngl.conceptIt356.12.2,
* McsEngl.name-of-srcpt-1047.2@cptIt,
* McsEngl.namespo-of-aaj'ksp-1047.2@cptIt,
* McsEngl.name'of'aaj'sc-1047.2@cptIt,
* McsEngl.aaj'Name'of'a'sc@cptIt,
_DEFINITION:
* CONVENSION: the first NOUN is the name of the sc.
[hknu_{2001-03-08}]
* The NAME of a SC is the most used NOUN lexeme/synonym of the sc.
[hknu_{2001-03-05}]
name::
* McsEngl.aaj'SINAMERO@cptIt,
* McsEngl.conceptIt356.12.3,
* McsEngl.sinamero-of-aaj'ksp-1047.3@cptIt,
* McsEngl.aaj'knca'synonymer-1047.3@cptIt,
* McsEngl.synonymer'of'aaj'sc-1047.3@cptIt,
_DEFINITION:
* SINAMERO-OF-KSP is the SET with all its nameros.
[hknu_2008-03-24]
* SYNONYMA OF AA-SC is the xml-element that holds all the synonyms for every semantic-word a language uses for this sc, for all languages.
[hknu_2003-03-15]
* SC SYNONYM is ANY noun/verb/adjective/adverb/operator form (lexeme) of the SC in any language.
[hknu_{2001-03-05}]
_GENERIC
* SYNONYMER#cptCore453.4#
_IMPLEMENTATION:
* the files mm'synonymers_lang.xml contains the synonymers (namers and formers) of a mm's concepts.
[hknu_2004-03-30]
name::
* McsEngl.aaj'FILENAME@cptIt,
* McsEngl.conceptIt356.12.10,
* McsEngl.aaj'scpt-s-FileName-1047.10@cptIt,
* McsEngl.fileName-of-aaj'ksp-1047.10@cptIt,
* McsEngl.aaj'FileName'of'SC@cptIt,
_DEFINITION:
Every sc in the jscs belongs to an xml-file. The name of this file is the filename of the sc.
The FileName consists of the FormalName plus ".xml".
The FormalName consists of the FormalName's verbal, plus "@" and the FormalName's ID.
The FormalNameID consists of the KnowledgeBase plus "-" and a number.
[hknu_{2001-03-05}]
_CONVENSION:
* We can write code, to give names to srcpt-files. Another method is manually with the rule:
- entity_attribute = entity with attribute
- entity_s_attribute = attribute of entity
- Tree-network_s_node
[HkNu_2008-12-02]
* FileName of a ksp will be the "first-namoNounero in langoKomo" @ formaloYunikero.xml.
[hknu_2008-03-24]
* The fileName without ".xml" is the namoFormalero of a koncespo.
[hknu_2008-03-25]
the first NOUN is the name of the sc.
[hknu_{2001-03-08}]
_EXAMPLE:
* konsepto@mdbNikkas.simb-1.xml
* FILE-CPT: Hard-Disk@it-1.xml
* INTERNAL-CPT:
name::
* McsEngl.aaj'FORMAL-NAME (Koncepo@HoKoNoUmo.simb-1),
* McsEngl.conceptIt356.12.5,
* McsEngl.FormalName-of-srcpt-1047.5@cptIt,
* McsEngl.aaj'namoFormalero-1047.5@cptIt,
* McsEngl.namoFormalero-of-aaj'ksp-1047.5@cptIt,
* McsEngl.formalepero-of-ksp-1047.5@cptIt,
* McsEngl.formaleptero'of'knca-1047.5@cptIt,
* McsEngl.aaj'knca'FormalName@cptIt,
* McsEngl.aaj'FormalName'of'SC@cptIt,
* McsEngl.aaj'Τυπικό-Όνομα@cptIt,
_CONVENSION:
* I added an extra @ to the end. This way I will find with less code xcpts because will give us exactly what ends in for ex ...2 and not and not ...21, ...22, ...212, ...2122, ...
[hknu_2009-10-21]
* TODO: the first komo-namoNounero to be the FormaloTermero. If komo does not exist, then the english one.
- The fileName without ".xml" is the namoFormalero of a koncespo.
[hknu_2008-03-25]
* NamoFormalero of a ksp will be the
- "first-namoNounero in langoKomo" (Koncepo)
- @
- formaloYunikero (vsHokoYonko.simb-1)
[hknu_2008-03-24]
_GENERIC
* SC-FORMAL-NAME#cptCore50.28.7#
_EXAMPLE:
* konsepto@mdbNikkas.simb-1, 2006-11-10
* xxx@mdbNikkas...soft-1, 2006-11-11
* xxx@mdbNikkas.it.soft-1, 2006-11-11
* Hard-Disk@it-1
_PART:
* formal-term#cptItsoft1047.9: attPar#
* @
* formal-id#cptItsoft1047.4: attPar#
name::
* McsEngl.aaj'FORMAL-TERM (Koncepo)@cptIt,
* McsEngl.conceptIt356.12.9,
* McsEngl.FormalTerm-of-srcpt-1047.9@cptIt,
* McsEngl.aaj'formalotermero-1047.9@cptIt,
* McsEngl.formalotermero-1047.9@cptIt,
* McsEngl.termero-of-namoformalero-aaj'ksp-1047i@cptIt,
* McsEngl.aaj'formal'name'worder@cptIt, {2005-09-08}
* McsEngl.aaj'formal'namer'of'sc@cptIt,
* McsEngl.aaj'ssc'sformalnamer@cptIt,
* McsEngl.aaj'sc'FormalWord-(ΤυπικήΛέξη)@cptIt, {2001-06-27}
* McsEngl.aaj'VerbalFormalName@old,
* McsEngl.aaj'Verbal'ofa'SC@cptIt,
* McsElln.Λεκτικό-ΔΕ@cptIt,
_EXAMPLE:
* Koncepo <=== Koncepo@vsHokoYonko.simb-1
* Hard-Disk.
_CONVENTION:
* First letter Capital.
* instead of "space", we use "hyphen(-)"
* "underscore(_)", means specific.
* 's denotes attribute.
[hknu_2009-09-30]
* FormaloTermero of a ksp will be the first-namoNounero in langoKomo.
[hknu_2008-03-24]
xxx'syyy = yyy is an attribute of xxx
xxx.yyy = a specific of xxx
xxx'and'yyy = a corelaton of xxx and yyy
I'm using the 's convention for the attribute because we can use it and in spoken and in written language.
[hknu_2004-08-08]
The FormalWord now doesn't give the name of the concept because every language has its own name, ONLY the english-name we can get. 2001-06-27
PROGRAMMATICALLY we can take from a FNVerbal a NORMALNAME as:
statement'predicate >>> statement's-predicate.
statement.incomple >>> incomplete-statement.
xxx'and'yyy >>> Relation of xxx to yyy.
xxx_yyy >>> xxx yyy.
The NormalName is always an english-string. It is useful to be equal with the english-name of the cpt.
[hknu_{2001-03-08}]
name::
* McsEngl.aaj'FORMAL-ID (HoKoNoUmo.simb-1)@cptIt,
* McsEngl.conceptIt356.12.4,
* McsEngl.FormalID-of-srcpt-1047.4@cptIt,
* McsEngl.aaj'formaloYunikero-1047i@cptIt,
* McsEngl.formaloYunikero-1047i@cptIt,
* McsEngl.yunikero-of-namoformalero-aaj'ksp-1047i@cptIt,
* McsEngl.ID-of-namoformalero-aaj'ksp-1047i@cptIt,
* McsEngl.aaj'knca'ID@cptIt,
* McsEngl.aaj'ID'ofa'SC@cptIt,
_DEFINITION:
* the sc-id uniquely identifies the concept.
_GENERIC:
* SC-ID#cptCore50.28.4#
_PART:
* formalWorldview
* formalSubworldview
* formalNumber
_EXAMPLE:
* vsHokoYonko.simb-1 <=== Koncepo@vsHokoYonko.simb-1
* mdbNikkas.it-1
* FILE-CPT: it-1
* INTERNAL-CPT: it-1#2
name::
* McsEngl.aaj'FORMAL-VIEW (HoKoNoUmo.simb)@cptIt,
* McsEngl.FormalView-of-srcpt-1047i@cptIt,
* McsEngl.aaj'formaloVudo-1047i@cptIt,
* McsEngl.formaloVudo-1047i@cptIt,
* McsEngl.vudo-of-namoformalero-aaj'ksp-1047i@cptIt,
_EXAMPLE:
* vsHokoYonko.simb <=== Koncepo@vsHokoYonko.simb-1
name::
* McsEngl.aaj'FORMAL-WORLDVIEW (HoKoNoUmo)@cptIt,
* McsEngl.FormalWorldview-of-srcpt@cptIt1047i,
* McsEngl.aaj'formaloVudoSimbanespto@cptIt1047i,
* McsEngl.formaloVudoSimbanespto@cptIt1047i,
* McsEngl.vs-of-namoformalero-aaj'ksp@cptIt1047i,
* McsEngl.aaj'knca'MDB@cptIt,
* McsEngl.aaj'BM'of'SC@cptIt,
* McsElln.ΒάσηΕννοιών@cptIt,
_EXAMPLE:
* vsHokoYonko <=== Koncepo@vsHokoYonko.simb-1
* mdbNikkas.simb,
* FILE-CPT: it
* INTERNAL-CPT: it
name::
* McsEngl.aaj'FORMAL-SUBWORLDVIEW (simb)@cptIt,
* McsEngl.FormalSubworldview-of-srcpt@cptIt1047i,
* McsEngl.aaj'formaloVudespto@cptIt1047i,
* McsEngl.formaloVudespto@cptIt1047i,
* McsEngl.vudespto-of-namoformalero-aaj'ksp@cptIt1047i,
name::
* McsEngl.aaj'FORMAL-NUMBER (1)@cptIt,
* McsEngl.FormalNumber-of-srcpt@cptIt1047i,
* McsEngl.aaj'formaloNumbero@cptIt1047i,
* McsEngl.formaloNumbero@cptIt1047i,
* McsEngl.number-of-namoFormalero-of-aaj'ksp@cptIt1047i,
* McsEngl.aaj'knca'Number@cptIt,
* McsEngl.aaj'Number'ofa'SC@cptIt,
EXAMPLE:
* 1 <=== Koncepo@vsHokoYonko.simb-1
* FILE-CPT: 1
* INTERNAL-CPT: 1#2
name::
* McsEngl.aaj'UNIQUE-NAME@cptIt,
* McsEngl.conceptIt356.12.7,
* McsEngl.unique-name-of-xcpt-1047.7@cptIt, {2009-10-03}
* McsEngl.unique-identifier-of-srcpt-1047.7@cptIt,
* McsEngl.aaj'kspID-1047.1@cptIt,
* McsEngl.aaj'kspYunikero-1047.1@cptIt,
* McsEngl.koncespo'id-1047.1@cptIt,
* McsEngl.yunikero-of-ksp-1047.1@cptIt,
* McsEngl.namoYunikero-of-aaj'ksp-1047.7@cptIt,
* McsEngl.aaj'identifeptero-1047.7@cptIt,
* McsEngl.aaj'identifier-1047.7@cptIt,
* McsEngl.aaj'idfier-1047.7@cptIt,
_DEFINITION:
A namoYunikero or any other entity such as fileName that uniquely indentifies the koncespo.
[HokoYono, 2008-04-06]* SC's IDENTIFIER is any symbol that uniquely identifies it, such as:
- id: it-1
- formal-name: Hard-Disk@it-1
- file-name: Hard-Disk@it-1.xml
[hknu_2004-09-08]
* 1. identifier -- (a symbol that establishes the identity of the one bearing it) [WordNet 2.0]
_SPECIFIC:
* FILE_NAME#cptCore1047.10: attSpe#
* FORMAL_NAME#cptCore1047.5: attSpe#
* FORMAL_ID#cptCore1047.4: attSpe#
_Numbering:
0
1
...
999999 1 mil
1-0
1-1
...
1-999999 2 mil
2-0
...
2-999999 3 mil
...
999999-999999 1 mil mil (tera)
1-0-0
1-0-1
...
[hmnSngo.2012-02-08]
Every concept in the worldview must have an ID (a unique-number):
1-0
1-1
1-2
1-3
...
1-999999
2-0
2-1
...
2-999999
3-0
3-1
...
999999-999999
[hknu_2010-09-02]
==================
A=1000
B=1000.000
C=1000.000.000
1 0.000.001
2 0.000.001
999 0.000.999
A 0.001.000
A1 0001.001
A999
2A
2A1
2A999 0.002.999
3A 0.003.000
999A 0.999.000
999A999 0.999.999
B 1.000.000
BA 1.001.000
name::
* McsEngl.aaj'DTD@cptIt,
* McsEngl.aaj'DTD@cptIt,
<!-- Creation: 1997dec, LastModified: 1997dec14 -->
<!ELEMENT concept (name, synonyma, definition, general*, whole*, attributes*, environment*, subgeneral*)>
<!ATTLIST concept
id ID #REQUIRED
creation CDATA #REQUIRED
lastmodified CDATA #IMPLIED
author CDATA #REQUIRED>
<!-- name/synonyma/definition DON'T have 'creation' attribute, because they are created together with the concept -->
<!ELEMENT name (#PCDATA)>
<!ATTLIST name
lastmodified CDATA #REQUIRED
author CDATA #REQUIRED>
<!ELEMENT synonyma (synonym)+>
<!ELEMENT synonym (#PCDATA)>
<!ATTLIST synonym
creation CDATA #REQUIRED
lastmodified CDATA #REQUIRED
author CDATA #REQUIRED>
<!ELEMENT definition (#PCDATA)>
<!ATTLIST definition
lastmodified CDATA #REQUIRED
author CDATA #REQUIRED>
<!ELEMENT general (#PCDATA)>
<!ELEMENT general (name | synonym)+>
<!ATTLIST general
creation CDATA #REQUIRED
lastmodified CDATA #REQUIRED
author CDATA #REQUIRED>
<!ELEMENT whole (#PCDATA)>
<!ELEMENT whole (name | synonym)+>
<!ATTLIST whole
creation CDATA #REQUIRED
lastmodified CDATA #REQUIRED
author CDATA #REQUIRED>
<!-- attributes/environment what really contain is a concept, ie: "xml'element" is a unique concept that has the "xml" as a whole and the "sgml'element" as general. -->
<!ELEMENT attributes (concept)+>
<!ELEMENT environment (concept)+>
<!ELEMENT subgeneral (dimension|name)+>
<!ATTLIST subgeneral
creation CDATA #REQUIRED
lastmodified CDATA #REQUIRED
author CDATA #REQUIRED>
<!ELEMENT dimension (class)+>
<!ATTLIST dimension
attribute CDATA #REQUIRED
creation CDATA #REQUIRED
lastmodified CDATA #REQUIRED
author CDATA #REQUIRED>
<!ELEMENT class (#PCDATA)>
<!ATTLIST class
name CDATA #REQUIRED>
name::
* McsEngl.aaj'MORE-THAN-ONE-SAME-SPECIFICS@cptIt,
aaj'notation.SAME_SPECIFICS:
* Entity(1)@hknu.symb-7@
* Entity(2)@hknu.symb-7@
Denotes two entities but different.
[hknu_2009-11-12]
name::
* McsEngl.aaj'EXAMPLE-SrCPT@cptIt,
<?xml version="1.0" encoding="ISO-8859-7"?>
<KONSEPTO FLN="Thing@mdbNikkas.simb-13.xml" LASTINTID="0" INTEGRATED="no" LASTMOD="2001-07-17" CREATED="2001-07-17" AUTHOR="nikkas">
<DEZIGNEPTERO LASTMOD="2001-07-17" CREATED="2001-07-17" AUTHOR="nikkas">
<ELD LASTMOD="2001-07-17" CREATED="2001-07-17" AUTHOR="nikkas">
<NOUNERO ESTR="Πράγμα" RULE="eln3a1" LASTMOD="2001-07-17" CREATED="2001-07-17" AUTHOR="nikkas"/>
</ELD>
<ENG LASTMOD="2001-07-17" CREATED="2001-07-17" AUTHOR="nikkas">
<NOUNERO ESTR="Thing" RULE="enn11" LASTMOD="2001-07-17" CREATED="2001-07-17" AUTHOR="nikkas"/>
</ENG>
</DEZIGNEPTERO>
<DEFINERO LASTMOD="2001-07-17" AUTHOR="nikkas">
Thing is the ENTITY we perceive as an independent one, distinct from other entities. For example an apple, a tree, a society, a town etc. What is not 'thing' is a 'RELATION'.
</DEFINERO>
<PART LASTMOD="2001-07-17" CREATED="2001-07-17" AUTHOR="nikkas">
<KNSEXT FLN="Entity'Definitness@mdbNikkas.simb-19.xml" JENEREPTO="Entity'Definitness@mdbNikkas.simb-19.xml" LASTMOD="2006-10-01" CREATED="2006-10-01" AUTHOR="nikkas"/>
<KNSEXT FLN="Entity'Interdependence@mdbNikkas.simb-8.xml" JENEREPTO="Entity'Interdependence@mdbNikkas.simb-8.xml/Entity@mdbNikkas.simb-7.xml" LASTMOD="2001-07-17" CREATED="2001-07-17" AUTHOR="nikkas"/>
</PART>
<JENEREPTO LASTMOD="2001-07-17" CREATED="2001-07-17" AUTHOR="nikkas">
<KNSEXT FLN="Entity@mdbNikkas.simb-7.xml" JENEREPTO="..." LASTMOD="2001-07-17" CREATED="2001-07-17" AUTHOR="nikkas"/>
</JENEREPTO>
</KONSEPTO>
name::
* McsEngl.aaj'FILE-SrCPT@cptIt,
* McsEngl.file-koncespo@cptIt1047.1i,
* McsEngl.aaj'File'SC@cptIt,
_DEFINITION:
* FILE-SC is a SC that is stored in an idependent xml-file.
[hknu_{2001-03-05}]
name::
* McsEngl.aaj'INTERNAL-SrCPT@cptIt,
* McsEngl.internal-koncespo@cptIt1047.1i,
* McsEngl.inner-sc@cptIt,
* McsEngl.aaj'internal'cpt@cptIt,
_DEFINITION:
* It is the opposite of file-cpt.
An internal can be an attribute or subgeneral.
A sub-internal has att the atts of its host.
An att-internal has as whole its host.
ATRIBESPO:
An internal-att can be general (inheriting). But when we overide one of its inherited then this general att must become 'file'-cpt because it has sub.
name::
* McsEngl.aaj'XmlSemasia@cptIt,
* McsEngl.aaj'ssma@cptIt,
* McsEngl.aaj'semasia@cptIt,
* McsEngl.aaj'XmlVudesmo@cptIt,
<VDSM LABEL="ex1" LNG="eng">
<!-- Concept is called every node of a concept-model -->
<!-- Concept I call every node of a concept-model. -->
<!-- Έννοια ονομάζεται κάθε κόμβος ενός εννοιακού-μοντέλου -->
<Sentensemo LABEL="s1">
<Verbemo LABEL="x1" NMFLR="Calling@HokoYono.simb-17" ATM="ind,pre,ins,pass,iper,ning,aff,sin,3"/>
<Nounemo LABEL="x2" NMFLR="Person@HokoYono.simb-12" INSTANCE="nikkas" ATM="def,sin"/>
<Nounemo LABEL="x3" NMFLR="Koncepo@HokoYono.simb-1" ATM="none,sin"/>
<StrukturoNounemo LABEL="x4">
<Nounemo LABEL="a" NMFLR="Koncepo-Model@HokoYono.simb-6" ATM="idef,sin"/>
<StrukturoNounemo LABEL="b">
<Nounemo LABEL="b1" NMFLR="Hierarchy-Node@HokoYono.simb-11" ATM="idef,sin"/>
<Specialemo LABEL="b2" NMFLR="Quantity@HokoYono.simb-18" ATM="idef-every,any"/>
<Deanemo NMFLR="properteino" ARGS="b1,b2"/>
</StrukturoNounemo>
<Deanemo NMFLR="parteino" ARGS="a,b"/>
</StrukturoNounemo>
<Deanemo NMFLR="verboleteino" ARGS="x1,x3"/>
<Deanemo NMFLR="vbteino.agenteto" ARGS="x1,x2"/>
<Deanemo NMFLR="verbeleteino" ARGS="x1,x4"/>
</Sentensemo>
</VDSM>
name::
* McsEngl.aaj'LOGAL-SUBWORLDVIEW@cptIt,
* McsEngl.aaj'vudero@cptIt,
name::
* McsEngl.aaj'Name-of-LgConcept@cptIt,
<NamoNounero ESTR="Koncepo" NMRULE="rlEngNmNnr11" CREATED="2006-02-05" AUTHOR="HokoYono"/>
name::
* McsEngl.aaj'TERM-FILE@cptIt,
_DEFINITION:
Contain only the terms of logal_concepts.
[2008-12-15]
aaj'ToDo.TermFile:
* Terminals of first type, do NOT contain "name" attribute, because it is the same with expression in order to minimize storage.
[hknu_2009-11-03]
ENTRY:
<TRMNL TXeXP="tree network's node" TRMNLtYPE="trmNnCsNm1" SRcPT="Tree-network's-node@hknu.simb-11.xml" NAME="tree network's node"/>
aaj'TRMNL_ELEMENT_OF_TERMFILE:
<TRMNL TXeXP="tree network's node" TRMNLtYPE="trmNnCsNm1" SRcPT="Tree-network's-node@hknu.simb-11.xml" NAME="tree network's node"/>
aaj'SRcPT_ATTRIBUTE:
* its value its better to be the FileName, because we can change it every where in the knowledgeBase and its end ".xml" makes unique it.
[2009-06-29]
name::
* McsEngl.aaj'TERMINAL-FILE@cptIt,
* McsEngl.aaj'TerminalFile@cptIt,
_ATTRIBUTES:
- TxEXP="tia"
- TRMNLTYPE="auxNnC"
- LgCPT="nnC3"
- TxEXP_A="trmNnC1"
- EXMPL="homo tia"
- USG="dependent-sentence"
ORDER:
* If we put terminal alphabetically, then when we found it we can stop reading any more.
[2008-11-14]
name::
* McsEngl.aaj'Auxiliary@cptIt,
<TRMNL TxEXP="tia"
TRMNLTYPE="auxNnC"
LgCPT="nnC4"
TxEXP_A="trmNnC2"
EXMPL="homi tia"/>
<ISR ESTR="ta" USG="dependent-sentence">
<SINTAKS ESTR="ta" TMtYPE="idrVbr" KCR="" ESR1B="" ESR1A="" EPL="dependent sentence"/>
</ISR>
<ISR ESTR="ο" TMtYPE="idrNnr" KCR="nmr03" ESR1A="*AV" ESR1A="*AN" ESR3A="nmNnr1" EPL="ο πατέρας"/>
<ISR ESTR="the">
<SINTAKS ESTR="the" TMtYPE="idrNnr" KCR="nmr3" ESR1A="*AV" ESR2A="*AN" ESR3A="nmNnr1" EPL="the *red car"/>
<SINTAKS ESTR="the" TMtYPE="idrNnr" KCR="nmr4" ESR1A="*AV" ESR2A="*AN" ESR3A="nmNnr2" EPL="the *red cars"/>
<SINTAKS ESTR="the" TMtYPE="isr.npr" KCR="npr3" ESR1A="*AV" ESR2A="*AN" ESR3A="nmNnr3" EPL="the *red car's"/>
<SINTAKS ESTR="the" TMtYPE="isr.npr" KCR="npr4" ESR1A="*AV" ESR2A="*AN" ESR3A="nmNnr4" EPL="the *red cars'"/>
</ISR>
<TMR TxEXP="is" USG="usage">
* <TRMNL TxEXP="is" TRMNLTYPE="auxVrb" LgCPT="vrb019" SmCPT="vbt51" TxEXP_B="$HE|SHE|IT|S" TxEXP_A="trmVrb3"/>
* <TRMNL TRMNLTYPE="trmVrb3" LgCPT="vrb" SrCPT="Calling@HoKoNoUmo.simb-17.xml"/>
* </TMR>
* TxEXP="the expression of word (text)"
* TxEXP_B => first expression BEFORE the exp.
* TxEXP_A => first expression AFTER the exp.
* TxEXP="VC" => a verb-complement.
* TxEXP="S" => a lg_subject.
* TxEXP="SC" => a lg_subject-complement.
* TxEXP="O" => an lg_object.
* TxEXP="-" => no expression. 2005-09-30
* TxEXP="he|she" => he OR she.
* TxEXP="?AN" => none or one adjectives.
* TxEXP="*AN" => none or more adjectives.
* TxEXP="+AN" => one or more adjectives.
* TxEXP="Part@" => denotes a 'part' concept.
*
* $ and CAPITALS denote words not in a concepter.
* SMALL-LETTERS denotes words inside a concepter. 2004-10-14
name::
* McsEngl.aaj'Conjunction@cptIt,
<TRMNL TxEXP="of" TRMNLTYPE="trmCnj" SrCPT="Relation_whole_part@..."
TxEXP_B="part@;nominative"
TxEXP_A="whole@;nominative"
/>
* In the word-element: TxEXP= the >>>FIRST<<< word we search.
* In the syntax-element: TxEXP= the whole expresion we are searching for.
* The program will tokenize the second and will search if the other words are
* follow. Convention "#" means that other words are inserted. 2005-09-28
FORMAT-CONJUNCTION:
* <LgYUORDO TxEXP="of">
* <SNTX TxEXP="of"
TRMNLTYPE="trmCnj"
LgCPT="cnj068"
SmCPT="att.internal.mo"
SrCPT="Corelaton.PartWhole@"
ARGS="1:whole@,2:part@"
TxEXP1_B="2,nominative"
TxEXP1_A="1,nominative"
EXMPL="the engine of the car"/>
* </LgYUORDO>
<SINTAKS NDB1="NounStrukture;Entity@" NDA1="StrukturoOnr;Attribute@" EPL="a crowd of insects"/>
name::
* McsEngl.aaj'Verb@cptIt,
On trmVrb1, we can add the syntax.
[2008-12-15]
<TRMNL
TxEXP="call"
TRMNLTYPE="trmVrb1"
SrCPT="Naming@HoKoNoUmo.simb-17"
NAME="call"/>
VRB="active"
SBJ="scpt;lgCpt"
OBJ="scpt;lgCpt"
FORMAT-VERB:
* <LgYUORDO TxEXP="is">
* <SNTX TxEXP="is" TRMNLTYPE="auxVrb" LgCPT="vrb019" SmCPT="vbt51" TxEXP1_B="$HE|SHE|IT|S" TxEXP1_A="trmVrb3"/>
* <SNTX TRMNLTYPE="trmVrb3" LgCPT="vrb" SrCPT="Naming@HoKoNoUmo.simb-17.xml"/>
* </LgYUORDO>
<TRMNL TxEXP="called"
TRMNLTYPE="trmVrb3"
SrCPT="Calling@HoKoNoUmo.simb-17"
NAME="call"/>
<TRMNL TxEXP="called" TRMNLTYPE="trmVrb5" SrCPT="Calling@HoKoNoUmo.simb-17" NAME="call"/>
name::
* McsEngl.aaj'Noun@cptIt,
FORMAT-NOUN (nominative, possessive):
* <LgYUORDO TxEXP="the">
* <SNTX TxEXP="the" TRMNLTYPE="auxNn" LgCPT="nnCs3" SmCPT="mn#" TxEXP1_A="trmNnCsNm1" EXMPL="the *red car"/>
* <SNTX TRMNLTYPE="NORnn1" LgCPT="n" SrCPT="Tree-network_s_node@HoKoNoUmo.simb-11"/>
* </LgYUORDO>
FORMAT-PROPERTER (adjective, adverb):
* <LgYUORDO TxEXP="good">
* <SNTX TxEXP="the" TRMNLTYPE="auxNnAj" LgCPT="anr1" SmCPT="mp#" SrCPT="" TxEXP1_A="1n1" EXMPL="the *red car"/>
* </LgYUORDO>
<NMR ESTR="κόμβε" TMtYPE="nmNnra4" KSP="Hierarchy-Node@vsHokoYono.simb-11"
NMR1="κόμβος"/>
name::
* McsEngl.aaj'Menu@cptIt,
name::
* McsEngl.aaj'menu.RETRIEVE-KBASE@cptIt,
name::
* McsEngl.aaj'menu.TRANSLATE@cptIt,
TRANSLATE: TEXTERO/EN ==> MINETO/EN:
TxParsor tparsor = new TxParsor("simb","en");
MnNode jmdm=null;
try {
jmdm = tparsor.parseFromString(input);
} catch (IOException eio) {
System.out.println(eio.toString());
}
try {
jmdm.mapToCharNode(writer);
} catch (IOException ioe) {
System.out.println("FrameTranslation: IOException");
}
Util.log("START-PARSING: TEXTERO-ENGLISH");
TxParsorEn enp = new TxParsorEn(context);
outermostMnNode = enp.parseFromReader(reader);
- Creates the MdTextero-java.
- Creates the MdMeaning-java.
PERIODERO'S-UNDERSTANDING:
public MNode TParsorEn.understandPeriodero (TNode piriodero, int lineNr, MNode parent, String cntxt)
1) finds the tokeneros (Yordero, Numero, SimboStructure, Separatero and Punktero) of a periodero:
piriodero=findTokenerosTerminal(periodero);
ch = scanTokeneroTextero(reader, tmpbuf); scans separateros and
non-stoperos tokeneros.
Hashtable htType = identifyTokeneroTexteroWithSintaksero(stk);
Textero.isSimboStructure(tkn)
result = Textero.isYorderoWithSintaksero(tkn);
problem: "hierarchy-node": to be considered one yordero.
2) creates a vector with piriodero's-tokeneros:
Vector<TNode> vot=piriodero.tnChildren;
3) creates the empty mnode that maps the piriodero:
MnNode mnode = new MNode("UNKNOWN", parent);
4) takes one yordero each time and trys to figure out
the surrounding KONSEPTEROS and CONTENT-NODES:
** HashTable htKnr = identifyKonseptero(vot, i);
a) validates the sintakseros of the yorderos:
HashMap hmk = isSintakseroValid(sks,vot,i);
** Replace the yordero with the FIRST (or after evaluation) konseptero. Put the rest valid konsepteros in the hashtable of konsepteros. This way we will have stored only the valid konsepteros and not ALL the sintakseros of a yordero.
5) first understanding attempt:
The LINGUISTIC-INFORMATION is not enough to UNDERSTAND a textero. Eventhough we can find the correct structure from only linguistic-information, this method includes the possibility of a mistake if we don't take into account BRAINEPTO-INFORMATION:
::mdt: The wind closed the door.
In this sentensero linguistic information is enough to find the corect structure.
::mdt: The failure closed the door.
Here only brainepto-information can find the meaningless of the sentesero.
[hknu_2006-10-23]
PREVIOUS-METHOD:
//TEXT,en ==> JTEXT,en ==> MEANING,en
TParsor tparsor = new TParsor("phil","en");
TNode jtmodel = tparsor.parseFromString(input);
TMaporToMeaning tmm = new TMaporToMeaning(jtmodel, "en", writer);
TxNode pr = readPeriodero(spr,lineNrSrcBeg,tnode,cntxt);
tnode=findChildTokeneros(tnode)
tnode=findChildKonsepteros(tnode);
tnode=findChildKpterStructures(tnode);
tnode=findVerbero_Arguments(tnode, parent);
TRANSLATE MINETO,en --> TEXTERO,en:
MnParsor parsor = new MnParsor();
MnNode mdmj = parsor.parseFromString(mdmineto);
StringWriter wr = new StringWriter();
MnMaporToMineto mmm = new MnMaporToMineto(mdmj,lang);
MnMaporToTextero mm = new MnMaporToTextero(mmm.jmdmOut, lang, wr);
wr.toString();
name::
* McsEngl.aaj'Method_Data-Representation@cptIt,
* McsEngl.aaj'krl@cptIt1047,
* McsEngl.krl'of'aaj@cptIt1047,
_SPECIFIC:
* kpta
* mdba
* mdma
* mdla
name::
* McsEngl.aaj'METHODOLOGY@cptIt,
Each xml'file corresponds to ONE concept.
The 'doc' will be created on the fly, from all related xml files.
[nikos, 1999jan03]
name::
* McsEngl.aaj'Notation@cptIt,
* McsEngl.aaj'convention@cptIt,
* McsEngl.aaj'sNotation@cptIt1047i,
* McsElln.ΣΥΜΒΑΣΗ@cptIt1047i,
_DESCRIPTION:
Here I store the notation I use in all my writings.
[hknu_2009-09-20]
SEARCH-ALL: (I put everywhere notations, not only here and I search for them).
notation.CASES:
* english language
* komo language
* java programing
* FolioViews writing
* AAj work
==============
- specific-concept
- attribute-concept
- expression
notation.UNDERSCORE (_):
* ENGLISH (specific): tx_verb: (aaj) multiword "specific concept" with first word the attribute.
* JAVA (specific):
* FolioViews (expression):
notation.UNDERSCORE (_s):
* JAVA (attribute): scpt_sFile: (java) multiword "attribute of concept" with first word the concept.
notation.HYPHEN (-):
* ENGLISH (specific): sensorial-concept--computer-system (attribute before generic).
* ENGLISH (expression): lg-concept's-name: (aaj) multiword term.
* KOMO (specific): lango-ho (attribute after generic).
notation.HYPHEN (s-):
* KOMO (attribute): langos-diktetro.
notation.APOSTROPHE ('):
* FolioViews (attribute): multiword "attribute of concept" with first word the concept: car'wheel
notation.APOSTROPHE ('s):
* ENGLISH (attribute): car's wheel.
notation.PERIOD (.):
* FolioViews (specific): car.toyota: multiword "specific concept" with first-word the general.
notation.CAPITAL_LETTER:
* ENGLISH (expression):
* JAVA (expression): frameEditor: multiword "specific concept" with first-word the general.
* KOMO (specific): LangoHo.
notation.SMALL_LETTER:
* JAVA (expression): SENSORIALcONCEPT, SrCONCEPT.
* KOMO (specific): LANGOhO.
notation.S:
* KOMO (attribute): LangosDiktetro.
notation.SPACE:
* ENGLISH (expression):
* ENGLISH (specific): red car.
* ENGLISH (attribute): car's wheel.
* KOMO (expression):
name::
* McsEngl.aaj'Notation.PROGRAM (java)@cptIt,
* McsEngl.aaj'notation.java@cptIt,
* McsEngl.aaj'assumption@cptIt,
* McsEngl.aaj'code@cptIt,
_DEFINITION:
It is special-words I use in the program to find specific locations I want to work with.
[hknu_2008-03-23]
_SPECIAL-WORD:
- llll: LAST place we worked.
- ppp: Something wrong is there.
- nnn: general place to look at.
- addLng: A place where I have to add code for a new adding language.
- sout: system.out to check
- wrkrnd: specific workaround. A change in the program, must find another solution.
- toDo: In future, I must add functionality there.
- cnvntn: Convention, I use in the program that must be followed systematically everywhere in it, and I must remember it. [2008-11-14]
_SPECIFIC-CONCEPT:
* Term_Komo:
[2009-08-17]
* TermKomo:
_ATTRIBUTE-CONCEPT:
* term_sConcept:
_EXPRESSION:
* ThisIsAMultiwordExpression:
* SENSORIALcONCEPT:
* SrCONCEPT:
name::
* McsEngl.aaj'Notation.SrCONCEPT-XML-FILE@cptIt,
NAME_OF_XML_FILE_OF_SrCPT:
_ ==> denote specific:
Entity_generic@HoKoNoUmo.simb-3.xml
[hknu_2009-06-29]
_ ==> denote part or specific:
Entity_s_definition@HoKoNoUmo.simb-2.xml
Entity_generic@HoKoNoUmo.simb-3.xml
- ==> denote "space":
Entity-and-Referent@HoKoNoUmo.simb-4.xml
Entity's-definition@HoKoNoUmo.simb-2.xml
SCONCEPT'S_FILE_NAME:
* it would be the first english-noun. Then we don't need the "FLN" attribute
[2008-10-06]
IF the value of GENEREFINO is "no|...", THEN we must omit it, for less space.
[2009-06-06]
SRcPTiNT:
With this xml-element we can present any ATTRIBUTE
** DEFINITIONS:
>>>Concept's NAME:
It is the most used noun-synonym.
[2001-03-06]
>>>CONCEPT'S FILE-NAME:
formalnameVerbal +@ +id +extension
example: Hard-Disk@it-1.xml, aaa@lang-32#3.xml
[2001-03-05]
>>>CONCEPT'S FormalName:
example: Hard-Disk@it-1.
[2001-03-05]
>>>CONCEPT'S FormalNameVerbal:
I call a SET of words that except of a concept's name, also denote
and concept relations, as follows: [{1999-04-21}]
A NAME of a cpt: HardDisk
An Attribute cpt: HardDisk'Capacity
A Subgeneral cpt: HardDisk.Seagate
An Environment relation: HardDisk'and'Paper
[1999feb12]
>>>CONCEPT'S ID:
I call the sequence of
a)a word (usally short) that denotes a knowledge-base.
b)the '-'
c)a number.
example: it-1, phil-2, lang-32#3
[{1999-04-21}]
ID'S KNOWELEDGEBASE:
I call the word before '-' that denotes the knowledge base the concept belogs.
[{1999-04-21}]
ID'S NUMBER:
I call the number after '-' which is unique in this kb for any concept.
[{1999-04-21}]
>>>CONCEPT'S NAME (NORMAL-NAME):
We can get it from formal-name(or file-name) by a function.
[{1999-04-20}]
I CAN use '-' in formal name, if I want in normal-name to show that more than one
word construct a name.
[{1999-04-20}]
// The formal-name will NOT contain '-' to connect words.
// A Capital Letter will show the connected words.
// Not-Removable >>> NorRemovable.
// [{1999-04-14}]
I changed the file-name
from "it19_Relation.xml"
to "Relation_it-19.xml"
in order to find easily concepts by its name.
[{1999-04-18}]
I refer to a concept with its file-name or its id, as:
cpt / cptID
cptSib / cptSibID
[{1999-04-18}]
** INTERNAL CONCEPTS:
** XML-ATTRIBUTES:
* I put them on ONE line for space economy.
[1999mar]
* I put each one on a new line. This way I'm extracting them.
[1999feb22]
** EMPTY LINES:
* no more than one continuasly.
* One among xml elements.
* Nothing at the end tag of an element.
[1999feb22]
* one empty line between noninherited and inherited attributes.
[{1999-04-16}]
** INHERITED ATTRIBUTES:
We understand them because they have NOT 'no' as 'general' value.
We can have or not a file for them.
[1999feb15]
** CONEXT ORDER IN XML FILE:
Ascending.
[1999feb13]
** 'ID' XML-ATTRIBUTE:
IF I do NOT have a 'FILE' for a 'conref', I give as id
the general's id.
That way I'm reducing the numbers i'm giving for concepts.
[1999feb10]
As ID I give not only the number but the full name (number_name)
because I need a name for them when we display its definition as attributes.
[1999feb10]
name::
* McsEngl.aaj'Notation.Site (English)@cptIt,
SPECIFIC_CONCEPT:
* Komo-Language:
name::
* McsEngl.aaj'Notation.FolioViews@cptIt,
SPECIFIC_CONCEPT:
* language.komo:
name::
* McsEngl.aaj'Notation.KomoLanguage@cptIt,
name::
* McsEngl.aaj'Notation.EnglishLanguage@cptIt,
SPECIFIC_CONCEPT:
* language_komo:
[2009-08-20]
* komo-language:
* sensorial-concept--computer-system:
* komo language:
name::
* McsEngl.aaj'resourceInfHmn@cptIt,
JUNG — the Java Universal Network/Graph Framework--is a software library that provides a common and extendible language for the modeling, analysis, and visualization of data that can be represented as a graph or network. It is written in Java, which allows JUNG-based applications to make use of the extensive built-in capabilities of the Java API, as well as those of other existing third-party Java libraries.
http://jung.sourceforge.net/
RDF Gravity (RDF Graph Visualization Tool)
http://semweb.salzburgresearch.at/apps/rdf-gravity/index.html:
name::
* McsEngl.aaj'ToDo@cptIt,
LAST_WORK:
* DEFINITION_NAME:
- on Parser_XCpt.java ==> scanDefinitionName
- Maper_XDefinitionToText_Eng ==> write the code
================================
* SEARCH-ALL:
On every function to exist a "todo" attribute.
[HokoYono, 2008-03-10]
================================
VIEWER_ATTRIBUTE:
* If it displays all attributes, then we can have on the left FIXED tools|icons for the attributes. This way small computers can display more content of a concept.
[2009-03-08]
VIEWER_ATTRIBUTE:
* to display all attributes, and not only parts.
[2009-03-04]
LIST_OF_CONCEPTS_CREATED_PER_SUBWORLDVIEW_PER_NUMBER:
* on each subworldview_directory we can maintain a list of the concepts created.
[2008-12-11]
MANAGE_NAMES:
* "ok", on internals does not work for xml_file. [2008-12-05]
* insert new, AFTER the selected. DONE 2008-12-04
* for internal sconcepts. DONE 2008-12-05
[2008-12-04]
<TRMNL TxEXP=" more conceptual" TRMNLTYPE="trmNnAj2"
* remove space before "more"
[2008-12-04]
trmNnCs and trmNnNm:
the two types must become one.
[2008-12-03]
VIEWER: DONE
add WORLDVIEW and VIEW labels except "name" for every koncespo.
[HokoYono, 2008-03-24]
MENU: Language: DONE
For quick access to the displayed languages.
[HokoYono, 2008-03-24]
** on viewer when we double clicking on a word to go that concept IF the search result is one (in the same brain-model) and show the results if the results are many. A right click on a word will give the comand to search in another brain-model.
[2005-09-05]
** To edit and save back the parsed xml file.
[1999jan03]
** implement DOCUMENT'LISTENER on editors'doc, in order the tree to reflect changes.
[1999jan03]
** implement CARET'LISTENER on editor, in order the tree reflect where the caret is.
[1999jan03]
** implement TREE'SELECTION'LISTENER on tree, in order the doc shows the correspoding selection on tree.
[1999jan03]
name::
* McsEngl.aaj'Evolution@cptIt,
* McsEngl.KONCESTO-PROGRAM-EVOLUTION@cptIt,
* McsEngl.aaj'evolution@cptIt,
We need 2 branches, one that is stable and one that is "development".
one for bugfixes and one for new features.
[alan.ezust@gmail.com]
2009-01-25: Definefino To Text.
I have created the first mapping of
<ANALYTIC_PART_MIDDLE CREATED="2008-04-18" AUTHOR="HoKoNoUmo">
<DEFINEMENT_ENG LASTMOD="2004-03-23" CREATED="2001-09-30" AUTHOR="HoKoNoUmo">
Concept is every tree network node of a conceptual-subworldview.
</DEFINEMENT_ENG>
<NameNounCase LNG="eng" TxEXP="Concept" TRMRULE="rlEngTrmNnCs11"/>
<SOURCE FrmlNAME="Subworldview_conceptual@HoKoNoUmo.simb-6"/>
<PRODUCT>
<SrCPT LABEL="b1" FrmlNAME="Tree-network_s_node@HoKoNoUmo.simb-11"/>
<SrCPT LABEL="b2" FrmlNAME="Number_every@HoKoNoUmo.simb-22#1"/>
<SrCPT LABEL="b3" FrmlNAME="Quantiteino@HoKoNoUmo.simb-23" ARGS="b1,b2"/>
</PRODUCT>
</ANALYTIC_PART_MIDDLE>
To english text:
analytic-part-middle: Concept is every tree network's node of a Conceptual subworldview.
2006-11-21: Komunolingvo Yordero Management.
* Create Komuno Yorderos and validates them. A logetro file contains the rules.
2006-02-04: index-files.
* I no more use the desgs.bm.lang.xml files. I get the nonimeros, programmatically, from the akpt-files and the rule I have in dezigneitos.
* Also I created the "index-files" which hold alphabetically all the nonimeros and the rest dezigneitos of all akpt-files.
2004-11-21: English to Greek TEXT
I 've done my first translation of an example fraser:
- Concept is called every hierarchy-node of a concept-model.
to
- έννοια ονομάζεται κάθε κόμβος από ένα εννοιακό-μοντέλο.
2004-10-31: TextToMeaning
I managed to get the meaning of the first fraser: "Concept is called any hierarchy-node of a concept-model".
Unfortunatly the code is very limitted for the concepts in the above fraser.
[hknu_2004-10-31]
2004.06:
I hacked the NanoXML-2.2.3 parser of Marc De Scheemaecker, to write my own xml-scsm parser.
2001-06-17:
I hacked the "NOTIO" program of Finnegan-Southey, to create my textual-scsm and parse it.
{2001-04-28}: Integrated-ConceptBase.
I treat as SAME the names 'conceptual-information' and the 'concept-base'. Then identify as the goal of a scs the creation of an 'INTEGRATED-CONCEPTBASE'.
{2001-03-05}: SC's Synonym:
"SC SYNONYM is ANY noun/verb/adjective/adverb/operator form (lexeme) of the SC in any language".
{2000-11-09}:
version 00.02.00 (00.01.10) begins. The goal is my system to become NATURAL-LANGUAGE aware. I think that I have solved the problem theoritically. My program will test my theory (conceptual-grammar).
{2000-11-07}:
I removed SAXON. I wrote my code to display an xml file.
2000feb21-{2000-11-08}:
VERSION 00.01.09.
{1999-04-25} - 2000feb21:
VERSION 00.01.08.
1999jan03:
Help in html form I added.
1999jan01:
I updated the program for jdk1.2.
1997dec28:
Open and Search Commands were added.
1997dec27:
ToolBar and StatusBar were added,
1997dec14:
I put a TREE-VIEW for concept-relations.
1997dec13:
** I made my program global.
1997dec04:
** I made the program applet.
1997sep:
** I've lost code when I switched drives to my new K6-200 computer.
1997jul03:
** I made the program global with Greek and US locales.
1997jun08:
** Property Editor added.
1997may25:
** experiment: OK-innerclass added to About-innerclass.
RESULT: When I run the program, first comes the about dialog.
1997may24:
** openCommand was added. On "NorthPanel" I've putted gridbaglayout.
1997may23:
** searchTField action was added (It shows class attributes written in the textfield).
1997may19:
* ClassViewer (deprecated) was integrated.
1997may13:
* AboutCommand action added.
1997may09:
* WholeButton class creation and dispose() funtion.
* examples of attributes, subgeneral.
* colors to components.
name::
* McsEngl.aaj'VERSION@cptIt,
STEPS:
1) aa1History.txt: write the history.
2) strVersion @ AAj.java sets the version.
3) compile the program.
4) save it at d:/java/AAj
5) set new version at
- AAj.java
- java_comment_method.bsh
In file: \file1\AAjWorking\AAjProgram\aa1History.txt there is more info.
name::
* McsEngl.aaj'version-01.XX.XX: published-version@cptIt,
name::
* McsEngl.aaj'version-00.02.XX: natural-language@cptIt,
aaj'v00.02.02 (2010-01-02-):
* bconcept/sbconcept
aaj'v00.02.01 (2009-08-08-2010-01-02):
* difference in definition and creation
aaj'v00.02.00 (2000-11-09-2009-08-08):
* Natural-language management.
name::
* McsEngl.aaj'version-00.01.XX: integration@cptIt,
aaj'v00.01.09 (2000-02-21-2000-11-08):
* No saxon.
* Definition with "Vudetro"
aaj'v00.01.08 (1999-04-25-2000-02-21):
* Internal-Cpt kb'names.
aaj'v00.01.07 (1999.0314-1999-04-25):
* Many-KB One-line-Xml-Att New-Formal-Name Inline-Concepts
aaj'v00.01.06 (1999-02-21-1999-03-14):
* Search.
aaj'v00.01.05 (1999-02-16-1999-02-21):
* Add Attribute Concept.
aaj'v00.01.04 (1999-02-10-1999-02-16):
* Fix integration errors.
aaj'v00.01.03 (1999-02-09-1999-02-10):
* Sib_Sub integration.
aaj'v00.01.02 (1999-02-07-1999-02-09):
* General integration.
aaj'v00.01.01 (1999-01-19-1999-02-07):
* Whole-part integration.
name::
* McsEngl.aaj'version-00.00.XX: beginning@cptIt,
aaj'v00.00.17 (1999-01-17-1999-01-19):
* Editor-xt.
aaj'v00.00.16 (1999-01-03-1999-01-17):
* Sax-ConRef-Editor.
aaj'v00.00.15 (1999-01-01-1999-01-03):
* Help
aaj'v00.00.14 (1998-01-09-1999-01-01):
* JDK1.2 update.
aaj'v00.00.13 (1998-01-04-1998-01-09):
* XML-ZLF parent3
aaj'v00.00.12 (1997-12-30-1998-01-04):
* MSXML
aaj'v00.00.11 (1997-12-28-1997-12-30):
* TextPane-MouseListener.
aaj'v00.00.10 (1997-12-27-1997-12-28):
* Open-Search
aaj'v00.00.09 (1997-12-21-1997-12-27):
* ToolBar.
aaj'v00.00.08 (1997-12-14-1997-12-21):
* XML-ZLFREAD parser.
aaj'v00.00.07 (1997-12-13-1997-12-14):
* Tree
aaj'v00.00.06 (1997-12-12-1997-12-13):
* Global-program.
aaj'v00.00.05 (1997-06-08-1997-12-12):
* Applet.
aaj'v00.00.04 (1997-05-25-1997-06-08):
* Bean
aaj'v00.00.03 (1997-05-24-1997-05-25):
* About-command.
name::
* McsEngl.Mcsm.HTML (2010)@cptIt,
* McsEngl.conceptIt356.6,
* McsEngl.cbsHtml-program@cptIt356.6,
* McsEngl.html-koncesto-program@cptIt356.6,
_DEFINITION:
Html_koncesto_program is a web_browser and an editor I use to write and display html_koncestos.
[KasNik, 2008-01-23]
name::
* McsEngl.HtmlMgr@cptIt356i,
_ADDRESS.WPG:
* http://htmlmgr.sourceforge.net
* https://sourceforge.net/projects/htmlmgr/
* LocDoc proposal:
- http://lists.w3.org/Archives/Public/public-html-comments/2010May/0027.html
* TabKit Forum: http://tabkit.uservoice.com/forums/9546-general
name::
* McsEngl.Mcsm.WikiWorldview (2011)@cptIt,
* McsEngl.conceptIt356.9,
* McsEngl.wcp@cptIt356.9, {2011-12-26}
* McsEngl.wcpt@cptIt356.9,
* McsEngl.WikiCbs@cptIt356.9, {2011-12-04}
* McsEngl.WikiCpt@cptIt356.9, {2011-12-04}
* McsEngl.WikiConcept@cptIt356.9,
* McsEngl.WikiConceptProgram@cptIt356.9, {2011-12-26}
* McsEngl.wikiWorldview-program@cptIt356.9, {2012-01-27}
* McsEngl.ww@cptIt356.9, {2012-01-27}
_DESCRIPTION:
A CbsMgr program derived from MediaWiki.
[hmnSngo.2011-11-30]
name::
* McsEngl.ww'CBS@cptIt,
* McsEngl.cbs-wikiconcept@cptIt,
* McsEngl.wcp'concept@cptIt,
* McsEngl.wcp'CBS@cptIt,
* McsEngl.ww'concept@cptIt, {2012-02-05}
* McsEngl.ww'cpt@cptIt, {2012-02-05}
_GENERIC:
* html-cbs#ql:cbs.html###
* CBS#ql:cbsmgr'cbs#
_DESCRIPTION:
FROM every concept, the user must find ALL the related concept.
[hmnSngo.2011-12-04]
name::
* McsEngl.ww'cpt'Attribute@cptIt,
* McsEngl.wcp'concept'Attribute@cptIt,
* McsEngl.wcp'attribute@cptIt,
_Notation:
* generic.specific.specific...
* whole/part/part/.../
[hmnSngo.2012-02-07]
name::
* McsEngl.wcp'concept'Creating@cptIt,
* McsEngl.wcp'creating-concept@cptIt,
_Method1, address-bar:
* on address-bar write a new "name" and then content.
_method2, extension:
* CreateAPage#ql:mw'extension.cre*#,
* MakeArticle,
name::
* McsEngl.wcp'concept'Definition@cptIt,
* McsEngl.wcp'Definition@cptIt,
_DEFINITION:
Definition is the ATTRIBUTES#ql:wcp'attribute# that UNIQUELY distiquishes a cbs from others.
[hmnSngo.2012-01-16]
===
It is the "text" that uniquely distiguishes a cbs from others.
or
The "relations" that uniquely distiguishes a cbs from others.
[hmnSngo.2012-01-16]
name::
* McsEngl.wcp'concept'Term@cptIt,
* McsEngl.wcp'Term@cptIt,
_Method1, wikitext:
- creates a new page with the wikitext:
#REDIRECT [[Joannina]]
name::
* McsEngl.wcp'Content-Building@cptIt,
* McsEngl.wcp'building-knowledge@cptIt,
* McsEngl.wcp'Content-Storing@cptIt,
name::
* McsEngl.wcp'Content-Retrieving@cptIt,
* McsEngl.wcp'reading@cptIt,
_GENERIC:
* using#ql:wcp'using#
_DESCRIPTION:
With the http://www.mediawiki.org/wiki/Extension:Lingo extension, we can show the defintion (info) of a term in a sentence, just hovering.
[hmnSngo.2011-12-12]
===
On every term, in a text, by hovering to show an overview AND a link to this concept if we want to go there.
[hmnSngo.2011-12-13]
name::
* McsEngl.ww'Data@cptIt,
* McsEngl.wcp'Data@cptIt,
* McsEngl.wcp'data-content@cptIt,
_GENERIC:
* cbsmgr-data#ql:cbsmgr'data.list#
_SPECIFIC:
* endUser-data#ql:ww'enduser_data#,
* programer-data,
===
* Attribute#ql:wcp'attribute#,
* Attribute-definition#ql:wcp'definition#,
* Attribute-term#ql:wcp'term#,
* CBS#ql:wcp'cbs#,
* Collection,
* Measure,
* Measure-number,
* Measure--Unit-of-measurement,
* Text,
* Time,
name::
* McsEngl.wcp'Collection-term@cptIt,
Every concept has "collection-term", synonyms, translations and parts-of-speech.
[hmnSngo.2011-12-29]
name::
* McsEngl.wcp'Measure@cptIt,
_DESCRIPTION: "Quantity" is "some|many" of a concept.
name::
* McsEngl.wcp'Text@cptIt,
_Text_disambiguating:
We can use, hidden markup on every text's-term with a link to term's-concept. This way IF we have stored every concept we use in different worldviews, we can write text without ambiguation. This will incease communication, collaboration, consistency, aggreement.
For example:
<span id="idTerm">
<span id="idTermInstance">
Worldview
</span>
<span id="idTermConcept">
ShortDesc: Point of view of the world
<br/><a href="target">Name-of-concept</a>
</span>
</span>
The content of idTermConcept can be poped-up when a user is hovering the term.
[hmnSngo.2011-12-18]
===
When an author writes text, the program automatically must markup the terms from HIS worldview.
- IF a term does not exist in his worldview, the program automatically will search the worldview of the language he is writing.
- The author must have the ability to choose and change from which worldview the program will markup his terms.
[hmnSngo.2011-12-19]
name::
* McsEngl.ww'Database@cptIt,
* McsEngl.wcp'database@cptIt,
name::
* McsEngl.wcp'table.Term-english@cptIt,
_Field:
* term_expression:
* term_type:
* term_concept:
* term_name:
<TRMNL TxEXP="called" TRMNLtYPE="trmVrb3" XCPT="Naming@hknu.symb-17@" NAME="call"/>
name::
* McsEngl.ww'Doing@cptIt,
name::
* McsEngl.ww'Inferencing@cptIt,
* McsEngl.ww'computing@cptIt,
_GENERIC:
* cbsmgr-inferencing#ql:cbsmgr'inferencing#
_DESCRIPTION:
It must store the MINIMUM info and computes the MOST.
[hmnSngo.2012-02-08]
name::
* McsEngl.ww'Extension@cptIt,
* McsEngl.wcp'extension@cptIt,
name::
* McsEngl.ww'KnowledgeBase@cptIt,
* McsEngl.wcp'content@cptIt,
* McsEngl.wcp'KnowledgeBase@cptIt,
* McsEngl.ww'EndUser-data@cptIt,
name::
* McsEngl.ww'Program@cptIt,
name::
* McsEngl.ww'Code@cptIt,
* McsEngl.wcp'code@cptIt,
* McsEngl.wcp'code-program@cptIt,
name::
* McsEngl.ww'Site@cptIt,
* McsEngl.wcp'site@cptIt,
* McsEngl.wcs@cptIt356.9i, {2011-12-26}
* McsEngl.wikiConceptSite@cptIt356.9i, {2011-12-26}
* McsEngl.wiki-concept-site@cptIt356.9i, {2011-12-26}
* McsEngl.ww'application@cptIt,
* McsEngl.ww'WebSite@cptIt, {2012-02-05}
_GENERIC:
* webprg-app#ql:prgweb'site#
name::
* McsEngl.ww'Using@cptIt,
* McsEngl.wcp'using@cptIt,
_SPECIFIC:
* retrieving#ql:wcp'content_retrieving#,
* storing#ql:wcp'content_storing#
name::
* McsEngl.ww'Worldview@cptIt,
* McsEngl.ww'namespace@cptIt,
_Notation:
* /worldview/subwv/number/conceptName, 2012-02-06,
* conceptName@worldview/subwv/number/, 2012-02-06,
===
* /worldview/subwv/number/conceptName, 2012-02-04,
* conceptName/worldview/subwv/number/, 2012-02-04,
===
* like file notation which denotes a whole/part relation: 2012-02-03,
* /worldview/subwv/number/conceptName, 2012-02-03,
- the firs / denotes we talk about worldview.
* conceptName@worldview/subwv/number@, 2012-02-03,
===
* worldview:subwv:concept-number
* concept@worldview:subwv-number
name::
* McsEngl.ww'Evolution@cptIt,
_2012-01-27: ww
I chose the abbreviation "ww" (WikiWorldview) as better than "wc" (WikiConcept) for the project.
- google gives About 780,000,000 results (0.20 seconds) today for "ww".
AND 99 results (0.21 seconds) for [WikiWorldview].
AND About 73 results (0.32 seconds) for ["WikiWorldview"]
---
WW
From Wikipedia, the free encyclopedia
The letters WW may refer to:
"World Wide"
Bmibaby IATA airline code
Watson Wyatt Worldwide NYSE identifier
Winchester and Western Railroad reporting mark
Waterworks (disambiguation)
Weather watch
William H. Webster, a director of the FBI and CIA, referred to in the Kryptos sculpture as "WW"
Weight Watchers
White widow
an abbreviation for whitewater in the International Scale of River Difficulty
Woodrow Wilson, the 28th President of the United States of America
Woodwind instrument
World war, a term for a military conflict affecting the majority of the world
Writers Workshop in Calcutta, India
"Wrong word" in proofreading
the code for Wicklow, Ireland
In entertainment:
Washington Wizards, an NBA basketball team
Wayne's World
The West Wing, a television series
Wonder Woman
World Wrestling Entertainment, an organisation whose logo appears as WW
The Wubbulous World of Dr. Seuss, a television series
WW (album), a 2005 album by the Norwegian metal group Gehenna
In video games:
Animal Crossing: Wild World
The Legend of Zelda: The Wind Waker
Prince of Persia: Warrior Within
WarioWare (series)
Wario World
[http://en.wikipedia.org/wiki/WW] 2012-01-27
_2011-11-30:
Created this concept. I chose MediaWiki as the program which I have to study, to build my theroy.
_CREATED: {1998-08-09} _LastModified: {1999-01-10}
name::
* McsEngl.Mcsm.LONG-TERM@cptIt,
* McsEngl.conceptIt519,
* McsEngl.long-term-SCS@cptIt,
* McsEngl.long-term-science-support-system@cptIt,
* McsEngl.scs.long'term@cptIt519,
* McsEngl.sss3@cptIt519,
Με αυτό το πρόγραμμα
θα γινει το ΜΕΛΟΝΤΙΚΟ συστημα ΔΟΜΗΜΕΝΗΣ-ΠΛΗΡΟΦΟΡΙΑΣ.
SSS is an 'electronic-book-program#cptIt327#'
SSS will be the computer-system which will help to integrate the human knowledge.
The system will be the TOOL to create the integrated-concept-system (ICS).
Also the system will be the TOOL for further improvment of the ICS.
At the same time autoimprovement of the system will be one of its features.
[Nikos, Nov 1993]
SSS does not create science by itself. It can't. It is a tool for the scientist to create science. And this science will be better than the present one. It will be more comlex and more consistent.
[NIKOS, March 1991]
SSS: support the evolution of a science. An example is my dbase system.
[NIKOS, AUG. 30, 1990]
ΟΠΟΙΟΣΔΗΠΟΤΕ, Σ'ΟΛΟ ΤΟΝ ΚΟΣΜΟ, ΜΕ ΕΝΑ ΚΟΜΠΙΟΥΤΕΡ ΘΑ ΜΠΟΡΕΙ ΝΑ ΕΧΕΙ ΠΡΟΣΒΑΣΗ ΣΤΟ ΣΥΣΤΗΜΑ.
[ΝΙΚΟΣ, ΝΟΕΜ 1993]
ICS (Integrated Concept System) will be the knowledge-base of the sss.
[nikos, 1998aug09]
Of course, the goal of SSS is the construction of the information structure of all sciences.
[NIKOS, JUNE 1991]
Το σύστημα αυτο ΘΑ χρησιμοποιηθεί για τη δημιουργία του μελλοντικου ΔΟΜΗΜΕΝΟΥ-ΣΥΣΤΗΜΑΤΟΣ-ΠΛΗΡΟΦΟΡΙΩΝ
[ΝΙΚΟΣ, ΝΟΕΜ. 1994]
name::
* McsEngl.sss3-CONCEPT'NAME@cptIt,
The notation below will facilitate formal-reading:
Hard-Disk: a name with two words.
Hard-Disk'Capacity: Capacity is attribute of Hard Disk.
Hard-Disk.Removable: Removable Hard Disk is subgeneral concept of Hard Disk.
[Nikos, 1999jan10]
ΤΟ ΣΥΣΤΗΜΑ ΘΑ ΕΚΤΕΛΕΙ "ΝΟΗΤΙΚΕΣ ΕΡΓΑΣΙΕΣ". ΓΙΑΥΤΟ ΟΠΩΣΔΗΠΟΤΕ ΘΑ ΕΧΕΙ ΕΣΩΤΕΡΙΚΑ ΜΙΑ ΜΟΡΦΗ "ΑΝΑΠΑΡΑΣΤΑΣΗΣ ΣΗΜΑΣΙΩΝ" ΑΝΕΞΑΡΤΗΤΗ ΑΠΟ ΦΥΣΙΚΗ-ΓΛΩΣΣΑ.
[ΝΙΚΟΣ, ΝΟΕΜ 1993]
Because information is something subjective, the system must present the CONTRADICTIONS in knowledge.
[NIKOS, MARCH 1991]
name::
* McsEngl.sss3-ADDING'CONCEPT@cptIt,
The system must guarantee that, when someone register a concept, this concept will not conflict with ALL the existing concepts.
[NIKOS, 1997apr]
name::
* McsEngl.sss3-CHANGE'CONCEPT'S'NAME@cptIt,
Τhe system must have the ability to automatically change a concepts'name in all of its uses.
ΠΑΡΑΔΕΙΓΜΑ:
τον απρίλιο του 1995 άλλαξα το στάνταρ όνομα της 'ΔΟΜΗΜΕΝΗΣ ΠΛΗΡΟΦΟΡΙΑΣ' σε 'ΔΟΜΗΜΕΝΗ ΕΝΝΟΙΑ'. Το σύστημα έπρεπε να έχει τη δυνατότητα να αλλάξει σε όλες τις πληροφορίες ΜΟΥ που χρησιμοποίησα το όνομα δομημένη-πληροφορία σε δομημένη έννοια.
[hmnSngo.1995-03]
name::
* McsEngl.sss3-integrity@cptIt,
Modifications in the KB must leave it consistent.
- truth maintenance
INCONSISTENCIES:
- redundant pieces of knowledge
- similar
- misspelling
[nikos, {1998-04-22}]
1. CONCEPT UNIQUENESS.
The system must ensure that every concept is stored once.
[1998may12]
2. PART-WHOLE CONSISTENCY.
** The system must find the concept which is and part and whole of another one.
[1998may12]
** IF concept1 is part of concept2 THEN concept2 is whole of concept1. 1998aug14
3. GENERAL-SPECIFIC CONSISTENCY.
[1998may12]
** A concrete-concept cannot have subgeneral concepts. 1998aug14
** All the partitions of a concept have the same referents. 1998aug14
** The system must find missing siblings. 1998aug14
** IF concept1 is subgeneral of concept2 THEN concept2 is general of concept1. 1998aug14
4. OPPOSITE CONSISTENCY.
IF a concept is opposite of another, THEN the other is opposite of this one.
[nikos, 1998aug13]
5. CONCEPT INCOPLETNESS.
The system must find the places where concepts are missing (they were not defined).
[nikos, 1998aug13]
name::
* McsEngl.sss3-CREATING/EDITING CONCEPT'S ATTRIBUTES@cptIt,
Με τη δημιουργία μερικής/subgeneral εννοιας, το σύστημα αυτόματα να δίνει τα χαρακτηριστικά που έχει η γενικη/general έννοια.
ΚΑΘΕ ΜΕΤΑΒΟΛΗ ΣΤΑ ΧΑΡΑΚΤΗΡΙΣΤΙΚΑ ΜΙΑΣ "ΓΕΝΙΚΗΣ" ΕΝΝΟΙΑΣ, ΤΟ ΣΥΣΤΗΜΑ ΑΥΤΟΜΑΤΑ ΘΑ ΚΑΝΕΙ ΑΥΤΕΣ ΤΙΣ ΑΛΛΑΓΕΣ ΚΑΙ ΣΕ ΟΛΕΣ ΤΙΣ "ΥΠΟΓΕΝΙΚΕΣ" ΕΝΝΟΙΕΣ και αντίστροφα.
ΤΟ ΣΥΣΤΗΜΑ ΑΠΟ ΚΑΤΑΣΚΕΥΗΣ ΘΑ ΕΧΕΙ ΜΗΧΑΝΙΣΜΟΥΣ ΠΟΥ ΘΑ ΒΟΗΘΟΥΝ ΣΤΗΝ ΕΞΕΛΙΚΗ ΤΟΥ ΟΛΟΚΛΗΡΩΜΕΝΟΥ ΕΝΝΟΙΑΚΟΥ ΣΥΣΤΗΜΑΤΟΣ.
[ΝΙΚΟΣ, ΝΟΕΜ 1993]
It must have a CONTINOUS updating mechanism.
[NIKOS, MARCH 1991]
name::
* McsEngl.sss3-INFORMATION'RETRIEVAL (REPRESENTATION)@cptIt,
AΝΑΖΗΤΗΣΗ:
- ΚΑΘΕ ΛΕΞΗΣ.
- ΣΗΜΑΣΙΑΚΟ ΨΑΞΙΜΟ.
- ΠΕΡΙΕΧΟΜΕΝΑ.
name::
* McsEngl.sss3-ABSTRACT'LEVELS@cptIt,
** το σχεσιακό περιεχόμενο εννοιων να υπαρχει σε διαφορετικα επίπεδα αφαιρεσης για να δινει πιο γρήγορα τη γενική εικόνα.
** να έχει ιστορία εξέλιξης του θέματος, σε επίπεδα αφαίρεσης.
name::
* McsEngl.sss3-CONCEPT'DISPLAY@cptIt,
DYNAMIC LAYOUT OF CONCEPTS:
The SAME entity,
- to have an ATTRIBUTE'LAYOUT when we look at the concept where the entity is an attribute and
- to have a CONCEPT'LAYOUT when we look at the entity as a concept.
[NIKOS, 1997aug]
name::
* McsEngl.sss3-CONCEPT'EVOLUTION@cptIt,
The system must display the evolution of a concept:
** referent evolution (if referent and meaning are clearly different)
** concept evolution (who first conceived the idea etc.)
** evolution in abstract-levels.
[nikos, 1998aug09]
name::
* McsEngl.sss3-GRAFICAL'REPRESENTATION OF KB@cptIt,
Ενα άλλο βασικό χαρακτηριστικό που πρέπει να έχει το σύστημα είναι να μπορεί να παρουσιάζει ΓΡΑΦΙΚΑ τη δομή του εννοιακού συστήματος σε επίπεδα αφαίρεσης.
name::
* McsEngl.sss3-MEANINGFULL'INFORMATION'RETRIEVAL@cptIt,
Σημασιολογικό ψάξιμο σημαίνει να ψάχνει για μία ΣΗΜΑΣΙΑ, με όλα τα ονόματα που εμφανίζεται αυτή η σημασία.
Να μπορεί να ψάχνει για μια ΓΕΝΙΚΗ-ΠΛΗΡΟΦΟΡΙΑ και για όλες τις ΜΕΡΙΚΕΣ-ΤΗΣ.
[hmnSngo.1995-01]
πρέπει να διαβάζεται σειριακά όπως και ένα χάρτινο βιβλίο.
να έχει ΑΛΦΑΒΗΤΙΚΟ ΕΥΡΕΤΗΡΙΟ ΕΝΝΟΙΩΝ, με συνδέσεις στις αντίστοιχες έννοιες. Δεν είναι άσχημο να υπάρχουν και οι γεννήτορες έννοιες κάθε μιας.
FOLIO: Η σύνδεση οδηγεί σε παράθυρο που πάντα στη αρχή έχει τη σχέση της έννοιας με άλλες υποσύνολά της. Μετα ακολουθεί η σχετική πληροφορία.
Πάντα στη αρχή αρχή του παράθυρου υπάρχει σύνδεση στις γονικές έννοιες. Ενας μη αυτόματος τροπος δημιουργείας αμφίδρομης σύνδεσης.
πρέπει να εχει ΣΧΕΣΙΑΚΟ ΠΕΡΙΕΧΟΜΕΝΟ ΕΝΝΟΙΩΝ και παντα συνδέσεις στις αντίστοιχες έννοιες.
On every statement, on every word will exist a link to the corresponding concept.
[nikos, 1998aug22]
name::
* McsEngl.sss3-RELATIONS'CREATION@cptIt,
Οταν δημιουργούμε μια έννοια, το σύστημα αυτόματα να φτιάχνει και όλες τις δυνατές συνδέσεις που συνεπάγονται απο την έννοια με όλες τις υπάρχουσες έννοιες.
[ΝΙΚΟΣ, ΙΟΥΛ. 1994]
ΠΑΡΑΔΕΙΓΜΑ1:
Στην οικονομία, για κάθε έννοια υπάρχει το χαρακτηριστικό δίκαιο. Αυτό που θέλουμε είναι το σύστημα να μπορεί να φτιάξει ΚΑΙ τις συνδέσεις εκείνες που όταν έχεις πρόσβαση στην έννοια <ΔΙΚΑΙΟ ΟΙΚΟΝΟΜΙΑΣ> να μπορείς να έχεις προσβαση και σε όλο το δίκαιο ΜΟΝΟ όλων των εννοιών.
[hmnSngo.1994-08]
name::
* McsEngl.sss3-STRUCTURING'UNSTRUCTURED'INFORMATION@cptIt,
ΤΟ ΣΥΣΤΗΜΑ ΠΡΕΠΕΙ ΑΥΤΟΜΑΤΑ ΝΑ ΠΑΙΡΝΕΙ ΚΑΠΟΙΟ ΚΕΙΜΕΝΟ ΚΑΙ ΝΑ ΤΟ ΔΟΜΕΙ ΣΥΜΦΩΝΑ ΜΕ ΤΗΝ ΗΔΗ ΥΠΑΡΧΟΥΣΑ ΑΝΤΙΠΡΟΣΩΠΕΥΣΗ, ΚΑΙ ΝΑ ΔΕΙΧΝΕΙ ΤΑ ΛΑΘΗ-ΤΟΥ.
[ΝΙΚΟΣ, ΟΚΤΩ 1993]
name::
* McsEngl.sss3-UPDATING'DATE@cptIt,
Να βάζει σε κάθε πληροφορία που προστίθεται/αλλάζει ημερομηνία. Κάτι τέτοιο έκανα στο σύστημα των ντοσιε.
[ΝΙΚΟΣ, ΙΟΥΛ. 1994]
name::
* McsEngl.sss3-INTERFACE'LANGUAGE@cptIt,
ΤΟ ΣΥΣΤΗΜΑ, ΕΠΕΙΔΗ ΘΑ ΕΧΕΙ ΚΑΠΟΙΟ ΒΑΘΜΟ ΑΝΑΠΑΡΑΣΤΑΣΗΣ ΤΗΣ ΚΑΤΑΧΩΡΗΜΕΝΗΣ ΓΝΩΣΗΣ, ΘΑ ΜΠΟΡΕΙ ΝΑ ΕΚΦΡΑΣΕΙ ΑΥΤΗ ΤΗ ΓΝΩΣΗ ΣΕ ΟΠΟΙΑΔΗΠΟΤΕ ΓΛΩΣΣΑ ΤΟΥ ΚΟΣΜΟΥ.
[ΝΙΚΟΣ, ΝΟΕΜ 1993]
Like the creation on the fly of html files, the display of concepts will be created on-the-fly and the many pieces of knowledge could be in many files in many computers.
[nikos, {1998-04-25}]
name::
* McsEngl.Mcsm.MEDIUM-NAME#cptCore93.42#@cptIt,
* McsEngl.conceptIt520,
* McsEngl.medium-term-scs@cptIt,
* McsEngl.sss2@cptIt520,
MEDIUM-TERM SCS is the SCS-KMS with a 'significant' functionality.
[nikos, 1998aug09]
name::
* McsEngl.Mcsm.REAL@cptIt,
* McsEngl.conceptIt522,
* McsEngl.real-scs@cptIt,
* McsEngl.sss1@cptIt522,
_DESCRIPTION:
SSS1 is the SCS that manages at least general and whole concept-relations,
[nikos, 1998aug13]
name::
* McsEngl.Mcsm.WEB@cptIt,
* McsEngl.conceptIt356.8,
* McsEngl.cbsmgrWeb@cptIt,
* McsEngl.conceptIt356.8,
_GENERIC:
* program-web#cptItsoft580#
name::
* McsEngl.Mcsm.HITP@cptIt,
* McsEngl.Mcsm.Hitp@cptIt,
* McsEngl.McspHitp@cptIt,
page-wholepath: https://synagonism.net / dirFolioViews / FvMcsIt / FvMcsIt2