Commit 4d56ed05 authored by 3b7ameed's avatar 3b7ameed
Browse files

add arabic localization

parent 9fd2ea28
---
entry: "Jump Service"
tags: ["kovri"]
terms: ["Jump-Service"]
summary: "An I2P website service that adds addresses to your address book"
---
{% include untranslated.html %}
### The Basics
In your @I2P configured web browser, you can use a Jump Service to *jump* to an @I2P address that you don't have in your @address-book. Once you've *jumped* to the address, the address will be saved into your @address-book.
### In-depth Information
In an @I2P configured browser, visit: http://stats.i2p/i2p/lookup.html (courtesy of @Java-I2P's lead developer *zzz*)
Then, you'll have two options:
1. *Hostname lookup* the address you wish to visit and then manually copy/paste the result
2. *Jump* to the @I2P website by entering the @I2P hostname (**recommended**)
### Using hostname lookup
For example, entering `pinkpaste.i2p` into the *Hostname lookup* box (and then submitting) will return:
```
pinkpaste.i2p=m-HrPrIAsdxts0WM~P4mE8mt9P7g-QTaBvu7Gc6Nl0UX7Vwck-i~RvOPfK6W~kfdRvwhNTqevkBL2UF5l36We02Aiywu7kB2xOHRkze68h-Tg2ewvRVwokohguCD2G3wwAEz~7FVda2avYDCb9-N6TfuzxKLnmhPMvbNSjGL7ZsD2p-h207R3-2kvuMV9bfu-K~w9NI9XJhIyufvUnFYc2jnTVg8PbaR4UP57cNaOO2YIMPkbr6~yTcIu9B1sUfHK6-N~6virQDOxW4M-62rjnZkLpaCtkOsXslmCwZI--TkZ6hKi1kXZvNmJRE1rYfffYRFn38zhaqszeETX8HiIvahZhXF5fNumBziYdmLdw8hkuN1A~emU6Xz9g~a1Ixfsq1Qr~guYoOtaw-0rOFxNRS9yMehE-2LCb8c-cAg6z5OdlN4qJDl~ZHgru4d~EHp~BpAK3v7u2Gi-8l1ygVW-1CHVna~fwnbOPN3ANPwh6~~yUit0Cx1f54XiNRn6-nPBQAEAAcAAA==
```
Copy/paste this [email protected] pairing into your **private** @subscription.
### Directly jumping
For example, entering `pinkpaste.i2p` into the *Jump* box (and then submitting) will automatically redirect you to the website **and** insert the @locally-unique-host into @address-book.
---
entry: "Kovri"
tags: ["kovri"]
terms: ["Kovri"]
summary: "Monero's C++ router implementation of the I2P network"
---
{% include untranslated.html %}
### The Basics
[Kovri](https://github.com/monero-project/kovri/) is a C++ implementation of the @I2P network. @Kovri is currently in heavy, active development and not yet integrated with Monero. When Kovri is integrated into your Monero @node, your transactions will be more secure than ever before.
### In-depth information
Kovri will protect you and Monero from:
- @Node partitioning attacks
- Associations between a particular txid and your IP address
- Mining and/or running a node in highly adversarial environments
- Metadata leakage (e.g., @OpenAlias lookups)
...and much more.
Read [anonimal's FFS proposal](https://forum.getmonero.org/9/work-in-progress/86967/anonimal-s-kovri-full-time-development-funding-thread) for more details and for reasoning behind the project. Also read the FAQ and User Guide in the [Kovri repository](https://github.com/monero-project/kovri/).
### @Kovri / @I2P Terminology
#### Client + API
- @Address-Book
- @Base32-address
- @Base64-address
- @Canonically-unique-host
- @Eepsite (@Hidden-Service, @Garlic-Site, @Garlic-Service)
- @I2PControl
- @Jump-Service
- @Locally-unique-host
- @Reseed
- @Subscription
#### Core + Router
- @Clearnet
- @Data-Directory
- @Destination
- @Encryption
- @Floodfill
- @Garlic-Encryption
- @Garlic-Routing
- @I2NP
- @In-net
- @Java-I2P
- @Layered-Encryption
- @Lease
- @LeaseSet
- @Message @Messages
- @NTCP
- @Network-Database
- @Router-Info
- @SSU
- @Transports
- @Tunnel
---
entry: "Lease-Set"
tags: ["kovri"]
terms: ["LeaseSet", "LeaseSets"]
summary: "Contains all currently authorized Leases for a particular I2P Destination"
---
{% include untranslated.html %}
### The Basics
A Lease-Set contains a set of authorized @leases (and other related information) for a particular @destination.
### In-depth information
A Lease-Set contains:
- all of the currently authorized @leases for a particular @destination
- the public key to which garlic messages can be encrypted (see @garlic-routing)
- the signing public key that can be used to revoke this particular version of the structure
The Lease-Set is one of the two structures stored in the @network-database (the other being @router-info), and is keyed under the SHA256 of the contained @destination.
### Notes
For further details, read @Java-I2P's [LeaseSet](https://geti2p.net/en/docs/how/network-database#leaseSet)
---
entry: "Lease"
tags: ["kovri"]
terms: ["Lease", "Leases"]
summary: "Authorizes an I2P tunnel to receive messages targeting a destination"
---
{% include untranslated.html %}
### The Basics
A lease defines the authorization for a particular @I2P @tunnel to receive a @messages targeting a @destination.
### In-depth information
For further details, read @Java-I2P's [Lease](https://geti2p.net/spec/common-structures#lease)
---
entry: "Locally-unique host"
tags: ["kovri"]
terms: ["Locally-unique-host"]
summary: "A host defined by you and resolved only by you"
---
{% include untranslated.html %}
### The Basics
A locally-unique host is a [FQDN](https://en.wikipedia.org/wiki/FQDN) defined by **you** and resolved only by you; similar to how a [hosts file](https://en.wikipedia.org/wiki/etc/hosts) is implemented. Not to be confused with @canonically-unique-host.
### In-depth information
You have the option to share your interpretation of how the host is resolved (e.g., `localhost` always resolves to `127.0.0.1`) but the resolution is not canonically enforced (e.g., someone else can map `localhost` to any arbitrary IP address).
Hosts in a public subscription can be considered @canonically-unique-host's within the @I2P network but, ultimately, you are free to re-define them as you wish.
### Notes
- Monero primarily uses @canonically-unique-host resolution while @I2P only uses @locally-unique-host resolution.
- @I2P's and @Kovri's 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)
---
entry: "Message"
tags: ["kovri"]
terms: ["Message", "Messages"]
summary: "The mechanisms in which information travels within I2P"
---
{% include untranslated.html %}
### The Basics
*Messages* (which exist on top of the @transports layer), contain varying types of information that are needed for the network but, most importantly, everything you see, do, send, or receive, will come and go in the form of *messages*.
There are 2 essential types of *messages* in @I2P:
- @Tunnel messages
- @I2NP messages
Essentially: *@tunnel messages* **contain** @I2NP **message fragments** which are then [reassembled](https://geti2p.net/en/docs/tunnels/implementation) at certain points within a @tunnel's path.
### In-depth information
@I2NP messages have a close relationship with @tunnel @messages so it is easy to get the term *messages* confused when reading @Java-I2P specifications:
>
1. First, the tunnel gateway accumulates a number of I2NP messages and preprocesses them into tunnel messages for delivery.
2. Next, that gateway encrypts that preprocessed data, then forwards it to the first hop.
3. That peer, and subsequent tunnel participants, unwrap a layer of the encryption, verifying that it isn't a duplicate, then forward it on to the next peer.
4. Eventually, the tunnel messages arrive at the endpoint where the I2NP messages originally bundled by the gateway are reassembled and forwarded on as requested.
### Notes
- @I2NP @messages need to be fragmented because they are variable in size (from 0 to almost 64 KB) and @tunnel @messages are fixed-size (approximately 1 KB).
- For details and specifications, visit the [I2NP spec](https://geti2p.net/spec/i2np) and [Tunnel Message spec](https://geti2p.net/spec/tunnel-message)
---
entry: "Mining"
terms: ["mining", "miner", "miners"]
summary: "the process of cryptographically computing a mathematical proof for a block, containing a number of transactions, which is then added to the blockchain"
---
{% include untranslated.html %}
### The Basics
The process of cryptographically computing a mathematical proof for a block, containing a number of transactions, which is then added to the blockchain.
Mining is the distributed process of confirming transactions on the public ledger of all transactions, aka @blockchain. Monero nodes use the blockchain to distinguish legitimate transactions from attempts to re-spend coins that have already been spent elsewhere.
Monero is powered strictly by Proof of Work. It employs a mining algorithm that has the potential to be efficiently tasked to billions of existing devices (any modern x86 CPU and many GPUs). Monero uses the CryptoNight Proof of Work (PoW) algorithm, which is designed for use in ordinary CPUs and GPUs.
The smart mining feature allows transparent CPU mining on the user's computer, far from the de facto centralization of mining farms and pool mining, pursuing Satoshi Nakamoto's original vision of a true P2P currency.
---
entry: "Mnemonic Seed"
terms: ["mnemonic-seed", "mnemonic"]
summary: "a 13 or 25 word phrase used to backup a Monero account, available in a number of languages"
---
{% include untranslated.html %}
### The Basics
A 13 or 25 word phrase used to backup a Monero account, available in a number of languages. This 25-word phrase (13 words in the case of MyMonero) has all the information needed to view and spend funds from a Monero @account.
### In-depth Information
In the official wallet, the mnemonic seed comprises 25 words with the last word being used as a checksum. Those words correspond to a 256-bit integer, which is the account's *private* @spend-key. The *private* @view-key is derived by hashing the private spend key with Keccak-256, producing a second 256-bit integer. The corresponding *public* keys are then derived from the private keys.
By storing the 25 word mnemonic key in a secure location, you have a backup of your private keys and hence all of your Moneroj. Sharing this 25 word key is the equivalent of allowing another person complete access to your funds.
It's not a good idea to store more than you want to lose in a "hot wallet" aka a wallet which is currently or has ever been connected to the internet or loaded onto any device that has or may in the future be connected to the internet or any untrusted source!
By creating a cold, or @paper-wallet you can safely store Moneroj.
---
entry: "Network Database"
tags: ["kovri"]
terms: ["Network-Database"]
summary: "A distributed database which contains needed router information so the network can stay intact"
---
{% include untranslated.html %}
### The Basics
@network-database is a [distributed database](https://en.wikipedia.org/wiki/Distributed_database) which contains router information that peers must use so the network can stay intact.
### In-depth information
From @Java-I2P:
>
@I2P's @network-database is a specialized distributed database, containing just two types of data - router contact information (@Router-Infos) and @destination contact information (@LeaseSets). Each piece of data is signed by the appropriate party and verified by anyone who uses or stores it. In addition, the data has liveliness information within it, allowing irrelevant entries to be dropped, newer entries to replace older ones, and protection against certain classes of attack.
>
The @network-database is distributed with a simple technique called "@floodfill", where a subset of all routers, called "@floodfill routers", maintains the distributed database.
### Notes
Read [Network-Database](https://geti2p.net/en/docs/how/network-database) for details.
---
entry: "Node"
terms: ["node", "nodes", "full-node", "full-nodes"]
summary: "a device on the Internet running the Monero software, with a full copy of the Monero blockchain, actively assisting the Monero network"
---
{% include untranslated.html %}
### The Basics
A device on the Internet running the Monero software, with a full copy of the Monero blockchain, actively assisting the Monero network.
### More Information
Nodes participate in the Monero network and secure @transactions by enforcing the rules of the network. Nodes download the entire @blockchain to know what transactions have taken place. Nodes assist the network by relaying transactions to other nodes on the network. Nodes may also choose to contribute to the Monero network by participating in crafting @blocks (this is called @mining).
Mining is the process by which nodes create a block from the previously accepted block, transactions that are waiting to be processed in the transaction pool, and the @coinbase-transaction. When a node believes it has crafted a valid block it will transmit the completed block to other nodes on the network and those nodes signal agreement by working on the next block in the chain.
The rules that nodes follow are built into the Monero software; When all nodes agree about the rules to follow this is called @consensus. Consensus is necessary for a cryptocurrency because it is how the blockchain is built; If nodes don't agree about which blocks are valid, for example people who have not updated their Monero software, those nodes that don't agree will no longer be able to participate in the Monero network.
The Monero Core Team plans for a hardfork every 6 months, to occur in September and March of each year. At that time, if you are running a node it must be updated to the most recent version of the Monero software or it will no longer be able to participate in the network.
---
##### Other Resources
<sub>1. *Fluffypony gives a great explanation of why mandatory hardforks are good for Monero.* ([Monero Missives for the Week of 2016-06-20](https://getmonero.org/2016/06/20/monero-missive-for-the-week-of-2016-06-20.html))</sub>
---
entry: "NTCP"
tags: ["kovri"]
terms: ["NTCP"]
summary: "NIO-Based TCP (Non-blocking I/O based TCP): one of two Kovri transports"
---
{% include untranslated.html %}
### The Basics
*NIO-Based TCP (Non-blocking I/O based TCP)* is one of two encrypted @transports for @Kovri.
Similar to @SSU, @NTCP's *primary* purpose is to securely transmit @in-net @I2NP messages through @tunnels but, unlike @SSU, @NTCP functions solely over encrypted [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol).
### In-depth information
- Passes along individual @I2NP messages (both Standard and Time Sync) after:
- TCP has been established
- Establishment Sequence has been completed
- Uses the following @encryption:
- 2048-bit [Diffie-Hellman](https://en.wikipedia.org/wiki/Diffie-hellman)
- [AES-256](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard)/[CBC](https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation)
- Establishment Sequence has the following *states*:
- Pre-establishment
- Establishment
- Post-establishment or "Established"
- Uses the following from the @network-database:
- Transport name: NTCP
- Host: IP (IPv4 or IPv6) or host name (shortened IPv6 address (with "::") is allowed)
- Port: 1024 - 65535
### Notes
For further details, read @Java-I2P's [NTCP](https://geti2p.net/en/docs/transport/ntcp)
---
entry: "OpenAlias"
terms: ["OpenAlias"]
summary: "a standard that allows you to use an email or domain syntax to pay someone instead of an address, eg. [email protected] or donate.getmonero.org"
---
{% include untranslated.html %}
### The Basics
The Monero Core Team released a standard called OpenAlias which permits much more human-readable addresses and "squares" the Zooko's triangle. OpenAlias can be used for any cryptocurrency and is already implemented in Monero, Bitcoin (in latest Electrum versions) and HyperStake.
OpenAlias seeks to provide a way to simplify aliasing amidst a rapidly shifting technology climate. Users are trying to cross the bridge to private and cryptographically secure infrastructure and systems, but many of them have just barely started remembering the email addresses of their friends and family.
As part of the ongoing development of the Monero cryptocurrency project, we asked ourselves: how can we simplify payments for users unfamiliar with cryptocurrency? Monero stealth addresses are at least 95 characters long - memorizing them is not an option, and asking someone to send a payment to <95-character-string> is only going to lead to confusion.
At its most basic, OpenAlias is a TXT DNS record on a FQDN (fully qualified domain name). By combining this with DNS-related technologies we have created an aliasing standard that is extensible for developers, intuitive and familiar for users, and can interoperate with both centralized and decentralized domain systems.
A standard that allows you to use an email or domain syntax to pay someone instead of an address, eg. [email protected] or donate.getmonero.org.
More information can be found on the [OpenAlias page](/resources/openalias) or on the [OpenAlias website](https://openalias.org)
---
entry: "Paper Wallet"
terms: ["paperwallet", "paperwallets", "paper-wallet", "paper-wallets"]
summary: "A paper wallet stores the information necessary to send and receive Monero"
---
{% include untranslated.html %}
### The Basics
A paper wallet stores the information necessary to send and receive Monero.
---
entry: "Payment ID"
terms: ["payment-ID", "payment-IDs"]
summary: "an optional flag that is added to identify transactions to merchants, consisting of 64 hexadecimal characters"
---
{% include untranslated.html %}
### 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```
---
entry: "Pedersen Commitment"
terms: ["commitments", "commitment", "pedersen"]
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"
---
{% include untranslated.html %}
### 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.
---
entry: "Reseed"
tags: ["kovri"]
terms: ["Reseed"]
summary: "The method of which Kovri uses to bootstrap into the I2P network"
---
{% include untranslated.html %}
### 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.
---
entry: "Ring Size"
terms: ["ring-size"]
summary: "total number of possible signers in a ring signature"
---
{% include untranslated.html %}
### 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
---
entry: "Ring CT"
terms: ["ringCT", "ring-CT"]
summary: "a way to hide the amount sent in a Monero transaction"
---
{% include untranslated.html %}
### 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).
---
entry: "Ring Signature"
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"
---
{% include untranslated.html %}
### 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
---
entry: "Router-Info"
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.
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