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

Dutch translation - User guides

parent 101b114d
---
terms: ["payment-ID", "payment-IDs"]
summary: "an optional flag that is added to identify transactions to merchants, consisting of 64 hexadecimal characters"
---
### The Basics
Payment ID is an **arbitrary** and **optional** transaction attachment that consists of 32 bytes (64 hexadecimal characters) or 8 bytes (in the case of integrated addresses).
The Payment ID is usually used to identify transactions to merchants and exchanges: Given the intrinsic privacy features built into Monero, where a single public address is usually used for incoming transactions, the Payment ID is especially useful to tie incoming payments with user accounts.
### Compact Payment IDs and Integrated Addresses
Since the 0.9 Hydrogen Helix version, Payment IDs can be encrypted and embedded in a payment address. The Payment IDs of this type should be 64-bits and are encrypted with a random one-time key known only to the sender and receiver.
### Creating a Payment ID
It is recommended to use the official wallet's `integrated_address` command to automatically generate Integrated Addresses that contain Compact Payment IDs. If you want to use the command line, you can generate Payment IDs as follows:
Creating a compact Payment ID for an Integrated Address:
```# openssl rand -hex 8```
Creating an old-style Payment ID:
```# openssl rand -hex 32```
---
terms: ["commitments", "commitment", "pedersen", "pedersen-commitment", "pedersen-commitments"]
summary: "Pedersen commitments are cryptographic algorythms that allow a prover to commit to a certain value without revealing it or being able to change it"
---
### The Basics
Pedersen commitments are cryptographic algorythms that allow a prover to commit to a certain value without revealing it or being able to change it.
When you spend Monero, the value of the inputs that you are spending and the value of the outputs you are sending are encrypted and opaque to everyone except the recipient of each of those outputs. Pedersen commitments allow you to send Monero without revealing the value of the transactions. Pedersen commitments also make it possible for people to verify that transactions on the blockchain are valid and not creating Monero out of thin air.
### What It Means
As long as the encrypted output amounts created, which include an output for the recipient and a change output back to the sender, and the unencrypted transaction fee is equal to the sum of the inputs that are being spent, it is a legitimate transaction and can be confirmed to not be creating Monero out of thin air.
Pedersen commitments mean that the sums can be verified as being equal, but the Monero value of each of the sums and the Monero value of the inputs and outputs individually are undeterminable. Pedersen commitments also mean that even the ratio of one input to another, or one output to another is undeterminable.
It is unclear which inputs are really being spent as the ring signature lists both the real inputs being spent and decoy inputs, therefore you don't actually know which input Pedersen commitments need to be summed. That's okay, because the @RingCT ring signature only has to prove that for one combination of the inputs the outputs are equal to the sum of the inputs. For mathematical reasons, this is impossible to forge.
### In-depth Information
See information in [Ring Confidential Transactions paper](https://eprint.iacr.org/2015/1098.pdf) by Shen Noether of the Monero Research Lab.
---
tags: ["kovri"]
terms: ["Reseed"]
summary: "The method of which Kovri uses to bootstrap into the I2P network"
---
### The Basics
When you start @Kovri for the first time (or if it's been offline for a long time), @Kovri will need a list of peers to connect to so it can [bootstrap](https://en.wikipedia.org/wiki/Bootstrap) into the @I2P network. @Kovri gets these peers from a special file stored on a reseed server. On this file are all the various pieces of information @Kovri needs in order to connect with @I2P peers.
### In-depth information
@Kovri has a list of [hard-coded](https://en.wikipedia.org/wiki/Hard-coded) reseed servers available to fetch from. These servers securely serve an [SU3](https://geti2p.net/spec/updates#su3) file (signed with a cryptographic @signature) over @clearnet with [HTTPS](https://en.wikipedia.org/wiki/HTTPS). This SU3 file contains information that's used to verify both the integrity of the file and its content.
Aside from the technical elements needed to verify and process the file, the file's main contents consist of a series of @router-info files which @Kovri and @I2P routers use to locate and communicate with other @I2P peers. These peers are then stored into a @network-database.
---
terms: ["ring-size"]
summary: "total number of possible signers in a ring signature"
---
### The Basics
Ring size refers to the total number of possible signers in a @ring-signature. If a ring size of 4 is selected for a given @transaction, this means that there are 3 foreign outputs in addition to your “real” output. A higher ring size number will typically provide more privacy than a lower number. However, reusing an odd, recognizable ring size number for transactions could possibly make transactions stand out.
`Ring size = foreign outputs + 1 (your output)`
\ No newline at end of file
---
terms: ["ringCT", "ring-CT"]
summary: "a way to hide the amount sent in a Monero transaction"
---
### The Basics
RingCT, short for Ring Confidential Transactions, is how transaction amounts are hidden in Monero.
Ring CT was implemented in block #1220516 in January 2017. After September 2017, this feature became mandatory for all transactions on the network.
RingCT introduces an improved version of @ring-signatures called "A Multi-layered Linkable Spontaneous Anonymous Group signature", which allows for hidden amounts, origins and destinations of transactions with reasonable efficiency and verifiable, trustless coin generation.
For more information, please read the creator Shen Noether's paper [here](https://eprint.iacr.org/2015/1098).
---
terms: ["ring-signature", "ring-signatures"]
summary: "a group of cryptographic signatures with at least one real participant, but no way to tell which in the group is the real one as they all appear valid"
---
### The Basics
In cryptography, a ring signature is a type of digital signature that can be performed by any member of a group of users that each have keys. Therefore, a message signed with a ring signature is endorsed by someone in a particular group of people. One of the security properties of a ring signature is that it should be computationally infeasible to determine *which* of the group members' keys was used to produce the signature.
For instance, a ring signature could be used to provide an anonymous signature from "a high-ranking White House official", without revealing which official signed the message. Ring signatures are right for this application because the anonymity of a ring signature cannot be revoked, and because the group for a ring signature can be improvised (requires no prior setup).
### Application to Monero
A ring signature makes use of your @account keys and a number of public keys (also known as outputs) pulled from the @blockchain using a triangular distribution method. Over the course of time, past outputs could be used multiple times to form possible signer participants. In a "ring" of possible signers, all ring members are equal and valid. There is no way an outside observer can tell which of the possible signers in a signature group belongs to your @account. So, ring signatures ensure that transaction outputs are untraceable. Moreover, there are no @fungibility issues with Monero given that every transaction output has plausible deniability (e.g. the network can not tell which outputs are spent or unspent).
To read how Monero gives you privacy by default (unlinkability), see @stealth-addresses.
\ No newline at end of file
---
tags: ["kovri"]
terms: ["Router-Info", "Router-infos"]
summary: "A data structure or file which contains an I2P peer's needed network information"
---
### The Basics
@Router-Info is a data structure (periodically written to a [binary file](https://en.wikipedia.org/wiki/Binary_file)) which contains all needed information to locate, identify, and communicate with an @I2P peer. @Router-Info includes IP address, router identity, other misc. technical details; is needed for @network-database and is published to @floodfill routers.
### In-depth information
In human-readable form, Router-Info may look like this:
```
Identity: [RouterIdentity:
Hash: nYZ5Qe7gQ-~QgfgJVRUG4c0JnVeVqzM~duUX1EGT1ek=
Certificate: [Certificate: type: Key certificate
Crypto type: 0
Sig type: 7 (EdDSA_SHA512_Ed25519)]
PublicKey: [PublicKey: size: 256]
SigningPublicKey: [SigningPublicKey EdDSA_SHA512_Ed25519: size: 32]
Padding: 96 bytes]
Signature: [Signature EdDSA_SHA512_Ed25519: size: 64]
Published: Sun Oct 09 01:34:59 UTC 2016
Options (5):
[caps] = [LfR]
[netId] = [2]
[netdb.knownLeaseSets] = [37]
[netdb.knownRouters] = [2435]
[router.version] = [0.9.26]
Addresses (4):
[RouterAddress:
Type: SSU
Cost: 4
Options (5):
[caps] = [BC]
[host] = [2a01:e35:8b5c:b240:71a2:6750:8d4:47fa]
[key] = [nYZ5Qe7gQ-~QgfgJVRUG4c0JnVeVqzM~duUX1EGT1ek=]
[mtu] = [1472]
[port] = [22244]]
[RouterAddress:
Type: NTCP
Cost: 9
Options (2):
[host] = [2a01:e35:8b5c:b240:71a2:6750:8d4:47fa]
[port] = [22244]]
[RouterAddress:
Type: SSU
Cost: 6
Options (4):
[caps] = [BC]
[host] = [88.181.203.36]
[key] = [nYZ5Qe7gQ-~QgfgJVRUG4c0JnVeVqzM~duUX1EGT1ek=]
[port] = [22244]]
[RouterAddress:
Type: NTCP
Cost: 11
Options (2):
[host] = [88.181.203.36]
[port] = [22244]]]
```
### Notes
For details and specification, visit @Java-I2P [Network Database](https://geti2p.net/en/docs/how/network-database) page.
---
terms: ["scalability"]
summary: "Growth potential of Monero, resources required, and methods of increasing efficiency"
---
### The Basics
Monero has no hardcoded maximum block size, which means that unlike Bitcoin it does not have a 1 MB block size limit preventing scaling. However, a block reward penalty mechanism is built into the protocol to avoid a too excessive block size increase: The new block's size (NBS) is compared to the median size M100 of the last 100 blocks. If NBS>M100, the block reward gets reduced in quadratic dependency of how much NBS exceeds M100. E.g. if NBS is [10%, 50%, 80%, 100%] greater than M100, the nominal block reward gets reduced by [1%, 25%, 64%, 100%]. Generally, blocks greater than 2*M100 are not allowed, and blocks <= 60kB are always free of any block reward penalties.
---
terms: ["signature", "signatures"]
summary: "a cryptographic method for proving ownership of a piece of information, as well as proving that the information has not been modified after being signed"
---
### The Basics
A cryptographic method for proving ownership of a piece of information, as well as proving that the information has not been modified after being signed.
\ No newline at end of file
---
terms: ["smart-mining"]
summary: "a process of having a throttled miner mine when it otherwise does not cause drawbacks"
---
### The Basics
Smart mining is the process of having a throttled @miner mine when it otherwise does not cause drawbacks.
Drawbacks include increases heat, slower machine, depleting battery, etc. The intent of smart mining is to increase network security by allowing as many people as possible to let the smart miner on all the time. For this to work, the miner must prove unobtrusive, or it will be turned off, depriving the Monero network from a little bit of security. As such, it is likely that a smart miner will mine slower than a normal miner on the same hardware.
Smart mining is available in the official CLI and GUI wallet, which are available in the [downloads page](https://getmonero.org/downloads/).
It is hoped that the relative slowness of a smart miner (especially on low-power machines) will be offset by the large amount of people running a miner for a possible "lottery win", and thus increase the Monero network security by a non trivial amount. The increased hash rate from many different sources helps keep the Monero network decentralized.
---
terms: ["spend-key", "spend-keys"]
summary: "one of the two pairs of private and public cryptographic keys that each account has, with the *private* spend key used to spend any funds in the account"
---
### The Basics
One of the two pairs of private and public cryptographic keys that each account has, with the *private* spend key used to spend any funds in the account.
### In-depth Information
The *private* spend key is a 256-bit integer that is used to sign Monero transactions. With the current deterministic key derivation method of the official wallet, the private spend key is also an alternate representation of the @mnemonic-seed. It can be used to derive all other account keys.
---
tags: ["kovri"]
terms: ["SSU"]
summary: "Secure Semi-reliable UDP: one of two Kovri transports"
---
### The Basics
*Secure Semi-reliable UDP* is one of two encrypted @transports for @Kovri.
Similar to @NTCP, @SSU's *primary* purpose is to securely transmit @in-net @I2NP messages through @tunnels but, unlike @NTCP, @SSU functions solely over encrypted [UDP](https://en.wikipedia.org/wiki/User_Datagram_Protocol).
### In-depth information
- Like @NTCP, @SSU is a connection-oriented, point-to-point data transport
- Termed *semi-reliable* because @SSU will repeatedly retransmit *unacknowledged* messages (up to maximum number then dropped)
- @SSU also provides several unique services (in addition to its function as a @transport layer):
- IP detection (local inspection or with [peer testing](https://geti2p.net/en/docs/transport/ssu#peerTesting))
- [NAT](https://en.wikipedia.org/wiki/Network_address_translation) traversal (using [introducers](https://geti2p.net/en/docs/transport/ssu#introduction))
- [Firewall](https://en.wikipedia.org/wiki/Firewall_%28computing%29) status and, if implemented, @SSU can notify @NTCP if the external address or firewall status changes
### Notes
For further details, read @Java-I2P's [SSU](https://geti2p.net/en/docs/transport/ssu)
---
terms: ["stealth-address", "stealth-addresses"]
summary: "automatic one-time addresses for every transaction"
---
### The Basics
Stealth addresses are an important part of Monero's inherent privacy. They allow and require the sender to create random one-time addresses for every @transaction on behalf of the recipient. The recipient can publish just one address, yet have all of his/her incoming payments go to unique addresses on the @blockchain, where they cannot be linked back to either the recipient's published address or any other transactions' addresses. By using stealth addresses, only the sender and receiver can determine where a payment was sent.
When you create a Monero account you’ll have a private @view-key, a private @spend-key, and a Public Address. The @spend-key is used to send payments, the @view-key is used to display incoming transactions destined for your account, and the Public Address is for receiving payments. Both the @spend-key and @view-key are used to build your Monero address. You can have a “watch only” wallet that only uses the @view-key. This feature can be used for accounting or auditing purposes but is currently unreliable due to the inability to track outgoing transactions. You can decide who can see your Monero balance by sharing your @view-key. Monero is private by default and optionally semi-transparent!
When using the Monero Wallet all this is handled by the software. Sending Monero is as easy as entering the destination address, the amount, and pressing Send. To recieve Monero, simply provide the sender your Public Address.
To learn how Monero prevents tracking history (untraceability), see @ring-signatures.
---
tags: ["kovri"]
terms: ["Subscription"]
summary: "A file used by address book which contains I2P hosts paired with I2P destinations"
---
### The Basics
A subscription is a file which contains a list of `.i2p` hosts paired with their respective @destination. Subscriptions are used by the @address-book.
### In-depth information
Similar to how a [hosts file](https://en.wikipedia.org/wiki/Hosts_(file)) can map an internet hostname to a specified address, a subscription matches a `.i2p` address to @base64-address by using the following format (no spaces allowed): `host=address`
More specifically, a subscription pairs a @locally-unique-host to @base64-address.
Example:
```
anonimal.i2p=AQZGLAMpI9Q0l0kmMj1vpJJYK3CjLp~fE3MfvE-e7KMKjI5cPOH6EN8m794uHJ6b09qM8mb9VEv1lVLEov~usVliTSXCSHuRBOCIwIOuDNU0AbVa4BpIx~2sU4TxKhoaA3zQ6VzINoduTdR2IJhPvI5xzezp7dR21CEQGGTbenDslXeQ4iLHFA2~bzp1f7etSl9T2W9RID-KH78sRQmzWnv7dbhNodMbpO6xsf1vENf6bMRzqD5vgHEHZu2aSoNuPyYxDU1eM6--61b2xp9mt1k3ud-5WvPVg89RaU9ugU5cxaHgR927lHMCAEU2Ax~zUb3DbrvgQBOTHnJEx2Fp7pOK~PnP6ylkYKQMfLROosLDXinxOoSKP0UYCh2WgIUPwE7WzJH3PiJVF0~WZ1dZ9mg00c~gzLgmkOxe1NpFRNg6XzoARivNVB5NuWqNxr5WKWMLBGQ9YHvHO1OHhUJTowb9X90BhtHnLK2AHwO6fV-iHWxRJyDabhSMj1kuYpVUBQAEAAcAAA==
```
1. `anonimal.i2p` is the @locally-unique-host
2. `=` is the separator
3. Everything that remains is the @base64-address
### Subscription types
For @Kovri, there are two types of subscription files: *public* and *private*.
A *public* subscription:
- is used when bootstrapping to use essential services (IRC, email, Monero, etc.)
- is static and is refreshed every 12 hours from Monero's @address-book server
- allows you to safely share the subscription with everyone as it is publically available (anyone who shares the same public subscription will also be able to resolve the same hostname to the same destination as you)
A *private* subscription:
- is used exclusively by you and is not shared with others unless you explicitly choose to share the file
- default file is `private_hosts.txt` in your @data-directory
### Updating a private subscription
You can use a @jump-service to manually update your private subscription. The updated subscription will then be fed into the @address-book for you to use.
### Notes
To learn how to subscribe to multiple subscriptions, see the [user-guide](https://gitlab.com/kovri-project/kovri-docs/blob/master/i18n/en/user_guide.md).
---
terms: ["Tail-Emission"]
summary: "the block reward at the end of the emission curve"
---
### The Basics
Monero block rewards will never drop to zero. Block rewards will gradually drop until tail emission commences at the end of May 2022. At this point, rewards will be fixed at 0.6 XMR per block.
### Why
Miners need an incentive to mine. Because of the dynamic blocksize, competition between @miners will cause fees to decrease. If mining is not profitable due to a high cost and low reward, miners lose their incentive and will stop mining, reducing the security of the network.
Tail emission ensures that a dynamic block size and fee market can develop.
---
terms: ["transaction", "transactions"]
summary: "a cryptographically signed container that details the transfer of Monero to a recipient (or recipients)"
---
### The Basics
A cryptographically signed container that details the transfer of Monero to a recipient (or recipients).
The parameters of a transaction contain one or more recipient addresses with corresponding amounts of funds and a @ring-size parameter that specifies the number outputs bound to the transaction. The more outputs that are used, a higher degree of obfuscation is possible, but that comes with a cost. Since a transaction gets larger with more outputs, the transaction fee will be higher.
It is possible to form a transaction offline, which offers additional privacy benefits.
A transaction can be uniquely identified with the use of an optional Transaction ID, which is usually represented by a 32-byte string (64 hexadecimal characters).
### In-depth Information
Every transaction involves two keys: a public @spend-key, and a public @view-key. The destination for an output in a transaction is actually a one-time public key computed from these two keys.
When a wallet is scanning for incoming transactions, every transaction is scanned to see if it is for "you". This only requires your private view key and your public spend key, and this check is immutable and cannot be faked. You cannot receive transactions and identify them without a corresponding private view key.
In order to spend the funds you have to compute a one-time private spend key for that output. This is almost always done automatically by the Monero Wallet software.
---
tags: ["kovri"]
terms: ["Transports", "Transport"]
summary: "The two encrypted transport layers for Kovri"
---
### The Basics
@I2P comes with two encrypted transport layer technologies that allow @Kovri to securely use [TCP/IP](https://en.wikipedia.org/wiki/Tcp/ip) connections. These technologies (@SSU and @NTCP) are called *@transports*.
### In-depth information
@SSU is encrypted [UDP](https://en.wikipedia.org/wiki/User_Datagram_Protocol) and @NTCP is encrypted [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol). They provide @encryption at the [transport layer](https://en.wikipedia.org/wiki/Transport_layer) so higher level @messages can be sent through @tunnels across the @I2P network.
### Notes
- Read about @I2P's transports on the [Transport](https://geti2p.net/en/docs/transport) page
- Read about the transports layer within the [OSI model](https://en.wikipedia.org/wiki/OSI_model)
---
tags: ["kovri"]
terms: ["Tunnel", "Tunnels"]
summary: "Uni-directional virtual paths that pass messages through a defined sequence of I2P routers"
---
### The Basics
When you communicate over @I2P (visit an @eepsite / use a @garlic-service), you'll first need to connect to a peer by using @transports and then build virtual *tunnels*. These virtual tunnels are temporary, uni-directional paths that pass information through a defined sequence of @I2P routers to your @destination. Tunnels are built, and then used, with layered @garlic-encryption and are a general-purpose mechanism to transport all @I2NP @messages.
Each peer builds, at a minimum, *two* uni-directional tunnels: one for **outbound traffic**, and one for **inbound traffic**. These tunnels are classified as either **inbound tunnels** (where @messages come toward the creator of the tunnel) or **outbound tunnels** (where the tunnel creator sends @messages away from the creator of the tunnel). Thus, *four* tunnels are required for a single round-trip @message and reply to your @destination (two for your, two for your destination).
### In-depth information
From @Java-I2P:
>
Within I2P, @messages are passed in one direction through a virtual tunnel of peers, using whatever means are available to pass the @message on to the next hop. Messages arrive at the tunnel's gateway, get bundled up and/or fragmented into fixed-size @tunnel @messages, and are forwarded on to the next hop in the tunnel, which processes and verifies the validity of the @message and sends it on to the next hop, and so on, until it reaches the @tunnel endpoint. That endpoint takes the messages bundled up by the gateway and forwards them as instructed - either to another router, to another tunnel on another router, or locally.
>
Tunnels all work the same, but can be segmented into two different groups - inbound tunnels and outbound tunnels. The inbound tunnels have an untrusted gateway which passes messages down towards the tunnel creator, which serves as the tunnel endpoint. For outbound tunnels, the tunnel creator serves as the gateway, passing messages out to the remote endpoint.
>
The tunnel's creator selects exactly which peers will participate in the tunnel, and provides each with the necessary configuration data. They may have any number of hops. It is the intent to make it hard for either participants or third parties to determine the length of a tunnel, or even for colluding participants to determine whether they are a part of the same tunnel at all (barring the situation where colluding peers are next to each other in the tunnel).
### Notes
From @Java-I2P:
>
@I2P is an inherently packet switched network, even with these tunnels, allowing it to take advantage of multiple tunnels running in parallel, increasing resilience and balancing load. Even though the tunnels within I2P bear a resemblance to a circuit switched network, everything within I2P is strictly message based - tunnels are merely accounting tricks to help organize the delivery of messages. No assumptions are made regarding reliability or ordering of messages, and retransmissions are left to higher levels (e.g. I2P's client layer streaming library).
### Documentation
For specification and detailed documentation, visit the [Tunnel-Routing](https://geti2p.net/en/docs/how/tunnel-routing) and [Tunnel-Implementation](https://geti2p.net/en/docs/tunnels/implementation) page.
---
terms: ["unlock-time"]
summary: "a special transaction where the recipient can only spend the funds after a future date, as set by the sender"
---
### The Basics
A special transaction where the recipient can only spend the funds after a future date, as set by the sender.
Unlock time allows you to send a transaction to someone, such that they can not spend it until after a certain number of blocks, or until a certain time.
Note that this works differently than Bitcoin's [nLockTime](https://en.bitcoin.it/wiki/NLockTime), in which the transaction is not valid until the given time.
---
terms: ["view-key", "view-keys"]
summary: "one of two sets of private and public cryptographic keys that each account has, with the private view key required to view all transactions related to the account"
---
### The Basics
One of two sets of private and public cryptographic keys that each account has, with the private view key required to view all transactions related to the account.
Monero features an opaque blockchain (with an explicit allowance system called the @view-key), in sharp contrast with transparent blockchains used by any other cryptocurrency not based on CryptoNote. Thus, Monero is said to be "private, optionally transparent".
Every Monero address has a private viewkey which can be shared. By sharing a viewkey, a person is allowing access to view every incoming transaction for that address. However, outgoing transactions cannot be reliably viewed as of June 2017. Therefore, the balance of a Monero address as shown via a viewkey should not be relied upon.
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