Commit 8d79f880 authored by Leza89's avatar Leza89
Browse files

German translation for getmonero.org

main:
 - [x] translated: de.yml - Status: peer-reviewed
 - [x] translated: lang\de\ - Status: peer-reviewed
 - [x] added: "de: Deutsch in other ymls"

resources:
 * untranslated: moneropedia - some terms added to match de.yml
 * untranslated: user guides
 * untranslated:  developer guides

Special thanks to ErCiccione and rodolfo912 as well as to rbrunner7
parent 8d3986e6
---
tags: ["kovri"]
terms: ["Router-Info", "Router-infos"]
summary: "A data structure or file which contains an I2P peer's needed network information"
---
{% include untranslated.html %}
### 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"
---
{% include untranslated.html %}
### 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"
---
{% include untranslated.html %}
### 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"
---
{% include untranslated.html %}
### 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"
---
{% include untranslated.html %}
### 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"
---
{% include untranslated.html %}
### 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", "Schattenadressen", "Schattenadresse"]
summary: "automatic one-time addresses for every transaction"
---
{% include untranslated.html %}
### 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"
---
{% include untranslated.html %}
### 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"
---
{% include untranslated.html %}
### 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)"
---
{% include untranslated.html %}
### 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"
---
{% include untranslated.html %}
### 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"
---
{% include untranslated.html %}
### 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"
---
{% include untranslated.html %}
### 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"
---
{% include untranslated.html %}
### 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.
---
terms: ["wallet", "wallets"]
summary: "A wallet stores the information necessary to send and receive Monero"
---
{% include untranslated.html %}
### The Basics
A Monero account, or wallet, stores the information necessary to send and receive Moneroj. In addition to sending and receiving, the Monero Wallet software keeps a private history of your transactions and allows you to cryptographically sign messages. It also includes Monero mining software and an address book.
The term "hot wallet" describes a Monero @account which is connected to the Internet. You can send funds easily but security is much lower than a cold wallet. Never store large amounts of cryptocurrency in a hot wallet!
A cold wallet is generated on a trusted device or computer via an @airgap. If the device is to be reused, the data storage should be securely overwritten. As soon as a cold wallet is connected to the Internet or its mnemonic phrase or @spend-key is entered on an Internet-connected device, it's no longer "cold" and should be considered "hot".
A Monero @paper-wallet can be generated by downloading the source code of https://moneroaddress.org/. Verify the signature of the code on a trusted airgapped device. Create the wallet and print or store it on the media of your choice.
Monero accounts and paper-wallets can be stored on any media - paper, USB drive, CD/DVD, or a hardware wallet device (Ledger available since June 2018).
{% assign version = '1.1.0' | split: '.' %}
{% include disclaimer.html translated="false" version=page.version %}
## How to mine Monero (XMR) without a mining equipment?
If you don’t have a profitable mining equipment, nor time or
money to invest into building it, you can still mine Monero with NiceHash.
NiceHash is a hashing power marketplace. Sellers of hashing
power, i.e. miners, provide the hashing power for buyers (those who want to buy
a service of mining a certain coin). Hence, NiceHash can provide you a massive
hashing power in short amount of time. You won’t have to wait for years to see
if you will make a profit or not and you can control which coin, at which pool,
and for how long you want to mine.
### **Step 1:** Create new account at NiceHash
Visit [registration
page](https://www.nicehash.com/?p=register) and register with your e-mail address.
### **Step 2:** Deposit some Bitcoins to your account
You will mine Monero, but you can buy hashing power at
NiceHash only with Bitcoins. You can always withdraw unspent Bitcoins from your
account back to any Bitcoin wallet.
Visit your [wallet
page](https://www.nicehash.com/?p=wallet) and make a deposit. Note that the minimum price for placing an order
equals 0.01 BTC.
### **Step 3:** Find a suitable pool for mining and add it to your pool list
Selection of the pool plays a big role in the final amount
of mined cryptocurrency. Make sure the pool you have selected can handle
massive hashing rate and loads of shares, especially from a single connection.
You can find a list of Monero pools [here](https://bitcointalk.org/index.php?topic=583449.0).
Note that you will probably have to register an account at
selected pool as well. The pool will provide you with all the information you need.
You can save your favorite pools at [this page](https://www.nicehash.com/?p=managepools).
### **Step 4:** Create new order and start mining
When creating a [new order](https://www.nicehash.com/?p=orders&new), make sure you
select CryptoNightV7 algorithm for mining Monero (New algorithm variant since 2018 April the 6th). If you want to first learn more
about placing an order with NiceHash, we recommend you to read this [frequently asked question](https://www.nicehash.com/?p=faq#faqb0).
If you want to bid on
hashing power select Standard (bidding) order type and if you want a fixed
order that cannot be outbid, select Fixed order type. The status of marketplace
and approximate prices of mining can be checked at [live marketplace](https://www.nicehash.com/index.jsp?p=orders)
\ No newline at end of file
{% assign version = '1.1.0' | split: '.' %}
{% include disclaimer.html translated="false" version=page.version %}
## Operating Systems: Various versions of Linux and Windows 7, 8
### Wallet Software: Simplewallet
#### Resource for Creating Bootable Disks: [Linux](http://www.pendrivelinux.com/), [Windows](https://www.microsoft.com/en-us/download/windows-usb-dvd-download-tool)
#### Resource for Monero Binaries: [Monero Binaries](https://getmonero.org/downloads/)
- Take any computer you have lying around, even your normal workstation. You may find it easier to use an older computer that has no wifi or bluetooth if you're particularly paranoid
- Create a Linux or Windows bootable disk, and make sure you have the Monero binaries on the same disk or on a second disk (for Linux make sure you have also downloaded copies of the dependencies you will need, libboost1.55 and miniupnpc for instance)
- Disconnect the network and/or Internet cables from your computer, physically remove the wifi card or switch the wifi/bluetooth off on a laptop if possible
- Boot into your bootable OS, install the dependencies if necessary
- Copy the Monero binaries to a RAM disk (/dev/shm in Linux, Windows bootable ISOs normally have a Z: drive or something)
- Don't run the Monero daemon. Instead, using the command line, use monero-wallet-cli to create a new Monero @account
- When prompted for a name, give it any name, it doesn't really matter
- When prompted for a password, type in like 50 - 100 random characters. Don't worry that you don't know the password, just make it LONG
- **CRITICAL STEP**: Write down (on paper) your 25 word @mnemonic-seed
**WARNING**: If you forget to write down this information your funds may be lost forever
- Write down (on your phone, on paper, on another computer, wherever you want) your address and view key
- Switch off the computer, remove the battery if there is one, and leave it physically off for a few hours
The account you've created was created in RAM, and the digital files are now inaccessible. If some adversary manages to somehow obtain the data, they will lack the long password to open it. If you need to receive payments, you have your public address, and you have the view key if needed. If you need access to it, you have your 25 word @mnemonic-seed, and you can now write out several copies of it, including an offsite copy (e.g. a bank deposit box).
Credit: Riccardo Spagni
Related: [Offline Account Generator](http://moneroaddress.org/)
{% assign version = '1.1.0' | split: '.' %}
{% include disclaimer.html translated="false" version=page.version %}
# CLI Wallet/Daemon Isolation with Qubes + Whonix
With [Qubes](https://qubes-os.org) + [Whonix](https://whonix.org) you can have a Monero wallet that is without networking and running on a virtually isolated system from the Monero daemon which has all of its traffic forced over [Tor](https://torproject.org).
Qubes gives the flexibility to easily create separate VMs for different purposes. First you will create a Whonix workstation for the wallet with no networking. Next, another Whonix workstation for the daemon which will use your Whonix gateway as it's NetVM. For communication between the wallet and daemon you can make use of Qubes [qrexec](https://www.qubes-os.org/doc/qrexec3/).
This is safer than other approaches which route the wallets rpc over a Tor hidden service, or that use physical isolation but still have networking to connect to the daemon. In this way you don't need any network connection on the wallet, you preserve resources of the Tor network, and there is less latency.
## 1. [Create Whonix AppVMs](https://www.whonix.org/wiki/Qubes/Install):
+ Using a Whonix workstation template, create two workstations as follows:
- The first workstation will be used for your wallet, it will referred to as `monero-wallet-ws`. You will have `NetVM` set to `none`.
- The second workstation will be for the `monerod` daemon, it will be referred to as `monerod-ws`. You will have `NetVM` set to the Whonix gateway `sys-whonix`.
## 2. In the AppVM `monerod-ws`:
+ Download, verify, and install Monero software.
```
[email protected]:~$ curl -O "https://downloads.getmonero.org/cli/monero-linux-x64-v0.11.1.0.tar.bz2" -O "https://getmonero.org/downloads/hashes.txt"
[email protected]:~$ gpg --recv-keys BDA6BD7042B721C467A9759D7455C5E3C0CDCEB9
[email protected]:~$ gpg --verify hashes.txt
gpg: Signature made Wed 01 Nov 2017 10:01:41 AM UTC
gpg: using RSA key 0x55432DF31CCD4FCD
gpg: Good signature from "Riccardo Spagni <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: BDA6 BD70 42B7 21C4 67A9 759D 7455 C5E3 C0CD CEB9
Subkey fingerprint: 94B7 38DD 3501 32F5 ACBE EA1D 5543 2DF3 1CCD 4FCD
[email protected]:~$ echo '6581506f8a030d8d50b38744ba7144f2765c9028d18d990beb316e13655ab248 monero-linux-x64-v0.11.1.0.tar.bz2' | shasum -c
monero-linux-x64-v0.11.1.0.tar.bz2: OK
[email protected]:~$ tar xf monero-linux-x64-v0.11.1.0.tar.bz2
[email protected]:~$ sudo cp monero-v0.11.1.0/monerod /usr/local/bin/
```
+ Create a `systemd` file.
```
[email protected]:~$ sudo gedit /home/user/monerod.service
```
Paste the following contents:
```
[Unit]
Description=Monero Full Node
After=network.target
[Service]
User=user
Group=user
Type=forking
PIDFile=/home/user/.bitmonero/monerod.pid
ExecStart=/usr/local/bin/monerod --detach --data-dir=/home/user/.bitmonero \
--no-igd --pidfile=/home/user/.bitmonero/monerod.pid \
--log-file=/home/user/.bitmonero/bitmonero.log --p2p-bind-ip=127.0.0.1
Restart=always
PrivateTmp=true
[Install]
WantedBy=multi-user.target
```
+ Copy `monero-wallet-cli` executable to the `monero-wallet-ws` VM.
```
[email protected]:~$ qvm-copy-to-vm monero-wallet-ws monero-v0.11.1.0/monero-wallet-cli
```
+ Make `monerod` daemon run on startup by editing the file `/rw/config/rc.local`.
```
[email protected]:~$ sudo gedit /rw/config/rc.local
```
Add these lines to the bottom:
```
cp /home/user/monerod.service /lib/systemd/system/
systemctl start monerod.service
```
Make file executable.
```
[email protected]:~$ sudo chmod +x /rw/config/rc.local
```
+ Create rpc action file.
```
[email protected]:~$ sudo mkdir /rw/usrlocal/etc/qubes-rpc
[email protected]:~$ sudo gedit /rw/usrlocal/etc/qubes-rpc/user.monerod
```
Add this line:
```
socat STDIO TCP:localhost:18081
```
+ Shutdown `monerod-ws`.
## 3. In the AppVM `monero-wallet-ws`:
+ Move the `monero-wallet-cli` executable.
```
[email protected]:~$ sudo mv QubesIncoming/monerod-ws/monero-wallet-cli /usr/local/bin/
```
+ Edit the file `/rw/config/rc.local`.
```
[email protected]:~$ sudo gedit /rw/config/rc.local
```
Add the following line to the bottom:
```
socat TCP-LISTEN:18081,fork,bind=127.0.0.1 EXEC:"qrexec-client-vm monerod-ws user.monerod"
```
Make file executable.
```
[email protected]:~$ sudo chmod +x /rw/config/rc.local
```
+ Shutdown `monero-wallet-ws`.
## 4. In `dom0`:
+ Create the file `/etc/qubes-rpc/policy/user.monerod`:
```
[[email protected] ~]$ sudo nano /etc/qubes-rpc/policy/user.monerod
```