mirror of
https://github.com/monero-project/monero-site.git
synced 2024-11-16 15:58:16 +00:00
Add initial Turkish translation
This commit is contained in:
Nine Zero
erciccione
parent
b87207f315
commit
2849edd417
223 changed files with 13388 additions and 3224 deletions
|
|
@ -24,7 +24,7 @@ plugins:
|
|||
- jekyll-multiple-languages-plugin
|
||||
|
||||
# jekyll-multiple-languages-plugin settings:
|
||||
languages: ["en", "es", "it", "pl", "fr", "ar", "ru", "de", "nl", "pt-br"]
|
||||
languages: ["en", "es", "it", "pl", "fr", "ar", "ru", "de", "nl", "pt-br", "tr"]
|
||||
|
||||
|
||||
exclude_from_localizations: ["img", "css", "fonts", "media", "404", "feed.xml", "404", "meta", "forum-funding-system", "_posts", "legal"]
|
||||
|
|
|
|||
52
_data/lang/tr/footer-1.yml
Normal file
52
_data/lang/tr/footer-1.yml
Normal file
|
|
@ -0,0 +1,52 @@
|
|||
- title: Kaynaklar
|
||||
subfolderitems:
|
||||
- name: Monero Hakkında
|
||||
url: resources/about/
|
||||
- name: Moneropedi
|
||||
url: resources/moneropedia/
|
||||
- name: Geliştirici Rehberleri
|
||||
url: resources/developer-guides/
|
||||
- name: Kullanıcı Rehberleri
|
||||
url: resources/user-guides/
|
||||
- name: Kütüphane
|
||||
url: library
|
||||
- name: RSS Besleme
|
||||
url: https://getmonero.org/feed.xml
|
||||
- title: IRC Kanalları
|
||||
subfolderitems:
|
||||
- name: monero
|
||||
url: irc://chat.freenode.net/#monero
|
||||
- name: monero-dev
|
||||
url: irc://chat.freenode.net/#monero-dev
|
||||
- name: monero-markets
|
||||
url: irc://chat.freenode.net/#monero-markets
|
||||
- name: monero-pools
|
||||
url: irc://chat.freenode.net/#monero-pools
|
||||
- name: monero-community
|
||||
url: irc://chat.freenode.net/#monero-community
|
||||
- name: monero-translations
|
||||
url: irc://chat.freenode.net/#monero-translations
|
||||
- name: monero-hardware
|
||||
url: irc://chat.freenode.net/#monero-hardware
|
||||
- title: Topluluk
|
||||
subfolderitems:
|
||||
- name: Reddit
|
||||
url: https://reddit.com/r/monero
|
||||
- name: Stack Exchange
|
||||
url: https://monero.stackexchange.com/
|
||||
- name: BitcoinTalk Başlığı
|
||||
url: https://bitcointalk.org/index.php?topic=583449.0
|
||||
- name: Mattermost Sohbet
|
||||
url: https://mattermost.getmonero.org/
|
||||
- name: Telegram Sohbet
|
||||
url: https://telegram.me/bitmonero
|
||||
- title: Monero Projesi
|
||||
subfolderitems:
|
||||
- name: Open Alias
|
||||
url: https://openalias.org/
|
||||
- name: Kovri
|
||||
url: https://kovri.io/
|
||||
- name: Monero Araştırma Laboratuvarı
|
||||
url: resources/research-lab/
|
||||
- name: Monero Basın Kiti
|
||||
url: press-kit
|
||||
6
_data/lang/tr/footer-2.yml
Normal file
6
_data/lang/tr/footer-2.yml
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
- name: Yasal
|
||||
url: legal
|
||||
- name: Kaynak Kodu
|
||||
url: https://github.com/monero-project
|
||||
- name: Teknik Özellikler
|
||||
url: technical-specs/
|
||||
54
_data/lang/tr/navigation.yml
Normal file
54
_data/lang/tr/navigation.yml
Normal file
|
|
@ -0,0 +1,54 @@
|
|||
- title: Başlangıç
|
||||
subfolderitems:
|
||||
- page: Monero Nedir?
|
||||
url: get-started/what-is-monero
|
||||
- page: Kullanımı
|
||||
url: get-started/using
|
||||
- page: Kabulü
|
||||
url: get-started/accepting
|
||||
- page: Katkıda Bulunulması
|
||||
url: get-started/contributing
|
||||
- page: Madenciliği
|
||||
url: get-started/mining
|
||||
- page: SSS
|
||||
url: get-started/faq
|
||||
- title: İndirmeler
|
||||
url: downloads/
|
||||
- title: Son Haberler
|
||||
subfolderitems:
|
||||
- page: Tüm Gönderiler
|
||||
url: blog
|
||||
- page: Mektuplar
|
||||
url: blog/tags/monero%20missives.html
|
||||
- page: Toplantı Kayıtları
|
||||
url: blog/tags/dev%20diaries.html
|
||||
- page: Bültenler
|
||||
url: blog/tags/releases.html
|
||||
- title: Topluluk
|
||||
subfolderitems:
|
||||
- page: Ekip
|
||||
url: community/team
|
||||
- page: Buluşmalar
|
||||
url: community/hangouts
|
||||
- page: Sponsorluklar
|
||||
url: community/sponsorships
|
||||
- page: Satıcılar
|
||||
url: community/merchants
|
||||
- title: Kaynaklar
|
||||
subfolderitems:
|
||||
- page: Hakkında
|
||||
url: resources/about
|
||||
- page: Yol Haritası
|
||||
url: resources/roadmap
|
||||
- page: Araştırma Laboratuvarı
|
||||
url: resources/research-lab
|
||||
- page: Moneropedi
|
||||
url: resources/moneropedia
|
||||
- page: Kullanıcı Rehberleri
|
||||
url: resources/user-guides
|
||||
- page: Geliştirici Rehberleri
|
||||
url: resources/developer-guides
|
||||
- page: Teknik Özellikler
|
||||
url: technical-specs
|
||||
- page: Kütüphane
|
||||
url: library
|
||||
120
_data/lang/tr/roadmap.yml
Normal file
120
_data/lang/tr/roadmap.yml
Normal file
|
|
@ -0,0 +1,120 @@
|
|||
- year: 2014
|
||||
accomplishments:
|
||||
- name: Bitcointalk'ta faaliyete geçti
|
||||
date: 2014-04-18
|
||||
status: completed
|
||||
- name: İsmi Bitmonero'dan Monero'ya değiştirildi
|
||||
date: 2014-04-23
|
||||
status: completed
|
||||
- name: Bir spam saldırıyı atlattı
|
||||
date: 2014-09-04
|
||||
status: completed
|
||||
- name: Monero Araştırma Laboratuvarı Makale 1 ve 2 yayınlandı
|
||||
date: 2014-09-12
|
||||
status: completed
|
||||
- name: Monero Araştırma Laboratuvarı Makale 3 yayınlandı
|
||||
date: 2014-09-25
|
||||
status: completed
|
||||
- name: 0.8.8.6 yayınlandı
|
||||
date: 2014-12-08
|
||||
status: completed
|
||||
- year: 2015
|
||||
accomplishments:
|
||||
- name: Monero Araştırma Laboratuvarı Makale 4 yayınlandı
|
||||
date: 2015-01-26
|
||||
status: completed
|
||||
- year: 2016
|
||||
accomplishments:
|
||||
- name: 0.9.0 Hydrogen Helix yayınlandı
|
||||
date: 2016-01-01
|
||||
status: completed
|
||||
- name: Monero Araştırma Laboratuvarı Makale 5 yayınlandı
|
||||
date: 2016-02-10
|
||||
status: completed
|
||||
- name: Tüm işlemlerde asgari 3 halkaboyunun zorunlu kılınması için ağ yükseltildi
|
||||
date: 2016-03-22
|
||||
status: completed
|
||||
- name: 0.10.0 Wolfram Warptangent yayınlandı
|
||||
date: 2016-09-18
|
||||
status: completed
|
||||
- name: Para tabanının birimlere ayrılması için ağ yükseltildi
|
||||
date: 2016-09-21
|
||||
status: completed
|
||||
- name: 0.10.1 Wolfram Warptangent yayınlandı
|
||||
date: 2016-12-14
|
||||
status: completed
|
||||
- name: Resmi GUI Beta 1 yayınlandı
|
||||
date: 2016-12-22
|
||||
status: completed
|
||||
- year: 2017
|
||||
accomplishments:
|
||||
- name: RingCT işlemlerinin etkinleştirilmesi için ağ yükseltildi
|
||||
date: 2017-01-05
|
||||
status: completed
|
||||
- name: 0.10.2 yayınlandı; kritik zaaf yamalandı
|
||||
date: 2017-02-22
|
||||
status: completed
|
||||
- name: 0.10.3.1 Wolfram Warptangent yayınlandı
|
||||
date: 2017-03-27
|
||||
status: completed
|
||||
- name: Asgari blok boyutu ve dinamik ücret algoritmasının ayarlanması için ağ yükseltildi
|
||||
date: 2017-04-15
|
||||
status: completed
|
||||
- name: Web sitesi yeniden tasarlandı
|
||||
date: 2017-07-04
|
||||
status: completed
|
||||
- name: 0.11.0.0 Helium Hydra yayınlandı
|
||||
date: 2017-09-07
|
||||
status: completed
|
||||
- name: Pofuduk bloklar
|
||||
date: 2017-09-07
|
||||
status: completed
|
||||
- name: GUI betadan çıktı
|
||||
date: 2017-09-10
|
||||
status: completed
|
||||
- name: Asgari halka boyutunu 5'e artırılması ve RingCT işlemlerini zorunlu kılınması için ağ yükseltildi
|
||||
date: 2017-09-15
|
||||
status: completed
|
||||
- name: 0MQ/ZeroMQ
|
||||
date: September, 2017
|
||||
status: completed
|
||||
- name: Altadresler
|
||||
date: October, 2017
|
||||
status: completed
|
||||
- name: Çoklu-imzalar (multisig)
|
||||
date: December, 2017
|
||||
status: completed
|
||||
- year: 2018
|
||||
accomplishments:
|
||||
- name: Yeni İş Kanıtı CryptoNoteV7
|
||||
date: 2018-04-06
|
||||
status: completed
|
||||
- name: Asgari halka boyutunun 7'ye yükseltilmesi, çoklu-imzaların, altadreslerin entegre edilmesi ve PoW algoritmasını değiştirilmesi için ağ yükseltildi
|
||||
date: 2018-04-06
|
||||
status: completed
|
||||
- name: Getmonero.org'un Fransızca ve Polonyacaya yerelleştirilmesi
|
||||
date: 2018-04-24
|
||||
status: completed
|
||||
- name: Ledger Donanım Cüzdanları Desteği
|
||||
date: 2018-06-04
|
||||
status: completed
|
||||
- name: Kovri alfa yayını
|
||||
date: 2018-08-01
|
||||
status: completed
|
||||
- name: İşlem boyutlarının düşürülmesi için Kurşun-geçirmezlerin uygulamaya konulması
|
||||
date: 2018-10-18
|
||||
status: completed
|
||||
- name: Forum Fonlama Sistemi yeniden tasarımı
|
||||
date:
|
||||
status: ongoing
|
||||
- name: Kovri'nin Uygulamaya Konulması
|
||||
date:
|
||||
status: upcoming
|
||||
- year: 2019
|
||||
accomplishments:
|
||||
- name: Hız ve ölçeklenebilirlik için ikinci-katman çözümler
|
||||
date:
|
||||
status: upcoming
|
||||
- name: Ek MAL araştırma makaleleri
|
||||
date:
|
||||
status: upcoming
|
||||
|
|
@ -9,6 +9,7 @@ langs:
|
|||
de: Deutsch
|
||||
nl: Nederlands
|
||||
pt-br: Português do Brasil
|
||||
tr: Türkçe
|
||||
|
||||
global:
|
||||
date: '%Y/%m/%d'
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ langs:
|
|||
de: Deutsch
|
||||
nl: Nederlands
|
||||
pt-br: Português do Brasil
|
||||
tr: Türkçe
|
||||
|
||||
global:
|
||||
date: '%Y/%m/%d'
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ langs:
|
|||
de: Deutsch
|
||||
nl: Nederlands
|
||||
pt-br: Português do Brasil
|
||||
tr: Türkçe
|
||||
|
||||
global:
|
||||
date: '%Y/%m/%d'
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@
|
|||
de: Deutsch
|
||||
nl: Nederlands
|
||||
pt-br: Português do Brasil
|
||||
tr: Türkçe
|
||||
|
||||
global:
|
||||
date: '%d/%m/%Y'
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ langs:
|
|||
de: Deutsch
|
||||
nl: Nederlands
|
||||
pt-br: Português do Brasil
|
||||
tr: Türkçe
|
||||
|
||||
global:
|
||||
date: '%d/%m/%Y'
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ langs:
|
|||
de: Deutsch
|
||||
nl: Nederlands
|
||||
pt-br: Português do Brasil
|
||||
tr: Türkçe
|
||||
|
||||
global:
|
||||
date: '%Y/%m/%d'
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ langs:
|
|||
de: Deutsch
|
||||
nl: Nederlands
|
||||
pt-br: Português do Brasil
|
||||
tr: Türkçe
|
||||
|
||||
global:
|
||||
date: '%Y/%m/%d'
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ langs:
|
|||
de: Deutsch
|
||||
nl: Nederlands
|
||||
pt-br: Português do Brasil
|
||||
tr: Türkçe
|
||||
|
||||
global:
|
||||
date: '%Y/%m/%d'
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ langs:
|
|||
de: Deutsch
|
||||
nl: Nederlands
|
||||
pt-br: Português do Brasil
|
||||
tr: Türkçe
|
||||
|
||||
global:
|
||||
date: '%Y/%m/%d'
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ langs:
|
|||
de: Deutsch
|
||||
nl: Nederlands
|
||||
pt-br: Português do Brasil
|
||||
tr: Türkçe
|
||||
|
||||
global:
|
||||
date: '%Y/%m/%d'
|
||||
|
|
|
|||
647
_i18n/tr.yml
Normal file
647
_i18n/tr.yml
Normal file
|
|
@ -0,0 +1,647 @@
|
|||
langs:
|
||||
en: English
|
||||
es: Español
|
||||
it: Italiano
|
||||
pl: Polski
|
||||
fr: Français
|
||||
ar: العربية
|
||||
ru: Русский
|
||||
de: Deutsch
|
||||
nl: Nederlands
|
||||
pt-br: Português do Brasil
|
||||
tr: Türkçe
|
||||
|
||||
global:
|
||||
date: '%Y/%m/%d'
|
||||
monero: Monero
|
||||
getting_started: Başlangıç
|
||||
copyright: Teklif Hakkı
|
||||
monero_project: Monero Projesi
|
||||
sitename: getmonero.org, Monero Projesi
|
||||
wiki: Moneropedi
|
||||
tags: Etiketlere göre Yazılar
|
||||
wikimeta: Monero bilgisinin açık ansiklopedisi Moneropedi'de
|
||||
tagsmeta: Etiketlenen tüm Monero blog yazıları
|
||||
titlemeta: Güvenli, gizli ve takip edilemeyen bir dijital para olan Monero'nun ana sayfasında
|
||||
terms: Şartlar
|
||||
privacy: Gizlilik
|
||||
copyright: Telif Hakkı
|
||||
untranslated: Bu sayfa henüz çevrilmedi. Çevrilmesine yardım etmek isterseniz şunu görüntüleyin
|
||||
outdatedMax: Bu sayfa güncel değil. Kullanmanızı tavsiye etmiyoruz. Bunun yerine şunu görüntüleyin
|
||||
outdatedVersion: İngilizce sürüm
|
||||
outdatedMin: Bu sayfa çeviriden sonra güncellendi. Bu sürümü kullanabilirsiniz, ancak eksik olabilir.
|
||||
upgrade: Monero kullanmaya devam etmek için yazılımınızın 9 Mart ağ yükseltmesine güncellediğinden emin olun.
|
||||
moreinfo: Daha fazla bilgi
|
||||
lang_tag: "@lang_tag_en"
|
||||
|
||||
titles:
|
||||
index: Ana Sayfa
|
||||
whatismonero: Monero (XMR) Nedir?
|
||||
using: Monero Kullanımı
|
||||
accepting: Monero Kabulü
|
||||
contributing: Monero'ya Katkıda Bulunulması
|
||||
mining: Monero Madenciliği
|
||||
faq: SSS
|
||||
downloads: İndirmeler
|
||||
allposts: Tüm Blog Gönderileri
|
||||
team: Monero Ekibi
|
||||
hangouts: Buluşmalar
|
||||
events: Etkinlikler
|
||||
sponsorships: Sponsorluklar
|
||||
merchants: Satıcılar & Hizmetler
|
||||
about: Monero Hakkında
|
||||
roadmap: Yol Haritası
|
||||
researchlab: Monero Araştırma Laboratuvarı
|
||||
moneropedia: Moneropedi
|
||||
userguides: Kullanıcı Rehberleri
|
||||
developerguides: Geliştirici Rehberleri
|
||||
technicalspecs: Teknik Özellikler
|
||||
themoneroproject: Monero Projesi
|
||||
presskit: Monero Basın Kiti
|
||||
legal: Yasal
|
||||
ffs: Forum Fonlama Sistemi
|
||||
ffs-cp: Tamamlanan Öneriler
|
||||
ffs-fr: Fonlama Gerekenler
|
||||
ffs-ideas: Fikirler
|
||||
ffs-ot: Açık Görevler
|
||||
ffs-wip: Devam Eden İşler
|
||||
blogbytag: Etiketlere Göre Blog
|
||||
library: Kütüphane
|
||||
|
||||
index:
|
||||
page_title: "Monero - güvenli, gizli, takip edilemez"
|
||||
|
||||
home:
|
||||
translated: "yes"
|
||||
heading2: Gizli Dijital Para
|
||||
monero_is_cash: Monero bağlı bir dünya için paradır. Hızlı, gizli ve güvenlidir. Monero'yla kendi bankanız siz olursunuz. Başkalarının bakiyenizi göremeyeceğini veya aktivitelerinizi takip edemeyeceğini bilerek güvenli şekilde harcayabilirsiniz.
|
||||
get_started: Başlangıç
|
||||
why_monero_is_different: Monero'nun farklı olma sebepleri
|
||||
monero_is_secure: Monero güvenlidir
|
||||
monero_is_secure_para: Monero merkeziyetsiz bir kripto-paradır, yani bir kullanıcılar ağınca işletilen güvenli dijital paradır. İşlemler dağıtık uzlaşımla onaylanıp değiştirilemez şekilde blokzincire kaydedilir. Moneronuzun güvende tutulması için üçüncü taraflara güvenilmesi gerekmez.
|
||||
monero_is_private: Monero gizlidir
|
||||
monero_is_private_para: Monero tüm işlemlerin kaynaklarını, miktarlarını ve varış noktalarını gizlemek için halka imzaları, halka gizli işlemleri ve hayalet adresleri kullanır. Monero olağan gizlilikten imtiyaz vermeden merkeziyetsiz bir kriptoparanın tüm faydalarını sağlar.
|
||||
monero_is_untraceable: Monero takip edilemezdir
|
||||
monero_is_untraceable_para: Gönderici ve alıcı adreslerin yanında aktarılan miktarlar da varsayılan şekilde gizlidir. Monero blokzincirindeki işlemler belirli bir kullanıcıya veya gerçek dünya kimliğine bağlanamaz.
|
||||
monero_is_fungible: Monero is değiştirilebilirdir
|
||||
monero_is_fungible_para1: Monero
|
||||
monero_is_fungible_para2: değiştirilebilirdir
|
||||
monero_is_fungible_para3: çünkü varsayılan şekilde gizlidir. Monero birimleri önceki işlemlerdeki ilişkilendirmesi sebebiyle satıcı veya borsalarca kara listeye alınamaz.
|
||||
downloads: İndirmeler
|
||||
downloads_windows: Windows için Monero
|
||||
downloads_mac: Mac için Monero
|
||||
downloads_linux: Linux için Monero
|
||||
downloads_blockchain: Son Blokzincir
|
||||
different_system: Başka bir işletim sistemi için mi ihtiyacınız var?
|
||||
view_all_downloads: Tüm mevcut indirmeleri burada görüntüleyin.
|
||||
latest_news: Son Haberler
|
||||
more_news: Daha fazla haber
|
||||
moneropedia: Moneropedi
|
||||
moneropedia_para: Monero'da kullanılan terimlerin ve kavramların anlamlarına bakmak ister misiniz? Burada hem Monero hem de Kovri projelerinden terimlerin ve onların anlamlarının alfabetik bir rehberini bulacaksınız.
|
||||
moneropedia_button: Moneropedi'yi Oku
|
||||
user_guides: Kullanıcı Rehberleri
|
||||
user_guides_para: Monero olan tüm şeylerin kategorilerle ayrıldığı ve bir cüzdan yaratmaktan ağı desteklemeye, hatta bu internet sitesini düzenlemeye kadar her şeyi kapsayan adım adım rehberler.
|
||||
user_guides_button: Kullanıcı rehberlerini oku
|
||||
faq: SSS
|
||||
faq_para: Yıllar boyunca pek çok soruyla karşılaştık ve kolaylığınız için ayrıntılı ve çeşitlendirilmiş bir SSS derledik. Merak etmeyin, eğer sorularınız burada değilse her zaman topluluğumuza sorabilirsiniz.
|
||||
faq_button: Cevapları oku
|
||||
|
||||
hangouts:
|
||||
translated: "yes"
|
||||
intro: Monero topluluğu çeşitli ve farklı bireylerden oluşur. Dünya'nın her yerinden geliyor olsak da birlikte takılmaktan hoşlandığımız bazı yerler de yok değildir. Çoğunu aşağıda bulacaksınız. Bize katılın!
|
||||
resources: Çalışma Grubu Kaynakları
|
||||
resources_para: Organik çalışma gruplarını desteklemek adına Monero, topluluğun buluşup proje planlayabileceği birçok kaynağa sahiptir. Mattermost'un en popüler Monero ilintili IRC kanallarına röleleri bile vardır.
|
||||
irc: IRC Kanalları
|
||||
irc_para: Monero topluluğu her biri farklı amaçlara sahip pek çok IRC kanalından faydalanmaktadır. Kimisi çalışır, kimisiyse sadece takılır. En popüler olanları aşağıda bulacaksınız.
|
||||
stack_exchange: Stack Exchange
|
||||
stack_exchange_para: Monero Stack Exchange sayfası soru sorup cevap almanın hızlı bir yoludur. Aşağıda bazı sıkça sorulan sorulara yüksek kalitedeki bazı soru/cevap çiftlerini bulacaksınız.
|
||||
stack_exchange_link: Stack Exchange'i Ziyaret Edin
|
||||
irc_channels:
|
||||
- channel: monero
|
||||
description: Bu kanal Monero'ya ilişkin her şeyi tartışmak için kullanılır.
|
||||
- channel: monero-community
|
||||
description: Bu kanal Monero topluluğunun toplanıp fikirlerini tartışması içindir.
|
||||
- channel: monero-dev
|
||||
description: Çok sayıdaki katkıda bulunan ve geliştirici buraya geliştirme şeylerini tartışmak için gelir.
|
||||
- channel: monero-markets
|
||||
description: Bu kanalı Monero'nun değeri ve diğer paralar hakkında konuşmak için kullanıyoruz.
|
||||
- channel: monero-offtopic
|
||||
description: Monero'ya ilişkin olmayan şeyler hakkında diğer Monero kullanıcıyla sohbet.
|
||||
- channel: monero-otc
|
||||
description: Borsa dışı Monero. Akran Monerodaşlarınızdan XMR almak için buraya gelin.
|
||||
- channel: monero-pools
|
||||
description: Madencilik sorularının ve tartışmalarının yeri burasıdır.
|
||||
- channel: monero-research-lab
|
||||
description: Kriptoparalarla finansal mahremiyet araştırmaları.
|
||||
- channel: monero-translations
|
||||
description: Monero'nun diğer dillere yerelleştirilmesi.
|
||||
- channel: monero-hardware
|
||||
description: Monero'nuzu güvende tutmak için donanım cüzdanları yapımı.
|
||||
- channel: kovri
|
||||
description: Bu kanal Kovri'ye ilişkin her şeyi tartışmak için kullanılır.
|
||||
- channel: kovri-dev
|
||||
description: Çok sayıdaki katkıda bulunan ve geliştirici buraya Kovri geliştirme şeylerini tartışmak için gelir.
|
||||
|
||||
merchants:
|
||||
translated: "yes"
|
||||
intro1: Her türden satıcı Monero'nun getirdiği finansal gizliliğe değer vermeye başlamıştır. Aşağıda malları ve hizmetleri için şu anda Monero kabul ettiğini bildiğimiz satıcıların bir listesi bulunmaktadır. Eğer bir şirket artık Monero kabul etmiyorsa veya işletmenizin listelenmesini istiyorsanız lütfen
|
||||
intro2: bir GitLab sorunu açın ve bize haber verin.
|
||||
disclaimer: |
|
||||
"Lütfen dikkate alınız: Bu bağlantılar kolaylık olması ve sadece bilgi verme amaçlı olarak sağlanmaktadır; listelenen şirketlerin veya organizasyonların veya bireylerin herhangi bir ürününün, hizmetinin veya düşüncesinin Monero topluluğunca kabulünü oluşturmazlar. Monero topluluğu bu harici sitelerin doğruluğu, yasallığı veya içeriği üzerinde hiçbir sorumluluk sahibi değildir. İçerikleri hakkındaki sorularınıza cevap için harici sayfaya ulaşın. Her zamanki gibi, caveat emptor ('alıcı sakınsın'); kendi araştırmanızı yapmaktan siz sorumlusunuz. Çevrimiçi satın alım yaparken her zaman sağduyu kullanın."
|
||||
|
||||
sponsorships:
|
||||
translated: "yes"
|
||||
intro: Aşağıdaki işletmeler Dünyaya finansal gizlilik getirme hedefinde Monero Projesini desteklemektedir. Katkıları için ne kadar minnettar olsak az. Eğer Monero Projesine sponsor olmak ve bu sayfada listelenmek isterseniz lütfen dev@getmonero.org'a bir e-posta gönderin.
|
||||
|
||||
team:
|
||||
translated: "yes"
|
||||
core: Çekirdek
|
||||
developers: Geliştiriciler
|
||||
developers_para1: Monero Projesi, projesinin yaşamı boyunca 500'den çok daha fazla geliştiriciye sahip olmuştur. Tam bir liste için ziyaret etmeniz gereken yer
|
||||
developers_para2: OpenHub katkıda bulunanlar sayfasıdır.
|
||||
developers_para3: Aşağıda Monero için sınırları zorlayan bazı bireyleri bulacaksınız.
|
||||
community: Topluluk
|
||||
mrl: Araştırma Laboratuvarı
|
||||
thanks: Özel Teşekkürler
|
||||
|
||||
downloads:
|
||||
translated: "yes"
|
||||
choose: İşletim Sisteminizi Seçin
|
||||
sourceblockchain: Kaynak & Blokzincir
|
||||
mobilelight: Mobil & Hafif
|
||||
hardware: Donanım
|
||||
intro1: Doğru uygulamayı seçmek için yardıma ihtiyacınız varsa lütfen hızlı bir cevap için
|
||||
intro2: burayı
|
||||
intro3: tıklayıp aşağıdan işletim sisteminiz için uygun yayını seçin.
|
||||
note1: "Not: SHA256 sağlamaları indirmelere göre kolaylık için listelenmiştir, ama sağlamaların GPG-imzalanmış bir listesini bulabileceğiniz adres"
|
||||
note2: ve kaynak kodundaki uygun GPG anahtarına (/utils/gpg_keys'de) karşı imzanın kontrol edilmesiyle kanonik olarak kabul edilmelidir.
|
||||
currentversion: Mevcut Sürüm
|
||||
sourcecode: Kaynak Kodu
|
||||
mirror: Alternatif
|
||||
blockchain1: Bir blokzincir önyüklemesi kullanmayı tercih ediyorsanız sıfırdan senkron yerine
|
||||
blockchain2: en son önyükleme için bu bağlantıyı kullanabilirsiniz.
|
||||
blockchain3: Normalde sıfırdan senkrondan çok daha hızlıdır, ancak çok daha az RAM kullanır (içe aktarım çok aç gözlüdür).
|
||||
hardware1: Monero topluluğu şu anda gelişmekte olan bir
|
||||
hardware2: Özel Donanım Cüzdanı
|
||||
hardware3: fonlamıştır. Dahası CLI 0.12.1 ve GUI 0.12.3'ten beri Ledger
|
||||
hardware4: Monero'yu donanım cüzdanlarına entegre etmiştir.
|
||||
mobilelight1: Aşağıdakiler topluluğun güvenilen üyeleri tarafından güvenli olarak görülen mobil veya hafif cüzdanlardır. Eğer burada olmayan bir cüzdan varsa topluluktan kontrol etmesini isteyebilirsiniz. Nerede olduklarını görüntülemek için
|
||||
mobilelight2: Buluşmalar
|
||||
mobilelight3: sayfasına gidin.
|
||||
clionly: Sadece Komut-Satırı Araçları
|
||||
installer: Kurucu
|
||||
|
||||
monero-project:
|
||||
translated: "yes"
|
||||
kovri: Kovri projesi bir Monero işleminin ne göndericisinin ne de alıcısının IP adreslerinin diğer tarafa veya üçüncü taraf gözlemcilerine (blokzincire) açığa çıkmaması gerekliliği için uçtan-uca şifrelemeyi kullanır. Bu karanlık ağı güçlendiren aynı teknolojiyi, i2p'yi (Görünmez İnternet Protokolü) kullanır. Proje şu anda yoğun, aktif gelişim hâlindedir ve henüz Monero ile entegre edilmemiştir.
|
||||
kovri_button: Kovri İnternet Sayfasını Ziyaret Edin
|
||||
openalias: OpenAlias projesi Monero cüzdan adresleri için herkesin gizliliğinin korunduğundan emin olunacak bir şekilde FQDN'ler (Tam Nitelikli Alan adı, örneğin örnek.openalias.org) sağlayarak kriptopara ödemelerini kolaylaştırır. Proje oldukça ilerlemiştir ve pek çok Monero cüzdanında uygulamaya konmuştur.
|
||||
openalias_button: OpenAlias İnternet Sayfasını Ziyaret Edin
|
||||
|
||||
press-kit:
|
||||
translated: "yes"
|
||||
intro1: Burada, aşağıda Monero sembolünü ve logosunu bulacaksınız. Dilediğiniz boyutu seçebilir veya logoyla kendiniz oynamak için .ai dosyasını indirebilirsiniz.
|
||||
intro2: Beyaz arka plan seçeneklerinin SADECE Monero sembolü altında beyaz bir arka planı olduğuna, tüm imgeye arka plan olmadığına dikkat edin.
|
||||
intro3: Son olarak bu sayfadaki her şeyi tek bir zip dosyası olarak indirmek için
|
||||
intro4: buraya tıklayın.
|
||||
noback: Arka plansız
|
||||
whiteback: Beyaz arka plan
|
||||
symbol: Monero Sembolü
|
||||
logo: Monero Logosu
|
||||
small: Küçük
|
||||
medium: Orta
|
||||
large: Büyük
|
||||
symbol_file: Sembol .ai dosyası
|
||||
logo_file: Logo .ai dosyası
|
||||
documents:
|
||||
- category: Basın Belgelendirmesi
|
||||
publications:
|
||||
- name: "Hızlı Gerçekler Tablosu"
|
||||
url_file: "http://www.monerooutreach.org/pubs/2018/QuickFacts/QuickFacts.pdf"
|
||||
abstract: >
|
||||
Monero hakkındaki her şeyi öğrenmek için okuması hızlı ve kolay bir belge: tarihi, önemli farklılaştıran etkenleri, teknik temel prensipleri ve gelişimdeki özellikleri.<br>
|
||||
Daha fazla bilgi için <a target="_blank" href="https://www.monerooutreach.org/index.php">Monero Outreach</a> sayfasını görüntüleyin.
|
||||
|
||||
accepting:
|
||||
translated: "yes"
|
||||
title: Komut-Satırı Arayüzü için Talimatlar
|
||||
basics: Temel Öğeler
|
||||
basics_para1: Monero alışagelmiş olabileceğiniz diğer @kriptoparalar dan biraz daha farklı çalışır. Bitcoin gibi dijital paralar ve bunların çok sayıdaki türev satıcı ödeme sistemleri genellikle her ödeme veya kullanıcı için yeni bir alıcı @adres i yaratır.
|
||||
basics_para2: Ancak Monero @hayalet-adresler e sahip olduğu için her ödeme veya kullanıcı için ayrı alıcı adreslerine sahip olmaya gerek yoktur ve tek bir @hesap adresi yayımlanabilir. Bunun yerine ödeme alırken bir satıcı ödeme yapacak kişiye bir "ödeme ID"si sağlar.
|
||||
basics_para3: "Bir @ödeme-id si 64 karakter uzunluğunda olan bir onaltılı bir dizidir ve normalde satıcı tarafından rastgele yaratılır. Bir ödeme ID örneği şöyledir:"
|
||||
checking: monero-wallet-cli'da Ödeme Kontrolü
|
||||
checking_para1: |
|
||||
Eğer monero-wallet-cli kullanarak bir ödemeyi kontrol etmek isterseniz kontrol etmek istediğiniz ödeme ID veya ID'lerini takip eden şekilde "payments" komutunu kullanabilirsiniz. Örneğin:
|
||||
checking_para2: Eğer programlanabilir şekilde ödemeleri kontrol etmeniz gerekiyorsa detaylar bir sonraki bölümde yer almaktadır.
|
||||
receiving: Adım Adım Ödeme Almak
|
||||
receiving_list1: Ödeme için bir rastgele 64 karakterlik onaltılı dizi oluşturun
|
||||
receiving_list2: Ödeme ID'sini ve Monero adresini ödemeyi yapmakta olan kişiye iletin
|
||||
receiving_list3: monero-wallet-cli'da "payments" komutunu kullanarak ödemeleri kontrol edin
|
||||
program: Programlanabilir Şekilde Ödeme Kontrolü
|
||||
program_para1: Programlanabilir şekilde ödemeleri kontrol etmek için get_payments veya get_bulk_payments JSON RPC API çağrılarını kullanabilirsiniz.
|
||||
program_para2: bu tek bir ödeme ID'siyle bir payment_id parametresi gerektirir.
|
||||
program_para3: bu tercih edilen yöntemdir ve iki parametre, payment_ids - ödeme ID'lerinin bir JSON dizilimi - ve opsiyonel bir min_block_height - taramanın başlayacağı blok yüksekliği - gerektirir.
|
||||
program_para4: |
|
||||
Dönen verinin bir örneği aşağıdaki gibidir:
|
||||
program_para5: Geri dönen miktarların temel Monero birimlerinde olduğuna, normalde son-kullanıcı uygulamalarında kullanılan gösterim birimlerinde olmadığına dikkat etmek önemlidir. Ayrıca bir işlemin tipik olarak ödeme için gereken toplama eklenecek çoklu çıktısı olduğu için miktarlar tx_hash veya payment_id tarafından gruplanmalı ve birlikte eklenmelidir. Ek olarak çoklu çıktılar aynı miktara sahip olabileceği için tek bir get_bulk_payment çağrısından dönen veriyi filtrelemeyi denememek zaruridir.
|
||||
program_para6: Ödemeleri taramadan önce ek blokların alınıp alınmadığını görmek için daemon RPC API'a (get_info RPC çağrısı) karşı kontrol etmek kullanışlıdır. Tipik olarak alınan bloğu get_bulk_payments'a min_block_height olarak belirterek sadece oradan taramak istersiniz.
|
||||
scanning: Programlanabilir Şekilde Ödeme Taraması
|
||||
scanning_list1: Daemon'dan mevcut blok yüksekliğini alın, sadece son taramamızdan beri arttıysan ilerleyin
|
||||
scanning_list2: get_bulk_payments RPC API çağrısını son taranmış yüksekliğimizle ve sistemimizdeki tüm ödeme ID'lerin listesiyle arayın
|
||||
scanning_list3: Mevcut blok yüksekliğini taranan son yüksekliğimiz olarak depolayın
|
||||
scanning_list4: Zaten almış ve işlemiş olduğumuz işlem sağlamalarına dayanarak kopyaları kaldırın
|
||||
|
||||
contributing:
|
||||
translated: "yes"
|
||||
intro: Monero açık kaynak kodlu, topluluk güdümlü bir projedir. Aşağıda projeyi desteklemenin birçok yolu tarif edilmiştir.
|
||||
network: Ağı Destekleyin
|
||||
develop: Geliştirin
|
||||
develop_para1: "Monero öncelikli olarak C++'da yazılmıştır. Merkeziyetsiz bir proje olması sayesinde herkes var olan koda ekleme veya değişiklik yapabilir. İste talepleri topluluk uzlaşımına dayanılarak birleştirilir. Görüntüleyin:"
|
||||
develop_para2: Depolar
|
||||
develop_para3: ve öne çıkan
|
||||
develop_para4: sorunlar.
|
||||
full-node: Tam Düğüm Çalıştırın
|
||||
full-node_para: Port 18080 açıkken monerod çalıştırın. Bir tam düğüm çalıştırmak Monero'yla işlem yaparken azami gizliliği kesinleştirir. Ayrıca blokzincirin yeni kullanıcılara dağıtımını geliştirir.
|
||||
mine: Madencilik Yapın
|
||||
mine_para1: Madencilik Monero ağının merkeziyetsiz ve güvenli kalmasını kesinleştirir. Monero grafiksel kullanıcı arayüzünde ve komut-satırı arayüzünde arka plan madenciliği etkinleştirilebilir. Madencilik hakkındaki ek kaynakları
|
||||
mine_para2: burada görüntüleyebilirsiniz.
|
||||
ffs: Forum Fonlama Sistemini Görüntüleyin
|
||||
ffs_para1: Monero projelerin gelişim için önerildiği ve topluluk tarafından fonlandığı bir
|
||||
ffs_para2: forum fonlama sistemi
|
||||
ffs_para3: kullanır. Fonlama emanette tutulur ve programlama kilometre taşları başarıya ulaştıkça geliştiricilere karşılık olarak verilir. Herkes yeni öneriler üretebilir veya mevcut olanları fonlayabilir.
|
||||
donate: Bağışla
|
||||
donate_para1: Mevcut gelişimi destekleme araçları bağışlar ve
|
||||
donate_para2: sponsorluklar.
|
||||
donate-xmr: Monero Bağışlama
|
||||
donate-xmr_para: "Bağış gönderebileceğiniz adresler şunlardır:"
|
||||
or: ve
|
||||
donate-btc: Bitcoin Bağışlama
|
||||
donate-btc_para: "Bağış gönderebileceğiniz adresler şunlardır:"
|
||||
donate-other: Diğer
|
||||
donate-other_para1: Alternatif bağış yolları için veya Monero Projesine sponsor olmak istiyorsanız
|
||||
donate-other_para2: a e-posta gönderin.
|
||||
|
||||
faq:
|
||||
translated: "yes"
|
||||
q1: Monero'nun değeri niye vardır?
|
||||
a1: İnsanlar almak istediği için Monero'nun değeri vardır. Hiç kimse Monero almaya gönüllü değilse bir değeri olmayacaktır. Monero'nun değeri talep arzı aştığında artar ve arz talebi aştığında düşer.
|
||||
q2: Nasıl Monero alabilirim?
|
||||
a2: Bir borsadan veya kişiden Monero alabilirsiniz. Alternatif olarak blok ödülünden para almak için Monero madenciliği yapmayı deneyebilirsiniz.
|
||||
q3: Anımsatıcı tohum nedir?
|
||||
a3: Anımsatıcı tohum hesabınızı nerede olursanız olun geri getirmek için kullanılabilecek 25 kelimelik bir kümedir. Bu kelimeleri güvenli şekilde koruyun ve başka kimseyle paylaşmayın. Bilgisayarınız bozulsa bile bu tohumu kullanarak hesabınızı geri getirebilirsiniz.
|
||||
q4: Monero'nun gizliliği diğer paralardan nasıl farklıdır?
|
||||
a4: |
|
||||
Monero üç farklı gizlilik teknolojisi kullanır: halka imzalar, halka gizli işlemler (RingCT) ve hayalet adresler. Bunlar sırasıyla göndericiyi, miktarı ve alıcıyı gizler. Ağdaki tüm işlemler zorunlu olarak gizlidir; kazayla saydam bir işlem göndermenin bir yolu yoktur. Bu özellik sadece Monero'da bulunur. Gizliliğiniz için başka birine güvenmeniz gerekmez.
|
||||
q5: Cüzdanımın senkronize olması neden bu kadar uzun sürüyor?
|
||||
a5: Eğer yerel olarak bir tam düğüm çalıştırıyorsanız tüm blokzinciri bilgisayarınıza kopyalamanız gerekir. Bu özellikle eski bir sabit sürücüde veya yavaş bir internet bağlantısında uzun zaman alabilir. Eğer bir uzak düğüm kullanıyorsanız bilgisayarınız yine de tüm çıktıların bir kopyasını istemesi gerekecektir ki bu birkaç saat alabilir. Sabırlı olun ve daha hızlı senkron süreleri için biraz gizlilik feda etmek isterseniz bunların yerine bir hafif cüzdan kullanmayı düşünün.
|
||||
q6: Hafif ve normal cüzdan arasındaki fark nedir?
|
||||
a6: Hafif bir cüzdanda görüntüleme anahtarınızı sizin yerinize blokzinciri tarayan ve hesabınıza gelecek işlemleri bekleyen bir uca verirsiniz. Bu uç ne zaman paranızı aldığınızı bilecektir, ancak ne kadar aldığınızı, kimden aldığınızı veya kime para gönderdiğinizi bilmeyecektir. Cüzdan yazılımınıza bağlı olarak gizlilik sızıntılarından kaçınmak için sizin kontrol ettiğiniz bir düğüm kullanabilirsiniz. Daha fazla gizlilik için kendi düğümünüzle kullanılabilecek olan bir normal cüzdan kullanın.
|
||||
q7: Monero'nun Bitcoin'den nesi farklı?
|
||||
a7: Monero Bitcoin'e dayanmaz. CryptoNote protokolüne dayanır. Bitcoin insanların bir kullanıcının diğerine tam olarak ne kadar para gönderdiğini görebildiği tamamıyla saydam bir sistemdir. Monero kullanıcı gizliliğini korumak için tüm işlemlerde bu bilgiyi saklar. Ayrıca pek çok başka değişikliğin yanında dinamik blok boyutu ve dinamik ücretleri, ASIC-dirençli bir iş kanıtına ve bir uç para salınımına sahiptir.
|
||||
q8: Monero'nun bir blok boyutu sınırı var mı?
|
||||
a8: Hayır, Monero'nun sert bir blok boyutu sınırı yoktur. Bunun yerine blok boyutu talebe bağlı olarak zamanla artabilir veya azılabilir. Ölçüsüz büyümeyi engellemek adına belirli bir büyüme oranıyla sınırlanmıştır.
|
||||
q9: Blokzincir nedir?
|
||||
a9: Blokzincir, Monero ağında tüm işlem tarihçesinin bir kopyasını saklayan bir sistemdir. Her iki dakikada bir en son işlem bilgilerinin olduğu bir blok, blokzincire eklenir. Bu zincir ağa para hesaplarının sahip olduğu miktarı doğrulamasına izin verir ve saldırılara ve merkezileşme çabalarına karşı onu dirençli kılar.
|
||||
q10: Kovri nedir?
|
||||
a10: Kovri C++’da yazılmış olan bir I2P yönelticidir. I2P Tor gibi gizli bir ağdır, ama çeşitli teknik farklılıklara sahiptir. Kovri Monero'dan bağımsız bir projedir, ama Monero’yla ve birkaç başka projeyle birlikte çalışacaktır. Kovri işlem yayınını saklar, böylelikle diğer uçlar işlemleri kimin yarattığını bilmez. Muhalif durumlarda Kovri insanların Monero’nun kullanıldığını öğrenmesini engellemek için I2P aracılığıyla tüm Monero trafiğini saklamak için kullanılabilir. Kovri şu an alfa aşamasındadır ve Monero’yla tamamen entegre edilmemiştir. Kovri hakkında daha fazla bilgiyi <a href="https://kovri.io">projenin internet sayfası</a>ndan öğrenebilirsiniz.
|
||||
q11: Değiştirilebilirlik nedir ve neden önemlidir?
|
||||
a11: Değiştirilebilirlik paranın aynı değerdeki iki miktarı arasında hiçbir fark olmaması yönündeki basit bir özelliğidir. Eğer iki kişi bir 10’luk ve iki 5’lik değişirse kimse kaybetmez. Ancak diyelim ki herkes 10'luğun daha önce bir fidye yazılım saldırısında kullanıldığını biliyor. Diğer kişi bu takası yine de yapar mıydı? 10’luğu olan kişinin fidye yazılımla bir bağlantısı olmasa bile herhalde hayır. Paranın alıcısının aldıkları paranın lekelenmiş paralara karışmayacağını sürekli kontrol etmesi gerektiği için bu bir sorundur. Monero değiştirilebilirdir, yani insanların bu çabayı harcamasını gerektirmez.
|
||||
q12: Monero bu kadar gizliyse hiç yoktan yaratılmadığını nasıl biliyoruz?
|
||||
a12-1: Monero’da her işlem çıktısı sadece o çıktının sahibi tarafından üretilebilen bir anahtar imgesiyle eşsiz şekilde eşleştirilir. Birden fazla kullanılan anahtar imgeleri çifte harcama olarak madenciler tarafından reddedilir ve geçerli bir bloka eklenemez. Yeni bir işlem alındığında madenciler bunun bir çifte harcama olmadığına emin olmak için anahtar imgesinin önceki bir işlemde olmadığını doğrular.
|
||||
a12-2: Ayrıca harcadığınızın girdi değerleri ve gönderdiğinizin çıktı değerleri şifrelenmiş olsa bile (bunlar alıcı dışında herkes için gizlidir) işlem miktarlarının geçerli olduğunu bilebiliriz. Bunun sebebi hiçbir gözlemcinin girdilerin ve çıktıların miktarlarını bilemeyeceği Pedersen üstlenmelerinin kullanılarak miktarların şifrelenmesidir, ancak hiçbir Monero'nun yoktan yaratılmadığını belirlemek için Pedersen üstlenmelerinde matematik yapabilirler.
|
||||
a12-3: Yarattığınız şifrelenmiş çıktı miktarları harcanan girdilerin toplamına eşit olduğu sürece (ki bu alıcı için bir çıktı, kendinize bir değişiklik çıktısı ve şifrelenmemiş işlem ücretini içerir) meşru bir işleminiz vardır ve Monero'nun yoktan yaratılmadığını bilirsiniz. Pedersen üstlenmeleri toplamların eşit olmasıyla doğrulanabilir, ancak toplamların her birinin Monero değeri ve girdi ve çıktıların ayrı ayrı Monero değeri belirlenemez.
|
||||
q13: Monero büyülü müdür ve ne yaparsam yapayım gizliliğimi korur mu?
|
||||
a13: Monero büyülü değildir. Monero kullanır, ancak başka bir tarafa isminizi ve adresini verirsiniz diğer taraf büyülenmiş gibi isminizi ve adresinizi unutmayacaktır. Eğer gizli anahtarlarınızı verirseniz diğerleri ne yaptığınızı bilecektir. Eğer ifşa edilirseniz diğerleri tuşlarınızı kaydedebilir. Zayıf bir şifre kullanırsanız diğerleri anahtarlar dosyanızı kaba kuvvetle çözebilir. Eğer tohumunuzu bir buluta yedeklerseniz yakında fakirleşeceksiniz.
|
||||
q14: Monero %100 anonim mi ?
|
||||
a14: "%100 anonimlik diye bir şey yoktur. Hiç değilse anonimlik sınırınız Monero’yu kullanan insanlar kümesidir. Bazı insanlar Monero’yu kullanmaz. Monero’nun hataları da olabilir. Böyle olmasa bile şimdiye veya daha sonra Monero’nun gizlilik katmanları aracılığıyla bazı bilgilerin çıkarımını yapma yolları var olabilir. Saldırılar sürekli güçlenmektedir. Emniyet kemeri taksanız bile bir araba kazasında ölebilirsiniz. Mantığınızı, sağduyunuzu ve savunmanızı etraflıca kullanın."
|
||||
|
||||
mining:
|
||||
translated: "yes"
|
||||
intro1: Monero dağıtık uzlaşıma ulaşmak için iş kanıtı madenciliğine bel bağlayan bir kriptoparadır. Aşağıda madenciliğe nasıl başlanacağı hakkında bazı bilgiler ve kaynaklar bulacaksınız.
|
||||
intro2: Monero Projesi herhangi bir havuzu, yazılımı veya donanımı benimsememektedir ve aşağıdaki içerik sadece bilgilendirme amaçlı olarak sunulmuştur.
|
||||
support: Destek
|
||||
support_para1: "Şunları görüntüleyin:"
|
||||
support_para2: Buluşmalar,
|
||||
support_para3: /r/moneromining (İngilizce)
|
||||
support_para4: ve
|
||||
pools: Havuzlar
|
||||
pools_para1: Güvenilen Monero havuzlarının bir listesi
|
||||
pools_para2: buradadır.
|
||||
benchmarking: Donanım Karşılaştırma
|
||||
benchmarking_para1: Buraya tıklayarak
|
||||
benchmarking_para2: GPU/CPU'ların bir listesine ve sağlama oranlarına ulaşabilirsiniz.
|
||||
software: Madencilik Yazılımları
|
||||
software_para: Bazı madencilerin geliştirici ücreti olabileceğine dikkate alın.
|
||||
|
||||
using:
|
||||
translated: "yes"
|
||||
intro: Monero'yla işlem yapmak kolay olabilir. Bu sayfa kullanıcılara bu süreçte rehber olması için tasarlanmıştır.
|
||||
learn: 1. Öğrenin
|
||||
learn_para1: Monero güvenli, gizli ve takip edilemez bir kriptoparadır. Geliştiriciler ve topluluk kendilerini bu değerleri korumaya adamıştır.
|
||||
learn_para2: Monero Nedir
|
||||
learn_para3: sayfasını okuyarak daha fazlasını öğrenin.
|
||||
learn_para4: Kaynak kodu
|
||||
learn_para5: da incelemeye ve tartışmaya açıktır.
|
||||
support: 2. Destek İsteyin
|
||||
support_para1: Bir zorlukla karşılaşırsanız yardımcı olacak büyük ve destekçi bir topluluk var. Daha fazla bilgi için
|
||||
support_para2: Buluşmalar
|
||||
support_para3: sayfasını görüntüleyin.
|
||||
generate: 3. Bir Cüzdan Yaratın
|
||||
generate_para1: Bir Monero cüzdanı kendi fonlarınızı güvenlik altına almak için gereklidir. Mevcut cüzdanların bir listelemesi için
|
||||
generate_para2: İndirmeler sayfasını
|
||||
generate_para3: ziyaret edin.
|
||||
generate_para4: Ev bant aralığınızı etkilemeden bir Monero düğümü çalıştırmanın en kolay yolu bir VPS (Sanal Özel Sunucu) satın almaktadır. Güçlü bir şekilde
|
||||
generate_para5: ’i kullanmanızı tavsiye ediyoruz.
|
||||
generate_para6: kupon koduyla zaten ucuz olan aylık 6$’lık VPS'in yanında indirim alabilirsiniz. Bu kupon kodunu ve/veya
|
||||
generate_para7: işbirlik bağlantımızı
|
||||
generate_para8: kullanmak Monero gelişiminin devam eden fonlanmasına da yardımcı olacaktır.
|
||||
acquire: 4. Monero Elde Edin
|
||||
acquire_para1: Monero bir
|
||||
acquire_para2: borsa
|
||||
acquire_para3: dan itibari para veya diğer kriptoparalarla alınabilir. Monero elde etmenin başka bir yoluysa
|
||||
acquire_para4: madencilik,
|
||||
acquire_para5: yani işlemlerin değiştirilemez şekilde blokzincire kaydedildiği bilgi-sayımsal açıdan karmaşık bir süreçtir.
|
||||
send-receive: 5. Monero Gönderin ve Alın
|
||||
send-receive_para1: Nasıl Monero gönderip alındığını öğrenebileceğiniz
|
||||
send-receive_para2: rehber.
|
||||
transact: 6. Monero’yla İşlem Yapın
|
||||
transact_para1: Monero pek çok mal ve hizmetin alımında kullanılabilir. İşte bir listelemeye ulaşabileceğiniz
|
||||
transact_para2: Satıcılar sayfası.
|
||||
|
||||
what-is-monero:
|
||||
translated: "yes"
|
||||
need-to-know: Bilmeniz gerekenler
|
||||
leading: Monero gizliliğe ve sansüre dayanıklı işlemlere odaklanan önde gelen kriptoparadır.
|
||||
leading_para1: Bitcoin ve Ethereum’u da içeren var olan kriptoparaların çoğunun saydam blokzincirleri vardır, bu da işlemlerin Dünyadaki herkes tarafından açık şekilde doğrulanabildiği ve izlenebildiği anlamına gelir. Dahası bu işlemler için gönderici ve alıcı adreslerinin kişinin gerçek dünya kimliğine bağlanabilme potansiyeli vardır.
|
||||
leading_para2: Monero gönderici ve alıcı adreslerin yanı sıra gönderilen miktarları da korumak için kriptografi kullanır.
|
||||
confidential: Monero işlemleri mahremdir ve takip edilemez.
|
||||
confidential_para1: Her Monero işlemi varsayılan şekilde gönderici ve alıcı adreslerinin yanında gönderilen miktarları da karartır. Bu her zaman açık gizlilik, seçime bağlı saydamlıktaki kriptoparaların (örneğin Zcash) aksine her Monero kullanıcısının eylemlerinin diğer tüm kullanıcıların gizliliği arttırdığı anlamına gelir.
|
||||
confidential_para2: Monero değiştirilebilirdir. Karartmanın doğası gereği Monero önceki işlemlerde yer alması sebebiyle lekelenemez. Bu, Monero'nun sansür riski olmadan her zaman kabul edileceği anlamına gelir.
|
||||
confidential_para3: Kovri Projesi,
|
||||
confidential_para4: ki şu anda gelişim aşamasındadır
|
||||
confidential_para5: ", I2P Görünmez İnternet Projesi düğümleriyle işlemleri nakledecek ve şifreleyecektir. Bu işlemi gerçekleştirenin IP adresini karartacak ve ağ görüntülemesine karşı daha fazla koruma sağlayacak."
|
||||
grassroots: Monero Dünya’nın en iyi kriptopara araştırmacılarını ve mühendislik yeteneklerini çeken kökleşmiş bir topluluktur.
|
||||
grassroots_para1: 30 çekirdek geliştirici dahil,
|
||||
grassroots_para2: 500 geliştirici
|
||||
grassroots_para3: den fazlası Monero projesine katkıda bulunmuştur. Forumlar ve sohbet kanalları misafirperver ve aktiftir.
|
||||
grassroots_para4: Monero'nun Araştırma Laboratuvarı, Çekirdek Geliştirme Ekibi ve Topluluk Geliştiricileri kriptopara gizliliği ve güvenliğinde mümkün olanın sınırını sürekli şekilde ileriye taşımaktadır.
|
||||
grassroots_para5: Monero bir şirket değildir. Dünyanın dört bir yanından zamanlarını bağışlayan veya topluluk bağışlarıyla fonlanan kriptografi ve dağıtık sistemler uzmanlarınca geliştirilmektedir. Bu Monero’nun hiçbir ülke tarafından kapatılamayacağı ve hiçbir adli yargılama tarafından kısıtlanamayacağı anlamına gelir.
|
||||
electronic: Monero Dünya'nın her yerinden başka bir yerine hızlı, ucuz ödemelere olanak sağlayan elektronik paradır.
|
||||
electronic_para1: Çok sayıda bekletme günü ve sahtekâr ters ibraz riski yoktur. ’Sermaye kontrolleri'nden güvendedir - bunlar geleneksel paraların akışını, ekonomik istikrarsızlık yaşayan ülkelerde bazen uç noktalarda kısıtlayan önlemlerdir.
|
||||
videos: Monero Videoları (İngilizce)
|
||||
|
||||
about:
|
||||
translated: "yes"
|
||||
history: Kısa Bir Tarihi
|
||||
history_para1: Monero Nisan 2014’te faaliyete geçmişti. CryptoNote referans kodunun adil, önceden duyurulmuş bir yayınıydı. Ön-madeni veya anında-madeni yoktu ve blok ödülünün hiçbir kısmı geliştirmeye gitmez. Orijinal Bitcointalk başlığını
|
||||
history_para2: buradan
|
||||
history_para3: görüntüleyebilirsiniz. Kurucu thankful_for_today topluluğun kabul etmediği bazı tartışmalı değişiklikler önerdi. Bunu bir patlama takip etti ve Monero Çekirdek Ekibi, topluluğun bu yeni Çekirdek Ekibi takip etmesiyle projeyi çatalladı. Bu Çekirdek Ekip o zamandan beri gözetimi sağlıyor.
|
||||
history_para4: Monero faaliyete geçmesinden beri birçok büyük gelişim gerçekleştirdi. Blokzincir daha yüksek verimlilik ve esneklik sağlaması için başka bir veri tabanı yapısına taşındı, asgari halka imza boyutları tüm işlemlerin zorunlu şekilde gizli olması için ayarlandı ve RingCT işlem miktarlarını gizlemek için uygulamaya konuldu. Neredeyse tüm gelişimler güvenlik veya gizliliğe gelişim sağladı veya kullanımı kolaylaştırdı. Monero birinci sırada gizlilik ve güvenli, ikinci sırada kullanım kolaylığı ve verimlilik hedefleriyle gelişime devam ediyor.
|
||||
values: Değerlerimiz
|
||||
values_para: Monero bir teknolojiden fazlasıdır. Ayrıca teknolojinin simgesidir. Rehberlik eden önemli felsefelerden bazıları aşağıda listelenmiştir.
|
||||
security: Güvenlik
|
||||
security_para: Kullanıcılar hata veya saldırı riski olmadan işlemlerinde Monero'ya güvenebilmelidir. Monero bu güvenliği sağlayan ağın en önemli üyeleri olan madencilere tam blok ödülü verir. İşlemler mevcut en son ve en dirençli şifreleme araçları kullanılarak kriptografik açıdan güvenlidir.
|
||||
privacy: Gizlilik
|
||||
privacy_para: Monero gizliliği ciddiye alır. Monero'nun kullanıcılarını mahkemede ve uç durumlarda idam cezasından koruyabilmesi gerekir. Bu seviyedeki güvenlik teknolojik açıdan ehil olsalar da Monero’nun nasıl işlediğini hiç bilmeseler de tüm kullanıcılar tarafından tamamıyla erişilebilir olmalıdır. Bir kullanıcının Monero’ya bu kişinin diğerlerinin öğrenmesi riski sebebiyle harcama alışkanlıklarını değiştirme baskını hissetmeyecek şekilde eminlikle güvenmesi gerekir.
|
||||
decentralization: Merkeziyetsizlik
|
||||
decentralization_para: Monero en yüksek miktarda merkeziyetsizliği sağlamaya kendini adamıştır. Monero’yla ağda başka birine güvenmeniz gerekmez ve büyük bir grup tarafından işletilmemektedir. Erişilebilir bir “İş Kanıtı" algoritması normal bilgisayarlarda Monero’nun madenciliğini kolaylaştırır, bu da birinin yüksek miktarda madencilik gücü satın almasını zorlaştırır. Düğümler hassas işlem bilgisinin açığa çıkma ve sansür riskini azaltmak için birbirine I2P ile bağlanır. Geliştirici görüşme kayıtları bütünüyle çevrimiçi yayınlanır ve herkes tarafından görülebilir.
|
||||
|
||||
|
||||
developer-guides:
|
||||
translated: "yes"
|
||||
outdated: "Lütfen dikkate alın: Aşağıdaki rehberler topluluk tarafından yakında yenilenmiştir ve neredeyse güncel şekilde sürülmektedir. Ancak yöntemler sıklıkla eklenmekte / kaldırılmakta / güncellenmektedir ve burada isabetli şekilde anlatılmamış olabilir."
|
||||
rpc: RPC Belgelendirmesi
|
||||
daemonrpc: Daemon RPC Belgelendirmesi
|
||||
walletrpc: Cüzdan RPC Belgelendirmesi
|
||||
soon: Dahası pek yakında...
|
||||
|
||||
user-guides:
|
||||
translated: "yes"
|
||||
general: Genel
|
||||
mining: Madencilik
|
||||
recovery: Geri Alma
|
||||
wallets: Cüzdanlar
|
||||
offline-backup: Çevrimdışı yedek alımı
|
||||
vps-node: VPS’te düğüm çalıştırılması
|
||||
import-blockchain: Monero blokzincirinin içe aktarımı
|
||||
monero-tools: Monero Araçları
|
||||
purchasing-storing: Güvenli şekilde Monero alımı ve depolaması
|
||||
verify-allos: İkilileri Linux, Mac veya Windows komut satırında doğrulayın (ileri düzey)
|
||||
verify-windows: İkilileri Windows'da doğrulayın (başlangıç seviyesi)
|
||||
mine-on-pool: xmr-stak-cpu ile bir havuzda madencilik yapımı
|
||||
solo-mine: GUI ile tek başına madencilik yapımı
|
||||
mine-docker: Docker ve XMRig ile madencilik
|
||||
locked-funds: Kilitlenmiş fonlar düzeltilmesi
|
||||
restore-account: Hesabınızın geri alımı
|
||||
qubes: CLI cüzdan/daemon’ın Qubes + Whonix ile izolasyonu
|
||||
cli-wallet: CLI cüzdana başlangıç
|
||||
remote-node-gui: GUI cüzdan içerisinde uzak bir düğüme bağlanılması
|
||||
view-only: Sadece görüntülenir bir cüzdan yapımı
|
||||
prove-payment: Ödeme kanıtlanması
|
||||
restore-from-keys: Anahtarlardan cüzdanın geri alınması
|
||||
nicehash: Madencilik ekipmanı olmadan Monero XMR madenciliği yapımı
|
||||
ledger-wallet-cli: CLI (monero-wallet-cli) ile Ledger Monero cüzdanı üretimi
|
||||
multisig-messaging-system: MMS ve CLI cüzdanla çoklu-imza işlemleri
|
||||
|
||||
roadmap:
|
||||
translated: "yes"
|
||||
completed: Tamamlanmış görev
|
||||
ongoing: Devam eden görev
|
||||
upcoming: Yaklaşan görev
|
||||
future: Gelecek
|
||||
|
||||
|
||||
research-lab:
|
||||
translated: "yes"
|
||||
intro: Monero sadece değiştirilebilir bir para yaratmaya değil, kriptoparaları içermesiyle finansal gizlilik alemine sürekli araştırmaya da kendini adamıştır. Aşağıda Monero Araştırma Laboratuvarı’mızın gelecek olan daha fazla makalesiyle mevcut işlerini bulacaksınız.
|
||||
mrl_papers: Monero Araştırma Laboratuvarı Makaleleri (İngilizce)
|
||||
abstract: Özet
|
||||
introduction: Giriş
|
||||
read-paper: Makaleyi Oku
|
||||
mrl1: CryptoNote 2.0’da Zincir Reaksiyonlarda Takip Edilebilirlik Üzerine Bir Not
|
||||
mrl1_abstract: Bu araştırma bülteni anonim sisteme dayalı bir halka imza üzerinde makul bir saldırıyı betimler. 2012’de Nicolas van Saberhagen tarafından görünürde yayınlanan kriptopara protokolü CryptoNote 2.0’ı motivasyon olarak kullanıyoruz. Daha önce tek kullanımlık anahtar çiftini karartan takip edilemezliğin o halka imzayı oluşturmakta kullanılan anahtarların tümünün takip edilemezliğine dayanabileceği gösterilmişti. Bu, halka imzalar arasındaki takip edilebilirlikte zincir reaksiyonların olasılığına izin vererek parametrelerin yetersiz seçildiğinde ve bir saldırganın ağın yeterli yüzdesine sahip olduğunda tüm ağ çapında takip edilemezlikte kritik bir kayba sebep olur. İmzalar hâlâ tek kullanımlık olsa da böyle bir saldırı zorunlu şekilde kullanıcıların anonimliğini ihlal etmez. Ancak böyle bir saldırı, CryptoNote’un blokzincir analizine karşı gösterdiği direnci makul şekilde zayıflatabilir. Bu araştırma bülteni akran değerlendirmesinden geçmemiştir ve sadece dahili araştırma sonuçlarını yansıtır.
|
||||
mrl2: CryptoNote Protokolünü Barındıran Sanal Paralar İçerisinde Merkle Ağacı Suistimalleri Aracılığıyla Sahtecilik
|
||||
mrl2_abstract: 4 Eylül 2014’te sıra dışı ve alışılmamış bir saldırı Monero kriptopara ağına karşı gerçekleştirildi. Bu saldırı, ağı diğer altkümenin meşruluğunu kabul etmeyi reddeden iki ayrı altkümeye böldü. Bu tamamı henüz bilinmeyen çok sayıda etkiye sahipti. Saldırgan örneğin bu esnada bir çeşit sahteciliğin oluşabileceği kısa bir zaman aralığına sahipti. Bu araştırma bülteni bu saldırıya olanak sağlayan CryptoNote referans kodundaki yetersizlikleri betimler, ilk olarak Tigusoft.pl’den Rafal Freeman ve sonrasında CryptoNote ekibi tarafından öne sürülen çözümü betimler, Monero kod temelindeki mevcut düzeltmeyi betimler ve sorun yaratan bloğun ağa tam olarak ne yaptığı üzerinde durur. Bu araştırma bülteni akran değerlendirmesinden geçmemiştir ve sadece dahili araştırma sonuçlarını yansıtır.
|
||||
mrl3: Monero O Kadar da Gizemli Değil
|
||||
mrl3_abstract: Son zamanlarda örneğin Bitcoin’den daha karmaşık bir protokol olması gerçeğine dayanarak CryptoNote kaynak kodu ve protokolü hakkında internette dolaşan bazı belirsiz korkular ortaya çıkmıştır. Bu notun amacı bazı kavram hatalarını aydınlatmaya ve ümitle Monero Halka İmzaları saran gizemlerden bazılarını ortadan kaldırmaya çalışmaktır. ([CN]de betimlendiği şekliyle) CryptoNote halka imzalarında yer alan matematiği CryptoNote temelli [FS]deki matematikle kıyaslayarak başlayacağım. Bunun ardından halka imzaların matematiğini CryptoNote kod temelinde aslında olanla kıyaslayacağım.
|
||||
mrl4: CryptoNote Protokolündeki Karartmayı Geliştirmek
|
||||
mrl4_abstract: CryptoNote 2.0 protokolünün takip edilemezliğini indirgemeye müsait çeşitli blokzincir analiz saldırılarını tanımlıyoruz. Mevcut çözümleri analiz ediyor, bu çözümlerin görece faydalarını ve eksikliklerini tartışıyor ve ümitle blokzincir analizine karşı uzun vadeli kriptopara direnci sağlayacak Monero protokolüne gelişmeleri tavsiye ediyoruz. Monero’ya tavsiye ettiğimiz gelişmeler halka imza başına protokol seviyesinde, ağ çapında en az n = 2 yabancı çıktı katma poliçesini, iki yılın ardından protokol seviyesinde bu değerin n = 4’e bir artışı ve aradaki zamanda cüzdan seviyesinde n = 4 varsayılan değerini içerir. Ayrıca Monero çıktısı gönderiminin torrent tarzında bir yöntemi öneriyoruz. Ayrıca burada tanımlanan diğer blokzincir analiz şekillerini azaltmak için düzensiz, yaşa bağlı bir katma seçme yöntemini tartışıyoruz; ancak çeşitli sebeplerden dolayı uygulanması üzerine formal tavsiyelerde bulunmuyoruz. Bu gelişmeleri takip eden sonuçlar ayrıca bir miktar detayla tartışıldı. Bu araştırma bülteni akran değerlendirmesinden geçmemiştir ve sadece dahili araştırma sonuçlarını yansıtır.
|
||||
mrl5: Halka İmza Gizli İşlemleri
|
||||
mrl5_abstract: Bu makale yüksek şekilde merkeziyetsiz olan anonim kriptopara Monero’da işlem miktarlarını gizlemenin bir yöntemini tanıtır. Bitcoin’e benzer şekilde Monero bir iş kanıtı “madencilik“ süreci yoluyla dağıtık olan bir kriptoparadır. Orijinal Monero protokolü işlemlerin varış noktasını ve kökenini gizleyen halka imzalar ve tek kullanımlık anahtarlar kullanan CryptoNote’u temel alıyordu. Son zamanlarda bir işlemin miktarını gizlemek için bir üstlenme şemasının kullanılma tekniği Bitcoin Core Geliştirici Gregory Maxwell tarafından tartışılmış ve uygulanmıştır. Bu makalede işlemlerin gizli miktarlarına, kökenlerine ve varış noktalarına makul verimlilik ve doğrulanabilirlikle, güvensiz para üretimine olanak sağlayan yeni bir halka imza türü olan Çok-katmanlı Bağlanabilir Spontane Anonim Grup imzası betimlenmiştir. Protokolün Toplam Schnorr Seri Kanıtları ve Halka Çoklu-imzaları gibi uzantıları sağlanmıştır. Yazar bunun erken taslaklarının Monero Topluluğunda ve Bitcoin araştırma irc kanalında yayınlandığının dikkate alınmasını istemektedir. Bu işin 2015 Yazı’nda başladığını ve Ekim 2015 başında tamamlandığını gösteren blokzincir sağlamalı taslaklar [14]’de bulunabilir. Bir e-baskı ayrıca http://eprint.iacr.org/2015/1098 adresinde bulunabilir.
|
||||
mrl6: Monero Altadreslerinin Verimli Bir Uygulaması
|
||||
mrl6_abstract: Bağlanamaz bir şekilde cüzdan adreslerini tekrar kullanmayı dileyen Monero kriptoparası kullanıcıları her biri için gelen işlemleri taramayı zorunlu kılan ayrı cüzdanlar sürdürmek zorundadır. Bir kullanıcının tek bir temel cüzdan adresi sürdürmesine ve keyfi bir sayıda bağlanamayan altadres üretmesine olanak sağlayan yeni bir adres şeması belgeliyoruz. Her işlemin kullanıcının altadreslerinden birine varıp varmadığını belirlemek için sadece bir kez taranması gerekir. Şema diğer altadreslere çoklu çıktıyı ek olarak destekler ve geleneksel cüzdan işlemleri kadar verimlidir.
|
||||
mrl7: Harcanmış Çıktıların Kümeleri
|
||||
mrl7_abstract: Bu teknik not temel küme kuramını kullanarak harcama çıktıları kavramını genelleştirir. Tanım böyle çıktıları tanımla üzerindeki önceden yapılan çeşitli işleri kapsar. Bu analizin Monero blokzinciri üzerinde etkileri nitelendiriyor ve azaltımlarına kısa bir genel bakış veriyoruz.
|
||||
mrl8: Çifte Bağlanabilir Halka İmzalar
|
||||
mrl8_abstract: Bu bülten halka üyesi olarak çifte anahtar çıktıları izin veren Monero'nun bağlanabilir halka imza şemasına bir değişikliği betimler. Anahtar imgeler bir çift olarak çıktı tek kullanımlık açık anahtarlara bağlanarak bu işlemdeki iki anahtarın ayrı şekilde harcanmasını engeller. Bu yöntemin etkileşimsiz geri ödeme işlemlerinde uygulamaları vardır. Şemanın güvenlik çıkarımlarını tartışıyoruz.
|
||||
mrl9: Eşhalka İmzaları ve Harcayıcı-Belirsiz Dijital Paralara Uygulamaları
|
||||
mrl9_abstract: Halka imzaların işbirlikçi bilgi-sayımı için eşik halka çoklu imzaları (eşhalka imzalar) sunuyor, eşhalka imzaları için varoluşsal bir tahrifat oyunu sunuyor ve güvenilir bir kurulum olmadan gizli miktarların harcayıcı-belirsiz çapraz-zincir atomik değişimlerini içeren dijital paralarda eşhalka imzaların kullanımını tartışıyoruz. Eşhalka imzaların bağlanabilir spontane eşit anonim grup imzaları dediğimiz bir uygulamasını sunuyor ve uygulamanın varoluşsal açıdan tahrif edilemeyeceğini kanıtlıyoruz.
|
||||
mrl10: Gruplar Arası Ayrık Logaritma Denkliği
|
||||
mrl10_abstract: Bu teknik not farklı gruplar arasında aynı ayrık logaritmanın bilgisini kanıtlamakta kullanılan bir algoritmayı betimler. Şema bitlerin skalar bir temsilini ortak değer olarak ifade eder ve bir halka imzalar kümesini her bitin iki skalar grup arasında (bir denkliğe kadar) aynı olan geçerli bir değer olduğunu kanıtlamak için kullanır.
|
||||
cryptonote: Cryptonote Beyaz Bültenleri
|
||||
cryptonote-whitepaper: Cryptonote Beyaz Bülteni
|
||||
cryptonote-whitepaper_para: Bu, Cryptonote ekibi tarafından yazılan orijinal cryptonote makalesidir. Okumak size cryptonote algoritmasının genelde nasıl çalıştığı anlayışını verecektir.
|
||||
annotated: Açıklamalı Beyaz Bülten
|
||||
annotated_para: Monero Araştırma Laboratuvarı cryptonote beyaz bülteninin açıklamalı bir sürümünü yayınladı. Bu, beyaz bültende bulunulan iddiaların satır satır enformal bir incelemesi gibidir. Ayrıca daha zor kavramların bazılarını anlaşılması görece daha kolay terimlerle açıklar.
|
||||
brandon: Brandon Goodell'ın Beyaz Bülten İncelemesi
|
||||
brandon_para: Bu makale orijinal cryptonote makalesinin MRL araştırmacısı Brandon Goodell tarafından yapılan formal bir incelemesidir. Cryptonote makalesinde sunulan iddialara ve matematiğe derinlemesine bakar.
|
||||
|
||||
|
||||
specs:
|
||||
translated: "yes"
|
||||
fair_title: Ön-maden yok, anında-maden yok, jeton yok
|
||||
fair_premine: Monero'nun ön-madeni veya anında-madeni yoktu
|
||||
fair_token: Monero hiç jeton satmadı
|
||||
fair_presale: Monero'nun hiçbir şekilde önsatışı yoktu
|
||||
pow_title: İş Kanıtı
|
||||
pow_name: CryptoNight
|
||||
pow_disclaimer: gelecekte değişebilir
|
||||
diff_title: Zorluk tekrar hedeflemesi
|
||||
diff_freq: her blokta
|
||||
diff_base: zaman damgası uç değerlerinin %20'si hariç, son 720 bloka dayanır
|
||||
block_time_title: Blok zamanı
|
||||
block_time_duration: 2 dakika
|
||||
block_time_disclaimer: salınım eğrisi korunduğu sürece gelecekte değişebilir
|
||||
block_reward_title: Blok ödülü
|
||||
block_reward_amount: pürüzsüzce azalan ve son 100 blokun medyan boyutundan (M100) büyük bloklar için cezaya tabii
|
||||
block_reward_example1: şu anki ödül için
|
||||
block_reward_example_link: son blok
|
||||
block_reward_example2: paratabanı işlem miktarını görüntüleyin
|
||||
block_size_title: Blok boyutu
|
||||
block_size: dinamik, en fazla 2 * M100
|
||||
block_emission_title: Salınım eğrisi
|
||||
block_emission_main: "önce, ana eğri: Mayıs 2022 sonuna kadar ~18.132 milyon para"
|
||||
block_emission_tail: "sonra, uç eğrisi: 2 dakikalık blok başına 0.6 XMR, ana salınım bittiğinde geçerli, zamanla azalan <%1 enflasyona çevrilir"
|
||||
block_emission_disclaimer1: "Görüntüleyin:"
|
||||
block_emission_disclaimer_link: çizelgeler ve detaylar
|
||||
supply_title: Azami arz
|
||||
supply_amount: sonsuz
|
||||
sender_privacy_title: Gönderici gizliliği
|
||||
sender_privacy_mode: Halka imzalar
|
||||
recipient_privacy_title: Alıcı gizliliği
|
||||
recipient_privacy_mode: Hayalet adresler
|
||||
amount_hidden_title: Miktar karartma
|
||||
amount_hidden_mode: Halka gizli işlemler
|
||||
|
||||
library:
|
||||
translated: "yes"
|
||||
description: "Aşağı indirebileceğiniz bazı yayınlar, kitaplar ve dergiler yer almaktadır."
|
||||
books:
|
||||
- category: Kitaplar
|
||||
publications:
|
||||
- name: "Sıfırdan Monero'ya"
|
||||
file: "Zero-to-Monero-1-0-0.pdf"
|
||||
abstract: >
|
||||
Monero'nun kapsamlı kavramsal (ve teknik) bir açıklaması.<br>
|
||||
Temel cebir ve bir sayının 'bit temsili' gibi basit bilgisayar bilimi kavramları bilen herkese sadece Monero'nun derin ve kapsamlı bir seviyede nasıl işlediğini değil, ayrıca kriptografinin ne kadar kullanışlı ve güzel olabileceğini öğretmeye çabalıyoruz.
|
||||
- name: "Monero'da Ustalaşmak (Önizleme)"
|
||||
file: "Mastering-Monero-Preview.pdf"
|
||||
abstract: >
|
||||
Monero'nun karışık görünen dünyasına bir rehber.<br>
|
||||
Şunları içerir:
|
||||
<ul><li>Blokzincirlere ve gizliliğin önemine geniş bir giriş - teknik olmayan kullanıcılar için idealdir.</li>
|
||||
<li>Bitcoin'in eksikliklerinin ve Monero tarafından sunulan belirli çözümlerin tartışması.</li>
|
||||
<li>(Monero'nun gizliliğinizi nasıl koruduğunu sergileyen) kullanıcı hikayeleri, analojiler, örnekler, yasal/etik tartışmalar ve temel teknik kavramları sergileyen kod parçacıkları.</li>
|
||||
<li>Monero merkeziyetsiz ağının, eşler-arası mimarinin, işlem yaşam döngüsünün ve güvenlik prensiplerinin detayları.</li>
|
||||
<li>Geliştiricilere, mühendislere, yazılım mimarlarına ve meraklı kullanıcılara yönelik Monero'nun teknik temellerinin tanıtımları.</li>
|
||||
<li>Kovri, Kurşun-geçirmezler, Çoklu-imzalar, Donanım Cüzdanları vs. gibi yeni gelişmeler.</li></ul>
|
||||
Tam sürümü hakkında bilgi için <a href="https://masteringmonero.com/">Monero'da Ustalaşmak</a> internet sayfasını görüntüleyin.
|
||||
- category: Dergiler
|
||||
publications:
|
||||
- name: "Revuo Monero 2017 Ç4"
|
||||
file: "Revuo-2017-Q4.pdf"
|
||||
abstract: >
|
||||
Aylık Monero dergisi, 2017 Ç4 baskısı.<br>
|
||||
Bu sayıdaki güncellemeler: gelişim, Monero Araştırma Laboratuvarı, Kovri ve topluluk.
|
||||
- name: "Revuo Monero 2017 Ç3"
|
||||
file: "Monero-Revuo-3Q-2017.pdf"
|
||||
abstract: >
|
||||
Aylık Monero dergisi, 2017 Ç3 baskısı.<br>
|
||||
Bu sayıdaki güncellemeler: gelişim, Monero Araştırma Laboratuvarı, Kovri, topluluk, Donanım ve Monerujo.
|
||||
|
||||
moneropedia:
|
||||
translated: "yes"
|
||||
add_new_button: Yeni Girdi Ekleyin
|
||||
add_new_text1: Değiştirmek veya eklemek istediğiniz bir girdi varsa lütfen
|
||||
add_new_link: bu sitenin GitLab deposunda bir sorun açın
|
||||
add_new_text2: veya değişiklikleri iste talebiyle bildirin
|
||||
entries:
|
||||
account: Hesap
|
||||
address-book: Adres Defteri
|
||||
address: Adres
|
||||
airgap: Hava Aralığı
|
||||
atomic-units: Atomik Birimler
|
||||
base32-address: Temel32 adres
|
||||
base64-address: Temel64 adres
|
||||
blockchain: Blokzincir
|
||||
block: Blok
|
||||
bootstrap-node: Önyükleme-düğümü
|
||||
bulletproofs: Kurşun-geçirmezler
|
||||
canonically-unique-host: Kanonik-benzersiz barındırıcı
|
||||
change: Değiştir
|
||||
clearnet: Açıkağ
|
||||
coinbase: Paratabanı İşlemi
|
||||
consensus: Uzlaşım
|
||||
cryptocurrency: Kriptopara
|
||||
data-directory: Veri Rehberi
|
||||
denominations: Birimler
|
||||
destination: Varış Noktası
|
||||
eepsite: Uupsite
|
||||
encryption: Şifreleme
|
||||
floodfill: Taşkındolgu
|
||||
fluffyblocks: Pofuduk Bloklar
|
||||
fungibility: Değiştirilebilirlik
|
||||
garlic-encryption: Sarımsak-Şifreleme
|
||||
garlic-routing: Sarımsak Yöneltme
|
||||
i2np: I2NP
|
||||
i2pcontrol: I2PKontrol
|
||||
i2p: I2P
|
||||
in-net: In-ağ
|
||||
java-i2p: Java I2P
|
||||
jump-service: Zıplama Hizmeti
|
||||
kovri: Kovri
|
||||
lease: İcar
|
||||
lease-set: İcar-Küme
|
||||
locally-unique-host: Yerel-benzersiz barındırıcı
|
||||
message: Mesaj
|
||||
mining: Madencilik
|
||||
mnemonicseed: Anımsatıcı Tohum
|
||||
network-database: Ağ Veri Tabanı
|
||||
node: Düğüm
|
||||
ntcp: NTCP
|
||||
openalias: OpenAlias
|
||||
paperwallet: Kâğıt Cüzdan
|
||||
paymentid: Ödeme ID
|
||||
pedersen-commitment: Pedersen Üstlenmesi
|
||||
reseed: Tekrar-tohum
|
||||
ringCT: Halka CT
|
||||
ringsignatures: Halka İmza
|
||||
ring-size: Halka Boyutu
|
||||
router-info: Yöneltici-Bilgi
|
||||
scalability: Ölçeklenebilirlik
|
||||
signature: Kriptografik İmza
|
||||
smartmining: Akıllı Madencilik
|
||||
spendkey: Harcama Anahtarı
|
||||
ssu: SSU
|
||||
stealthaddress: Hayalet Adres
|
||||
subscription: Abonelik
|
||||
tail-emission: Uç Salınım
|
||||
transaction: İşlemler
|
||||
transports: İletim
|
||||
tunnel: Tünel
|
||||
unlocktime: İşlem Kilit Açma Zamanı
|
||||
viewkey: Görüntüleme Anahtarı
|
||||
wallet: Cüzdan
|
||||
|
||||
blog:
|
||||
title_1: Hepsi
|
||||
title_2: Blog
|
||||
title_3: Gönderilen
|
||||
tagged: Etiketler
|
||||
author: Gönderen
|
||||
date: Gönderim tarihi
|
||||
forum: Monero Forum'daki bu girdi için tartışmaya katılmak için buraya tıklayın
|
||||
|
||||
tags:
|
||||
all: Etiketlere göre Makaleler
|
||||
notags: Bu etiket için gönderi yok.
|
||||
2377
_i18n/tr/resources/developer-guides/daemon-rpc.md
Normal file
2377
_i18n/tr/resources/developer-guides/daemon-rpc.md
Normal file
File diff suppressed because it is too large
Load diff
2734
_i18n/tr/resources/developer-guides/wallet-rpc.md
Normal file
2734
_i18n/tr/resources/developer-guides/wallet-rpc.md
Normal file
File diff suppressed because it is too large
Load diff
8
_i18n/tr/resources/moneropedia/00-base-00
Normal file
8
_i18n/tr/resources/moneropedia/00-base-00
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
terms: ["", ""]
|
||||
summary: ""
|
||||
---
|
||||
|
||||
### The Basics
|
||||
|
||||
<Re-write summary here>
|
||||
80
_i18n/tr/resources/moneropedia/account.md
Normal file
80
_i18n/tr/resources/moneropedia/account.md
Normal file
|
|
@ -0,0 +1,80 @@
|
|||
---
|
||||
terms: ["account", "accounts", "wallet", "wallets"]
|
||||
summary: "similar in function to a bank account, contains all of your sent and received transactions"
|
||||
---
|
||||
|
||||
### The Basics
|
||||
|
||||
Those familiar with Monero's predecessors will be more familiar with the term *wallet* to describe this. In Monero we call this an account, and it is a private account owned and operated by a Monero user.
|
||||
|
||||
Your account contains all of the Monero @transactions you have sent and received. Your account balance is a sum of all the Monero you've received, less the Monero you've sent. When using Monero you may notice that your account has two balances, a locked and an unlocked balance. The unlocked balance contains funds that can be spent immediately, and the locked balance contains funds that you can't spend right now. You may receive a transaction that has an @unlock-time set, or you may have sent some Monero and are waiting for the @change to come back to your wallet, both situations that could lead to those funds being locked for a time.
|
||||
|
||||
A key difference between traditional electronic currency and Monero is that your account resides only under your control, normally on your computer, and cannot be accessed by anyone else if you [practice good security](#practicing-good-security).
|
||||
|
||||
### Multiple Accounts
|
||||
|
||||
There are no costs attached to creating a Monero account, and there are no fees charged except for individual @transaction fees that go to @miners.
|
||||
|
||||
This means that individuals can easily create a Monero account for themselves as well as a joint account to share with their partner, and individual accounts for their children. Similarly, a business could create separate accounts for each division or group. Since Monero's @transaction fees are quite low, moving funds between accounts is not an expensive exercise.
|
||||
|
||||
### Cryptographic Keys
|
||||
|
||||
Monero relies heavily on a cryptography principle known as *public/private key cryptography* or *asymmetric cryptography*, which is thoroughly detailed in [this Wikipedia article](https://en.wikipedia.org/wiki/Public-key_cryptography).
|
||||
|
||||
Your account is based on two keys, a @spend-key and a @view-key. The @spend-key is special in that it is the single key required to spend your Monero funds, whereas the @view-key allows you to reveal your @transactions to a third party, for example for auditing or accounting purposes. These keys in your account also play an important role in Monero's @transaction's privacy.
|
||||
|
||||
The private keys for both of these must be protected by you in order to retain your account privacy. On the other hand, the public keys are obviously public (they are part of your Monero account address). For normal public/private key cryptography someone could send you a private message by encrypting it with either of your public keys, and you would then be the only one able to decrypt it with your private keys.
|
||||
|
||||
### Backing Up Your Account
|
||||
|
||||
When you manage your own Monero Account with the private @spend-key, you are solely responsible for the security of your funds. Thankfully, Monero makes it very easy to backup your account. When creating a Monero account for the first time you will be given a unique @mnemonic-seed for your account that consists of 13 or 25 words in the language of your choosing. **This seed is the only thing you need to backup for your account**, and so it is imperative that it is written down and stored securely. Never store this seed in a form or location that would allow someone else to see it!
|
||||
|
||||
```
|
||||
List of available languages for your wallet's seed:
|
||||
0 : Deutsch
|
||||
1 : English
|
||||
2 : Español
|
||||
3 : Français
|
||||
4 : Italiano
|
||||
5 : Nederlands
|
||||
6 : Português
|
||||
7 : русский язык
|
||||
8 : 日本語
|
||||
9 : 简体中文 (中国)
|
||||
10 : Esperanto
|
||||
Enter the number corresponding to the language of your choice: 1
|
||||
Generated new wallet: 4B15ZjveuttEaTmfZjLVioPVw7bfSmRLpSgB33CJbuC6BoGtZrug9TDAmhZEWD6XoFDGz55bgzisT9Dnv61sbsA6Sa47TYu
|
||||
view key: 4130fa26463d9451781771a8baa5d0b8085c47c4500cefe4746bab48f1d15903
|
||||
**********************************************************************
|
||||
Your wallet has been generated.
|
||||
To start synchronizing with the daemon, use "refresh" command.
|
||||
Use "help" command to see the list of available commands.
|
||||
Always use "exit" command when closing monero-wallet-cli to save your
|
||||
current session's state. Otherwise, you might need to synchronize
|
||||
your wallet again (your wallet keys are NOT at risk in any case).
|
||||
|
||||
PLEASE NOTE: the following 25 words can be used to recover access to your wallet. Please write them down and store them somewhere safe and secure. Please do not store them in your email or on file storage services outside of your immediate control.
|
||||
|
||||
aunt knuckle italics moisture hawk thorn iris abort
|
||||
chlorine smog uphill glass aptitude nowhere sewage plywood
|
||||
dual relic fierce divers anvil nodes bubble cabin abort
|
||||
**********************************************************************
|
||||
Starting refresh...
|
||||
Refresh done, blocks received: 21939
|
||||
Balance: 0.000000000000, unlocked balance: 0.000000000000
|
||||
Background refresh thread started
|
||||
[wallet 4B15Zj]: █
|
||||
|
||||
```
|
||||
|
||||
As the example above indicates, it is incredibly important to store these words in safe locations. If you are concerned about the risk of critical loss at your home, for instance, you may want to store a second copy of your seed with your attorney or in a safety deposit box. It is also recommended that it is stored in a way that does not make it obvious that it is your seed, so writing it into a letter or as part of other notes is advisable.
|
||||
|
||||
### Practicing Good Security
|
||||
|
||||
Over and above backing up your @mnemonic-seed so that you have access to your account in the event of critical data loss, it is also important to practice good security. Use a secure password when creating a local Monero account (not used on [MyMonero](https://mymonero.com) or other web-based account systems).
|
||||
|
||||
Don't ever give your Monero account password to anyone, as this can be used to access the Monero on your computer without knowing your @mnemonic-seed. Similarly, make sure you have running and up-to-date antivirus, especially on Windows computers. Finally, be careful when clicking links in emails or on unknown and untrusted websites, as malware installed on your computer can sit and wait for you to access your Monero account before taking the funds from it.
|
||||
|
||||
### Leaving Your Account to Next of Kin
|
||||
|
||||
Providing access to your Monero account to your next of kin is just as easy as it is to backup your Monero account. Simply leave your @mnemonic-seed to them in your will, or store it somewhere safe where it will be given to them upon the execution of your will. A key advantage to this is that your next of kin won't have to wait for months for a third party to release the funds to them.
|
||||
33
_i18n/tr/resources/moneropedia/address-book.md
Normal file
33
_i18n/tr/resources/moneropedia/address-book.md
Normal file
|
|
@ -0,0 +1,33 @@
|
|||
---
|
||||
tags: ["kovri"]
|
||||
terms: ["Address-Book"]
|
||||
summary: "Allows you to visit I2P websites/services that have the .i2p domain"
|
||||
---
|
||||
|
||||
### The Basics
|
||||
|
||||
In order to browse @I2P sites or services with @Kovri, you'll need an address book. An address book will allow you to translate @I2P websites/services that use the `.i2p` [top-level domain](https://en.wikipedia.org/wiki/Top_level_domain) into an address that @I2P network will understand.
|
||||
|
||||
Without an address book, you would be stuck using a @base32-address every time you visit an @I2P website/service - and that's not fun!
|
||||
|
||||
### In-depth information
|
||||
|
||||
Since [DNS](https://en.wikipedia.org/wiki/DNS) does not exist on the @I2P network, @Kovri also does **not** use DNS or any sort of @canonically-unique-host resolution. Instead, Kovri pairs a @locally-unique-host to a @base64-address @destination in a @subscription. Once your address book is filled with a @subscription, you can resolve your favorite `.i2p` domain site into a usable @I2P destination.
|
||||
|
||||
### Creating an Address Book
|
||||
|
||||
By default, your installation will come with a default public @subscription called `hosts.txt` in your @data-directory. When @Kovri starts, it loads this subscription and fetches any other subscriptions you've specified. Once loaded, your address book will be appropriately filled. For details on how to manage subscriptions, see @subscription.
|
||||
|
||||
### Updating the Address Book
|
||||
|
||||
Currently, there are several ways to update your address book:
|
||||
|
||||
1. Use a @jump-service to insert I2P addresses into your address book
|
||||
2. Use a @jump-service to copy/paste an address into your private @subscription
|
||||
3. Manually add or subtract from a private @subscription
|
||||
|
||||
**Note: Kovri is in heavy development. In the future there *will* be easier ways to update the address book**
|
||||
|
||||
### Address Book / Naming specification
|
||||
|
||||
For specification details and more, visit the [Address Book and Naming Specification](https://geti2p.net/en/docs/naming)
|
||||
20
_i18n/tr/resources/moneropedia/address.md
Normal file
20
_i18n/tr/resources/moneropedia/address.md
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
terms: ["address", "addresses"]
|
||||
summary: "either an alias, such as donate.getmonero.org, or a set of 95 characters starting with a 4"
|
||||
---
|
||||
|
||||
### The Basics
|
||||
|
||||
When you send Monero to someone you only need one piece of information, and that is their Monero address. A *raw* Monero address is a set of 95 characters starting with a '4'. The Monero donation address, for instance, is <span class="long-term">44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A</span>.
|
||||
|
||||
Because those addresses are long and complex, you will often encounter an @OpenAlias address instead. For example, Monero donations can be sent to <span class="long-term">donate@getmonero.org</span> or <span class="long-term">donate.getmonero.org</span>.
|
||||
|
||||
If you would like to get an @OpenAlias address of your own then there is some information on the [OpenAlias page](/resources/openalias).
|
||||
|
||||
### Integrated address
|
||||
|
||||
An integrated address is an address combined with an encrypted 64-bit @payment-ID. A raw integrated address is 106 characters long.
|
||||
|
||||
### In-depth Information
|
||||
|
||||
The address is actually the concatenation, in Base58 format, of the *public* @spend-key and the *public* @view-key, prefixed with the network byte (the number 18 for Monero) and suffixed with the first four bytes of the Keccac-256 hash of the whole string (used as a checksum).
|
||||
10
_i18n/tr/resources/moneropedia/airgap.md
Normal file
10
_i18n/tr/resources/moneropedia/airgap.md
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
---
|
||||
terms: ["airgap"]
|
||||
summary: "An airgap is a security measure to physically separate a computer or device from all other networks, such as the Internet."
|
||||
---
|
||||
|
||||
### The Basics
|
||||
|
||||
"An air gap, air wall or air gapping is a network security measure employed on one or more computers to ensure that a secure computer network is physically isolated from unsecured networks, such as the public Internet or an unsecured local area network.[2] The name arises from the technique of creating a network that is physically separated (with a conceptual air gap) from all other networks. The air gap may not be completely literal, as networks employing the use of dedicated cryptographic devices that can tunnel packets over untrusted networks while avoiding packet rate or size variation can be considered air gapped, as there is no ability for computers on opposite sides of the gap to communicate."
|
||||
|
||||
Taken from https://en.wikipedia.org/wiki/Air_gap_(networking)
|
||||
10
_i18n/tr/resources/moneropedia/atomic-units.md
Normal file
10
_i18n/tr/resources/moneropedia/atomic-units.md
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
---
|
||||
terms: ["atomic-units", "atomic-unit"]
|
||||
summary: "Atomic Units refer to the smallest fraction of 1 XMR."
|
||||
---
|
||||
|
||||
### The Basics
|
||||
|
||||
Atomic Units refer to the smallest fraction of 1 XMR.
|
||||
One atomic unit is currently 1e-12 XMR (0.000000000001 XMR, or one @piconero).
|
||||
It may be changed in the future.
|
||||
25
_i18n/tr/resources/moneropedia/base32-address.md
Normal file
25
_i18n/tr/resources/moneropedia/base32-address.md
Normal file
|
|
@ -0,0 +1,25 @@
|
|||
---
|
||||
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`**
|
||||
20
_i18n/tr/resources/moneropedia/base64-address.md
Normal file
20
_i18n/tr/resources/moneropedia/base64-address.md
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
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
|
||||
14
_i18n/tr/resources/moneropedia/block.md
Normal file
14
_i18n/tr/resources/moneropedia/block.md
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
---
|
||||
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.
|
||||
10
_i18n/tr/resources/moneropedia/blockchain.md
Normal file
10
_i18n/tr/resources/moneropedia/blockchain.md
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
---
|
||||
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.
|
||||
12
_i18n/tr/resources/moneropedia/bootstrap-node.md
Normal file
12
_i18n/tr/resources/moneropedia/bootstrap-node.md
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
---
|
||||
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.
|
||||
30
_i18n/tr/resources/moneropedia/bulletproofs.md
Normal file
30
_i18n/tr/resources/moneropedia/bulletproofs.md
Normal file
|
|
@ -0,0 +1,30 @@
|
|||
---
|
||||
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).
|
||||
21
_i18n/tr/resources/moneropedia/canonically-unique-host.md
Normal file
21
_i18n/tr/resources/moneropedia/canonically-unique-host.md
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
---
|
||||
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)
|
||||
14
_i18n/tr/resources/moneropedia/change.md
Normal file
14
_i18n/tr/resources/moneropedia/change.md
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
---
|
||||
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.
|
||||
31
_i18n/tr/resources/moneropedia/clearnet.md
Normal file
31
_i18n/tr/resources/moneropedia/clearnet.md
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
---
|
||||
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)
|
||||
8
_i18n/tr/resources/moneropedia/coinbase.md
Normal file
8
_i18n/tr/resources/moneropedia/coinbase.md
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
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.
|
||||
8
_i18n/tr/resources/moneropedia/consensus.md
Normal file
8
_i18n/tr/resources/moneropedia/consensus.md
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
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.
|
||||
20
_i18n/tr/resources/moneropedia/cryptocurrency.md
Normal file
20
_i18n/tr/resources/moneropedia/cryptocurrency.md
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
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.
|
||||
20
_i18n/tr/resources/moneropedia/data-directory.md
Normal file
20
_i18n/tr/resources/moneropedia/data-directory.md
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
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.
|
||||
38
_i18n/tr/resources/moneropedia/denominations.md
Normal file
38
_i18n/tr/resources/moneropedia/denominations.md
Normal file
|
|
@ -0,0 +1,38 @@
|
|||
---
|
||||
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.
|
||||
17
_i18n/tr/resources/moneropedia/destination.md
Normal file
17
_i18n/tr/resources/moneropedia/destination.md
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
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.
|
||||
28
_i18n/tr/resources/moneropedia/eepsite.md
Normal file
28
_i18n/tr/resources/moneropedia/eepsite.md
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
---
|
||||
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).
|
||||
33
_i18n/tr/resources/moneropedia/encryption.md
Normal file
33
_i18n/tr/resources/moneropedia/encryption.md
Normal file
|
|
@ -0,0 +1,33 @@
|
|||
---
|
||||
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)
|
||||
13
_i18n/tr/resources/moneropedia/floodfill.md
Normal file
13
_i18n/tr/resources/moneropedia/floodfill.md
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
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.
|
||||
17
_i18n/tr/resources/moneropedia/fluffyblocks.md
Normal file
17
_i18n/tr/resources/moneropedia/fluffyblocks.md
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
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)
|
||||
15
_i18n/tr/resources/moneropedia/fungibility.md
Normal file
15
_i18n/tr/resources/moneropedia/fungibility.md
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
---
|
||||
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.
|
||||
|
||||
23
_i18n/tr/resources/moneropedia/garlic-encryption.md
Normal file
23
_i18n/tr/resources/moneropedia/garlic-encryption.md
Normal file
|
|
@ -0,0 +1,23 @@
|
|||
---
|
||||
tags: ["kovri"]
|
||||
terms: ["Garlic-Encryption", "Layered-Encryption"]
|
||||
summary: "Layered encryption as implemented in Kovri / I2P"
|
||||
---
|
||||
|
||||
### The Basics
|
||||
|
||||
@garlic-encryption is @I2P's implementation of @message based @layered-encryption (similar to flow-based [Onion-Routing](https://en.wikipedia.org/wiki/Onion_routing)).
|
||||
|
||||
By @encrypting @messages in layers, this allows a @message to be routed through a sequence of proxies without allowing the proxies (or any intermediaries) to read the contents of the @message. @Layered-Encryption is a fundamental feature in @Kovri, @I2P, and [Tor](https://torproject.org) and is the cornerstone for securing anonymity within these overlay-networks.
|
||||
|
||||
### In-depth information
|
||||
|
||||
For @garlic-encryption, the primary difference between @Kovri/@I2P and Tor is:
|
||||
|
||||
- @Kovri/@I2P bundles multiple @messages together to form garlic "cloves"
|
||||
- any number of messages can be contained in a "clove" instead of *only* a single message
|
||||
- @Kovri/@I2P uses [ElGamal](https://en.wikipedia.org/wiki/ElGamal)/[AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) @encryption for @messages and @transports
|
||||
|
||||
### Notes
|
||||
|
||||
For details, see @garlic-routing.
|
||||
43
_i18n/tr/resources/moneropedia/garlic-routing.md
Normal file
43
_i18n/tr/resources/moneropedia/garlic-routing.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
---
|
||||
tags: ["kovri"]
|
||||
terms: ["Garlic-Routing"]
|
||||
summary: "Routing technology as implemented in Kovri"
|
||||
---
|
||||
|
||||
### The Basics
|
||||
|
||||
The term *@garlic-routing* has a diverse history of varying interpretations. As it currently stands, Monero defines *@garlic-routing* as the method in which @Kovri and @I2P create a @message-based anonymous overlay network of Internet peers.
|
||||
|
||||
The @Garlic-Encryption of @Garlic-Routing is similar to the @Layered-Encryption of [Onion Routing](https://en.wikipedia.org/wiki/Onion_routing) and effectively conceals the IP address of the sender and secures information sent from the sender to its @destination (and vice-versa).
|
||||
|
||||
### History
|
||||
|
||||
In written form, the term *@garlic-routing* can be seen as early as June of 2000 in Roger Dingledine's [Free Haven Master's thesis](http://www.freehaven.net/papers.html) (Section 8.1.1) as derived from the term Onion Routing.
|
||||
|
||||
As recent as October of 2016, [#tor-dev](https://oftc.net/WebChat/) has offered insight into the creation of the term *@garlic-routing*:
|
||||
|
||||
[Nick Mathewson](https://en.wikipedia.org/wiki/The_Tor_Project,_Inc):
|
||||
>[I think that there was some attempt to come up with a plant whose structure resembled the 'leaky-pipe' topology of tor, but I don't believe we ever settled on one.]
|
||||
|
||||
[Roger Dingledine](https://en.wikipedia.org/wiki/Roger_Dingledine):
|
||||
>during the free haven brainstorming, there was a moment where we described a routing mechanism, and somebody said "garlic routing!", and everybody laughed.
|
||||
so we for sure thought we had invented the name, at the time.
|
||||
|
||||
*Note: permission to use the aforementioned quotes was granted by Nick Mathewson and Roger Dingledine*
|
||||
|
||||
### In-depth Information
|
||||
|
||||
In technical terms, for @Kovri and @I2P, *@garlic-routing* translates to any/all of the following:
|
||||
|
||||
- @Layered-Encryption (similar to the @layered-encryption in Onion Routing)
|
||||
- Bundling multiple @messages together (garlic cloves)
|
||||
- ElGamal/AES @encryption
|
||||
|
||||
*Note: though [Tor](https://torproject.org/) uses @layered-encryption, Tor does not use ElGamal and is not message-based.*
|
||||
|
||||
**Read more in @garlic-encryption.**
|
||||
|
||||
### Notes
|
||||
|
||||
- In terms of Onion/Garlic Routing, another way to envision layered @encryption is by replacing the onion/garlic with a [Matryoshka doll](https://en.wikipedia.org/wiki/Matryoshka_doll) - with each outer/inner doll having a lock and public key to the next/previous doll
|
||||
- For more technical details on Garlic Routing, read the @Java-I2P entry on [Garlic Routing](https://geti2p.net/en/docs/how/garlic-routing)
|
||||
26
_i18n/tr/resources/moneropedia/i2np.md
Normal file
26
_i18n/tr/resources/moneropedia/i2np.md
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
tags: ["kovri"]
|
||||
terms: ["I2NP"]
|
||||
summary: "The I2P Network Protocol: the mechanism in which I2NP messages are sent over the I2P network"
|
||||
---
|
||||
|
||||
### The Basics
|
||||
|
||||
From @Java-I2P:
|
||||
|
||||
>
|
||||
@I2NP manages the routing and mixing of messages between routers, as well as the selection of what transports to use when communicating with a peer for which there are multiple common transports supported
|
||||
|
||||
### In-depth information
|
||||
|
||||
From @Java-I2P:
|
||||
|
||||
>
|
||||
@I2NP (@I2P Network Protocol) @messages can be used for one-hop, router-to-router, point-to-point @messages. By @encrypting and wrapping @messages in other @messages, they can be sent in a secure way through multiple hops to the ultimate @destination. @I2NP does not specify nor require any particular @transport layer but does require at least one @transport in use.
|
||||
|
||||
>
|
||||
Whenever a @destination wants to send a message to to another @destination, it provides its local router with both the @destination structure and the raw bytes of the message to be sent. The router then determines where to send it, delivers it through outbound @tunnels, instructing the end point to pass it along to the appropriate inbound @tunnel, where it is passed along again to that @tunnel's end point and made available to the target for reception.
|
||||
|
||||
### Notes
|
||||
|
||||
Read more about the @I2NP [protocol](https://geti2p.net/en/docs/protocol/i2np) and [specification](https://geti2p.net/spec/i2np).
|
||||
29
_i18n/tr/resources/moneropedia/i2p.md
Normal file
29
_i18n/tr/resources/moneropedia/i2p.md
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
---
|
||||
tags: ["kovri"]
|
||||
terms: ["I2P"]
|
||||
summary: "The Invisible Internet Project: an anonymizing overlay network"
|
||||
---
|
||||
|
||||
### Monero
|
||||
|
||||
For Monero's implementation of @I2P, see @Kovri. For a comparison of @I2P to [Tor](https://torproject.org/), read the [Comparison](https://geti2p.net/en/comparison/tor) page.
|
||||
|
||||
### The Basics
|
||||
|
||||
From @Java-I2P:
|
||||
|
||||
>The I2P network provides strong privacy protections for communication over the Internet. Many activities that would risk your privacy on the public Internet can be conducted anonymously inside I2P.
|
||||
|
||||
### In-depth information
|
||||
|
||||
From @Java-I2P:
|
||||
|
||||
>I2P is an anonymous overlay network - a network within a network. It is intended to protect communication from dragnet surveillance and monitoring by third parties such as ISPs.
|
||||
|
||||
>I2P is used by many people who care about their privacy: activists, oppressed people, journalists and whistleblowers, as well as the average person.
|
||||
|
||||
>No network can be "perfectly anonymous". The continued goal of I2P is to make attacks more and more difficult to mount. Its anonymity will get stronger as the size of the network increases and with ongoing academic review.
|
||||
|
||||
### Notes
|
||||
|
||||
@I2P documentation and specifications are available [here](https://geti2p.net/docs/).
|
||||
15
_i18n/tr/resources/moneropedia/i2pcontrol.md
Normal file
15
_i18n/tr/resources/moneropedia/i2pcontrol.md
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
---
|
||||
tags: ["kovri"]
|
||||
terms: ["I2PControl"]
|
||||
summary: "An API inteface for Kovri and Java-I2P that allows simple remote control"
|
||||
---
|
||||
|
||||
### The Basics
|
||||
|
||||
@I2Pcontrol is a [JSONRPC2](https://en.wikipedia.org/wiki/JSON-RPC) [API](https://en.wikipedia.org/wiki/Application_programming_interface) for @Kovri and @Java-I2P which allows an @I2PControl client to remote control/monitor a running instance.
|
||||
|
||||
Two available @I2PControl clients are: [qtoopie](https://github.com/EinMByte/qtoopie) (C++ client) and [itoopie](https://github.com/i2p/i2p.itoopie) (Java client). Read `kovri.conf` to configure @I2PControl for @Kovri.
|
||||
|
||||
### In-depth information
|
||||
|
||||
Details and specification available on the [I2PControl](https://geti2p.net/en/docs/api/i2pcontrol) page.
|
||||
13
_i18n/tr/resources/moneropedia/in-net.md
Normal file
13
_i18n/tr/resources/moneropedia/in-net.md
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
tags: ["kovri"]
|
||||
terms: ["In-net"]
|
||||
summary: "Within the I2P network"
|
||||
---
|
||||
|
||||
### The Basics
|
||||
|
||||
**In-net** is a [colloquial](https://en.wikipedia.org/wiki/Colloquial) term of which describes activities, protocols, or functionality that exist *only* within the @I2P network.
|
||||
|
||||
### In-depth information
|
||||
|
||||
Example: *in-net download* would be defined as downloading *only* within @I2P.
|
||||
13
_i18n/tr/resources/moneropedia/java-i2p.md
Normal file
13
_i18n/tr/resources/moneropedia/java-i2p.md
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
tags: ["kovri"]
|
||||
terms: ["Java-I2P"]
|
||||
summary: "The original implementation of I2P - written in Java"
|
||||
---
|
||||
|
||||
### The Basics
|
||||
|
||||
The term "Java I2P" is often used to describe the original @I2P implementation currently most known and used today. There are various other @I2P implementations, including @Kovri; all of which look up to the original Java implementation.
|
||||
|
||||
### Notes
|
||||
|
||||
To download/learn more about the Java implementation, visit their [website](https://geti2p.net/).
|
||||
32
_i18n/tr/resources/moneropedia/jump-service.md
Normal file
32
_i18n/tr/resources/moneropedia/jump-service.md
Normal file
|
|
@ -0,0 +1,32 @@
|
|||
---
|
||||
tags: ["kovri"]
|
||||
terms: ["Jump-Service"]
|
||||
summary: "An I2P website service that adds addresses to your address book"
|
||||
---
|
||||
|
||||
### 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 host=@base64-address 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.
|
||||
60
_i18n/tr/resources/moneropedia/kovri.md
Normal file
60
_i18n/tr/resources/moneropedia/kovri.md
Normal file
|
|
@ -0,0 +1,60 @@
|
|||
---
|
||||
tags: ["kovri"]
|
||||
terms: ["Kovri"]
|
||||
summary: "Monero's C++ router implementation of the I2P network"
|
||||
---
|
||||
|
||||
### The Basics
|
||||
|
||||
[Kovri](https://gitlab.com/kovri-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://gitlab.com/kovri-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
|
||||
23
_i18n/tr/resources/moneropedia/lease-set.md
Normal file
23
_i18n/tr/resources/moneropedia/lease-set.md
Normal file
|
|
@ -0,0 +1,23 @@
|
|||
---
|
||||
tags: ["kovri"]
|
||||
terms: ["LeaseSet", "LeaseSets"]
|
||||
summary: "Contains all currently authorized Leases for a particular I2P Destination"
|
||||
---
|
||||
|
||||
### 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)
|
||||
13
_i18n/tr/resources/moneropedia/lease.md
Normal file
13
_i18n/tr/resources/moneropedia/lease.md
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
tags: ["kovri"]
|
||||
terms: ["Lease", "Leases"]
|
||||
summary: "Authorizes an I2P tunnel to receive messages targeting a destination"
|
||||
---
|
||||
|
||||
### 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)
|
||||
20
_i18n/tr/resources/moneropedia/locally-unique-host.md
Normal file
20
_i18n/tr/resources/moneropedia/locally-unique-host.md
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
tags: ["kovri"]
|
||||
terms: ["Locally-unique-host"]
|
||||
summary: "A host defined by you and resolved only by you"
|
||||
---
|
||||
|
||||
### 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/Hosts_(file)) 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)
|
||||
31
_i18n/tr/resources/moneropedia/message.md
Normal file
31
_i18n/tr/resources/moneropedia/message.md
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
---
|
||||
tags: ["kovri"]
|
||||
terms: ["Message", "Messages"]
|
||||
summary: "The mechanisms in which information travels within I2P"
|
||||
---
|
||||
|
||||
### 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)
|
||||
14
_i18n/tr/resources/moneropedia/mining.md
Normal file
14
_i18n/tr/resources/moneropedia/mining.md
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
---
|
||||
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"
|
||||
---
|
||||
|
||||
### 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 a variant of 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.
|
||||
18
_i18n/tr/resources/moneropedia/mnemonicseed.md
Normal file
18
_i18n/tr/resources/moneropedia/mnemonicseed.md
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
terms: ["mnemonic-seed", "mnemonic"]
|
||||
summary: "a 13 or 25 word phrase used to backup a Monero account, available in a number of languages"
|
||||
---
|
||||
|
||||
### 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.
|
||||
23
_i18n/tr/resources/moneropedia/network-database.md
Normal file
23
_i18n/tr/resources/moneropedia/network-database.md
Normal file
|
|
@ -0,0 +1,23 @@
|
|||
---
|
||||
tags: ["kovri"]
|
||||
terms: ["Network-Database"]
|
||||
summary: "A distributed database which contains needed router information so the network can stay intact"
|
||||
---
|
||||
|
||||
### 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.
|
||||
24
_i18n/tr/resources/moneropedia/node.md
Normal file
24
_i18n/tr/resources/moneropedia/node.md
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
---
|
||||
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"
|
||||
---
|
||||
|
||||
### 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 network upgrade every 6 months, to occur in October and April 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 network upgrades 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>
|
||||
|
||||
32
_i18n/tr/resources/moneropedia/ntcp.md
Normal file
32
_i18n/tr/resources/moneropedia/ntcp.md
Normal file
|
|
@ -0,0 +1,32 @@
|
|||
---
|
||||
tags: ["kovri"]
|
||||
terms: ["NTCP"]
|
||||
summary: "NIO-Based TCP (Non-blocking I/O based TCP): one of two Kovri transports"
|
||||
---
|
||||
|
||||
### 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)
|
||||
18
_i18n/tr/resources/moneropedia/openalias.md
Normal file
18
_i18n/tr/resources/moneropedia/openalias.md
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
terms: ["OpenAlias"]
|
||||
summary: "a standard that allows you to use an email or domain syntax to pay someone instead of an address, eg. donate@getmonero.org or donate.getmonero.org"
|
||||
---
|
||||
|
||||
### 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. donate@getmonero.org or donate.getmonero.org.
|
||||
|
||||
More information can be found on the [OpenAlias page](/resources/openalias) or on the [OpenAlias website](https://openalias.org)
|
||||
8
_i18n/tr/resources/moneropedia/paperwallet.md
Normal file
8
_i18n/tr/resources/moneropedia/paperwallet.md
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
terms: ["paperwallet", "paperwallets", "paper-wallet", "paper-wallets"]
|
||||
summary: "A paper wallet stores the information necessary to send and receive Monero"
|
||||
---
|
||||
|
||||
### The Basics
|
||||
|
||||
A paper wallet stores the information necessary to send and receive Monero.
|
||||
25
_i18n/tr/resources/moneropedia/paymentid.md
Normal file
25
_i18n/tr/resources/moneropedia/paymentid.md
Normal file
|
|
@ -0,0 +1,25 @@
|
|||
---
|
||||
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```
|
||||
22
_i18n/tr/resources/moneropedia/pedersen-commitment.md
Normal file
22
_i18n/tr/resources/moneropedia/pedersen-commitment.md
Normal file
|
|
@ -0,0 +1,22 @@
|
|||
---
|
||||
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.
|
||||
15
_i18n/tr/resources/moneropedia/reseed.md
Normal file
15
_i18n/tr/resources/moneropedia/reseed.md
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
---
|
||||
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.
|
||||
9
_i18n/tr/resources/moneropedia/ring-size.md
Normal file
9
_i18n/tr/resources/moneropedia/ring-size.md
Normal file
|
|
@ -0,0 +1,9 @@
|
|||
---
|
||||
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)`
|
||||
13
_i18n/tr/resources/moneropedia/ringCT.md
Normal file
13
_i18n/tr/resources/moneropedia/ringCT.md
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
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).
|
||||
16
_i18n/tr/resources/moneropedia/ringsignatures.md
Normal file
16
_i18n/tr/resources/moneropedia/ringsignatures.md
Normal file
|
|
@ -0,0 +1,16 @@
|
|||
---
|
||||
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.
|
||||
66
_i18n/tr/resources/moneropedia/router-info.md
Normal file
66
_i18n/tr/resources/moneropedia/router-info.md
Normal file
|
|
@ -0,0 +1,66 @@
|
|||
---
|
||||
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.
|
||||
8
_i18n/tr/resources/moneropedia/scalability.md
Normal file
8
_i18n/tr/resources/moneropedia/scalability.md
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
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.
|
||||
8
_i18n/tr/resources/moneropedia/signature.md
Normal file
8
_i18n/tr/resources/moneropedia/signature.md
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
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.
|
||||
13
_i18n/tr/resources/moneropedia/smartmining.md
Normal file
13
_i18n/tr/resources/moneropedia/smartmining.md
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
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.
|
||||
14
_i18n/tr/resources/moneropedia/spendkey.md
Normal file
14
_i18n/tr/resources/moneropedia/spendkey.md
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
---
|
||||
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.
|
||||
|
||||
|
||||
24
_i18n/tr/resources/moneropedia/ssu.md
Normal file
24
_i18n/tr/resources/moneropedia/ssu.md
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
---
|
||||
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)
|
||||
14
_i18n/tr/resources/moneropedia/stealthaddress.md
Normal file
14
_i18n/tr/resources/moneropedia/stealthaddress.md
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
---
|
||||
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.
|
||||
45
_i18n/tr/resources/moneropedia/subscription.md
Normal file
45
_i18n/tr/resources/moneropedia/subscription.md
Normal file
|
|
@ -0,0 +1,45 @@
|
|||
---
|
||||
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).
|
||||
14
_i18n/tr/resources/moneropedia/tail-emission.md
Normal file
14
_i18n/tr/resources/moneropedia/tail-emission.md
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
---
|
||||
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.
|
||||
21
_i18n/tr/resources/moneropedia/transaction.md
Normal file
21
_i18n/tr/resources/moneropedia/transaction.md
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
---
|
||||
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.
|
||||
18
_i18n/tr/resources/moneropedia/transports.md
Normal file
18
_i18n/tr/resources/moneropedia/transports.md
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
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)
|
||||
35
_i18n/tr/resources/moneropedia/tunnel.md
Normal file
35
_i18n/tr/resources/moneropedia/tunnel.md
Normal file
|
|
@ -0,0 +1,35 @@
|
|||
---
|
||||
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.
|
||||
12
_i18n/tr/resources/moneropedia/unlocktime.md
Normal file
12
_i18n/tr/resources/moneropedia/unlocktime.md
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
---
|
||||
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.
|
||||
12
_i18n/tr/resources/moneropedia/viewkey.md
Normal file
12
_i18n/tr/resources/moneropedia/viewkey.md
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
---
|
||||
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.
|
||||
17
_i18n/tr/resources/moneropedia/wallet.md
Normal file
17
_i18n/tr/resources/moneropedia/wallet.md
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
terms: ["wallet", "wallets"]
|
||||
summary: "A wallet stores the information necessary to send and receive Monero"
|
||||
---
|
||||
|
||||
### 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).
|
||||
|
||||
|
|
@ -0,0 +1,50 @@
|
|||
{% assign version = '3.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 CryptoNightR algorithm for mining Monero (New algorithm variant since 2019 March the 9th). 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/help/buyers).
|
||||
|
||||
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).
|
||||
38
_i18n/tr/resources/user-guides/Offline_Backup.md
Normal file
38
_i18n/tr/resources/user-guides/Offline_Backup.md
Normal file
|
|
@ -0,0 +1,38 @@
|
|||
{% 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/)
|
||||
|
|
@ -0,0 +1,151 @@
|
|||
{% 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.
|
||||
|
||||
```
|
||||
user@host:~$ curl -O "https://downloads.getmonero.org/cli/monero-linux-x64-v0.11.1.0.tar.bz2" -O "https://getmonero.org/downloads/hashes.txt"
|
||||
user@host:~$ gpg --recv-keys BDA6BD7042B721C467A9759D7455C5E3C0CDCEB9
|
||||
user@host:~$ 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 <ric@spagni.net>" [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
|
||||
user@host:~$ echo '6581506f8a030d8d50b38744ba7144f2765c9028d18d990beb316e13655ab248 monero-linux-x64-v0.11.1.0.tar.bz2' | shasum -c
|
||||
monero-linux-x64-v0.11.1.0.tar.bz2: OK
|
||||
user@host:~$ tar xf monero-linux-x64-v0.11.1.0.tar.bz2
|
||||
user@host:~$ sudo cp monero-v0.11.1.0/monerod /usr/local/bin/
|
||||
```
|
||||
+ Create a `systemd` file.
|
||||
|
||||
```
|
||||
user@host:~$ 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.
|
||||
|
||||
```
|
||||
user@host:~$ 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`.
|
||||
|
||||
```
|
||||
user@host:~$ 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.
|
||||
|
||||
```
|
||||
user@host:~$ sudo chmod +x /rw/config/rc.local
|
||||
```
|
||||
|
||||
+ Create rpc action file.
|
||||
|
||||
```
|
||||
user@host:~$ sudo mkdir /rw/usrlocal/etc/qubes-rpc
|
||||
user@host:~$ 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.
|
||||
|
||||
```
|
||||
user@host:~$ sudo mv QubesIncoming/monerod-ws/monero-wallet-cli /usr/local/bin/
|
||||
```
|
||||
|
||||
+ Edit the file `/rw/config/rc.local`.
|
||||
|
||||
```
|
||||
user@host:~$ 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.
|
||||
|
||||
```
|
||||
user@host:~$ sudo chmod +x /rw/config/rc.local
|
||||
```
|
||||
|
||||
+ Shutdown `monero-wallet-ws`.
|
||||
|
||||
## 4. In `dom0`:
|
||||
|
||||
+ Create the file `/etc/qubes-rpc/policy/user.monerod`:
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ sudo nano /etc/qubes-rpc/policy/user.monerod
|
||||
```
|
||||
|
||||
Add the following line:
|
||||
|
||||
```
|
||||
monero-wallet-ws monerod-ws allow
|
||||
```
|
||||
62
_i18n/tr/resources/user-guides/create_wallet.md
Normal file
62
_i18n/tr/resources/user-guides/create_wallet.md
Normal file
|
|
@ -0,0 +1,62 @@
|
|||
{% assign version = '1.1.0' | split: '.' %}
|
||||
{% include disclaimer.html translated="false" version=page.version %}
|
||||
### Operating Systems: Ubuntu
|
||||
|
||||
- Download the [official binaries](https://getmonero.org/downloads/) or compile the last source available on [Github](https://github.com/monero-project/bitmonero)
|
||||
|
||||
|
||||
|
||||
|
||||
- Extract the files with the archive manager (same as Winzip on Windows). Note the path where the files "monerod" and "monero-wallet-cli" are
|
||||
|
||||
|
||||
|
||||
|
||||
- You only need to do this step once : open a terminal (ctrl+alt+t) and install the required dependencies by typing : "*sudo apt-get install libboost-all-dev libssl-dev libevent-dev libdb++-dev*". When asked, press the Y key and then Enter to continue
|
||||
|
||||
|
||||
|
||||
|
||||
- Open a terminal and load the path where your binaries are extracted (cf. step 2) by typing : "*cd yourPathFromStep2*"
|
||||
|
||||
|
||||
|
||||
- Load monerod by typing in your terminal : "*./monerod*". Wait for the synchronization with the network (monerod is updating the blockchain you have downloaded in step 4 or is downloading it from scratch). This can take a lot of time the first time, so be patient
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- Once monerod is synchronized with the network, open a new terminal, change the directory (cf. step 5), and launch monero-wallet-cli by typing "*./monero-wallet-cli*"
|
||||
|
||||
|
||||
|
||||
- Enter the name you want for your portfolio and follow the instructions from the terminal
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
*This is your private key. Write it down and keep it in a safe place!*
|
||||
|
||||
|
||||
|
||||
*This is your view key. You need it to create a view only wallet (cf. associated user guide)*
|
||||
|
||||
|
||||
|
||||
*This is the address of your wallet*
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- To exit monerod or monero-wallet-cli just type "*exit*" in the associated terminal
|
||||
|
||||
Now to access the portfolio you have just created you will have to launch monerod, wait for it to be synchronized with the network, launch monero-wallet-cli, and type the name of your portfolio and your password.
|
||||
|
||||
|
||||
66
_i18n/tr/resources/user-guides/easiest_buy.md
Normal file
66
_i18n/tr/resources/user-guides/easiest_buy.md
Normal file
|
|
@ -0,0 +1,66 @@
|
|||
{% assign version = '1.1.0' | split: '.' %}
|
||||
{% include disclaimer.html translated="false" version=page.version %}
|
||||
## How to obtain Monero
|
||||
|
||||
This is a guide to obtain your own Monero as of 20150919. This is perhaps the easiest way to purchase and hold Monero.
|
||||
|
||||
####Step 1: Buy Bitcoin
|
||||
|
||||
There are many ways to buy Bitcoin. Perhaps the easiest way is through circle.com. Once you have purchased some Bitcoin, you are ready to buy some Monero! Buying Bitcoin is straightforward. Please goto circle.com and just follow the instructions there.
|
||||
|
||||
####Step 2: Set up a mymonero.com account
|
||||
|
||||
MyMonero.com is an online wallet for Monero, maintained by Monero Core Developer Ricardo Spagni (fluffpony). It is the easiest wallet to use. Simply go to MyMonero.com and click on the "Create an Account" button.
|
||||
|
||||
|
||||
|
||||
After clicking the button, you will see your private key. This key is what gives you access to your funds. Never share this key with anyone!
|
||||
|
||||
### WRITE DOWN THIS KEY IMMEDIATELY!
|
||||
|
||||
|
||||
|
||||
Type in your private key in the box below, and click the button.
|
||||
|
||||
On the next page, you will see your address.
|
||||
|
||||
|
||||
|
||||
Copy your address to the clipboard by highlighting the whole thing and hitting ctrl+c (or edit menu, copy), or clicking the little icon next to your address. Save your address somewhere. This is how others will send Monero to you, and what you will use to deposit Monero into your account!
|
||||
|
||||
#### Step 3: Buy Monero and transfer the Monero to your new address
|
||||
|
||||
Go to www.shapeshift.io . On the righthand side, of the screen, click icon under "Receive" to select Monero.
|
||||
|
||||
|
||||
|
||||
|
||||
Paste your address into the field under the Monero logo. Select the "agree to terms" button, then hit "Start"
|
||||
|
||||
|
||||
|
||||
In the new screen that pops up, copy the Deposit Address into your clipboard (select and hit ctrl+c or edit-copy)
|
||||
|
||||
|
||||
|
||||
Go back to your circle.com page, hit the "transfer" button, and paste the Bitcoin address into the field
|
||||
Enter the amount of Bitcoin you would like to spend.
|
||||
|
||||
|
||||
|
||||
|
||||
You will get a text message verification code. Enter code and hit send.
|
||||
|
||||
|
||||
|
||||
You will see the shapeshift change to "awaiting exchange"
|
||||
|
||||
|
||||
|
||||
Then it will change to COMPLETE!
|
||||
|
||||
|
||||
|
||||
After a while you will see it in your Monero account
|
||||
|
||||
|
||||
32
_i18n/tr/resources/user-guides/howto_fix_stuck_funds.md
Normal file
32
_i18n/tr/resources/user-guides/howto_fix_stuck_funds.md
Normal file
|
|
@ -0,0 +1,32 @@
|
|||
{% assign version = '1.1.0' | split: '.' %}
|
||||
{% include disclaimer.html translated="false" version=page.version %}
|
||||
Sometimes, your funds will become stuck - you will have some locked funds that never become unlocked. This is how you fix it.
|
||||
|
||||
- Load your wallet in monero-wallet-cli.
|
||||
|
||||
- Type
|
||||
|
||||
> seed
|
||||
|
||||
into the command prompt. Write down your 25 word seed, if you haven't already. This is the best way to make sure you don't loose access to your funds.
|
||||
|
||||
- Close monero-wallet-cli by typing
|
||||
|
||||
> exit
|
||||
|
||||
- Backup all of your wallet related files. These include:
|
||||
|
||||
> yourwalletname.bin
|
||||
> yourwalletname.bin.keys
|
||||
> yourwalletname.bin.address.txt
|
||||
|
||||
This can be done by copying the files to a new folder.
|
||||
|
||||
Sometimes, when creating your wallet, you might have named it something without the .bin part. In that case, the wallet file will be called yourwalletname without the .bin at the end.
|
||||
|
||||
- Delete yourwallet.bin
|
||||
|
||||
- Load monero-wallet-cli, type in the name of the wallet you just deleted
|
||||
|
||||
- Enter password. The wallet will now refresh and hopefully your locked funds will now become unlocked.
|
||||
|
||||
58
_i18n/tr/resources/user-guides/importing_blockchain.md
Normal file
58
_i18n/tr/resources/user-guides/importing_blockchain.md
Normal file
|
|
@ -0,0 +1,58 @@
|
|||
{% assign version = '1.1.0' | split: '.' %}
|
||||
{% include disclaimer.html translated="false" version=page.version %}
|
||||
# Importing the Blockchain to Monero GUI wallet (Windows)
|
||||
|
||||
### Step 1
|
||||
|
||||
Download the Current bootstrap from https://downloads.getmonero.org/blockchain.raw; you can skip this step if you are importing the Blockchain from another source.
|
||||
|
||||
### Step 2
|
||||
|
||||
Find the path of your Monero wallet (the folder where you extracted your wallet). For example mine is:
|
||||
|
||||
`D:\monero-gui-0.10.3.1`
|
||||
|
||||
Your path may be different depending on where you decided to download your wallet and what version of the Monero wallet you have.
|
||||
|
||||
### Step 3
|
||||
|
||||
Find the path of your downloaded Blockchain for example mine was:
|
||||
|
||||
`C:\Users\KeeJef\Downloads\blockchain.raw`
|
||||
|
||||
Yours might be different depending on where you downloaded the Blockchain to.
|
||||
|
||||
### Step 4
|
||||
|
||||
Open a Command Prompt window. You can do this by pressing the Windows key + R, and then typing in the popup box `CMD`
|
||||
|
||||
### Step 5
|
||||
|
||||
Now you need to navigate using the CMD window to the path of your Monero wallet. You can do this by typing:
|
||||
|
||||
`cd C:\YOUR\MONERO\WALLET\FILE\PATH\HERE`
|
||||
|
||||
It should look something like:
|
||||
|
||||
`cd D:\monero-gui-0.10.3.1`
|
||||
|
||||
If your Monero wallet is on another drive you can use `DriveLetter:` for example if your Monero wallet was on your D drive then before using the cd command you would do `D:`
|
||||
|
||||
### Step 6
|
||||
|
||||
Now type in your command prompt window:
|
||||
|
||||
`monero-blockchain-import --input-file C:\YOUR\BLOCKCHAIN\FILE\PATH\HERE`
|
||||
|
||||
For example I would type :
|
||||
|
||||
`monero-blockchain-import --input-file C:\Users\KeeJef\Downloads\blockchain.raw`
|
||||
|
||||
If you downloaded the Blockchain from a trusted, reputable source you may set `verify 0` this will reduce the amount of time to sync the Blockchain.
|
||||
|
||||
### Step 7
|
||||
|
||||
After the the Blockchain has finished syncing up you can open your Monero wallet normally. Your downloaded blockchain.raw can be deleted.
|
||||
|
||||
|
||||
Author: Kee Jefferys
|
||||
165
_i18n/tr/resources/user-guides/ledger-wallet-cli.md
Normal file
165
_i18n/tr/resources/user-guides/ledger-wallet-cli.md
Normal file
|
|
@ -0,0 +1,165 @@
|
|||
{% assign version = '1.1.0' | split: '.' %}
|
||||
{% include disclaimer.html translated="false" version=page.version %}
|
||||
## How to generate a Ledger Monero wallet with the CLI (monero-wallet-cli)
|
||||
|
||||
### Table of Content
|
||||
|
||||
* [1. Windows](#1-windows)
|
||||
* [2. Mac OS X](#2-mac-os-x)
|
||||
* [3. Linux](#3-linux)
|
||||
* [4. Final notes](#4-a-few-final-notes)
|
||||
|
||||
### 1. Windows
|
||||
|
||||
We first have to ensure that we're sufficiently prepared. This entails the following:
|
||||
|
||||
1. This guide assumes you have already initialized your Ledger wallet and thus generated a 24 word mnemonic seed.
|
||||
|
||||
2. You need to run / use CLI v0.12.2.0, which can be found <a href="{{site.baseurl}}/downloads/">here</a>.
|
||||
|
||||
3. You need to install the Ledger Monero app and configure your system. Instructions can be found [here](https://github.com/LedgerHQ/blue-app-monero/blob/master/doc/user/bolos-app-monero.pdf) (sections 3.1.1 and 3.2.3 in particular). In addition, make sure to set the network to `Mainnet`
|
||||
|
||||
4. Your Ledger needs to be plugged in and the Ledger Monero app should be running.
|
||||
|
||||
5. Either your daemon (`monerod.exe`) should be running and preferably be fully synced or you should connect to a remote node.
|
||||
|
||||
Now that we're sufficiently prepared, let's start!
|
||||
|
||||
1. Go to the directory / folder monerod.exe and monero-wallet-cli.exe are located.
|
||||
|
||||
2. Open a new command prompt / powershell. This is done by first making sure your cursor isn't located on any of the files and subsequently doing SHIFT + right click. It will give you an option to "Open command window here". If you're using Windows 10 in latest version, it'll give you an option to "open the PowerShell window here".
|
||||
|
||||
3. Now type:
|
||||
|
||||
`monero-wallet-cli.exe --generate-from-device <new-wallet-name> --subaddress-lookahead 3:200` (Win 7 + 8)
|
||||
|
||||
`.\monero-wallet-cli.exe --generate-from-device <new-wallet-name> --subaddress-lookahead 3:200` (Win 10)
|
||||
|
||||
Note that is simply a placeholder for the actual wallet name. If you, for instance, want to name your wallet `MoneroWallet`, the command would be as follows:
|
||||
|
||||
`monero-wallet-cli.exe --generate-from-device MoneroWallet --subaddress-lookahead 3:200` (Win 7 + 8)
|
||||
|
||||
`.\monero-wallet-cli.exe --generate-from-device MoneroWallet --subaddress-lookahead 3:200` (Win 10)
|
||||
|
||||
4. The CLI will, after executing aforementioned command, prompt your for a password. Make sure to set a strong password and confirm it thereafter.
|
||||
|
||||
5. The Ledger will ask whether you want to export the private view key or not. First and foremost, your funds cannot be compromised with merely the private view key. Exporting the private view key enables the client (on the computer - Monero v0.12.2.0) to scan blocks looking for transactions that belong to your wallet / address. If this option is not utilized, the device (Ledger) will scan blocks, which will be significantly slower. There is, however, one caveat. That is, if your system gets compromised, the adversary will potentially be able to compromise your private view key as well, which is detrimental to privacy. This is virtually impossible when the private view key is not exported.
|
||||
|
||||
6. You may have to hit confirm twice before it proceeds.
|
||||
|
||||
7. Your Ledger Monero wallet will now be generated. Note that this may take up to 5-10 minutes. Furthermore, there will be no immediate feedback in the CLI nor on the Ledger.
|
||||
|
||||
8. `monero-wallet-cli` will start refreshing. Wait until it has fully refreshed.
|
||||
|
||||
Congratulations, you can now use your Ledger Monero wallet in conjunction with the CLI.
|
||||
|
||||
### 2. Mac OS X
|
||||
We first have to ensure that we're sufficiently prepared. This entails the following:
|
||||
|
||||
1. This guide assumes you have already initialized your Ledger wallet and thus generated a 24 word mnemonic seed.
|
||||
|
||||
2. You need to run / use CLI v0.12.2.0, which can be found <a href="{{site.baseurl}}/downloads/">here</a>.
|
||||
|
||||
3. You need to install the Ledger Monero app and configure your system. Instructions can be found [here](https://github.com/LedgerHQ/blue-app-monero/blob/master/doc/user/bolos-app-monero.pdf) (sections 3.1.1 and 3.2.2 in particular). In addition, make sure to set the network to `Mainnet`
|
||||
|
||||
4. Note that the instructions for system configuration (section 3.2.2) on Mac OS X are quite elaborate and can be perceived as slightly convoluted. Fortunately, tficharmers has created a guide [here](https://monero.stackexchange.com/questions/8438/how-do-i-make-my-macos-detect-my-ledger-nano-s-when-plugged-in) that you can use for assistance.
|
||||
|
||||
5. Your Ledger needs to be plugged in and the Ledger Monero app should be running.
|
||||
|
||||
6. Either your daemon (`monerod`) should be running and preferably be fully synced or you should connect to a remote node.
|
||||
|
||||
Now that we're sufficiently prepared, let's start!
|
||||
|
||||
1. Use Finder to browse to the directory / folder `monero-wallet-cli` (CLI v0.12.2.0) is located.
|
||||
|
||||
2. Go to your desktop.
|
||||
|
||||
3. Open a new terminal (if don't know how to open a terminal, see [here](https://apple.stackexchange.com/a/256263)).
|
||||
|
||||
4. Drag `monero-wallet-cli` in the terminal. It should add the full path to the terminal. Do not hit enter.
|
||||
|
||||
5. Now type:
|
||||
|
||||
`--generate-from-device <new-wallet-name> --subaddress-lookahead 3:200`
|
||||
|
||||
Note that is simply a placeholder for the actual wallet name. If you, for instance, want to name your wallet `MoneroWallet`, the command would be as follows:
|
||||
|
||||
`--generate-from-device MoneroWallet --subaddress-lookahead 3:200`
|
||||
|
||||
Note that aforementioned text will be appended to the path of `monero-wallet-cli`. Thus, before you hit enter, your terminal should look like:
|
||||
|
||||
`/full/path/to/monero-wallet-cli --generate-from-device <new-wallet-name> --subaddress-lookahead 3:200`
|
||||
|
||||
Where the full path is, intuitively, the actual path on your Mac OS X.
|
||||
|
||||
7. The CLI will, after executing aforementioned command, prompt you for a password. Make sure to set a strong password and confirm it thereafter.
|
||||
|
||||
8. The Ledger will ask whether you want to export the private view key or not. First and foremost, your funds cannot be compromised with merely the private view key. Exporting the private view key enables the client (on the computer - Monero v0.12.2.0) to scan blocks looking for transactions that belong to your wallet / address. If this option is not utilized, the device (Ledger) will scan blocks, which will be significantly slower. There is, however, one caveat. That is, if your system gets compromised, the adversary will potentially be able to compromise your private view key as well, which is detrimental to privacy. This is virtually impossible when the private view key is not exported.
|
||||
|
||||
9. You may have to hit confirm twice before it proceeds.
|
||||
|
||||
10. Your Ledger Monero wallet will now be generated. Note that this may take up to 5-10 minutes. Furthermore, there will be no immediate feedback in the CLI nor on the Ledger.
|
||||
|
||||
11. `monero-wallet-cli` will start refreshing. Wait until it has fully refreshed.
|
||||
|
||||
12. Congratulations, you can now use your Ledger Monero wallet in conjunction with the CLI.
|
||||
|
||||
### 3. Linux
|
||||
We first have to ensure that we're sufficiently prepared. This entails the following:
|
||||
|
||||
1. This guide assumes you have already initialized your Ledger wallet and thus generated a 24 word mnemonic seed.
|
||||
|
||||
2. You need to run / use CLI v0.12.2.0, which can be found <a href="{{site.baseurl}}/downloads/">here</a>.
|
||||
|
||||
3. You need to install the Ledger Monero app and configure your system. Instructions can be found [here](https://github.com/LedgerHQ/blue-app-monero/blob/master/doc/user/bolos-app-monero.pdf) (sections 3.1.1 and 3.2.1 in particular). In addition, make sure to set the network to `Mainnet`
|
||||
|
||||
4. Your Ledger needs to be plugged in and the Ledger Monero app should be running.
|
||||
|
||||
5. Either your daemon (`monerod`) should be running and preferably be fully synced or you should connect to a remote node.
|
||||
|
||||
Now that we're sufficiently prepared, let's start!
|
||||
|
||||
1. Go to the directory / folder monero-wallet-cli and monerod are located.
|
||||
|
||||
2. Open a new terminal
|
||||
|
||||
3. Now type:
|
||||
|
||||
`./monero-wallet-cli --generate-from-device <new-wallet-name> --subaddress-lookahead 3:200`
|
||||
|
||||
Note that is simply a placeholder for the actual wallet name. If you, for instance, want to name your wallet `MoneroWallet`, the command would be as follows:
|
||||
|
||||
`./monero-wallet-cli --generate-from-device MoneroWallet --subaddress-lookahead 3:200`
|
||||
|
||||
4. The CLI will, after executing aforementioned command, prompt your for a password. Make sure to set a strong password and confirm it thereafter.
|
||||
|
||||
5. The Ledger will ask whether you want to export the private view key or not. First and foremost, your funds cannot be compromised with merely the private view key. Exporting the private view key enables the client (on the computer - Monero v0.12.2.0) to scan blocks looking for transactions that belong to your wallet / address. If this option is not utilized, the device (Ledger) will scan blocks, which will be significantly slower. There is, however, one caveat. That is, if your system gets compromised, the adversary will potentially be able to compromise your private view key as well, which is detrimental to privacy. This is virtually impossible when the private view key is not exported.
|
||||
|
||||
6. You may have to hit confirm twice before it proceeds.
|
||||
|
||||
7. Your Ledger Monero wallet will now be generated. Note that this may take up to 5-10 minutes. Furthermore, there will be no immediate feedback in the CLI nor on the Ledger.
|
||||
|
||||
8. `monero-wallet-cli` will start refreshing. Wait until it has fully refreshed.
|
||||
|
||||
Congratulations, you can now use your Ledger Monero wallet in conjunction with the CLI.
|
||||
|
||||
### 4. A few final notes
|
||||
|
||||
1. We'd strongly advise to test the full process first. That is, send a small amount to the wallet and subsequently restore it (using aforementioned guide) to verify that you can recover the wallet. Note that, upon recreating / restoring the wallet, you ought to append the `--restore-height` flag (with a block height before the height of your first transaction to the wallet) to the command in step 3 (Windows), step 5 (Mac OS X), or step 3 (Linux). More information about the restore height and how to approximate it can be found [here](https://monero.stackexchange.com/questions/7581/what-is-the-relevance-of-the-restore-height).
|
||||
|
||||
2. If you use a remote node, append the `--daemon-address host:port` flag to the command in step 3 (Windows), step 5 (Mac OS X), or step 3 (Linux).
|
||||
|
||||
3. If desired, you can manually tweak the `--subaddress-lookahead` value. The first value is the number of accounts and the second value is the number of subaddresses per account. Thus, if you, for instance, want to pregenerate 5 accounts with 100 subaddresses each, use `--subaddress-lookahead 5:100`. Bear in mind that, the more subaddresses you pregenerate, the longer it takes for the Ledger to create your wallet.
|
||||
|
||||
4. You only have to use the `--generate-from-device` flag once (i.e. upon wallet creation). Thereafter, you'd basically use it similar to how you normally use the CLI. That is:
|
||||
1. Make sure your Ledger is plugged in and the Monero app is running.
|
||||
2. Open `monero-wallet-cli`.
|
||||
3. Enter the wallet name of your Ledger Monero wallet.
|
||||
4. Enter the password to open the wallet.
|
||||
|
||||
If the Ledger wallet files are not in the same directory as `monero-wallet-cli`, you ought to open `monero-wallet-cli` with the `--wallet-file /path/to/wallet.keys/file` flag. Alternatively, you can copy the Ledger wallet files to the same directory as `monero-wallet-cli`.
|
||||
|
||||
5. If you have any further questions or need assistance, please leave a comment to the original [StackExchange](https://monero.stackexchange.com/questions/8503/how-do-i-generate-a-ledger-monero-wallet-with-the-cli-monero-wallet-cli) answer.
|
||||
|
||||
Author: dEBRUYNE
|
||||
Secondary scribe: el00ruobuob
|
||||
115
_i18n/tr/resources/user-guides/mine-to-pool.md
Normal file
115
_i18n/tr/resources/user-guides/mine-to-pool.md
Normal file
|
|
@ -0,0 +1,115 @@
|
|||
{% assign version = '1.1.0' | split: '.' %}
|
||||
{% include disclaimer.html translated="false" version=page.version %}
|
||||
# Selecting a pool
|
||||
|
||||
There are many pools to choose from, a list is available at
|
||||
[moneropools.com](https://moneropools.com). Mining on a larger pool could mean
|
||||
more frequent payouts, but mining on a smaller pool helps to keep the network
|
||||
decentralized.
|
||||
|
||||
# Selecting a CPU miner
|
||||
|
||||
Just like pools, there are a lot of miners to choose from. The one that you
|
||||
should pick depends on the hardware you want to mine on. This guide will only
|
||||
use a CPU miner, and will be using
|
||||
[xmr-stak-cpu](https://github.com/fireice-uk/xmr-stak-cpu). Alternatives include
|
||||
[wolf's CPUMiner](https://github.com/wolf9466/cpuminer-multi) and
|
||||
[sgminer-gm](https://github.com/genesismining/sgminer-gm). However, their
|
||||
configuration is slightly different and will not be covered in this guide.
|
||||
|
||||
## For Windows Systems
|
||||
|
||||
If you are using a Windows system, the developer of xmr-stak-cpu provides
|
||||
binaries to download on the
|
||||
[GitHub release page](https://github.com/fireice-uk/xmr-stak-cpu/releases).
|
||||
|
||||
Download `xmr-stak-cpu-win64.zip` and extract it somewhere you'll be able to
|
||||
find it again.
|
||||
|
||||
## For Other Operating Systems
|
||||
|
||||
If you're not using Windows, you will have to compile xmr-stak-cpu for yourself,
|
||||
luckily this isn't as hard as it sounds. Before you can compile the miner, you
|
||||
will need to install some of its prerequisites.
|
||||
|
||||
For Debian-based distros:
|
||||
|
||||
sudo apt-get install libmicrohttpd-dev libssl-dev cmake build-essential
|
||||
|
||||
For Red Hat based distros:
|
||||
|
||||
sudo yum install openssl-devel cmake gcc-c++ libmicrohttpd-devel
|
||||
|
||||
<!-- TODO: Add dependencies for other operating systems? -->
|
||||
|
||||
Following this, you just need to use cmake to generate the build files, run
|
||||
make and copy the config file:
|
||||
|
||||
mkdir build-$(gcc -dumpmachine)
|
||||
cd $_
|
||||
cmake ../
|
||||
make -j$(nproc)
|
||||
cp ../config.txt bin/
|
||||
cd bin
|
||||
|
||||
Don't celebrate just yet, as the miner needs to be configured. Running the miner
|
||||
now should give you a block of text to copy and paste:
|
||||
|
||||
|
||||
|
||||
Open `config.txt` and *replace* the two `"cpu_threads_conf"` lines with the text
|
||||
you just copied. It should look something like this afterwards:
|
||||
|
||||
|
||||
|
||||
Scroll down in the file until you see the lines containing `"pool_address"`.
|
||||
*Replace* the contents of the second set of quotes with the address and port of
|
||||
the pool you chose earlier. You can find this information on the pool's website.
|
||||
|
||||
Put your wallet address between the quotes on the wallet address. You may leave
|
||||
the password blank unless the pool specifies otherwise.
|
||||
|
||||
After this, your config should look something like this:
|
||||
|
||||
|
||||
|
||||
# Running the miner
|
||||
|
||||
**Save the config** file and run the miner!
|
||||
|
||||
|
||||
|
||||
Some pools allow you to monitor your hashrate by pasting your address into their
|
||||
website. You can also monitor your hashrate by pressing the `h` key.
|
||||
|
||||
# Tuning the miner
|
||||
|
||||
You might see nasty messages like this:
|
||||
|
||||
[2017-07-09 12:04:02] : MEMORY ALLOC FAILED: mmap failed
|
||||
|
||||
This means that you can get around a 20% hashrate boost by enabling large pages.
|
||||
|
||||
## Large pages on Linux
|
||||
|
||||
Firstly stop the miner (if it's running), run the following commands to enable
|
||||
large pages and then start the miner as root:
|
||||
|
||||
sudo sysctl -w vm.nr_hugepages=128
|
||||
sudo ./xmr-stak-cpu
|
||||
|
||||
## Large pages on Windows
|
||||
|
||||
Taken from `config.txt`:
|
||||
|
||||
>By default we will try to allocate large pages. This means you need to "Run As Administrator" on Windows
|
||||
You need to edit your system's group policies to enable locking large pages. Here are the steps from MSDN
|
||||
1. On the Start menu, click Run. In the Open box, type gpedit.msc.
|
||||
2. On the Local Group Policy Editor console, expand Computer Configuration, and then expand Windows Settings.
|
||||
3. Expand Security Settings, and then expand Local Policies.
|
||||
4. Select the User Rights Assignment folder.
|
||||
5. The policies will be displayed in the details pane.
|
||||
6. In the pane, double-click Lock pages in memory.
|
||||
7. In the Local Security Setting – Lock pages in memory dialog box, click Add User or Group.
|
||||
8. In the Select Users, Service Accounts, or Groups dialog box, add an account that you will run the miner on
|
||||
9. Reboot for change to take effect.
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
{% assign version = '1.1.0' | split: '.' %}
|
||||
{% include disclaimer.html translated="false" version=page.version %}
|
||||
## Introduction
|
||||
|
||||
This guide is two fold, ease of use for mining on Linux distributions and some extra security around mining as most of these miners have not had security auditing.
|
||||
|
||||
At the end of this guide you will be able to sleep a little easier knowing that if the miner gets exploited it will not migrate to your OS.
|
||||
|
||||
### Why Docker
|
||||
|
||||
[Docker](https://www.docker.com/) is being used as it is the most well known and has the biggest chance to be already installed.
|
||||
|
||||
The container I am using is [alpine-xmrig](https://hub.docker.com/r/bitnn/alpine-xmrig/) as per the name it is built on the [Alpine Linux](https://www.alpinelinux.org/) image.
|
||||
|
||||
If you are interested in getting started with Docker, here are some really good starting references.
|
||||
* Arch Linux Wiki [Docker Page](https://wiki.archlinux.org/index.php/Docker)
|
||||
* Container Solutions [Security Cheat Sheet](http://container-solutions.com/content/uploads/2015/06/15.06.15_DockerCheatSheet_A2.pdf)
|
||||
* Digital Oceans [Dockerfile Howto](https://www.digitalocean.com/community/tutorials/docker-explained-using-dockerfiles-to-automate-building-of-images).
|
||||
|
||||
For distribution specific installation please refer to the [Docker Docs](https://docs.docker.com/engine/installation/) website.
|
||||
|
||||
### Why XMRig
|
||||
|
||||
[XMRig](https://github.com/xmrig/xmrig) is just a really solid miner to me. Nice output and statistics, no flashy web-ui's or dependencies. The XMRig container is only ~4MB what makes it extremely portable.
|
||||
|
||||
#### Step 1: Mining with XMRig
|
||||
|
||||
Run the following
|
||||
|
||||
```bash
|
||||
# docker run --restart unless-stopped --read-only -m 50M -c 512 bitnn/alpine-xmrig -o POOL01 -o POOL02 -u WALLET -p PASSWORD -k
|
||||
# docker run --restart unless-stopped --read-only -m 50M -c 512 bitnn/alpine-xmrig -o pool.supportxmr.com:7777 -u 45CJVagd6WwQAQfAkS91EHiTyfVaJn12uM4Su8iz6S2SHZ3QthmFM9BSPHVZY388ASWx8G9Wbz4BA24RQZUpGczb35fnnJz -p docker:secret -k
|
||||
```
|
||||
|
||||
#### Step 2: There is no Step 2
|
||||
|
||||
You have already done everything you need to do. You are now mining in a docker container with XMRig `ctrl+c` to exit the miner or add `-d` just after `docker run` to background the miner.
|
||||
|
||||
147
_i18n/tr/resources/user-guides/monero-wallet-cli.md
Normal file
147
_i18n/tr/resources/user-guides/monero-wallet-cli.md
Normal file
|
|
@ -0,0 +1,147 @@
|
|||
{% assign version = '1.1.0' | split: '.' %}
|
||||
{% include disclaimer.html translated="false" version=page.version %}
|
||||
# monero-wallet-cli
|
||||
|
||||
`monero-wallet-cli` is the wallet software that ships with the Monero tree. It is a console program,
|
||||
and manages an account. While a bitcoin wallet manages both an account and the blockchain,
|
||||
Monero separates these: `monerod` handles the blockchain, and `monero-wallet-cli` handles the account.
|
||||
|
||||
This guide will show how to perform various operations from the `monero-wallet-cli` UI. The guide assumes you are using the most recent version of Monero and have already created an account according to the other guides.
|
||||
|
||||
|
||||
## Checking your balance
|
||||
|
||||
Since the blockchain handling and the wallet are separate programs, many uses of `monero-wallet-cli`
|
||||
need to work with the daemon. This includes looking for incoming transactions to your address.
|
||||
Once you are running both `monero-wallet-cli` and `monerod`, enter `balance`.
|
||||
|
||||
Example:
|
||||
|
||||
This will pull blocks from the daemon the wallet did not yet see, and update your balance
|
||||
to match. This process will normally be done in the background every minute or so. To see the
|
||||
balance without refreshing:
|
||||
|
||||
balance
|
||||
Balance: 64.526198850000, unlocked balance: 44.526198850000, including unlocked dust: 0.006198850000
|
||||
|
||||
In this example, `Balance` is your total balance. The `unlocked balance` is the amount currently available to spend. Newly received transactions require 10 confirmations on the blockchain before being unlocked. `unlocked dust` refers to very small amounts of unspent outputs that may have accumulated in your account.
|
||||
|
||||
## Sending monero
|
||||
|
||||
You will need the standard address you want to send to (a long string starting with '4'), and
|
||||
possibly a payment ID, if the receiving party requires one. In that latter case, that party
|
||||
may instead give you an integrated address, which is both of these packed into a single address.
|
||||
|
||||
### Sending to a standard address:
|
||||
|
||||
transfer ADDRESS AMOUNT PAYMENTID
|
||||
|
||||
Replace `ADDRESS` with the address you want to send to, `AMOUNT` with how many monero you want to send,
|
||||
and `PAYMENTID` with the payment ID you were given. Payment ID's are optional. If the receiving party doesn't need one, just
|
||||
omit it.
|
||||
|
||||
### Sending to an integrated address:
|
||||
|
||||
transfer ADDRESS AMOUNT
|
||||
|
||||
The payment ID is implicit in the integrated address in that case.
|
||||
|
||||
### Specify the number of outputs for a transaction:
|
||||
|
||||
transfer RINGSIZE ADDRESS AMOUNT
|
||||
|
||||
Replace `RINGSIZE` with the number of outputs you wish to use. **If not specified, the default is 11.** It's a good idea to use the default, but you can increase the number if you want to include more outputs. The higher the number, the larger the transaction, and higher fees are needed.
|
||||
|
||||
|
||||
## Receiving monero
|
||||
|
||||
If you have your own Monero address, you just need to give your standard address to someone.
|
||||
|
||||
You can find out your address with:
|
||||
|
||||
address
|
||||
|
||||
Since Monero is anonymous, you won't see the origin address the funds you receive came from. If you
|
||||
want to know, for instance to credit a particular customer, you'll have to tell the sender to use
|
||||
a payment ID, which is an arbitrary optional tag which gets attached to a transaction. To make life
|
||||
easier, you can generate an address that already includes a random payment ID:
|
||||
|
||||
integrated_address
|
||||
|
||||
This will generate a random payment ID, and give you the address that includes your own account
|
||||
and that payment ID. If you want to select a particular payment ID, you can do that too:
|
||||
|
||||
integrated_address 12346780abcdef00
|
||||
|
||||
Payments made to an integrated address generated from your account will go to your account,
|
||||
with that payment id attached, so you can tell payments apart.
|
||||
|
||||
|
||||
## Proving to a third party you paid someone
|
||||
|
||||
If you pay a merchant, and the merchant claims to not have received the funds, you may need
|
||||
to prove to a third party you did send the funds - or even to the merchant, if it is a honest
|
||||
mistake. Monero is private, so you can't just point to your transaction in the blockchain,
|
||||
as you can't tell who sent it, and who received it. However, by supplying the per-transaction
|
||||
private key to a party, that party can tell whether that transaction sent monero to that
|
||||
particular address. Note that storing these per-transaction keys is disabled by default, and
|
||||
you will have to enable it before sending, if you think you may need it:
|
||||
|
||||
set store-tx-info 1
|
||||
|
||||
You can retrieve the tx key from an earlier transaction:
|
||||
|
||||
get_tx_key 1234567890123456789012345678901212345678901234567890123456789012
|
||||
|
||||
Pass in the transaction ID you want the key for. Remember that a payment might have been
|
||||
split in more than one transaction, so you may need several keys. You can then send that key,
|
||||
or these keys, to whoever you want to provide proof of your transaction, along with the
|
||||
transaction id and the address you sent to. Note that this third party, if knowing your
|
||||
own address, will be able to see how much change was returned to you as well.
|
||||
|
||||
If you are the third party (that is, someone wants to prove to you that they sent monero
|
||||
to an address), then you can check this way:
|
||||
|
||||
check_tx_key TXID TXKEY ADDRESS
|
||||
|
||||
Replace `TXID`, `TXKEY` and `ADDRESS` with the transaction ID, per-transaction key, and destination
|
||||
address which were supplied to you, respectively. monero-wallet-cli will check that transaction
|
||||
and let you know how much monero this transaction paid to the given address.
|
||||
|
||||
|
||||
## Getting a chance to confirm/cancel payments
|
||||
|
||||
If you want to get a last chance confirmation when sending a payment:
|
||||
|
||||
set always-confirm-transfers 1
|
||||
|
||||
|
||||
## How to find a payment to you
|
||||
|
||||
If you received a payment using a particular payment ID, you can look it up:
|
||||
|
||||
payments PAYMENTID
|
||||
|
||||
You can give more than one payment ID too.
|
||||
|
||||
More generally, you can review incoming and outgoing payments:
|
||||
|
||||
show_transfers
|
||||
|
||||
You can give an optional height to list only recent transactions, and request
|
||||
only incoming or outgoing transactions. For example,
|
||||
|
||||
show_transfers in 650000
|
||||
|
||||
will only show incoming transfers after block 650000. You can also give a height
|
||||
range.
|
||||
|
||||
If you want to mine, you can do so from the wallet:
|
||||
|
||||
start_mining 2
|
||||
|
||||
This will start mining on the daemon usin two threads. Note that this is solo mining,
|
||||
and may take a while before you find a block. To stop mining:
|
||||
|
||||
stop_mining
|
||||
|
||||
19
_i18n/tr/resources/user-guides/monero_tools.md
Normal file
19
_i18n/tr/resources/user-guides/monero_tools.md
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
{% assign version = '1.1.0' | split: '.' %}
|
||||
{% include disclaimer.html translated="false" version=page.version %}
|
||||
# Monero tools
|
||||
|
||||
These tools can be used to gain information about the Monero network or your transaction data in the blockchain.
|
||||
|
||||
### [Check that a recipient has received your funds](http://xmrtests.llcoins.net/checktx.html)
|
||||
|
||||
### [Tools for monero address generation](https://xmr.llcoins.net/)
|
||||
|
||||
### [Monero node count](http://moneronodes.i2p.xyz/)
|
||||
|
||||
### [Monero node map](https://monerohash.com/nodes-distribution.html)
|
||||
|
||||
### [Monero offline wallet generator](http://moneroaddress.org/)
|
||||
|
||||
### [Monero network statistics](http://moneroblocks.info/stats)
|
||||
|
||||
### [Monero.how statistics](https://www.monero.how/)
|
||||
810
_i18n/tr/resources/user-guides/multisig-messaging-system.md
Normal file
810
_i18n/tr/resources/user-guides/multisig-messaging-system.md
Normal file
|
|
@ -0,0 +1,810 @@
|
|||
{% assign version = '1.1.1' | split: '.' %}
|
||||
{% include disclaimer.html translated="false" version=page.version %}
|
||||
# Multisig Transactions with MMS and CLI Wallet
|
||||
|
||||
## Introduction
|
||||
|
||||
This manual describes the *Multisig Messaging System*, abbreviated as *MMS*. It's a system that aims to **simplify multisig transactions** for Monero and similar CrypoNote-based cryptocurrencies by making it easy to exchange info like key sets and sync data between wallets and by offering some "workflow support" guiding you through the various steps.
|
||||
|
||||
The MMS so far presents itself to the user as a set of new commands in the CLI wallet. This is not surprising, as currently the CLI wallet is the only way to do multisig transactions interactively anyway. Hopefully this will be extended in the future; the MMS was designed with other wallets like e.g. the Monero GUI wallet in mind.
|
||||
|
||||
This manual has some tutorial-like aspects and is intended to be read in sequential fashion, best without skipping any chapter before chapter *The Commands in Detail*.
|
||||
|
||||
If you have high requirements regarding security and are not sure whether using the MMS is acceptable for you in the first place, you may read the chapter *Security* first.
|
||||
|
||||
This first version of the manual was written around year-end 2018 by René Brunner (*rbrunner7*), the original author of the MMS.
|
||||
|
||||
## Monero Multisig in a Nutshell
|
||||
|
||||
Probably it will be pretty hard to understand the MMS without at least a basic grasp of how Monero multisig transactions work in principle. Here a short overview together with info about the *terminology* that this manual uses; for more details and more *technical* explanations you will have to look elsewhere.
|
||||
|
||||
*Multisig* means that a transaction needs multiple signatures before it can be submitted to the Monero network and executed. Instead of one Monero wallet creating, signing, and submitting transactions all on its own, you will have a whole group of wallets and collaboration between them to transact.
|
||||
|
||||
In this manual those wallets, or if you prefer, the people controlling them, are called *authorized signers*. Depending on the type of multisig used, not **all** authorized signers need to sign before a transaction becomes valid, but only a subset of them. The corresponding number (which is equal to or smaller than the number of authorized signers) is called *required signers*.
|
||||
|
||||
The usual notation in use here is *M/N*, with *M* standing for the number of required signers, and *N* standing for the total number of authorized signers. For example, probably the most useful and most popular type of multisig is written as *2/3*: Out of a total of **three** authorized signers, any **two** are needed to make a transaction valid.
|
||||
|
||||
For technically "simple" coins like Bitcoin and its forks doing multisig transactions consists of the following steps:
|
||||
|
||||
* Configure the multisig wallets and establish the multisig address
|
||||
* Fund the multisig wallets / the multisig address so there is something to spend in the first place
|
||||
* Do as many multisig transactions as you like
|
||||
|
||||
Monero adds one more type of step, necessary for internal bookkeeping so to speak. Simply told all the mechanisms that make Monero transactions truly private complicate things and lead to a necessity to exchange information between wallets to enable them to correctly process transactions, both incoming and outgoing.
|
||||
|
||||
The MMS uses the term *syncing* for the process to making wallets ready to transact again after sending or receiving transactions, and *multisig sync data* or simply *sync data* for the information that has to be exchanged to achieve that.
|
||||
|
||||
So the steps for Monero multisig look like that:
|
||||
|
||||
* Configure the multisig wallets and establish the multisig address
|
||||
* Fund the multisig wallets / the multisig address so there is something to spend in the first place
|
||||
* Sync the wallets for a first time
|
||||
* Do 1 multisig transaction
|
||||
* Sync the wallets again
|
||||
* Do another multisig transaction and/or receive more funds
|
||||
* Sync the wallets yet again
|
||||
* ...
|
||||
|
||||
The "value" of the MMS is making it easy and painless to exchange all those data packets between the wallets, and telling the signers at which point of the "workflow" they currently are and what has to be the next action in order to proceed.
|
||||
|
||||
## The Architecture of the MMS
|
||||
|
||||
The MMS basically has 3 parts:
|
||||
|
||||
* A set of new commands in the CLI wallet
|
||||
* A running instance of PyBitmessage reachable from the computer running the CLI wallet, doing message transport on behalf of the wallet
|
||||
* Internal code extensions to wallet code managing a new `.mms` file per wallet with the messages in it and interfacing with PyBitmessage
|
||||
|
||||
[PyBitmessage](https://bitmessage.org/wiki/Main_Page) is currently the only supported program for message transport, the MMS won't "speak" to any other system. You can't use e-mail nor any other of the myriad of communication programs out there. If you don't like PyBitmessage or can't run it for any reason you won't be able to use the current version of the MMS.
|
||||
|
||||
The author of the MMS hopes that you will give it a try: PyBitmessage is fully open source, is under continued development, has enough users to almost assure message transport at any time, and takes privacy very seriously - just like Monero.
|
||||
|
||||
Hopefully a future MMS will build on Monero's "native" private communication system, [Kovri](https://kovri.io/), but we are probably still quite some time away from a Kovri release ready for broad use.
|
||||
|
||||
MMS communications should be **safe**: The Bitmessage system is considered safe as it's completely invisible who sends messages to whom, and all traffic is encrypted. For additional safety the MMS encrypts any message contents itself as well: Nobody except the receiver of an MMS message can decrypt and use its content, and the messages are signed, meaning the receiver can be sure they come from the right sender.
|
||||
|
||||
## The MMS User Experience
|
||||
|
||||
To see the "user experience" of multisig in the CLI wallet **without** MMS you can e.g. check [here](https://taiga.getmonero.org/project/rbrunner7-really-simple-multisig-transactions/wiki/22-multisig-in-cli-wallet) and [here](https://taiga.getmonero.org/project/rbrunner7-really-simple-multisig-transactions/wiki/23-multisig-in-cli-wallet).
|
||||
|
||||
Those pages are also useful to familiarize yourself with the steps for multisig transactions in general, as the MMS will not change the order of the steps or make any of them superfluous, but will just make execution considerably easier, and the MMS will be able to tell you the next step in order automatically in most cases.
|
||||
|
||||
### A Messaging System
|
||||
|
||||
The general approach of the MMS is very **similar to e-mail**: You send messages around, with the MMS command set in the CLI wallet playing the part of your e-mail client, allowing you to send messages, receive messages and manage a list of stored messages, something like a combined inbox and outbox.
|
||||
|
||||
The contents of those messages are of course all those things that must be transported between the wallets of the signers: key sets, wallet sync data, transactions to sign and/or submit to the network.
|
||||
|
||||
PyBitmessage is used for the actual message transport and thus plays the part of your e-mail server. Once configuration is done sending and receiving messages is fully automatic i.e. needs no manual intervention.
|
||||
|
||||
You don't use e-mail addresses, but Monero addresses to tell where messages should go, and you only ever send messages to other authorized signers: E.g. with 2/3 multisig you only have 2 partners to send something to.
|
||||
|
||||
Like with e-mail people don't have to be online at the same time for message transport to work: PyBitmessage will keep messages for up to 2 days, giving you time to fetch them.
|
||||
|
||||
The approach is in general quite flexbile and robust: If you need messages from several signers to proceed the MMS will wait until it finds all of them in the list of received messages, and the order of reception does not matter either, which results in a quite unstressed experience.
|
||||
|
||||
If another signer tells you that a particular message did not arrive or was lost somehow you can send it again anytime, picking it from the message list, like you would re-send an e-mail in a similar situation.
|
||||
|
||||
### Signers and Messages
|
||||
|
||||
So, where a "normal" Monero wallet without MMS simply told manages three types of data (addresses, accounts and transactions), the MMS adds two more: Signers and messages.
|
||||
|
||||
The MMS manages, for each multisig wallet separately, a list of *authorized signers*. With 2/3 multisig that list has **three** entries. On a technical level, each entry represents a Monero wallet containing keys that can be used to sign multisig transactions. On a conceptual level it's easier to imagine a group of 3 people, i.e. yourself and 2 partners, as those "authorized signers". (Often there will be indeed 3 distinct people controlling the 3 wallets, but not always of course.)
|
||||
|
||||
The MMS also manages a single list of *messages* per wallet: All messages you send, plus all messages you receive. While the list of authorized signers is the same in all involved wallets, those messages of course differ. The more authorized signers there are to send you messages, and the longer you transact, the more messages will accumulate.
|
||||
|
||||
## Getting the MMS
|
||||
|
||||
Right now, at the time of writing this manual (year-end 2018), the MMS is only available as part of the latest Monero code (`master` branch on Monero's [GitHub repository](https://github.com/monero-project/monero)). To use it, you have to check out that source code and compile it yourself. Doing so is easiest on a Linux system.
|
||||
|
||||
With the next hardfork in Spring 2019 the MMS will become an integral standard part of the Monero software: You install Monero, you have it.
|
||||
|
||||
A word of caution: At the time of writing using the latest development Monero version does not lead to conflicts and complications with any regular Monero release software and downloaded blockchain on the same system, but that may change between now and the hardfork, especially near the hardfork.
|
||||
|
||||
## Installing and Configuring PyBitmessage
|
||||
|
||||
Installing PyBitmessage is easy enough: You find links to downloads and install instructions from the [Bitmessage Wiki homepage](https://bitmessage.org/wiki/Main_Page). There are versions for all the major OS that Monero also supports: Linux, Windows, and macOS.
|
||||
|
||||
After installing run it, configure a Bitmessage address for you and note it, as you will later need it to configure your multisig wallet.
|
||||
|
||||
Don't worry right away if PyBitmessage does not seem to connect to the Bitmessage network when you run it the first time: Due to the decentral nature of that network it can take quite some time for your initial connect. It seems this often takes **half an hour**.
|
||||
|
||||
Likewise sending the very first message to a brand-new Bitmessage address can take time because there is a key exchange involved, sometimes another half of an hour. Once the key exchange is done messages are typically delivered within a few minutes however, sometimes within seconds.
|
||||
|
||||
You don't need to configure more than one Bitmessage address for you. You can run several multisig wallets over a **single** address without any problems because the MMS will be able to pick the right messages for the right wallets. You can even continue to use the same address for "normal" messages; those won't disturb the MMS, it will simply ignore any messages not intended for it.
|
||||
|
||||
Out of the box your PyBitmessage installation is not yet ready for use with the MMS because it does not allow other programs to use its API per default, you have to enable this explicitely (which makes sense, of course, for security reasons).
|
||||
|
||||
You find instructions how to **enable the API** on the [Bitmessage wiki API reference page](https://bitmessage.org/wiki/API_Reference). You will use the user name and the password you choose here later as command-line parameters for the CLI wallet so that the MMS will be able to log in to PyBitmessage.
|
||||
|
||||
## Further PyBitmessage Tweaks
|
||||
|
||||
The current official release version 0.6.3.2 has a [Dandelion++ protocol extension](https://arxiv.org/abs/1805.11060) built-in that hardens the network further against attacks that try to track message flow to find out who sends messages to whom. Unfortunately it seems that it has still a bug somewhere that can lead to wildly differing and very long message transmission times which is quite unfortunate when using the MMS.
|
||||
|
||||
There is a way to switch off Dandelion++ which, in general, is not recommended of course, but useful for using the MMS as of now:
|
||||
|
||||
* Locate PyBitmessage's config file `keys.dat`
|
||||
* Make a new section there named `[network]`
|
||||
* Add the following line to this new section: `dandelion = 0`
|
||||
* Restart PyBitmessage
|
||||
|
||||
As a "good citizen" you may consider to open your PC for access from other Bitmessage nodes to your node from the outside by opening port 8444. You find background info about that in their [FAQ](https://bitmessage.org/wiki/FAQ). It's not strictly necessary however for your client to function.
|
||||
|
||||
## MMS Command Overview
|
||||
|
||||
There is only **one** new command in the CLI wallet that gives access to the MMS, sensibly called `mms`. That command has however quite a number of subcommands to handle all the various functions of the MMS. Here a list of the commands; for details each command has its own chapter later in the manual:
|
||||
|
||||
init Initialize and configure the MMS
|
||||
info Display current MMS configuration
|
||||
signer Define a signer by giving a single-word label, a transport address, and a Monero address, or list all defined signers
|
||||
list List all messages
|
||||
next Evaluate the next possible multisig-related action(s) according to wallet state, and execute or offer for choice
|
||||
sync Force generation of multisig sync data regardless of wallet state, to recover from special situations like "stale data" errors
|
||||
transfer Initiate transfer with MMS support; arguments identical to normal 'transfer' command arguments, for info see there
|
||||
delete Delete a single message by giving its id, or delete all messages by using 'all'
|
||||
send Send a single message by giving its id, or send all waiting messages
|
||||
receive Check right away for new messages to receive
|
||||
note Send a one-line note message to a signer, identified by its label, or show all unread notes
|
||||
show Show detailed info about a single message
|
||||
export Export the content of a message to file
|
||||
set Set options, 'auto-send' being the only one so far
|
||||
|
||||
start_auto_config Start the auto-config process at the auto-config manager's wallet by creating new tokens
|
||||
auto_config Start auto-config by using the token received from the auto-config manager
|
||||
stop_auto_config Delete any tokens and abort an auto-config process
|
||||
send_signer_config Send your complete signer configuration to all other signers
|
||||
|
||||
You get the list of commands by issuing `help mms`, and help for a particular subcommand by using `help mms <subcommand>`, e.g. `help mms next`. You can alternatively use `mms help <subcommand>` if that feels more natural.
|
||||
|
||||
## Configuring a Wallet for Use with the MMS
|
||||
|
||||
### Addresses and Labels
|
||||
|
||||
First for better understanding some basic facts about addressing and referring to signers (or their wallets respectively) in the MMS:
|
||||
|
||||
If you create a new wallet it gets (of course) its own, unique public Monero address. If you later configure the wallet for multisig, the wallet **changes** its public address to the common multisig address that you share with all the other authorized signers.
|
||||
|
||||
The MMS uses the first, "original" public Monero address over the whole wallet lifetime for addressing, before **and** after "going multisig". It may be a little confusing that a wallet should have **two** public addresses somehow, but once you got the original address into your signer configuration you can more or less forget about it.
|
||||
|
||||
The MMS uses *labels* that allow you to name yourself and the other signers, and that the MMS commands use when referring to signers. (Using Monero addresses or Bitmessage addresses in such commands would be quite cumbersome.)
|
||||
|
||||
Labels must be one word, and they must be unique within a single wallet. The example later on in this manual uses the labels `alice` and `bob` for a case of 2/2 multisig.
|
||||
|
||||
### Running CLI Wallet
|
||||
|
||||
When you start the CLI wallet for use with the MMS there are the following two new (optional) command line parameters for connecting to PyBitmessage:
|
||||
|
||||
--bitmessage-address Use PyBitmessage instance at URL <arg>
|
||||
--bitmessage-login Specify <arg> as username:password for PyBitmessage API
|
||||
|
||||
If you have PyBitmessage running on the same machine as the CLI wallet the default for the first parameter will do, and you should not need to set anything different. If it does not seem to find it despite running locally try to use `http://localhost` or `http://127.0.0.1` as argument for the first parameter.
|
||||
|
||||
Beside that, you need of course either `--testnet` or `--stagenet` to connect to the right network. Also using `--log-level 0` could be useful: This instructs the wallet to write detailed info into its logfile that might help to find bugs or problems with the MMS.
|
||||
|
||||
So a complete command line for the CLI wallet could look like this:
|
||||
|
||||
./monero-wallet-cli --testnet --bitmessage-login mmstest:p4ssw0rd --log-level 0
|
||||
|
||||
### Initializing the MMS
|
||||
|
||||
After creating a new wallet you have to initialize it for use with the MMS; without that crucial first step you won't be able to use any MMS features. The command to do so is `mms init`:
|
||||
|
||||
mms init <required_signers>/<authorized_signers> <own_label> <own_transport_address>
|
||||
|
||||
`own_transport_address` is the Bitmessage address that you configured in your own PyBitmessage program. A full `init` command could look like this:
|
||||
|
||||
mms init 2/2 alice BM-2cUVEbbb3H6ojddYQziK3RafJ5GPcFQv7e
|
||||
|
||||
Use that `init` command **only once**: Executing it a second time will completely re-initialize the MMS by deleting any signer info and any messages, which you don't want except in special circumstances.
|
||||
|
||||
If you want to go through a MMS test as fast as possible you can instruct the wallet to ask for the password only when strictly necessary for technical reasons, and tell the MMS to send any generated message right away instead of prompting before doing so:
|
||||
|
||||
set ask-password 0
|
||||
mms set auto-send 1
|
||||
|
||||
(Both those settings are active during the 2/2 multisig example shown in this manual.)
|
||||
|
||||
### Configuring Signers
|
||||
|
||||
About each signer the MMS needs to know three things:
|
||||
|
||||
* The one-word *label* that you will use to refer to that signer
|
||||
* The *transport address* which currently means their Bitmessage address as long as this is the only supported message transport system
|
||||
* The *Monero address* i.e. the "original" Monero address of their wallet
|
||||
|
||||
(See also above chapter *Addresses and Labels*.)
|
||||
|
||||
You don't have to create signers; after the `mms init` command they are already all "there", although without any info yet with the exception of yourself. The commands for setting signer information refer to them by number, 1 up to the total number of authorized signers, so 1 and 2 in the following 2/2 multisig example with signers named *Alice* and *Bob* and thus with the labels *alice* and *bob*.
|
||||
|
||||
After the above sample `init` command the list of signers looks like that:
|
||||
|
||||
# Label Transport Address
|
||||
Auto-Config Token Monero Address
|
||||
1 alice BM-2cUVEbbb3H6ojddYQziK3RafJ5GPcFQv7e
|
||||
A1VRwm8HT8CgA5bSULDZKggR9Enc9enhWHNJuDXDK4wDD6Rwha3W7UG5Wu3YGwARTXdPw1AvFSzoNPBdiKfpEYEQP1b5cCH
|
||||
|
||||
2 <not set> <not set>
|
||||
<not set>
|
||||
|
||||
Note that signer #1 is always "me" i.e. your own label, transport address and Monero address. So in Alice's signer list #1 will be Alice and #2 will be Bob, while in Bob's wallet it will be exactly the other way round.
|
||||
|
||||
There are **three ways** to complete signer information: You can enter it manually, or you can use the auto-config mechanism that the MMS offers, which has a second, "semi-automatic" variant. With 2/2 there is hardly a difference in effort, but with higher numbers of signers auto-config is easier and more reliable. In any case, one advantage of auto-config is a secure transport of addresses because PyBitmessage is used.
|
||||
|
||||
So pick **one** method from the three following chapters *Manually Configuring Signers*, *Auto-Config* and *Sending Signer Information*:
|
||||
|
||||
### Manually Configuring Signers
|
||||
|
||||
The command to manually enter signer info and display the list of signers is `mms signer`:
|
||||
|
||||
mms signer [<number> <label> [<transport_address> [<monero_address>]]]
|
||||
|
||||
Without any argument the command displays the list of signers. With at least a number and a label you can set or change info about a particular signer. A full command to set everything about signer #2 could look like this:
|
||||
|
||||
mms signer 2 bob BM-2cStcTfCx8D3McrMcmGZYZcF4csKcQT2pa 9yXKZ6UUdd8NnNN5UyK34oXV7zp7gjgZ4WTKHk8KzWsAAuyksfqoeRMLLkdWur85vnc1YL5E2rrMdPMHunA8WzUS9EL3Uoj
|
||||
|
||||
A command to later change only the label of signer #2 could be:
|
||||
|
||||
mms signer 2 bob-the-builder
|
||||
|
||||
With this manual method it's up to the signers *how* they all get to know each other's addresses.
|
||||
|
||||
Be careful while entering signer information: Any mistakes like wrong Bitmessage addresses will probably make it impossible to correctly transact later on.
|
||||
|
||||
Before you go out and start to exchange signer information over insecure channels like IRC or plain unencrypted e-mail, please note that there are certain dangers in doing so. If somebody can e.g. intercept your e-mails and get hold of your addresses that you send to a signer that person can then impersonate the signer.
|
||||
|
||||
There is also the danger that in a 2/3 multisig scenario for *escrow* signer Bob can set up a second wallet for the trusted third-party Trent beside his own and trick Alice into sending everything to that wallet instead of Trent's. After this Bob will be able to transact alone and steal coins from Alice.
|
||||
|
||||
You find a more detailed explanation of this second danger in chapter *Security* towards the end of the manual or [here](https://taiga.getmonero.org/project/rbrunner7-really-simple-multisig-transactions/wiki/multisig-and-insecure-communication-channels). Auto-config mitigates this danger to quite some extent.
|
||||
|
||||
Alice's complete signer list looks like this:
|
||||
|
||||
# Label Transport Address
|
||||
Auto-Config Token Monero Address
|
||||
1 alice BM-2cUVEbbb3H6ojddYQziK3RafJ5GPcFQv7e
|
||||
A1VRwm8HT8CgA5bSULDZKggR9Enc9enhWHNJuDXDK4wDD6Rwha3W7UG5Wu3YGwARTXdPw1AvFSzoNPBdiKfpEYEQP1b5cCH
|
||||
|
||||
2 bob BM-2cStcTfCx8D3McrMcmGZYZcF4csKcQT2pa
|
||||
9yXKZ6UUdd8NnNN5UyK34oXV7zp7gjgZ4WTKHk8KzWsAAuyksfqoeRMLLkdWur85vnc1YL5E2rrMdPMHunA8WzUS9EL3Uoj
|
||||
|
||||
### Auto-Config
|
||||
|
||||
MMS auto-config is based on so-called *auto-config tokens*. Such tokens are always 11 characters long, the fixed string "mms" followed by 8 hexadecimal digits. Examples for such tokens are `mms561832e3eb` and `mms62cb2b87e2`.
|
||||
|
||||
The basic trick: Unlike Bitmessage addresses and Monero addresses those tokens are short enough to type them easily and e.g. use reasonably safe smartphone messenger apps or SMS to transmit them, or dictate them over the phone, again not perfectly safe, but still much safer than plain e-mail or IRC.
|
||||
|
||||
The workflow is as follows - it's simpler than it looks at first sight, go once through it in practice and it makes sense:
|
||||
|
||||
* One signer takes on the job to lead and organize configuration, furthermore called *manager*
|
||||
* The manager assigns a label to each signer and enters all labels into the signer configuration, either using `mms signer` commands or giving them as arguments of the `mms start_auto_config` command in the next step
|
||||
* The manager uses the command `mms start_auto_config` to generate auto-config tokens for all other signers, one distinct token per signer
|
||||
* The manager transmits the tokens to their respective signers outside of the MMS
|
||||
* All other signers enter their token with `mms auto_config <token>`
|
||||
* Their wallets will generate messages that send their addresses to the manager's wallet, already using PyBitmessage
|
||||
* As soon as all those messages arrive there the manager can in turn send messages to all other signers containing the complete signer information by doing `mms next`
|
||||
* The other signers process those messages to complete their signer information with `mms next`
|
||||
|
||||
Several points are noteworthy here. Manual configuration with e.g. 5 signers could mean 5 times 4 = 20 initial manual information transfers, if each of the 5 signers sends addresses to 4 others. Even a more clever approach with someone collecting all addresses first and sending the complete list to all others then would take 4 plus 4 = 8 information transfers. With auto-config there are only **4** such manual transfers - 4 tokens from the manager out to the other signers; after that point it's already messages over PyBitmessage.
|
||||
|
||||
You may wonder how the other signers' wallets can send their Bitmessage addresses back to the manager by using PyBitmessage. Doesn't this snake bite its own tail? The solution: A temporary, "throw-away" Bitmessage address is derived from each token and used just for this transfer, and temporary keys are derived as well for encrypting message content.
|
||||
|
||||
Part of the increased safety of the auto-config process is the fact that each signer gets its own, distinct token. In 2/3 multisig, just make sure Bob cannot get hold of Trent's own token, and already Bob has no way to "play" Trent and set up a second wallet to be able to sign transactions all on his own.
|
||||
|
||||
### Sending Signer Configuration
|
||||
|
||||
Beside full auto-config there is a second, alternative way to make configuration easier, based on a command called `send_signer_config`. It's less "automatic", but you may prefer it because it's more transparent what happens.
|
||||
|
||||
Here the workflow is as follows:
|
||||
|
||||
* One signer takes on the job to lead and organize configuration, furthermore called *manager*
|
||||
* The manager receives from all other signers their addresses over channels outside the MMS, e.g. encrypted and signed e-mail
|
||||
* The manager enters complete signer information into their wallet, using `mms member` commands
|
||||
* The manager uses the `mms send_signer_config` command to send the completed information to all other signers
|
||||
* The other signers process the messages containing signer information with `mms next`
|
||||
|
||||
For all signers except the manager this is nearly as comfortable as auto-config. Note however that the security of the scheme depends on securing the sending of info to the manager: If some signer can posit as not only themselves, but as other signers as well, they will be able to control several wallets and undermine the whole signing process. (See also chapter *Manually Configuring Signers* for more about such dangers.)
|
||||
|
||||
## Establishing the Multisig Address
|
||||
|
||||
In general, there are no MMS commands to execute particular steps regarding multisig transactions (with the exception of starting a transfer using `mms transfer` and force sync with `mms sync`). You just use the `mms next` command, and the MMS will do whatever is next in the "multisig workflow", and if nothing is ready, e.g. because some messages are still missing, will tell you the reason why nothing is "next" yet.
|
||||
|
||||
So, after you completed the info about all signers, either manually or through auto-config, you just issue a `mms next` command, and the MMS will start with the first step needed to establish the multisig address: Calculate *key sets* for all coalition members and set up messages to send those to them. The whole scene might look like this for Alice:
|
||||
|
||||
[wallet A1VRwm]: mms next
|
||||
prepare_multisig
|
||||
MultisigV18uEUr5L7EvFDqKWvbnK2ys395ddRPuG6zaxNTwbDq3WoUNJtkPUPbRAEQKBaCC52g5iJXi8XUF4aUP9984hdFrHsP1y3W8yQkm
|
||||
YUSDYXzouhzd479tMmpL4LJKUoW5e54bubEg5E4J3BZtJQiGNzvVsiBKGAKgT7J4bcNN66Xq7hpL4V
|
||||
Send this multisig info to all other participants, then use make_multisig <threshold> <info1> [<info2>...] with others' multisig info
|
||||
This includes the PRIVATE view key, so needs to be disclosed only to that multisig wallet's participants
|
||||
Id I/O Authorized Signer Message Type Height R Message State Since
|
||||
1 out bob: BM-2cStcTfCx8D3McrMcmGZ.. key set 0 0 ready to send 2018-12-26 07:46:21, 1 seconds ago
|
||||
Queued for sending.
|
||||
|
||||
The `prepare_multisig` output there is a hint that the MMS works by putting something like a "wrapper" about the CLI wallet `pepare_multisig` command, it even displays the `MultisigV1` string for confirmation. Now you don't have to send that manually to the other signer somehow: The MMS prepares a message for that and sends it in a fully automatic way.
|
||||
|
||||
After Alice receives Bob's key set, another `mms next` command will process it and establish the multisig address:
|
||||
|
||||
[wallet A1VRwm]: mms next
|
||||
make_multisig
|
||||
Wallet password:
|
||||
2/2 multisig address: 9uWY5Kq6XocGGqUByp22ty4HYxj4CfjCXdRrZ24EKvYW2U7fudSzCvTRRT35tMNx5heQfqKmVmFjahWUZ1BENnzH8UvyVF7
|
||||
|
||||
The wallet may be "out of sync" after this step; if yes, just do a quick `refresh`.
|
||||
|
||||
In the case of non-symmetrical M/N multisig, with M different from N, like e.g. in 2/3, it's not enough that each signer sends one key set to every other signer: There will be several *rounds* of key set exchanges. However the MMS knows about this and will automatically take care of almost everything: For a particular wallet it waits until the key sets of all other signers have arrived before going on. If there is another key exchange round necessary, `mms next` will then start a new one. If not, the command will process the last key set(s) and establish the multisig address.
|
||||
|
||||
It's possible that a future enhanced version of the MMS will do this in a fully automatic way, i.e. sending all necessary key sets around without further intervention until the multisig address is configured. For now however you have to push things along yourself by issuing `mms next` commands.
|
||||
|
||||
## Funding the Multisig Wallet
|
||||
|
||||
With the multisig address established the wallet is now ready to receive funds. Here the MMS plays no role, nor does multisig in general: Just transfer some coins to the address, to have something to transfer out later, and wait until they arrive.
|
||||
|
||||
## Syncing Wallets
|
||||
|
||||
Every time after receiving or sending coins multisig wallets must exchange some info with each other to get "into sync" again. That's the case whenever the CLI wallet tells you about *partial key images* like in this `balance` command output:
|
||||
|
||||
[wallet 9uWY5K]: balance
|
||||
Currently selected account: [0] Primary account
|
||||
Tag: (No tag assigned)
|
||||
Balance: 7.000000000000, unlocked balance: 7.000000000000 (Some owned outputs have partial key images - import_multisig_info needed)
|
||||
|
||||
That "import_multisig_info needed" thing is perhaps the single most tiresome aspect of CryptoNote multisig transactions and quite some work e.g. in the case of 3/3 or 2/3 multisig where already a total of **six** pieces of information must be passed around each time, only to finalize reception of some coins and/or being able to transfer again after a transfer.
|
||||
|
||||
At least, with the MMS, it's only a case of issuing `mms next` commands until all sync data is sent and received and the wallets get into sync again: It guides you automatically through the necessary `export_multisig_info` and `import_multisig_info` commands. Here again how Alice sees this:
|
||||
|
||||
[wallet 9uWY5K]: mms next
|
||||
export_multisig_info
|
||||
Multisig info exported to MMS
|
||||
Id I/O Authorized Signer Message Type Height R Message State Since
|
||||
5 out bob: BM-2cStcTfCx8D3McrMcmGZ.. multisig sync data 1 0 ready to send 2018-12-26 08:58:14, 0 seconds ago
|
||||
Queued for sending.
|
||||
MMS received new message
|
||||
Id I/O Authorized Signer Message Type Height R Message State Since
|
||||
6 in bob: BM-2cStcTfCx8D3McrMcmGZ.. multisig sync data 1 0 waiting 2018-12-26 08:59:45, 0 seconds ago
|
||||
[wallet 9uWY5K]: mms next
|
||||
import_multisig_info
|
||||
Height 1117984, txid <b515082063a6242f1b62f21c80f95c90801f14ce3f48f51094d069e3580a78aa>, 7.000000000000, idx 0/0
|
||||
Multisig info imported03
|
||||
|
||||
Don't worry if you receive such sync messages from other signers already before you are able to start sending yours: The MMS will handle this situation quite fine and send first, process afterwards.
|
||||
|
||||
Check the chapter *Troubleshooting* if you ever get stuck somehow: E.g. there is a way to force sync even if `mms next` gets confused and thinks that syncing is not necessary or not possible.
|
||||
|
||||
## Making Multisig Transactions
|
||||
|
||||
For initiating multisig transactions there is the command `mms transfer` instead of the normal `transfer` command. The MMS variant supports all the parameter variations of the normal command; thus to get help use `help transfer`.
|
||||
|
||||
The MMS does not care about subaddresses and accounts; whatever address you use for sending (and receiving) transactions, the MMS only cares about the data that the particular event creates, about the right moment to process that and about sending it to the right recipient(s).
|
||||
|
||||
If you don't like your transaction data to become part of the `.mms` file in the form of stored message content, you can use the normal `transfer` command, but then it's of course your problem to send the partially signed transaction to the next signer.
|
||||
|
||||
With multisig the `mms transfer` command does of course not yet transfer, but produces a partially-signed transaction instead. This stretches the concept of messages a bit because `mms transfer` produces a message to "me" i.e. the owner of the wallet itself, with the partially-signed transaction as content. Check message #7 below to Alice:
|
||||
|
||||
[wallet 9uWY5K]: mms transfer 9zo5QDV9YivQ8Fdygt7BNdGo1c98yfAWxAz6HMwsf15Vf1Gkme9pjQG2Typ9JnBKv5goziC2MT93o3YDUfoWdU9XUinX5kS 5
|
||||
No payment id is included with this transaction. Is this okay? (Y/Yes/N/No): y
|
||||
|
||||
Transaction 1/1:
|
||||
Spending from address index 0
|
||||
Sending 5.000000000000. The transaction fee is 0.000094300000
|
||||
Is this okay? (Y/Yes/N/No): y
|
||||
Unsigned transaction(s) successfully written to MMS
|
||||
[wallet 9uWY5K]: mms list
|
||||
Id I/O Authorized Signer Message Type Height R Message State Since
|
||||
...
|
||||
7 in alice: BM-2cUVEbbb3H6ojddYQz.. partially signed tx 1 0 waiting 2018-12-26 09:10:42, 40 seconds ago
|
||||
|
||||
The idea behind this: In this state, with the transaction waiting, and depending on the number of required signers, `mms next` will result in a question what to do with it: Especially in the case of 2/3 multisig, it's central to be able to decide **where** to send the transaction for the second signature that will make it valid, i.e. to **which** of the two possible signers.
|
||||
|
||||
This could look like in this case of 2/4 multisig:
|
||||
|
||||
Unsigned transaction(s) successfully written to MMS
|
||||
[wallet 9vAbBk]: mms next
|
||||
Choose processing:
|
||||
1: Send the tx for signing to two: BM-2cUVEbbb3H6ojddYQziK3RafJ5GPcFQv7e
|
||||
2: Send the tx for signing to three: BM-2cStcTfCx8D3McrMcmGZYZcF4csKcQT2pa
|
||||
3: Send the tx for signing to four: BM-2cUjNoSxPkUY7ho4sPcEA6Rr26jqcasKiE
|
||||
|
||||
In the case of the 2/2 multisig example in this manual, there is no choice however: The transaction started by Alice has to go to Bob as the only other authorized and required signer:
|
||||
|
||||
[wallet 9uWY5K]: mms next
|
||||
Send tx
|
||||
Id I/O Authorized Signer Message Type Height R Message State Since
|
||||
8 out bob: BM-2cStcTfCx8D3McrMcmGZ.. partially signed tx 1 0 ready to send 2018-12-26 09:29:30, 0 seconds ago
|
||||
Queued for sending.
|
||||
|
||||
After receiving Bob signs, as usual not with a dedicated signing command that does not exist, but by simply using `mms next`:
|
||||
|
||||
[wallet 9uWY5K]: mms next
|
||||
sign_multisig
|
||||
Loaded 1 transactions, for 7.000000000000, fee 0.000094300000, sending 5.000000000000 to
|
||||
9zo5QDV9YivQ8Fdygt7BNdGo1c98yfAWxAz6HMwsf15Vf1Gkme9pjQG2Typ9JnBKv5goziC2MT93o3YDUfoWdU9XUinX5kS, 1.999905700000 change to
|
||||
9uWY5Kq6XocGGqUByp22ty4HYxj4CfjCXdRrZ24EKvYW2U7fudSzCvTRRT35tMNx5heQfqKmVmFjahWUZ1BENnzH8UvyVF7, with min ring size 11,
|
||||
no payment ID. Is this okay? (Y/Yes/N/No): y
|
||||
Transaction successfully signed to file MMS, txid c1f603a9045f28b28f221eddf55be41e95f2ac7213384a32d35cadc0a8be3026
|
||||
It may be relayed to the network with submit_multisig
|
||||
|
||||
Yet another `mms next` does result in a choice for Bob, because he can either submit the transaction to the network himself, **or** send it back to Alice for doing so:
|
||||
|
||||
[wallet 9uWY5K]: mms next
|
||||
Choose processing:
|
||||
1: Submit tx
|
||||
2: Send the tx for submission to alice: BM-2cUVEbbb3H6ojddYQziK3RafJ5GPcFQv7e
|
||||
Choice:
|
||||
|
||||
As already mentioned elsewhere after the transaction is submitted to the network and processed you have to sync the wallets before you can do another transfer. Also note that regardless of any syncing needs it's a restriction of Monero multisig that you must do **strictly one transaction after the other**. For example you can't put away fully-signed transactions for submitting them later and already start a new one to submit that first. (For some such scenarious the MMS is not smart enough to prevent you from trying; see chapter *Troubleshooting* about how you can recover by deleting messages containing unprocessable transactions and forcing sync.)
|
||||
|
||||
As already mentioned you can keep out your transaction data out of the `.mms` file in the form of stored message content and use the normal `transfer` command, but then it's of course your problem to send the partially signed transaction to the next signer. Note also that the MMS does not support cold signing; that would be another reason to directly use `transfer` instead of `mms transfer`. You can, however, export transaction data contained in a message with the `mms export` command.
|
||||
|
||||
## The Commands in Detail
|
||||
|
||||
### mms init
|
||||
|
||||
mms init <required_signers>/<authorized_signers> <own_label> <own_transport_address>
|
||||
|
||||
Example:
|
||||
|
||||
mms init 2/2 alice 2cUVEbbb3H6ojddYQziK3RafJ5GPcFQv7e
|
||||
|
||||
Prepare a wallet for use with the MMS. You can later change your own label and your own transport address using `mms signer`, but the two numbers, required signers and authorized signers, cannot be changed without issuing `mms init` again which will erase all signer information and all messages. The command will lead to the creation of an additional file with an extension of `.mms` for the wallet.
|
||||
|
||||
For wallets created in "pre-MMS times" (before the MMS code was included in Monero) it's only possible to initialize the MMS if the wallet is not yet multisig. For wallets created with Monero code already present it's possible to initialize even with the wallet multisig already: When the wallet switched to multisig the "original" Monero address needed by the MMS was saved before it got replaced by the common multisig address.
|
||||
|
||||
There is no command to deactivate the MMS. If you no longer want to use it for a particular wallet, just delete the `.mms` file or at least move it out of the way.
|
||||
|
||||
### mms info
|
||||
|
||||
mms [info]
|
||||
|
||||
Display whether the MMS is active or not, and if yes, show the number of required signers and number of authorized signers. This is the only MMS command allowed with the MMS inactive.
|
||||
|
||||
### mms signer
|
||||
|
||||
mms signer [<number> <label> [<transport_address> [<monero_address>]]]
|
||||
|
||||
Examples:
|
||||
|
||||
mms signer
|
||||
mms signer 2 bob BM-2cStcTfCx8D3McrMcmGZYZcF4csKcQT2pa 9yXKZ6UUdd8NnNN5UyK34oXV7zp7gjgZ4WTKHk8KzWsAAuyksfqoeRMLLkdWur85vnc1YL5E2rrMdPMHunA8WzUS9EL3Uoj
|
||||
mms signer 2 bob-the-builder
|
||||
|
||||
Without argument, show the list of signers and their info, as far as known. Things never set and therefore still unknown are displayed as `<not set>`. Note that you don't have to and can't create signers: After `mms init` they already all "exist", although without any information set, with the exception of signer #1 which is always "me" i.e. the current wallet itself. Their number is fixed, it's the number of authorized signers as specified with `mms init`.
|
||||
|
||||
With at least a number and a label as argument, set information about a signer, or change any information already set. You can always freely change labels and transport addresses, but for technical reasons Monero addresses can only be changed as long as there are no messages. In the worst case do `mms init` again and start from scratch.
|
||||
|
||||
Numbers start with 1 and go up to the number of authorized signers.
|
||||
|
||||
A *label* must be a single word. Use characters like minus "-" or underscore "_" to write more complex labels like e.g. `alice_in_wonderland`. Labels must be unique for all signers. There is no fixed maximal length for labels but some output will look strange or become hard to read with very long labels.
|
||||
|
||||
A *transport address* can currently only be a Bitmessage address like e.g. `BM-2cStcTfCx8D3McrMcmGZYZcF4csKcQT2pa`, PyBitmessage being the only supported program for actual message transport. Transport addresses are not checked for syntax or validity by the MMS; if you enter a malformed address you will get an error message from PyBitmessage only later at first (attempted) use.
|
||||
|
||||
If you enter a wrong address i.e. not the correct address for the respective signer most probably nothing will happen, the messages will just not reach the intended recipient; if nobody holds the key for that address, with a Bitmessage client configured to receive messages to it, the message will just "float around" the Bitmessage network for a while and finally expire.
|
||||
|
||||
### mms list
|
||||
|
||||
mms list
|
||||
|
||||
List all stored messages. There are no separate inbox and outbox; all messages are contained in a single chronological list. The columns in detail:
|
||||
|
||||
* `Id`: The unique id of the message that you can use to refer to the message in commands like `mms show` and `mms send`. Message ids count strictly upwards from 1. Ids of deleted messages won't get "recycled".
|
||||
* `I/O`: Message direction. `in` denotes a message that you received, `out` a message that you sent. Note than for some message types you can receive a message from yourself, e.g. a partially signed transaction that you started yourself.
|
||||
* `Authorized Signer`: In case of a received message, the sender, in case of a sent message, the recipient. Listed are the label and, within the width limit of the column, the transport address of the signer.
|
||||
* `Message Type`: The type of the message telling what kind of data it contains. For a complete list of possible message types see below.
|
||||
* `Height`: The number of transfers contained in the wallet at the time of message construction or reception. Used to group the "right" sync data messages which all must be from the same "height" for all other signers before sync can be successful. This height is unimportant for you except in cases where something went wrong; for more see chapter *Troubleshooting*.
|
||||
* `R`: The number of the key exchange round a key set belongs to, if the type of multisig requires more than one round in the first place, like e.g. 2/3. 0 for all other message types.
|
||||
* `Message State`: The current state of the message. `waiting` or `sent` for outgoing messages, `waiting` or `processed` for incoming messages. You can't directly change this state, it's always the result of the execution of commands.
|
||||
* `Since`: Point in time and time span since the message got its current message state. Times are in UTC, not local time. If you re-send a message, this timestamp is not adjusted and continues to display the time of the first sending.
|
||||
|
||||
The complete list of message types:
|
||||
|
||||
* `key_set`: Data about keys that wallets must exchange with each other for establishing multisig addresses
|
||||
* `additional_key_set`: A key set for an additional key exchange round, after the original one, as necessary for non-symmetric multisig types like e.g. 2/3
|
||||
* `multisig_sync_data`: Data that wallets must exchange with each other to correctly and completely interpret incoming and outgoing transactions; see also chapter *Syncing Wallets*
|
||||
* `partially_signed_tx`: A transaction that has not yet the necessary number of signatures (= number of required signers) to commit it
|
||||
* `fully_signed_tx`: A transaction with a full set of required signatures, ready for submission to the Monero network; any signer could submit this
|
||||
* `note`: A message containing a note; see command `mms note`
|
||||
* `signer_config`: Full information about all signers, to be sent as part of an auto-config process or as a result of a `mms send_signer_config` command
|
||||
* `auto_config_data`: Address data from a signer to send back to the auto-config manager after entering a token with `mms auto_config`
|
||||
|
||||
### mms next
|
||||
|
||||
mms next [sync]
|
||||
|
||||
*The* central and probably most useful command of the MMS: Check the state of the wallet plus the received and sent messages and their message state, and decide which action is the next one to execute, and then actually execute it.
|
||||
|
||||
When in doubt, just issue a `mms next` command; the MMS will either execute the proper next command according to Monero's "multisig workflow rules", or tell you what it's waiting for before it can proceed. For "dangerous" things you can count on confirming prompts before the real action happens. Worst case a `mms next` can execute something earlier than you might have intended, but otherwise can hardly do any harm.
|
||||
|
||||
Note how for many actions there is **no** dedicated command, and `mms next` the **only** way to move things forward. Don't look e.g. for commands to selectively process certain messages: If it's time to process some received messages in state *waiting*, the command will do so.
|
||||
|
||||
Interestingly and maybe surprisingly, in Monero it's **always** clear what has to happen next regarding multisig, except in the case of partially signed transactions where you can decide **which** signer sending them to, and in the case of fully signed transactions that you can submit yourself to the network or send them to another signer for submission by them.
|
||||
|
||||
The special command form `mms next sync` is for cases where sync data is waiting that the MMS on its own would not process because it "thinks" the wallet is in a state needing no new sync - which might be wrong. More about this in chapter *Troubleshooting*.
|
||||
|
||||
### mms sync
|
||||
|
||||
mms sync
|
||||
|
||||
Manually start a round of syncing forcibly i.e. even if the MMS is of the opinion that no exchange of sync data is currently necessary. More about this in chapter *Troubleshooting*.
|
||||
|
||||
### mms transfer
|
||||
|
||||
mms transfer <transfer_command_arguments>
|
||||
|
||||
Start a transfer under the control of the MMS, the difference to the standard `transfer` command being that the resulting partially signed transaction won't be written to a file that you have to handle further yourself, but that a message containing the transaction will result. Use `mms next` after `mms transfer` to ask the MMS to actually process the message which in effect means deciding which signer send it to for the next signature and create another message for that.
|
||||
|
||||
The arguments of the `mms transfer` command are exactly the same of those of the standard `transfer` command. Check the info about that command with `help transfer` to learn about all the various possible parameters and parameter combinations.
|
||||
|
||||
Note that quite in general the MMS does not care about addresses, subaddresses and acccounts. Regardless of what you specify in this regard for a `mms transfer` command afterwards there will always be a single new message containing the partially signed transaction.
|
||||
|
||||
Even with MMS active you can still use the standard `transfer` command; you are then simply on your own regarding handling the transaction. Try to use the right command variant; `transfer` won't ask for confirmation whether you really intend to use it instead of `mms transfer`. If you issued `transfer` but really wanted the MMS variant, ignore the written transaction file and simply go on with `mms transfer`.
|
||||
|
||||
The MMS does not, or at least not yet, keep track how many signatures a transaction actually has and who signed already and who not yet. Because of this weakness it can include choices that do not make sense, e.g. a choice to send a partially signed transaction to somebody who signed already.
|
||||
|
||||
This hardly matters with multisig types like 2/2 or 2/3, but of course the higher the number of authorized signers, the more acute this can become. Some attention by the signers is needed to do the right thing. You can't go wrong in an absolute sense however: The CLI wallet, or more exactly the CLI commands called internally by the MMS, will reject any attempts to do invalid actions.
|
||||
|
||||
### mms delete
|
||||
|
||||
mms delete (<message_id> | all)
|
||||
|
||||
Delete a single message given its message id, or delete all messages by using the `all` parameter. Single messages will be deleted without confirmation even if not yet sent or not yet processed. A deleted message is gone for good, there is no undo, and it's gone from PyBitmessage's store as well. (If you loose a message you can ask the sender to re-send it to you.)
|
||||
|
||||
There are situations where you have to clear by deleting messages that did not get processed, got unprocessable and now "disturb the workflow"; more see chapter *Troubleshooting*. Deleting is also useful when somebody re-sends you a message and the original message finally reaches you as well later on.
|
||||
|
||||
You could say that the value of a sent or processed message itself is not very high as in most cases you won't ever need it again, and for many messages there are no commands to process them again on demand anyway. But of course the list of messages itself can be quite valuable to see what happened, and when, so better not delete messages without a good reason.
|
||||
|
||||
### mms send
|
||||
|
||||
mms send [<message_id>]
|
||||
|
||||
Example:
|
||||
|
||||
mms send 14
|
||||
|
||||
Without parameter send any messages in status *ready to send*. With a message id as parameter send or re-send that particular message. To be able to re-send a message is part of the "messaging system UX" and makes for a quite robust processing because there are very few situations that you can't recover from: The Bitmessage network ate your message? No problem, re-send. PyBitmessage crashed? No problem, restart PyBitmessage and re-send your message.
|
||||
|
||||
Whether messages are immediately sent or whether the MMS asks for confirmation to do so first depends on the value of the `auto-send` parameter; see `mms set` command. Getting each message to send presented that way may be useful for beginners because it's clearer to see what happens; on the other hand it hardly ever makes sense to postpone sending because something else has to be sent first.
|
||||
|
||||
"Sending" does not mean really send; the MMS just submits the message to PyBitmessage and *that* program will actually send. The MMS cannot give any feedback whether a message is still waiting to go out to the Bitmessage network or went out already. When in doubt, check in PyBitmessage itself.
|
||||
|
||||
Any mistakes in Bitmessage addresses will only be detected at the moment of sending; the MMS itself does not check those addresses.
|
||||
|
||||
### mms receive
|
||||
|
||||
mms receive
|
||||
|
||||
Force an immediate check for received messages, or more exactly force an immediate query of the MMS to PyBitmessage whether there are any new messages.
|
||||
|
||||
The MMS checks for new incoming messages with the same frequence the CLI wallet checks for incoming transactions: Once very 90 seconds. And the setting to decide whether checking automatically or not is the same as well, `auto-refresh`.
|
||||
|
||||
### mms note
|
||||
|
||||
mms note [<label> <text>]
|
||||
|
||||
Examples:
|
||||
|
||||
mms note
|
||||
mms note bob Did you already submit the last transaction?
|
||||
mms note alice Yes, just waiting for the next block :)
|
||||
|
||||
Without parameters display any notes not yet read. With a label and further text as parameters send the text as a message of type `note` to the signer with the label.
|
||||
|
||||
Sending notes to each other directly from one Monero wallet to the next might be a fun way to avoid having to use additional communication channels for talking to signers.
|
||||
|
||||
If you want to read or re-read a particular note use the `mms show` command and look at the last line with the message content, in this case the text of the note.
|
||||
|
||||
### mms show
|
||||
|
||||
mms show <message_id>
|
||||
|
||||
Show detailed information about the message with the id used as command parameter. Useful to read or re-read notes. Binary message content is not displayed; use the `mms export` command and inspect the resulting file if you need to check such a message content.
|
||||
|
||||
### mms export
|
||||
|
||||
mms export <message_id>
|
||||
|
||||
Export the content of the message with the given id into a file with the fixed name `mms_message_content` in the current directory. An already existing file will be silently overwritten.
|
||||
|
||||
There is no `mms import` counterpart command yet.
|
||||
|
||||
### mms set
|
||||
|
||||
mms set <option_name> [<option_value>]
|
||||
|
||||
Example:
|
||||
|
||||
mms set auto-send 1
|
||||
|
||||
The MMS equivalent of the general `set` command. With only the name of an option show the current value of that option. With option name and option value set that option to the given value.
|
||||
|
||||
The only MMS-specific setting so far that this command handles is the `auto-send` setting. If set messages are not sent out automatically right after they are created but the MMS asks for confirmation first. See also `mms send` command. As soon as you are familiar with the MMS and comfortable using it it may be a good idea to set `auto-send` to 1 for less prompts and speedier progressing.
|
||||
|
||||
### mms start\_auto\_config
|
||||
|
||||
mms start_auto_config [<label> <label> ...]
|
||||
|
||||
Example:
|
||||
|
||||
mms start_auto_config bob trent
|
||||
|
||||
Start an auto-config process at the wallet of the "config manager" by creating auto-config tokens for every signer expect "me" i.e. the first one and do a `mms signer` command to display the tokens. Asks for confirmation if auto-config is seemingly already running because there are already tokens for signers in the signer configuration.
|
||||
|
||||
The manager has to transmit the auto-config tokens to the respective signers outside the MMS. Note that those tokens are sensitive information: A token in the hand of a non-signer or in the hand of the wrong signer will enable that person to impersonate the rightful signer i.e. take part in all transactions in stead of that signer.
|
||||
|
||||
Precondition for starting auto-config is *all* signers having a label assigned. The idea is that auto-config establishes the **same** labels in the wallets of all signers to make it clear to everybody who is who. (Only the order of the signers in each wallet will be different, because the owner of the wallet will always be signer #1.) Later the signers are free to change labels they don't like, as long as there is no danger to confound signers of course.
|
||||
|
||||
You can establish labels for all signers using the `mms signer` command beforehand, or more comfortably right with the `mms start_auto_config` command itself, by listing all labels except the label for "me" in the correct order as command arguments.
|
||||
|
||||
The command can be issued at basically any time, although of course it makes most sense at the beginning where for the wallets of all signers only `mms init` commands were executed yet.
|
||||
|
||||
Check chapter *Auto-Config* for a description of the following steps after this command.
|
||||
|
||||
### mms auto\_config
|
||||
|
||||
mms auto_config <auto_config_token>
|
||||
|
||||
Example:
|
||||
|
||||
mms auto_config mms561832e3eb
|
||||
|
||||
Process an auto-config token that you received from the "config manager" during an auto-config process through some reasonably secure communication channel outside of the MMS, e.g. SMS, smartphone messenger app, encrypted e-mail or phone call. Each signer gets their own distinct token. Treat any MMS auto-config tokens as confidential information.
|
||||
|
||||
This will result in a message of type `auto-config data` to send your Bitmessage address and your Monero address to the manager. (Transmission of that message is already as secure as any later MMS message, as long as nobody else knows your token.)
|
||||
|
||||
There is some tolerance in the way the MMS interprets entered tokens (e.g. they are not case-sensitive), and any typo will result in an invalid token with a high degree of probability and will be detected.
|
||||
|
||||
If it was decided to do auto-config best refrain from entering any signer information yourself manually with `mms signer`. (The MMS won't prevent it however.)
|
||||
|
||||
Check chapter *Auto-Config* for a complete list of all steps of an auto-config process.
|
||||
|
||||
### mms stop\_auto\_config
|
||||
|
||||
mms stop_auto_config
|
||||
|
||||
Delete any auto-config tokens from signer configuration and stop any running auto-config process that way.
|
||||
|
||||
Deleted tokens cannot be recoverd or reconstructed, as they are random. If you are the "config manager" and delete tokens you will never become able again to receive auto-config messages that other signers send to you using those deleted tokens. (Nobody else will receive them either, however.) Everybody will need new tokens issued by you.
|
||||
|
||||
### mms send\_signer\_config
|
||||
|
||||
mms send_signer_config
|
||||
|
||||
Manually send your complete signer configuration to all other signers as messages of type `signer config`. After receiving your message they will be able to replace their signer configuration by yours with a `mms next` command. There will be a security prompt before that happens.
|
||||
|
||||
Each signer will get their label overwritten with the label you entered for them, but their own Bitmessage address and Monero address will be preserved.
|
||||
|
||||
This command and its capability to "broadcast" a particular signer configuration can serve as a building block for something like a "semi-auto-config". See also chapter *Sending Signer Configuration*. Sending out a complete signer configuration is also part of fully-automatic config, although without needing a separate `mms send_signer_config` command.
|
||||
|
||||
## Security
|
||||
|
||||
The MMS was carefully designed and implemented as a system offering a high degree of security.
|
||||
|
||||
Which was not particularly easy: Monero multisig itself is already a multi-faceted if not to say complex process and thus not trivial to secure, and the MMS is a powerful if not to say complex system on top of that, so it's no wonder that there are various possible security issues.
|
||||
|
||||
Note that this the very **first** version of the MMS, and it may well be that people using it in different circumstances will uncover new security problems beyond those mentioned here, or let some of them appear in a different light. There is reasonable hope however that the MMS does not have any deep and basically "unrepairable" conceptual flaws.
|
||||
|
||||
TL;DR: If in doubt, start to use the MMS only after you have configured your multisig wallets yourself on your own, presumably in more secure ways than the MMS could provide (not trivial, but doable). If in even more doubt, don't use the MMS.
|
||||
|
||||
### Use of Encryption and Signatures
|
||||
|
||||
All message content is encrypted either using the Monero viewkeys of the signers' Monero wallets, or with randomly generated keys of the same strength in the case of auto-config message contents. This may seem a little excessive given that PyBitmessage encrypts all messages itself already, but first PyBitmessage is a third-party software that you may not want to trust, and second with this feature the MMS is already prepared to some degree for less secure communication systems that don't encrypt themselves.
|
||||
|
||||
Messages are signed by the sender using their view private key. This is used for authentication: The MMS will reject a message from a signer that does not carry a valid signature that only that signer, and nobody else, could have made. Furthermore, a hash secures the message content against any changes. Lastly only messages from signers are accepted: A message from a Monero address that is not listed in the signer configuration gets rejected, even if it carries a valid signature.
|
||||
|
||||
The viewkey is also used to encrypt the content of the `.mms` file that contains signer configuration and all sent and received messages.
|
||||
|
||||
Still, regarding data transmission security requirements one should probably stay realistic: Of course you don't want the various data packets that get shuttled back and forth between the signers' wallets to get into the wrong hands, but it would not be easy to cause real harm for an attacker holding some of that data. After all, the whole point of multisig is that only a group of people **cooperating** can sign off and submit a transaction. An attacker that gets hold of a partially signed transaction won't be able to do much with it.
|
||||
|
||||
(An attacker eavesdropping on **all communication** from the very start probably could, if data was not encrypted, collect all keys and build a fully working Monero "single-sig" wallet for the multisig address and steal coins, but that's a pretty drastic scenario, and data sent by the MMS **is** encrypted.)
|
||||
|
||||
### Communication MMS to PyBitmessage
|
||||
|
||||
Communication between the MMS and PyBitmessage is, unfortunately, not encrypted. Here, HTTP is used, not its encrypted counterpart HTTPS. Message content is of course encrypted **before** the MMS transmits a message to PyBitmessage, and any content changes would be detected when receiving messages, but somebody listening there could learn things from the "metadata": Who sends what to whom at which point in time.
|
||||
|
||||
As long as your Monero wallet with the MMS and PyBitmessage run on the same machine, that's not a big danger in itself, because anybody who can listen on such strictly local communication `localhost` to `localhost` already sits inside your computer, in which case you have probably lost anyway, with the trojan listening to the traffic between MMS and PyBitmessage being the least of your worries.
|
||||
|
||||
But because of this it's not a good idea to set up a PyBitmessage instance reachable over the Internet, as some kind of "public node".
|
||||
|
||||
There is a second problem: The PyBitmessage API is only secured by a username and a password that has to be transmitted in cleartext with every HTTP request. It would be not very hard for an attacker to pick up username and password and starting DOS-type attacks, e.g. by deleting all messages in 10-second intervals.
|
||||
|
||||
(In PyBitmessage's defense one must say that is was **not** designed as a server that can face the big wide bad Internet, but as a program to run locally; it's hardly surprising that running it outside its intended use case leads to problems.)
|
||||
|
||||
### Impersonation
|
||||
|
||||
If Alice the buyer and Bob the seller use 2/3 multisig for *escrow* there will be Trent as a trusted third person that can arbitrate in case of problems and either help Alice get her money back if Bob does not deliver by signing a transaction started by Alice, or helping Bob getting his money if Alice likely got her wares but pretends otherwise and refuses to sign the payment to Bob.
|
||||
|
||||
In this *escrow* situation you really want **three** distinct persons in play. If Bob somehow can *impersonate* Trent by posing as him, by pretending to Alice to be two persons Bob plus Trent, and set up **two** different wallets with two sets of keys, Bob will be able to make those 2/3 multisig transactions valid all on his own and cheat.
|
||||
|
||||
How big this danger of impersonation is depends on how secure the initial exchange of key sets is at the very beginning of the whole process, when configuring the wallets and finally "going multisig": If you can assure that only the right people get the right key sets, and nobody can pose somehow as somebody else, everything is alright. If not, you may loose.
|
||||
|
||||
If you use the full capabilities of the MMS you don't use it only to transact, but already before that, to exchange key sets between all signers. Especially for higher forms of multisig like 2/4 with multiple key exchange rounds this is very helpful and less error-prone than some manual process. So, the task to prevent impersonation shifts from securing the exchange of keys to securely setting up signer addresses in the MMS: If Bob can somehow trick Alice into accepting one of **his** Monero and Bitmessage addresses in stead of those of Trent, he has won.
|
||||
|
||||
The three methods of setting up signer addresses that the MMS supports, manually configuring signers, auto-config and the "semi-automatic" sending of completed signer information, all have different risks associated with them regarding impersonation. Check the respective chapters *Manually Configuring Signers*, *Auto-Config* and *Sending Signer Information* for some more info about this.
|
||||
|
||||
Auto-config is by far the easiest to secure: You only have a tiny bit of information, an 11-character auto-config token, to transmit securely to each signer, and if you can do that, you have already won. (The "config manager" is of course assumed as trustworthy here.)
|
||||
|
||||
If this all sounds too complicated and therefore not trustworthy to you, you do have the option to configure wallets and establishing the multisig address leaving the MMS completely out of the picture and only later using it to comfortably send partially signed transactions around and relieve you from the tedious manual syncing of wallets after each transaction.
|
||||
|
||||
### Attacker-Controlled Data
|
||||
|
||||
There are two situations where your MMS-using wallet receives data from another signer where that other signer, if acting in bad faith, could try to deceive you or trick you into doing something harmful:
|
||||
|
||||
Notes as transmitted by the `mms note` command can be used for "social engineering". An attacker could e.g. try to formulate a note that looks like an error message in an attempt to deceive. The technical possibilities here are quite limited however: Notes are strictly textual only, and when displaying them the MMS filters out characters with ASCII codes less than 32 and the two characters "<" and ">" that could be used to build HTML or XML that might get interpreted somehow (very unlikely in the CLI wallet, but somewhat more likely in GUI-based wallets.) There is also a length limit for notes.
|
||||
|
||||
The second way is an attempt to deceive with labels that are sent through `mms send_signer_config`. Bob could label Alice as *trent* and Trent as *alice*, send that signer configuration to Alice and somehow convince her to use that. This is the reason why a message of type `singer config` if sent outside of auto-config with an explicit `mms send_signer_config` is not processed right away, but displayed first together with a confirmation prompt.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Solving Syncing Troubles
|
||||
|
||||
As explained in the chapter *Syncing Wallets* Monero multisig requires the exchange of some data between wallets after sending as well as receiving transactions, called *multisig sync data* in the MMS.
|
||||
|
||||
Sometimes things get out of sync somehow. There are four possible signs that this may have happened:
|
||||
|
||||
* The `balance` command shows a message *Some owned outputs have partial key images - import\_multisig\_info needed* that "refuses go away"
|
||||
* The wallet tells you *That signature was made with stale data* and refuses to process a transaction further
|
||||
* The wallet tells you about missing keys when you try to sign a transaction
|
||||
* The wallet accuses you of a double-spending attempt with you probably trying nothing like that
|
||||
|
||||
In some such cases the MMS fails to become aware of the problem and simply tells you after `mms next` that there is nothing to do instead of starting a sync round.
|
||||
|
||||
Because of this there is a way to **force sync** at basically any time:
|
||||
|
||||
* All signers issue a `mms sync` command instead of simply `mms next` to send sync info to each other
|
||||
* After receiving those messages all signers issue a `mms next sync` command - note the extra argument `sync`
|
||||
|
||||
For syncing to work all information must be from the same "height" i.e. produced with the same number of transfers recorded in the wallets of all signers: If for example one signer somehow does not receive a transaction and sends out sync information in this state, it will be of no value to other signers with complete wallets.
|
||||
|
||||
If the MMS seems to ignore not yet processed sync data messages in state `waiting` most probably it does so because of this reason. When in doubt check the column `Height` in a list of messages that you get with `mms list`.
|
||||
|
||||
Sometimes such not yet processed messages that became unprocessable trip up the `mms next` command. If that happens use `mms delete` to delete any message with a too-low height.
|
||||
|
||||
### Redirecting a Transaction to Another Signer
|
||||
|
||||
If in cases like 2/3 multisig you sent a partially-signed tx to somebody, but later change your mind and want to send it to somebody else, there is a little trick to do so: Locate the message of type `partially signed tx` addressed **to yourself** and issue a `mms send` command for that message. After reception, do `mms next`. You will be given choice again what to do with it.
|
||||
|
||||
Of course you are free to ignore that transaction and start a new one. Just consider that this new transaction might run into a roadblock later on if the first one gets fully signed and submitted to the network **earlier** than this second one.
|
||||
|
||||
### Ignoring Uncooperative Signers when Syncing
|
||||
|
||||
The normal MMS wallet syncing process assumes that all signers are cooperative and send out sync data messages after sending or receiving a transaction. `mms next` will therefore wait until it holds sync data messages (for the same "height") from **all** other signers before usually processing them.
|
||||
|
||||
However, with *M* being smaller than *N* in configurations like 2/3 multisig you can successfully sync with only (number of required signers minus 1) sync messages. `mms next` will tell you when you have reached this lower threshold and give a hint how to override and go ahead early: Use `mms next sync`.
|
||||
|
||||
If later you receive more sync data messages nevertheless just delete them with `mms delete`: They are unneeded, unprocessable for you and worst case will mess up the the next sync round.
|
||||
|
||||
Usually if you initiate sync the MMS will create messages to *all* other signers. If you want to prevent that to make it as hard as possible for other signers to transact further, make sure to set `auto-send` to false, answer "No" when first being asked to send, and manually delete any unwanted messages before sending the rest out with `mms send`.
|
||||
|
||||
### Recovering from Lost or Duplicate Messages
|
||||
|
||||
If you miss a message for any reason, because PyBitmessage failed to deliver it or because you deleted it too early, ask the sender of the message to send it again using the `mms send` command.
|
||||
|
||||
Note that messages sent multiple times do *not* automatically cancel out each other on the receiving end. If you resend e.g. just because somebody is impatient the addressed signer may end up receiving *two* messages of the same type with the same content.
|
||||
|
||||
If later the missing message belatedly shows up, that's not good, but you can solve this easily by using a `mms delete` command and get rid of one of the two copies.
|
||||
|
||||
### Correcting / Updating Signer Information
|
||||
|
||||
You can use the `mms signer` command to change a label `bob` that you don't like anymore:
|
||||
|
||||
mms member 2 bob-the-builder
|
||||
|
||||
With one more argument you can change Bitmessage addresses if needed:
|
||||
|
||||
mms member 2 bob BM-2cSrgmut9AD6bdU8b8GXd36iUYDjCS9xJb
|
||||
|
||||
You can even change Monero addresses in the same way (with the exception of your own of course), but with a limitation, only as long as there are no received messages. As soon as wallets are multisig it does not make sense anymore to change any Monero addresses anymore anyway.
|
||||
|
||||
### Starting from Scratch
|
||||
|
||||
If the state of the MMS for a wallet is messed-up beyond repair and you want to start from scratch, or if you want to stop using the MMS for a particular wallet, locate the wallet files in the file system and just delete the file with the `.mms` extension.
|
||||
|
||||
### MMS / PyBitmessage Interactions
|
||||
|
||||
Here some details about the interaction between the MMS and PyBitmessage to better understand any problems that may occur there:
|
||||
|
||||
The MMS tries to limit the number of messages that pile up in PyBitmessage's store and deletes them. However, for enhanced reliability it does not delete right after receiving already but only after a message changes its state from `waiting` to `processed`, or if you delete it from the message store. Sometimes messages get orphaned and the MMS has no chance to delete; you can safely delete such messages interactively in PyBitmessage itself.
|
||||
|
||||
If you use auto-config new addresses / identities will be created in PyBitmessage automatically for the MMS. It tries to delete those after finishing config, but note that the current version of PyBitmessage continues to display deleted addresses until next program restart: Harmless in principle, but somewhat confusing.
|
||||
|
||||
If such dynamic auto-config addresses don't get deleted at all e.g. because you delete a wallet beforehand unfortunately it seems there is no simple way in the current PyBitmessage version to get rid of them: You will have to manually locate and edit the `keys.dat` file and delete the corresponding lines (while hopefully not damaging anything else in there...)
|
||||
|
||||
Sometimes messages seem to get stuck and not sent out; try to restart PyBitmessage in such cases.
|
||||
|
||||
BIN
_i18n/tr/resources/user-guides/png/create_wallet/1.png
Normal file
BIN
_i18n/tr/resources/user-guides/png/create_wallet/1.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 215 KiB |
BIN
_i18n/tr/resources/user-guides/png/create_wallet/10.png
Normal file
BIN
_i18n/tr/resources/user-guides/png/create_wallet/10.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 102 KiB |
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue