Commit 7e66fb0c authored by Edwin den Boer's avatar Edwin den Boer Committed by luigi1111
Browse files

Dutch translation - User guides

parent 101b114d
---
tags: ["kovri"]
terms: ["Base32-address", "Base32-addresses"]
summary: "Base32 encoded hash of a Base64 address"
---
### The Basics
A Base32 address is a shortened, encoded version of an @I2P address. The Base32 address is the first part in a `.b32.i2p` hostname.
Example:
`i35yftyyb22xhcvghmev46t5knefur5v66qzekkajatwfwhyklvq.b32.i2p`
where
`i35yftyyb22xhcvghmev46t5knefur5v66qzekkajatwfwhyklvq` is the Base32 address.
### In-depth Information
Ultimately, a Base32 address is a 52 character [Base32 encoded representation](https://en.wikipedia.org/wiki/Base32) of the full SHA-256 hash of an @I2P @base64-address.
### Notes
**Note: `.b32` is not a sub-domain of `.i2p`**
---
tags: ["kovri"]
terms: ["Base64-address", "Base64-addresses"]
summary: "Base64 encoded I2P destination"
---
### The Basics
A @base64-address is a 516-character [Base64 encoded](https://en.wikipedia.org/wiki/Base64) @I2P @destination. @base64-addresses are primarily used for @address-book, @jump-service, and also internally.
Example:
```
AQZGLAMpI9Q0l0kmMj1vpJJYK3CjLp~fE3MfvE-e7KMKjI5cPOH6EN8m794uHJ6b09qM8mb9VEv1lVLEov~usVliTSXCSHuRBOCIwIOuDNU0AbVa4BpIx~2sU4TxKhoaA3zQ6VzINoduTdR2IJhPvI5xzezp7dR21CEQGGTbenDslXeQ4iLHFA2~bzp1f7etSl9T2W9RID-KH78sRQmzWnv7dbhNodMbpO6xsf1vENf6bMRzqD5vgHEHZu2aSoNuPyYxDU1eM6--61b2xp9mt1k3ud-5WvPVg89RaU9ugU5cxaHgR927lHMCAEU2Ax~zUb3DbrvgQBOTHnJEx2Fp7pOK~PnP6ylkYKQMfLROosLDXinxOoSKP0UYCh2WgIUPwE7WzJH3PiJVF0~WZ1dZ9mg00c~gzLgmkOxe1NpFRNg6XzoARivNVB5NuWqNxr5WKWMLBGQ9YHvHO1OHhUJTowb9X90BhtHnLK2AHwO6fV-iHWxRJyDabhSMj1kuYpVUBQAEAAcAAA==
```
### In-depth Information
See @destination for details behind @base64-address
---
terms: ["block", "blocks"]
summary: "a container of transactions, a sequence of which forms a blockchain"
---
### The Basics
A block is a container of @transactions, with a new block being added to the @blockchain once every 2 minutes (see constant `DIFFICULTY_TARGET_V2` defined as 120 seconds), on average.
Blocks also contain a special type of transaction, the @coinbase-transaction, which add newly created Monero to the network.
Blocks are created through the process of @mining, and the @node that successfully mines the block then broadcasts it to each of the @nodes connected to it, who subsequently re-broadcast the block until the entire Monero network has received it.
Fake or bad blocks generally cannot be created, as @nodes that receive blocks always verify the @transactions they contain against a set of consensus rules that all nodes adhere to, including validating the cryptographic @signatures on each transaction.
---
terms: ["blockchain", "blockchains"]
summary: "a distributed ledger of all transactions both past and present, without revealing who the funds came from or went to"
---
### The Basics
A @blockchain is a distributed database that continuously grows with a record of all of the transactions that have occurred with a given cryptocurrency. This database is often referred to as a ledger because the data contains a large list of transactions that have taken place. In Monero, these transactions are packaged together into 'blocks' every 2 minutes (on average), and all miners and nodes on the network have copies of these blocks.
### Monero's @Blockchain
Unlike Bitcoin and other cryptocurrencies, transactions in the Monero @blockchain do not reveal where funds came from or went to, providing anonymity and making the currency completely @fungible. Additionally, the amounts of all transactions are hidden by @RingCT, a feature of Monero. For auditing or other transparency purposes a user can share a @view-key to prove they control certain amounts of Moneroj.
---
terms: ["bootstrap-node", "bootstrap-nodes"]
summary: "A node to which a daemon connects to give immediate usability to wallets while syncing"
---
### The Basics
The daemon running on a local @node has to sync with other (remote) @nodes. While it is not fully synced, @wallet may still be connected to the local node. Therefore, the @wallet cannot access the @blocks that are bot yet synced on the local @node.
To allow the @wallet to be immediately usable, the daemon on the local @node uses a bootstrap node to which the RPC request are proxying to, giving access to the missing @blocks.
Note: the replies from the bootstrap node may be untrustworthy.
---
terms: ["bulletproofs", "bulletproof"]
summary: "a new kind of range proofs replacing RingCT in transactions to obfuscate the amounts sent"
---
### The Basics
@RingCT was introduced to obfuscate transaction amounts. One goal of @RingCT was to prove the sum of inputs - outputs in the @transaction was equal to 0, and all outputs were positive numbers.
To accomplish this, two kind of ring signatures were constructed: One ring signature for the whole transaction (to prove the sum is 0), and a set of ring signatures for the subsets of transaction bits (to prove the outputs are positive numbers), then combined together using originally Schnorr signatures (and later replaced by Borromean ring signature).
While it was doing the job, a big drawback was the huge size of such a ringCT transaction.
### Where it comes to bulletproofs
Back in 2017, a [Standford applied crypto group](https://crypto.stanford.edu/bulletproofs/) wrote a [paper](https://eprint.iacr.org/2017/1066.pdf) presenting a new kind of range proofs, called bulletproofs.
> Bulletproofs are short non-interactive zero-knowledge proofs that require no trusted setup.
Bulletproofs, unlike Borromean or Schnorr signatures, are very efficient as range proofs. Proving a big set of data only generates a small proof, and the size of this proofs grows logarithmically with the size of the data being proved.
It means that increasing the number of outputs in a transaction will, with bulletproofs only slightly increase the size of the proof.
Bulletproofs also have the advantage to allow to prove that multiple committed amounts are in the desired range at once. No need to prove each output to each destination in separate proofs; the whole transaction amounts could be proven in one bigger (but still very small) bulletproof.
### Thorough audit process and implementation
As bulletproofs were really new, and the initial implementation made by the group, while thoroughly done, needed a rewrite focused on our specific use-case, implementing bulletproof in Monero was not a simple thing.
The code has been written and rewritten to follow the new version of bulletproofs which was still being developed, but once this Monero implementation was finalized, the resulting deployment should be taken with extreme care.
Therefore, the community started an auditing process. Researchers reached out to Benedikt Bünz, lead author of the Bulletproofs paper, and to [OSTIF](https://ostif.org/) an organization which helps open source technologies to improve and secure themselves.
OSTIF directed the group to several organizations with the skills required to perform the audit. While one of them asked to be kept unnamed and was therefore put away from the process that needed to be public, two others (QuarksLab & Kudelski Security) were choosen to conduct the audit.
Our 3 auditors were funded by the community to check out the if the implementation did not did not contain critical bugs, and if it did not have any exploits.
The final reports were released during the summer of 2018, with several useful corrections and fixes suggested, and the final bulletproof implementation has been added first to Monero Stagenet, and then to the main Monero network during the October 2018 network upgrade.
Since the bulletproofs deployment, the size of an average transaction has dropped by at least 80%, as well as the transaction fees.
More explanations on Monero's implementation of bulletproofs could be found on youtube fondajo channel in a [conversation with Sarang Noether](https://www.youtube.com/watch?v=6lEWqIMLzUU).
---
tags: ["kovri"]
terms: ["Canonically-unique-host"]
summary: "A host that is canonically resolved to an address or set of addresses"
---
### The Basics
A Canonically-unique host is a [FQDN](https://en.wikipedia.org/wiki/FQDN) that will canonically resolve to a designated address or set of addresses. Not to be confused with a @locally-unique-host.
### In-depth information
A Canonically-unique host is defined by remote authoritative sources; usually through [DNS](https://en.wikipedia.org/wiki/DNS). When resolving a peer's hostname, you will most likely use an external source for resolution unless you have the following implemented:
- a database file similar to a [hosts file](https://en.wikipedia.org/wiki/Hosts_(file))
- an internal-network resolver (which eventually pulls from external sources)
### Notes
- Monero primarily uses @canonically-unique-host resolution while @I2P only uses @locally-unique-host resolution.
- @I2P's and @Kovri's self-assigned top-level domain is currently `.i2p` and @Kovri intends to only process/use the `.i2p` [top-level domain](https://en.wikipedia.org/wiki/Top_level_domain)
---
terms: ["change"]
summary: "Monero sent as part of a transaction, that returns to your account instead of going to another recipient"
---
### The Basics
Monero sent as part of a transaction, that returns to your account instead of going to another recipient.
### More Information
The @wallet in the Monero software makes change automatically, but when you send a transaction, you are taking an input that you control and telling the Monero network what to do with it. The input is a "deposit" to your account that you are able to spend. Outputs are the part of the transaction that tells the Monero network where to send the funds.
You might have multiple inputs in your account, in many different denominations (For example: you deposited 0.5 XMR on Friday, and 0.75 XMR on Saturday). So, when have a transaction with an input of 0.5 XMR, but you only want to send 0.1 XMR, your transaction will include a fee to pay the @miner, an output for 0.1 XMR to send to the recipient, and the rest that you want to send back to yourself will be an output back to you (this is called "change"). Once the transaction is completed, the change becomes available to you as an input that you can again split and send with a new transaction.
---
tags: ["kovri"]
terms: ["Clearnet"]
summary: "The Internet in which anonymous overlay networks are built upon"
---
### The Basics
When you use the Internet for things like news, email, social media, and even Monero, you are most likely using a clearnet connection. This means that *all* of your connections can be tracked, traced, and monitored by:
- your [ISP](https://en.wikipedia.org/wiki/ISP)
- the website/service/person you're communicating with
- possibly a [Five Eyes](https://en.wikipedia.org/wiki/5_Eyes) capable entity
and even if you use [HTTPS](https://en.wikipedia.org/wiki/HTTPS) or similar (which *encrypts* your transmission), your route is not hidden nor is it anonymous, thus; it is in the *clear*.
### In-depth information
Since a traditional [VPN](https://en.wikipedia.org/wiki/VPN) cannot save you from clearnet (as you are still using *clearnet* (though you are more proxied than without a VPN)), you should use an *anonymous overlay network* to avoid using clearnet directly:
- @Kovri
- @Java-I2P
- [Tor](https://torproject.org/)
These technologies protect you from clearnet by building an anonymous network **over** clearnet to keep your transmissions both encrypted **and** anonymous.
Here is an accurate, [interactive diagram](https://www.eff.org/pages/tor-and-https) provided by the [EFF](https://www.eff.org/) which describes *clearnet* as it relates to **Tor**. The concept also (somewhat) applies to @Kovri and @I2P in terms of anonymity with the exception that:
- @Kovri does not use exit nodes when connecting to an @eepsite
- Your traffic never need to leave the @I2P network
- You do not need HTTPS to use @Kovri (with the exception of @reseed)
---
terms: ["coinbase-transaction"]
summary: "a special type of transaction included in each block, which contains a small amount of Monero sent to the miner as a reward for their mining work"
---
### The Basics
A special type of transaction included in each block, which contains a small amount of Monero sent to the miner as a reward for their mining work.
\ No newline at end of file
---
terms: ["consensus", "consensus-network"]
summary: "consensus describes a property of distributed networks like Monero where most of the participants follow the rules, and thus reject bad participants"
---
### The Basics
Consensus describes a property of distributed networks like Monero where most of the participants follow the rules, and thus reject bad participants.
\ No newline at end of file
---
terms: ["cryptocurrency", "cryptocurrencies", "altcoin", "altcoins"]
summary: "a digital currency in which encryption techniques are used to regulate the generation of units of currency and verify the transfer of funds, usually operating independently of a central bank"
---
### The Basics
A digital currency in which encryption techniques are used to regulate the generation of units of currency and verify the transfer of funds, usually operating independently of a central bank.
### More Information
Cryptocurrency is the generic term for a large set of digital assets that use encryption techniques to generate units of currency, verify the transactions, and transfer value. Generally, cryptocurrencies are considered to be decentralized. Cryptocurrency should not be confused with virtual currency which is a type of digital money that is usually controlled by its creators or developers. Some examples of virtual currency are gametime in World of Warcraft, ROBUX in Roblox, reward points programs, or Ripple, all of which can be exchanged for currency or cash value, but are not considered cryptocurrency because they are centalized and controlled/issued by a single entity.
Monero is one of many cryptocurrencies currently available. Other examples are Bitcoin, Litecoin, Dogecoin, Dash, Zcash, etc, but nearly all other cryptocurrencies lack features that make them a true money (most importantly @fungibility which is a requirement for it to be a store-of-value).
Not all cryptocurrencies operate the same, but they usually share the properties of decentralization, encryption, and the ability to send and receive transactions. Most are irreversible, pseudonymous, global, and permissionless. Most aim to be a store-of-value or be digital cash that allows you to transact.
Most cryptocurrencies (including Monero) use a distributed ledger (called a @blockchain) to keep track of previous transactions. The blockchain serves to tell other users on the network that transactions have happened. There are many different ways for cryptocurrencies to create their blockchain, and not all are the same. Monero uses proof-of-work to craft blocks, where other cryptocurrencies may use proof-of-stake or other consolidated methods.
Ultimately, cryptocurrency is an attempt to create trustless value; that is free from borders, governments, and banks. Whether that be to transact or to be digital gold is up to the users of each.
---
tags: ["kovri"]
terms: ["Data-Directory"]
summary: "Where essential kovri data for runtime is stored"
---
### The Basics
Depending on your OS, @Kovri currently stores all run-time data in the following directory:
- Linux/FreeBSD:
- `$HOME/.kovri`
- OSX:
- `$HOME/Library/Application\ Support/Kovri`
- Windows:
- `"$APPDATA"\\Kovri`
This includes all configuration files, @address-book, certificates, and resources.
---
terms: ["denominations", "subunits", "tacoshi", "piconero", "nanonero", "micronero", "millinero", "centinero", "decinero","decanero","hectonero","kilonero","meganero","giganero"]
summary: "A denomination is a proper description of a currency amount. It is oftentimes a sub-unit of the currency. For example, traditionally a cent is 1/100th of a particular unit of currency.)"
---
### The Basics
A denomination is a proper description of a currency amount. It is oftentimes a sub-unit of the currency. For example, traditionally a cent is 1/100th of a particular unit of currency.).
Monero denomination names add SI prefixes after dropping the initial "mo" for ease of use. Actually, the smallest unit of Monero is 1 piconero (0.000000000001 XMR).
### Denominations of Monero
|------------+----------+-------------------|
| Name | Base 10 | Amount |
|-----------:|:--------:| -----------------:|
| piconero | 10^-12 | 0.000000000001 |
| nanonero | 10^-9 | 0.000000001 |
| micronero | 10^-6 | 0.000001 |
| millinero | 10^-3 | 0.001 |
| centinero | 10^-2 | 0.01 |
| decinero | 10^-1 | 0.1 |
|============+==========+===================|
| **monero** | **10^0** | **1** |
|============+==========+===================|
| decanero | 10^1 | 10 |
| hectonero | 10^2 | 100 |
| kilonero | 10^3 | 1,000 |
| meganero | 10^6 | 1,000,000 |
|------------+----------+-------------------|
### In-depth Information
Support for input using SI prefixes was [added to the Monero codebase](https://github.com/monero-project/monero/pull/1826) on March 3, 2017 by [Moneromooo](https://github.com/moneromooo-monero). The smallest unit of Monero (10^-12 XMR) was originally called a tacoshi in honor of user [Tacotime](https://bitcointalk.org/index.php?action=profile;u=19270), an early Monero contributor and was later renamed for ease of use and consistancy.
### Monerod Implementation
The smallest fraction of Monero in the current monerod implementation is also known as the @atomic-unit, which is currently one piconero.
---
tags: ["kovri"]
terms: ["Destination", "Destinations"]
summary: "A in-net address that serves as a final endpoint (either local or remote)"
---
### The Basics
A @destination is the @I2P @in-net address of the final endpoint you are trying to connect to (example: an @I2P website, service, or Monero node). This can also include a *local destination* of which *other* peers need to connect to in order to make contact for communication (similar to how, in @clearnet, your IP address is given to a website when you connect so it knows *where* to send the information back to).
### In-depth Information
An @I2P destination can be encoded into a @base32-address or @base64-address. Most users will only care about @base32-addresses or a `.i2p` hostname while, internally, @Kovri / @I2P @address-book uses @base64-addresses. Ultimately, all @destinations in @I2P are 516-byte (or longer) keys:
`256-byte public key + 128-byte signing key + a null certificate = 516 bytes in Base64 representation`
Note: certificates are not used now but, if they were, the keys would be longer.
---
tags: ["kovri"]
terms: ["Eepsite", "Hidden-Service", "Garlic-Site", "Garlic-Service"]
summary: "A website or service hosted within the I2P network"
---
### The Basics
Is it [**EEP!** *(in response to the site's content)*](https://en.wikipedia.org/wiki/Onomatopoeia), or **end-to-end protocol**, or something else entirely different?
While the original definition of eepsite has been lost with time, its use-case remains: an eepsite is a website or service that is hosted within (and only accessible by) the @I2P network.
### In-depth Information
Alternate names include:
1. *Hidden Service*
- because the site/service is *hidden* within the @I2P network and can only be visited within the network
2. *Garlic Site*
- because the website utilizes @I2P's @garlic-routing technology as a means of communicating with a client
- because the service is hosted as a website and not any other type of service
3. *Garlic Service*
- because the service utilizes @I2P's @garlic-routing technology as a means of communicating with a client
- because the service is specific to services like IRC, email, or a Monero peer (but may also include websites)
### Notes
To learn how to setup an Eepsite (Hidden Service, Garlic Site, Garlic Service) visit the @Kovri [user-guide](https://gitlab.com/kovri-project/kovri-docs/blob/master/i18n/en/user_guide.md).
---
tags: ["kovri"]
terms: ["encryption", "encrypted", "encrypting", "decryption", "decrypted", "decrypting"]
summary: "The process of encoding messages or information in a way that only authorized parties can decode and read"
---
### The Basics
From [Encryption](https://en.wikipedia.org/wiki/Encryption):
>
In cryptography, encryption is the process of encoding messages or information in such a way that only authorized parties can decode and read what is sent. Encryption does not of itself prevent interception, but denies the message content to the interceptor.
### In-depth information
From [Encryption](https://en.wikipedia.org/wiki/Encryption):
>
In an encryption scheme, the intended communication information or message (referred to as *plaintext*), is encrypted using an encryption algorithm, generating ciphertext that can only be read if decrypted. For technical reasons, an encryption scheme usually uses a pseudo-random encryption key generated by an algorithm. It is in principle possible to decrypt the message without possessing the key, but, for a well-designed encryption scheme, large computational resources and skill are required. An authorized recipient can easily decrypt the message with the key provided by the originator to recipients, but not to unauthorized interceptors.
>
The purpose of encryption is to ensure that only somebody who is authorized to access data (e.g. a text message or a file), will be able to read it, using the decryption key. Somebody who is not authorized can be excluded, because he or she does not have the required key, without which it is impossible to read the encrypted information.
### Kovri
@Kovri implements various types of encryption in *at least* 4 essential capacities:
- @Reseed for bootstrapping
- @Garlic-routing: three layers of encryption (@garlic-encryption) are used to verify the secure delivery of @messages to the recipient/peer/@destination
- @Tunnel encryption: garlic messages are passed through a @tunnel and encrypted by the @tunnel gateway to the @tunnel endpoint
- @Transport layer encryption prevents the ability to decrypt @messages at the [media layer](https://en.wikipedia.org/wiki/OSI_model)
For details on the types of encryption and cryptographic @signatures used in @Kovri and @I2P, visit @Java-I2P's [Cryptography](https://geti2p.net/spec/cryptography)
---
tags: ["kovri"]
terms: ["Floodfill"]
summary: "An I2P router which maintains a distributed network-database"
---
### The Basics
By actively managing a distributed network-database, a router with *floodfill* capability has the ability to help maintain network stability and resiliancy while also being decentralized and trust-less.
### In-depth information
Though floodfill itself is a simple storage system, the technical underpinnings of floodfill as it relates to @network-database and other protocols within @I2P are much more complex. Visit the [Network Database](https://geti2p.net/en/docs/how/network-database) page for details.
---
terms: ["fluffy blocks", "fluffyblocks"]
summary: "a way of saving bandwidth when sending new blocks around the network"
---
### The Basics
A @block is made up of a header and @transactions. Fluffy Blocks only contain
a header, a list of transaction indices, and any transactions that the node
recieving the block may be missing. This saves bandwidth because nodes might
already know about most or all of the transactions in the block and they don't
need to be sent them again.
### See Also
* [BIP152 "Compact Block Relay"](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki)
* [Xthin](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/release/doc/bu-xthin-protocol.md)
---
terms: ["fungibility", "fungible"]
summary: "property of a currency whereby two units can be substituted in place of one another"
---
### The Basics
Property of a currency whereby two units can be substituted in place of one another.
Fungibility means that two units of a currency can be mutually substituted and the substituted currency is equal to another unit of the same size. For example, two $10 bills can be exchanged and they are functionally identical to any other $10 bill in circulation (although $10 bills have unique ID numbers and are therefore not completely fungible). Gold is probably a closer example of true fungibility, where any 1 oz. of gold of the same grade is worth the same as another 1 oz. of gold. Monero is fungible due to the nature of the currency which provides no way to link transactions together nor trace the history of any particular XMR. 1 XMR is functionally identical to any other 1 XMR.
Fungibility is an advantage Monero has over Bitcoin and almost every other cryptocurrency, due to the privacy inherent in the Monero @blockchain and the permanently traceable nature of the Bitcoin blockchain. With Bitcoin, any BTC can be tracked by anyone back to its creation @coinbase-transaction. Therefore, if a coin has been used for an illegal purpose in the past, this history will be contained in the @blockchain in perpetuity. This lack of fungibility means that certain businesses will be obligated to avoid accepting BTC that have been previously used for purposes which are illegal, or simply run afoul of their Terms of Service. Currently some large Bitcoin companies are blocking, suspending, or closing accounts that have received Bitcoin used in online gambling or other purposes deemed unsavory by said companies.
Monero has been built specifically to address the problem of traceability and non-fungibility inherent in other cryptocurrencies. By having completely private transactions Monero is truly fungible and there can be no blacklisting of certain XMR, while at the same time providing all the benefits of a secure, decentralized, permanent blockchain.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment