Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • monero-project/monero-site
  • moneromooo-monero/monero-site
  • el00ruobuob/monero-site
  • erciccione/monero-site
  • woodser/monero-site
  • m2049r/monero-site
  • JohnnyMnemonic/monero-site
  • rehrar/monero-site
  • selsta/monero-site
  • mycryptocheckout/monero-site
  • antanst/monero-site
  • leon/monero-site
  • BlackLotus64/monero-site
  • lh1008/monero-site
  • MSavoritias/monero-site
  • Ehhoe/monero-site
  • turossztrapacska/monero-site
  • anonimal/monero-site
  • dsc/monero-site
  • IsthmusCrypto/monero-site
  • rbrunner7/monero-site
  • Degreel/monero-site
  • Kyritheous/monero-site
  • ProkhorZ/monero-site
  • Monero_Helper/monero-site
  • ulineto/monero-site
  • xjmzx/monero-site
  • vp11/monero-site
  • sawinyh/monero-site
  • chadyo/monero-site
  • XMRNoblesse/monero-site
  • bartvk/monero-site
  • dginovker/monero-site
  • rodolfo912/monero-site
  • Mitchellpkt/monero-site
  • Needmoney90/monero-site
  • ndorf/monero-site
  • Cactii1/monero-site
  • xeagu/monero-site
  • ngecoin01/monero-site
  • ninezero-tr.com/monero-site
  • janowitz/monero-site
  • Aurora/monero-site
  • Lafudoci/monero-site
  • hrumag/monero-site
  • xmr-romine/monero-site
  • hooftly/monero-site
  • binaryFate/monero-site
  • LocalCoinIS/monero-site
  • timetherewere/monero-site
  • serhack/monero-site
  • hyc/monero-site
  • jonathancross/monero-site
  • monerobby/monero-site
  • Wegerich/monero-site
  • matilde/monero-site
  • koe/monero-site
  • TheFuzzStone/monero-site
  • lalanza808/monero-site
  • sgp/monero-site
  • Rexi/monero-site
  • Monero-Weblate/monero-site
  • Avis/monero-site
  • emes/monero-site
  • xiphon/monero-site
  • omurad/monero-site
  • MoneroArbo/monero-site
  • dianacraig/monero-site
  • beeroliver/monero-site
  • ngulgowski/monero-site
  • getsmile/monero-site
71 results
Show changes
Showing
with 6679 additions and 78 deletions
{% assign version = '1.1.0' | split: '.' %}
{% include disclaimer.html translated="true" 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.
![image1](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/01.png)
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!
![image2](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/02.png)
Type in your private key in the box below, and click the button.
On the next page, you will see your address.
![image3](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/03.png)
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.
![image5](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/05.png)
![image6](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/06.png)
Paste your address into the field under the Monero logo. Select the "agree to terms" button, then hit "Start"
![image7](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/07.png)
In the new screen that pops up, copy the Deposit Address into your clipboard (select and hit ctrl+c or edit-copy)
![image8](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/08.png)
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.
![image4](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/04.png)
![image9](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/09.png)
You will get a text message verification code. Enter code and hit send.
![image10](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/10.png)
You will see the shapeshift change to "awaiting exchange"
![image11](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/11.png)
Then it will change to COMPLETE!
![image12](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/12.png)
After a while you will see it in your Monero account
![image13](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/13.png)
{% assign version = '1.1.0' | split: '.' %}
{% include disclaimer.html translated="true" version=page.version %}
# Импорт блокчейна в кошелёк Monero GUI (Windows)
### Шаг 1
Скачать последнюю программу самозагрузки по ссылке: https://downloads.getmonero.org/blockchain.raw. Этот шаг можно пропустить, если блокчейн импортируется из другого источника.
......
{% assign version = '1.1.1' | split: '.' %}
{% include disclaimer.html translated="true" version=page.version %}
# Multisig-транзакции с MMS и CLI кошельком
## Вступление
В настоящем руководстве описана *Multisig Messaging System*, сокращённо *MMS*. Система призвана облегчить **проведение multisig-транзакций** Monero и похожих криптовалют, в основе которых лежит протокол CryptoNote, за счёт упрощения обмена между кошельками такой информацией, как наборы данных ключей и данные синхронизации, а также путём обеспечения руководства по последовательности выполняемых операций, которое поможет вам на различных этапах.
Вплоть до этого момента система MMS являлась для пользователя просто набором новых команд для CLI-кошелька. И это не удивительно, так как сейчас в любом случае CLI-кошелёк является единственным средством интерактивного проведения multisig-транзакций. К счастью, в будущем это изменится в лучшую сторону, так как система MMS была разработана с учётом возможности использования и с другими кошельками, например, с GUI-кошельком Monero.
Данное руководство содержит некоторые обучающие аспекты, поэтому его следует читать последовательно, не пропуская никаких глав вплоть до главы *«Подробное описание команд»*.
Если вы предъявляете высокие требования к безопасности и не уверены в том, приемлема ли для вас будет система MMS, то сначала вы можете прочитать главу *«Безопасность»*.
Первая версия руководства была завершена к концу 2018 года Рене Бруннером (René Brunner), *rbrunner7*, являющимся оригинальным автором MMS.
## В двух словах о Monero Multisig
Возможно, будет довольно непросто понять MMS, не рассмотрев базовые принципы работы multisig-транзакций Monero. Поэтому мы предлагаем ознакомиться с коротким обзором и *терминологией*, которая используется в руководстве. Более подробную информацию и *технические* подробности придётся поискать в других источниках.
*Multisig* означает, что для того, чтобы транзакция попала в сеть Monero и была реализована, требуется множество подписей. В данном случае транзакции создаются, подписываются и передаются в сеть не одним кошельком Monero, а целой группой кошельков, которым приходится взаимодействовать для проведения транзакции.
В данном руководстве кошельки или, если хотите, люди, контролирующие их, называются *правомочными подписантами*. В зависимости от типа используемой multisig, чтобы транзакция стала действительной, требуется подпись не **всех** правомочных подписантов, а только некоторых из них. Соответствующее количество (которое равно или меньше количества правомочных подписантов) называется необходимым *количеством подписантов*.
В данном документе, как правило, используется обозначение *M/N*, где *M* обозначает необходимое количество подписантов, а *N* обозначает общее количество правомочных подписантов. Например, возможно, наиболее полезный и самый популярный тип multisig записывается как *2/3*: то есть, чтобы транзакция стала действительной, из **трёх** правомочных подписантов требуется подпись **двоих**.
В случае с технически «простыми» монетами, такими как Bitcoin и его форки, проведение multisig-транзакции включает в себя следующие этапы:
* конфигурирование multisig-кошельков и создание multisig-адреса;
* внесение средств на multisig-кошельки / multisig-адрес, чтобы было, что тратить;
* проведение такого количества multisig-транзакций, которое пожелаете.
В случае с Monero добавляется ещё один этап, необходимый, скажем так, для внутренней бухгалтерии. Если объяснять всё простыми словами, то все механизмы, обеспечивающие настоящую анонимность транзакций Monero, усложняют процесс, и кошелькам приходится обмениваться информацией, чтобы правильно обработать транзакции как входящие, так и исходящие.
Система MMS использует термин *синхронизация*, чтобы обозначить процесс, при помощи которого кошельки будут вновь готовы провести транзакцию после отправки или получения транзакции, а термин *данные multisig-синхронизации* или просто *данные синхронизации* используется для обозначения информации, обмен которой должен произойти для достижения этой цели.
Поэтому этапы проведения multisig-транзакции в случае с Monero выглядят следующим образом:
* конфигурирование multisig-кошельков и создание multisig-адреса;
* внесение средств на multisig-кошельки / multisig-адрес, чтобы было, что тратить;
* первая синхронизация кошельков;
* проведение 1 multisig-транзакции;
* повторная синхронизация кошельков;
* проведение ещё одной multisig-транзакции и/или получение дополнительных средств;
* очередная синхронизация кошельков;
* ...
«Ценность» системы MMS в том, что она упрощает и делает «безболезненным» процесс обмена всеми этими пакетами данных между кошельками, а также в том, что подписанты знают, на каком этапе «последовательности операций» они находятся в данный момент, и какое действие необходимо выполнить, чтобы продолжить.
## Архитектура MMS
В основном MMS состоит из 3 частей:
* набора новых команд CLI-кошелька;
* использования копии PyBitmessage, с которой можно связаться с компьютера с установленным CLI-кошельком, что позволяет передавать сообщения от имени кошелька;
* внутренних расширений кода для кошелька с новым файлом `.mms` на кошелёк с сообщениями в нём и связью с PyBitmessage.
В настоящее время [PyBitmessage](https://bitmessage.org/wiki/Main_Page) является единственной поддерживаемой программой для передачи сообщений. MMS не станет «говорить» ни с какой другой системой. Вы не можете использовать ни электронную почту, ни какую-либо другую программу обмена сообщениями из мириад существующих. Если вам не нравится PyBitmessage, или вы по какой-то причине не можете запустить её, то вы не сможете пользоваться текущей версией MMS.
Автор MMS надеется, что вы всё-таки попытаетесь использовать эту программу: PyBitmessage - это полностью открытое программное обеспечение, постоянно развивающееся, и у него достаточно пользователей, чтобы гарантировать передачу сообщений в любое время. К тому же, его разработчики очень серьёзно относятся к вопросам анонимности, точно так же, как в случае с Monero.
Надеемся, что будущие версии MMS будут основаны на «родной» системе анонимного обмена данными Monero, [Kovri](https://kovri.io/), но мы пока далеки от широкой реализации и использования Kovri.
Связь MMS должна быть **безопасной**: система The Bitmessage считается безопасной, так как отправитель и получатель сообщения остаются совершенно невидимыми, а весь трафик зашифрован. С целью повышения безопасности MMS также шифрует и любое содержание сообщения: никто, кроме получателя сообщения MMS, не сможет расшифровать и использовать его содержимое, а сообщения подписываются, поэтому получатель может быть уверен в том, что сообщение пришло от правильного отправителя.
## Опыт использования MMS
Чтобы ознакомиться с «опытом использования» multisig с CLI-кошельком **без** MMS можно, например, перейти по этой [ссылке](https://taiga.getmonero.org/project/rbrunner7-really-simple-multisig-transactions/wiki/22-multisig-in-cli-wallet) и по этой [ссылке](https://taiga.getmonero.org/project/rbrunner7-really-simple-multisig-transactions/wiki/23-multisig-in-cli-wallet).
На этих страницах содержится полезная информация, которая позволит вам ознакомиться с этапами проведения multisig-транзакций в целом, так как система MMS не меняет порядка следования этапов (шагов), не делает их избыточными, но просто значительно упрощает процесс проведения транзакций, а также в большинстве случаев автоматически указывает на следующий этап.
### Система передачи сообщений
Общий принцип работы MMS довольно **схож с электронной почтой**: вы обмениваетесь сообщениями, а набор команд MMS в вашем CLI-кошельке играет роль почтового клиента, позволяя вам отправлять сообщения, получать сообщения и управлять списком полученных сообщений, что-то вроде комбинированной папки входящих и исходящих сообщений.
Содержанием этих сообщений, безусловно, является информация, которой необходимо обмениваться кошелькам подписантов: это наборы ключей, данные синхронизации кошельков, транзакции, которые необходимо подписать и/или передать в сеть.
PyBitmessage используется для фактической передачи сообщений и поэтому играет роль вашего почтового сервера. Как только будет выполнено конфигурирование, отправка и получение сообщений станет полностью автоматическим, то есть не будет требовать ручного вмешательства.
Для указания адреса назначения сообщений используются не адреса электронной почты, а адреса Monero, и сообщения всегда отправляются только правомочным подписантам. Например, при использовании с схемы multisig 2/3 данные отправляются только 2 партнёрам.
Как и в случае с электронной почтой людям не приходится находиться онлайн, чтобы сообщение было передано. PyBitmessage сохраняет сообщения до 2 дней, чтобы вы могли доставить их.
В целом такой подход довольно гибок и устойчив к ошибкам: если вам необходимы сообщения от нескольких подписантов, MMS подождёт до тех пор, пока не найдёт всех их в списке полученных сообщений, а порядок получения не имеет значения, что облегчает весь процесс использования.
Если подписант скажет вам, что какое-то определённое сообщение не было получено или было потеряно, вы сможете в любое время отправить его повторно, взяв из списка сообщений, как если бы вы переслали электронное сообщение почтой в подобной ситуации.
### Подписанты и сообщения
Итак, в случае, когда «нормальный» кошелёк Monero без MMS просто управляет тремя типами данных (адресами, счетами и транзакциями), MMS добавляет ещё пару: подписантов и сообщения.
MMS управляет (отдельно для каждого multisig-кошелька) списком *правомочных подписантов*. В случае со схемой multisig 2/3 в списке имеется **три** записи. На техническом уровне каждая запись представляет кошелёк Monero с ключами, которые могут использоваться для подписания multisig-транзакций. На концептуальном уровне проще представить группу из 3 человек, то есть вас самих и двух партнёров в качестве «правомочных подписантов» (часто это будут 3 конкретных человека, контролирующих три кошелька, но так будет не всегда, безусловно).
Система MMS также управляет одним списком *сообщений* на кошелёк: всеми сообщениями, которые вы отправляете, плюс всеми сообщениями, которые вы получаете. Несмотря на то, что список правомочных подписантов будет одним и тем же для всех кошельков-участников, сообщения, конечно же, будут отличаться. Чем больше правомочных подписантов будут отправлять вам сообщения, и чем дольше вы будете проводить транзакции, тем больше сообщений накопится.
## Где взять MMS
Сейчас, на момент написания этого руководства (конец 2018 года), MMS доступна только как часть последней версии кода Monero (`главной` ветки [GitHub репозитория Monero](https://github.com/monero-project/monero)). Чтобы использовать эту систему, необходимо найти исходный код и самостоятельно скомпилировать его. Проще это сделать под операционной системой Linux.
При реализации следующего хардфорка весной 2019 MS станет неотъемлемой стандартной частью программного обеспечения Monero, то есть, как только вы установите Monero, вы получите и систему MMS.
Внимание! На момент написания руководства использование последней версии Monero не приводило к каким-либо конфликтам и осложнениям с регулярно обновляемым программным обеспечением Monero и при загрузке блокчейна на ту же систему, но это может измениться до реализации хардфорка, особенно вероятно, непосредственно перед хардфорком.
## Установка и конфигурирование PyBitmessage
Установить PyBitmessage довольно просто. Необходимо найти ссылки на загрузку и установить инструкции с домашней страницы [Bitmessage Wiki](https://bitmessage.org/wiki/Main_Page). Доступны версии для всех поддерживаемых Monero операционных систем: Linux, Windows и macOS.
После установки необходимо запустить программу, конфигурировать адрес Bitmessage под себя и записать его, так как позже он понадобится для конфигурирования вашего multisig-кошелька.
Не стоит беспокоиться, если покажется, что PyBitmessage не соединяется с сетью Bitmessage, когда вы запустите программу в первый раз: из-за децентрализованной природы сети первое соединение может потребовать некоторого времени. Зачастую это занимает **полчаса**.
Подобным образом, отправка первого сообщения на абсолютно новый адрес Bitmessage также может занять некоторое время, поскольку при этом происходит обмен ключами, и иногда это занимает ещё полчаса. Как только произойдёт обмен ключами, на отправку сообщений будет уходить несколько минут, а иногда и секунды.
Для себя достаточно конфигурировать один адрес Bitmessage. По одному адресу без каких-либо проблем можно запускать **несколько** multisig-кошельков, так как система MMS способна выбирать правильные сообщения для правильных кошельков. Тот же самый адрес можно использовать и для «нормальных» сообщений. Они не будут препятствовать работе MMS, система просто будет игнорировать любые сообщения, не предназначенные для неё.
Только что установленная PyBitmessage не будет готова для использования с MMS, так как не позволяет другим программам использовать свой API по умолчанию, это необходимо сделать самостоятельно (что имеет смысл с точки зрения безопасности).
Инструкции, **как подключить API**, можно найти на странице [Bitmessage wiki API](https://bitmessage.org/wiki/API_Reference). Понадобятся имя пользователя и пароль, которые будут выбраны нами позже в качестве параметров командной строки CLI-кошелька. Это необходимо, чтобы MMS получила доступ к PyBitmessage.
## Дальнейшая настройка PyBitmessage
Текущая официальная версия 0.6.3.2 имеет встроенное [расширение протокола Dandelion++](https://arxiv.org/abs/1805.11060), которое усиливает защиту сети от атак, направленных на отслеживание потока сообщений с целью определения, кто и кому отправляет эти сообщения. К сожалению, кажется, до сих пор где-то есть баг, в результате которого время передачи сообщений крайне различно и продолжительно, что довольно неудобно при использовании MMS.
Есть способ отключить Dandelion++, что, в принципе, не рекомендуется делать, но что будет полезно с точки зрения применения системы MMS:
* найти файл конфигурации PyBitmessage `keys.dat`
* создать новый раздел `[network]`
* добавить в новый раздел следующую строку: `dandelion = 0`
* перезапустить PyBitmessage.
Будучи «лояльным гражданином», вы можете открыть доступ к своему узлу на ПК для других узлов Bitmessage. Для этого необходимо открыть порт 8444. Всю необходимую информацию можно найти в соответствующем разделе [FAQ](https://bitmessage.org/wiki/FAQ). Тем не менее в этом нет острой необходимости с точки зрения функционирования вашего клиента.
## Обзор команд MMS
В CLI-кошельке есть только **одна** новая команда, которая обеспечивает доступ к MMS, которая благоразумно была названа `mms`. Тем не менее у этой команды есть ряд подкоманд, позволяющих использовать все функции системы MMS. Ниже приводится список команд. Подробное описание каждой команды содержится далее в руководстве.
init Запуск и конфигурирование MMS
info Отображение текущей конфигурации MMS
signer Определение подписанта ярлыком из одного слова, адресом передачи и адресом Monero или списком всех определённых подписантов
list Список всех сообщений
next Оценка следующего возможного связанного с multisig действия (действий), выполнение или предложение выбора
sync Запуск генерирования данных multisig-синхронизации независимо от состояния кошелька с целью восстановления после различных ситуаций, например, после ошибки «устаревания данных»
transfer Запуск передачи с поддержкой системы MMS, аргументы идентичны аргументам команд нормальной «передачи», дополнительную информацию можно найти здесь
delete Удаление одного сообщения с указанием его идентификатора (id) или всех сообщений с указанием all
send Отправка одного сообщения с указанием его идентификатора (id) или всех ожидающих отправки сообщений
receive Быстрая проверка наличия сообщений для получения
note Отправка сообщения одной строкой подписанту, идентифицированному ярлыком, или же просмотр всех непрочитанных примечаний
show Просмотр подробной информации по одному сообщению
export Экспорт содержания сообщения в файл
set Установка опций. Пока имеется только опция автоматической отправки auto-send
start_auto_config Запуск процесса автоконфигурирования в кошельке менеджера автоконфигурирования путём создания новых токенов
auto_config Запуск процесса автоконфигурирования с использованием токена, полученного от менеджера автоконфигурирования
stop_auto_config Удаление любых токенов и прерывание процесса автоконфигурирования
send_signer_config Отправление вашей полной конфигурации подписанта всем другим подписантам
Список команд можно просмотреть путём ввода `help mms`, а помощь по определённой подкоманде можно получить, используя `help mms <subcommand>`, например, `help mms next`. Как вариант, можно использовать подкоманду `mms help <subcommand>`, если вам кажется это более естественным.
## Конфигурирование кошелька для использования с MMS
### Адреса и ярлыки
Во-первых, для лучшего понимания необходимо узнать несколько базовых фактов об адресах и обращении к подписантам (или их кошелькам, соответственно) в системе MMS.
Если вы создаёте новый кошелёк, он получает (безусловно) свой собственный уникальный публичный адрес Monero. Если позже вы будете конфигурировать кошелёк для multisig, кошелёк **изменит** свой публичный адрес на общий multisig-адрес, которым вы поделитесь со всеми остальными правомочными подписантами.
Система MMS использует первый «оригинальный» публичный адрес Monero в течение всего времени существования кошелька для адресации до **и** после «перехода на multisig». Наличие **двух** публичных адресов у кошелька может в некотором смысле запутать, но как только в вашей конфигурации подписанта появится оригинальный адрес, вы сможете забыть об этом в той или иной мере.
MMS использует ярлыки, которые позволяют наименовать себя и других подписантов, которые пользуются командами MMS при обращении к подписантам. (Использование адресов Monero или адресов Bitmessage выглядело бы несколько громоздко).
*Ярлыки* должны состоять из одного слова и они должны быть уникальными для каждого отдельно взятого кошелька. Далее в руководстве в качестве примера для схемы 2/2 multisig используются ярлыки `alice` и `bob`.
### Запуск CLI-кошелька
Когда вы запускаете CLI-кошелёк для использования с системой MMS, появляются два новых (опциональных) параметра командной строки, позволяющие соединиться с PyBitmessage:
--bitmessage-address Используется PyBitmessage для URL <arg>
--bitmessage-login Указывает <arg> как имя пользователя / пароль для PyBitmessage API
Если PyBitmessage запущен на той же машине, что и CLI-кошелёк, значение первого параметра, используемое по умолчанию, вполне подойдёт, и вам не придётся задавать что-либо иное. Если же всё будет не так, несмотря на то, что программа будет запущена локально, попробуйте использовать http://localhost или http://127.0.0.1 в качестве аргумента для первого параметра.
Помимо этого, вам понадобится либо `--testnet`, либо `--stagenet`, чтобы соединиться с правильной сетью. Также может помочь использование `--log-level 0`. Это будет инструкцией для кошелька записать подробную информацию в файл журнала, что поможет выявить баги или другие проблемы с MMS.
Таким образом, полная командная строка для CLI-кошелька может выглядеть так:
./monero-wallet-cli --testnet --bitmessage-login mmstest:p4ssw0rd --log-level 0
### Запуск MMS
После создания нового кошелька необходимо запустить его для использования с MMS. Без этого критически важного первого этапа вы не сможете использовать какую-либо из функций MMS. В данном случае следует использовать команду `mms init`:
mms init <required_signers>/<authorized_signers> <own_label> <own_transport_address>
`own_transport_address` является адресом Bitmessage, который вы сконфигурировали в вашей программе PyBitmessage. Полная команда `init` выглядит следующим образом:
mms init 2/2 alice BM-2cUVEbbb3H6ojddYQziK3RafJ5GPcFQv7e
Эту команду `init` следует использовать лишь **единожды**: повторное использование команды полностью перезапустит MMS, удалив любую информацию о подписантах и любые сообщения, в чём нет необходимости за исключением определённых обстоятельств.
Если вы хотите пройти тест MMS как можно быстрее, вы можете проинструктировать кошелёк, чтобы он запрашивал пароль только в случае острой необходимости по техническим причинам, а также проинструктировать систему MMS, чтобы она сразу отправляла сообщения, а не сообщала перед этим о такой отправке:
set ask-password 0
mms set auto-send 1
(Обе эти настройки активны в случае с примером 2/2 multisig, который мы используем в настоящем руководстве).
### Конфигурирование подписантов
О каждом подписанте система MMS должна знать следующие три вещи:
* *ярлык*, состоящий из одного слова, который будет использоваться для обращения к определённому подписанту;
* *транспортный адрес*, который в настоящее время обозначает адрес Bitmessage, так как сейчас это единственная поддерживаемая система передачи сообщения;
* *адрес Monero*, то есть «оригинальный» адрес Monero их кошелька.
(Также см. главу *«Адреса и ярлыки»* выше)
Вам не нужно создавать подписантов. После команды `mms init` они уже все «будут там», даже несмотря на отсутствие какой-либо информации, за исключением информации о вас самих. Команды для получения информации подписантов соотносятся с ними по номеру: от 1 до общего количества правомочных подписантов, 1 и 2 в случае с примером 2/2 multisig, где подписантов зовут *Элис* и *Боб*, и у которых имеются соответствующие ярлыки *alice* и *bob*.
После ввода приведённого выше примера команды `init` список подписантов будет выглядеть следующим образом:
# Label Transport Address
Auto-Config Token Monero Address
1 alice BM-2cUVEbbb3H6ojddYQziK3RafJ5GPcFQv7e
A1VRwm8HT8CgA5bSULDZKggR9Enc9enhWHNJuDXDK4wDD6Rwha3W7UG5Wu3YGwARTXdPw1AvFSzoNPBdiKfpEYEQP1b5cCH
2 <not set> <not set>
<not set>
Следует отметить, что подписант #1 всегда будет «мной», то есть вашим собственным ярлыком, будет иметь транспортный адрес и адрес Monero. Таким образом, в списке подписантов Элис подписантом #1 будет Элис, а #2 Боб, в то время как в случае с кошельком Боба ситуация будет обратной.
Всегда есть **три способа** заполнения информации о подписантах. Вы можете сделать это вручную либо можете использовать механизм автоматического конфигурирования, предлагаемый системой MMS, который также обеспечивает второй «полуавтоматический» вариант. При использовании схемы 2/2 едва ли будет какая-либо разница, но чем больше будет количество подписантов, тем проще и надежнее будет использовать автоматическое конфигурирование. В любом случае одним из преимуществ автоматического конфигурирования является безопасная передача адресов, так как используется PyBitmessage.
Так что вы можете выбрать **один** из трёх методов, ознакомившись с тремя главами *«Ручное конфигурирование подписантов»*, *«Автоматическое конфигурирование»* и *«Отправка информации подписантов»*.
### Ручное конфигурирование подписантов
Командой для ручного ввода информации подписанта и отображения списка подписантов является `mms signer`:
mms signer [<number> <label> [<transport_address> [<monero_address>]]]
При отсутствии какого-либо аргумента команда используется для отображения списка подписантов. При наличии, по крайней мере, номера и ярлыка можно задать или изменить информацию определённого подписанта. Полная команда, чтобы задать информацию подписанта #2, будет выглядеть подобным образом:
mms signer 2 bob BM-2cStcTfCx8D3McrMcmGZYZcF4csKcQT2pa 9yXKZ6UUdd8NnNN5UyK34oXV7zp7gjgZ4WTKHk8KzWsAAuyksfqoeRMLLkdWur85vnc1YL5E2rrMdPMHunA8WzUS9EL3Uoj
Команда, чтобы позднее изменить только ярлык подписанта #2, может быть следующей:
mms signer 2 bob-the-builder
При использовании ручного метода сами подписанты должны озаботиться тем, *как* они узнают адреса друг друга.
Следует быть очень внимательным при вводе информации подписанта. Любые ошибки, например, неверные адреса Bitmessage, впоследствии могут стать причиной неверного проведения транзакции.
Перед тем как вы начнёте обмен информацией подписантов по небезопасным каналам, таким как IRC или обычная незашифрованная электронная почта, следует отметить, что с этим связаны определённые опасности. Если кто-то может, например, перехватить вашу электронную почту и заполучить адреса, которые вы отправили подписанту, то этот кто-то может выяснить личность подписанта.
Также существует опасность, что при реализации сценария 2/3 multisig для *условного депонирования* денежной суммы у третьего лица подписант Боб, помимо своего кошелька, может создать второй кошелёк для доверенной третьей стороны Трента и обмануть Элис таким образом, что она отправит всё на тот кошелёк вместо кошелька Трента. После этого Боб сможет проводить транзакции самостоятельно и красть монеты у Элис.
Более подробное описание второго варианта опасности приводится в главе *«Безопасность»* ближе к концу руководства. Также его можно найти [здесь](https://taiga.getmonero.org/project/rbrunner7-really-simple-multisig-transactions/wiki/multisig-and-insecure-communication-channels). Автоматическое конфигурирование в некоторой мере позволяет избежать этой опасности.
Полный список подписантов Элис выглядит примерно так:
# Label Transport Address
Auto-Config Token Monero Address
1 alice BM-2cUVEbbb3H6ojddYQziK3RafJ5GPcFQv7e
A1VRwm8HT8CgA5bSULDZKggR9Enc9enhWHNJuDXDK4wDD6Rwha3W7UG5Wu3YGwARTXdPw1AvFSzoNPBdiKfpEYEQP1b5cCH
2 bob BM-2cStcTfCx8D3McrMcmGZYZcF4csKcQT2pa
9yXKZ6UUdd8NnNN5UyK34oXV7zp7gjgZ4WTKHk8KzWsAAuyksfqoeRMLLkdWur85vnc1YL5E2rrMdPMHunA8WzUS9EL3Uoj
### Автоконфигурирование
Процесс автоматического конфигурирования MMS основан на использовании так называемых *токенов автоконфигурирования*. Длина таких токенов всегда составляет 11 символов. Это фиксированная строка mms, за которой следуют 8 шестнадцатеричных цифр. Примером таких токенов являются `mms561832e3eb` и `mms62cb2b87e2`.
В чём тут основная хитрость: в отличие от адресов Bitmessage и адресов Monero эти токены достаточно коротки для того, чтобы их было удобно набирать и, например, использовать с разумно безопасными мессенджерами для смартфонов, передавать их в SMS-сообщениях или же диктовать их по телефону, что, опять же, не совсем безопасно, но всё же гораздо безопаснее, чем пересылать такие токены по электронной почте или IRC.
Порядок операций будет следующим — он гораздо проще, чем может показаться на первый взгляд, достаточно попробовать его один раз на практике, и всё станет понятно:
* один подписант организует и реализует конфигурирование, и называется *менеджером*;
* менеджер назначает ярлыки каждому подписанту и вводит все ярлыки в конфигурацию подписанта, либо используя команды `mms signer`, либо присваивая им аргументы команды `mms start_auto_config` на следующем этапе;
* менеджер использует команду mms `start_auto_config`, чтобы сгенерировать токены автоконфигурирования для всех других подписантов по одному индивидуальному токену для каждого подписанта;
* менеджер передаёт токены соответствующим подписантам за пределами MMS;
* все остальные подписанты вводят свои токены, используя `mms auto_config <token>`;
* их кошельки должны сгенерировать сообщения, с которыми их адреса будут переданы на кошелёк менеджера, уже при помощи PyBitmessage;
* как только все сообщения будут получены, менеджер сможет в свою очередь, используя `mms next`, отправить сообщения всем остальным подписантам; в этих сообщениях будет содержаться полная информация подписантов;
* другие подписанты обработают эти сообщения, чтобы дополнить свою информацию подписантов, используя `mms next`.
В данном случае следует отметить следующее. В случае с ручным конфигурированием, например, при наличии 5 подписантов, это составило бы 5 раз по 4 (всего 20) изначальной ручной передачи информации, если каждый из 5 подписантов отправит адреса 4 другим. Даже при использовании более продуманного подхода, когда сначала кто-то один собирает все адреса и отправляет полный список всем остальным, это заняло бы 4 + 4 (всего 8) передач информации. Процесс автоматического конфигурирования предусматривает только **4** таких ручные передачи: 4 токена передаются менеджером другим подписантам. После этого сообщения уже передаются через PyBitmessage.
Вы можете спросить, как кошельки других подписантов смогут отправить свои адреса Bitmessage обратно менеджеру, используя PyBitmessage. Не тот ли это случай, когда змея кусает себя за хвост? Решение: временный, «выбрасываемый» адрес Bitmessage выводится на основе каждого токена и используется только для такой передачи, а временные ключи выводятся также для шифрования содержания сообщения.
Что касается более высокого уровня безопасности процесса автоконфигурирования, то он заключается в том, что каждый подписант получает свой собственный, индивидуальный токен. В случае со схемой 2/3 multisig просто следует убедиться в том, что Боб не сможет завладеть токеном Трента, и тогда у Боба не будет возможности «притворяться» Трентом и настраивать кошелёк таким образом, чтобы подписывать транзакции от его имени.
### Отправка конфигурации подписантов
Помимо возможности полного автоконфигурирования существует второй способ упростить процесс конфигурирования, основанный на использовании команды `send_signer_config`. Это менее «автоматизированный» способ, но он может понравиться вам больше, поскольку в этом случае всё происходит более прозрачно.
Вот как он работает:
* один подписант организует и реализует конфигурирование, и называется *менеджером*;
* менеджер получает от всех остальных подписантов их адреса по каналам за пределами MMS, например, зашифрованным и подписанным сообщением по электронной почте;
* менеджер вводит полную информацию о подписантах в их кошельки, используя команды `mms member`;
* менеджер использует команду `mms send_signer_config`, чтобы отправить полную информацию всем остальным подписантам;
* другие подписанты обработают сообщения, содержащие информацию подписантов, используя `mms next`.
Для всех подписантов, за исключением менеджера, этот способ практически так же удобен, как и автоконфигурирование. Тем не менее следует отметить, что безопасность схемы зависит от обеспечения безопасности отправки информации менеджеру. То есть, если кто-то из подписантов может выступать не только от своего имени, но также и от имени других подписантов, то такой подписант сможет контролировать несколько кошельков, подрывая тем самым весь процесс подписания. (Подробнее риски, связанные с таким сценарием, описаны в главе *«Ручное конфигурирование подписантов»*)
## Создание multisig-адреса
В целом команды MMS для реализации определённых этапов multisig-транзакций отсутствуют (за исключением запуска передачи при помощи `mms transfer` и синхронизации при помощи `mms sync`). Используется только команда `mms next`, после чего MMS выполняет любое последующее действие в рамках «последовательности операций multisig». А если необходимые для этого условия не будут соблюдены, например, будут отсутствовать некоторые сообщения, MMS сообщит причину, по которой пока невозможно перейти к следующему действию.
Таким образом, после того как информация подписантов будет внесена вручную или с использованием процесса автоконфигурирования, нужно будет просто ввести команду `mms next`, и MMS перейдёт к первому шагу, необходимому для создания multisig-адреса, вычислению набора ключей для всех членов объединения и созданию сообщений для отправки вычисленных *наборов ключей* таким членам. Для Элис всё будет выглядеть примерно следующим образом:
[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.
В выходе `prepare_multisig` имеется подсказка, что MMS некоторым образом «оборачивает» команду `pepare_multisig` CLI-кошелька и даже отображает строку `MultisigV1` для подтверждения. Теперь необходимость в какой-либо отправке другому подписанту отсутствует, так как для этого MMS сама подготавливает сообщение и отправляет его в автоматическом режиме.
После того как Элис получит набор ключей Боба, он будет обработан при помощи команды `mms next`, после чего будет создан multisig-адрес:
[wallet A1VRwm]: mms next
make_multisig
Wallet password:
2/2 multisig address: 9uWY5Kq6XocGGqUByp22ty4HYxj4CfjCXdRrZ24EKvYW2U7fudSzCvTRRT35tMNx5heQfqKmVmFjahWUZ1BENnzH8UvyVF7
После этого кошелёк может «выйти из синхронизации». Если случится именно так, необходимо произвести быстрое обновление, используя `refresh`.
В случае несимметричной схемы M/N multisig, где M будет отличаться от N, как, например, в случае со схемой 2/3, недостаточно, чтобы каждый подписант просто отправлял один набор ключей каждому из подписантов. Необходимо несколько *раундов* обмена наборами ключей. Тем не менее MMS известно это, и система автоматически заботится обо всём: для определённого кошелька, перед тем как продолжить, она ожидает получения наборов ключей всех остальных подписантов. В случае необходимости в ещё одном раунде обмена ключами, он запускается командой `mms next`. Если же такой раунд не нужен, команда запустит обработку последнего набора (наборов) ключей и создаст multisig-адрес.
Возможно, будущая улучшенная версия MMS будет делать это полностью автоматически, то есть будет отправлять все необходимые наборы ключей без дальнейшего вмешательства вплоть до момента, когда будет сконфигурирован multisig-адрес. Однако на данный момент всё приходится делать самостоятельно путём ввода команд `mms next`.
## Получение средств на multisig-кошелёк
После создания multisig-адреса кошелёк будет готов к приёму средств. В данном случае система MMS не играет никакой роли, впрочем, как и multisig в целом. Необходимо просто перевести несколько монет на адрес, чтобы было что переводить в дальнейшем, и подождать, пока они не придут.
## Синхронизация кошельков
Всякий раз после получения или отправки монет multisig-кошелькам необходимо обменяться некоторой информацией друг с другом, чтобы снова «синхронизироваться». Это тот самый случай, когда CLI-кошелёк напомнит вам о *частичных образах ключей*, как в этом примере с выводом команды `balance`:
[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)
Вот эта часть "import_multisig_info needed", пожалуй, является единственным и самым утомительным аспектом multisig-транзакций CryptoNote, требующим некоторой работы, например, в случае использования схемы multisig 3/3 или 2/3, где в совокупности каждый раз требуется передавать **шесть** порций информации, только чтобы завершить получение нескольких монет и/или передать их снова после передачи.
По крайней мере, в случае использования MMS, это всего лишь вопрос выдачи команд `mms next` до тех пор, пока все данные синхронизации не будут отправлены и получены, а также пока все кошельки снова не синхронизируются. Это автоматически приводит нас к необходимости использования команд `export_multisig_info` и `import_multisig_info`. И вновь, как это будет выглядеть для Элис:
[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
Не стоит беспокоиться, если вы получите такие сообщения синхронизации от других подписантов до того, как сможете отправить свои. Система MMS прекрасно справится с такой ситуацией и сначала отправит сообщения, а потом приступит к обработке.
На случай, если у вас возникнут проблемы, ознакомьтесь с главой *«Устранение ошибок»*. Например, есть способ запустить синхронизацию, даже если `mms next` ошибочно решит, что в синхронизации не необходимости или же, что синхронизация невозможна.
## Совершение multisig-транзакций
Для запуска multisig-транзакции вместо обычной команды `transfer` используется команда `mms transfer`. Вариант MS поддерживает все варианты параметров обычной команды, поэтому, если вам необходима помощь, вы можете использовать `help transfer`.
Системе MMS не важны подадреса и учётные записи. Какой бы адрес вы не использовали для отправки (и получения) при проведении транзакций, MMS будут важны только данные, создаваемые при определённом событии, о времени, когда данные должны быть обработаны, и о правильном получателе (получателях).
Если вы не хотите, чтобы данные вашей транзакции стали частью файла `.mms` в форме содержания сохранённого сообщения, вы можете использовать обычную команду `transfer`. Однако в этом случае вся ответственность за отправку частично подписанной транзакции следующему подписанту будет целиком на вас.
При использовании multisig команда `mms transfer`, конечно же, ещё не инициирует передачу, но вместо этого создаёт частично подписанную транзакцию. Это немного растягивает концепцию сообщений, поскольку команда `mms transfer` создаёт сообщение «мне», то есть владельцу самого кошелька, содержанием которого является частично подписанная транзакция. Ниже показано сообщение #7 для Элис:
[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
За этим стоит следующая идея. В таком состоянии (ожидания транзакции) и в зависимости от количества необходимых подписантов ввод команды `mms next` вызовет вопрос, что делать с ней, особенно в случае со схемой multisig 2/3, когда центральный должен быть способен принять решение, **куда** отправить транзакции для получения второй подписи, которая сделает её действительной, то есть кому из **двух** возможных подписантов.
В случае со схемой multisig 2/4 это может выглядеть следующим образом:
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
Однако в случае с примером схемы multisig 2/2, который приводится в данном руководстве, выбор отсутствует. Транзакция, инициированная Элис, должна быть передана Бобу как единственному правомочному и требуемому подписанту:
[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.
После получения Боб подписывает транзакцию, используя не какую-то специальную команду подписи, а используя простую команду `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
А ещё одна команда `mms next` может повлиять на выбор Боба, поскольку он может передать транзакцию в сеть либо самостоятельно, **либо** для этого отправить её обратно Элис:
[wallet 9uWY5K]: mms next
Choose processing:
1: Submit tx
2: Send the tx for submission to alice: BM-2cUVEbbb3H6ojddYQziK3RafJ5GPcFQv7e
Choice:
Как уже упоминалось, после того как транзакция будет передана в сеть и обработана, перед тем как вы сможете осуществить следующий перевод, вам будет необходимо синхронизировать кошельки. Также следует отметить, что, независимо от каких-либо требований к синхронизации, ограничение multisig Monero состоит в том, что **транзакции могут проводиться только строго одна после другой**. Например, вы не сможете отложить полностью подписанные транзакции, чтобы отправить их позднее, и инициировать другую транзакцию, чтобы провести её раньше. (Для некоторых такой сценарий MMS недостаточно доходчив, и они пробуют сделать иначе. В главе *«Устранение ошибок»* описано, как можно всё исправить, удалив сообщения, содержащие необработанные транзакции, и запустив процесс синхронизации).
Как уже было сказано, можно хранить данные транзакции не в файле `.mms` в форме содержания сохранённого сообщения и использовать обычную команду `transfer`, но в этом случае, конечно же, вся ответственность за отправку частично подписанной транзакции следующему подписанту будет лежать на вас. Также следует отметить, что система MMS не поддерживает «холодного» подписания. Это ещё одна причина, по которой нужно напрямую использовать команду `transfer`, а не `mms transfer`. Тем не менее данные транзакции, которые содержатся в сообщении, могут быть экспортированы при помощи команды `mms export`.
## Подробное описание команд
### mms init
mms init <required_signers>/<authorized_signers> <own_label> <own_transport_address>
Пример:
mms init 2/2 alice 2cUVEbbb3H6ojddYQziK3RafJ5GPcFQv7e
Подготовка кошелька к использованию с системой MMS. Позднее вы можете заменить свой собственный ярлык и свой собственный адрес передачи, используя команду `mms signer`, но два числа, обозначающие количество требуемых подписантов и правомочных подписантов, не могут быть изменены без повторного ввода команды `mms init`, которая сотрёт всю информацию подписантов и все сообщения. Использование команды приведёт к созданию дополнительного файла с расширением `.mms` для кошелька.
В случае с кошельками, созданными «до эры MMS» (до того, как код MMS был включён в Monero), MMS можно использовать только если кошелёк ещё не является multisig-кошельком. Для кошельков, созданных уже после этого, MMS можно использовать даже если это уже multisig-кошелёк. Когда кошелёк переключается на multisig, «оригинальный» адрес Monero, необходимы MMS, сохраняется перед тем, как будет заменён общим multisig-адресом.
Команда для деактивации MMS отсутствует. Если вы более не желаете пользоваться этой системой вместе с определённым кошельком, необходимо просто удалить файл `.mms` или же, по крайней мере, переместить его в другое место.
### mms info
mms [info]
Отображение активности MMS. Если MMS активна, указывается необходимое количество подписантов и количество правомочных подписантов. Это единственная команда MMS, которую можно использовать при неактивной MMS.
### mms signer
mms signer [<number> <label> [<transport_address> [<monero_address>]]]
Примеры:
mms signer
mms signer 2 bob BM-2cStcTfCx8D3McrMcmGZYZcF4csKcQT2pa 9yXKZ6UUdd8NnNN5UyK34oXV7zp7gjgZ4WTKHk8KzWsAAuyksfqoeRMLLkdWur85vnc1YL5E2rrMdPMHunA8WzUS9EL3Uoj
mms signer 2 bob-the-builder
Без аргумента выводит список подписантов и известную о них информацию. Атрибуты никогда не задаются и поэтому, будучи неизвестными, отображаются как `<not set>`. Следует отметить, что вам не нужно, и вы не можете создавать подписантов. После команды `mms init` все они уже будут «существовать», хоть и без заданной информации. Исключением является подписант #1, который всегда будет «мною», то есть самим используемым кошельком. Число их фиксировано: это количество правомочных подписантов, указываемое командой `mms init`.
При наличии указанного количества и ярлыка в качестве аргумента задаёт информацию подписанта или изменяет любую уже заданную информацию. Всегда есть возможность свободно изменить ярлыки и адреса передачи. Но по техническим причинам адреса Monero могут быть изменены только при отсутствии сообщений. В самом худшем случае, чтобы начать с начала, снова введите команду `mms init`.
Числа начинаются с 1 и возрастают вплоть до количества правомочных подписантов.
*Ярлык* должен быть выражен одним словом. Для написания более сложных ярлыков, таких как `alice_in_wonderland`, следует использовать такие символы, как минус «-» или символ нижнего подчёркивания «_». Ярлык должен быть уникальным для каждого подписанта. Максимальная фиксированная длина ярлыка отсутствует, но некоторые выходы будут выглядеть странно (или их будет просто трудно прочитать), если ярлык будет слишком длинным.
*Адресом передачи* на данный момент может являться только адрес Bitmessage, например, `BM-2cStcTfCx8D3McrMcmGZYZcF4csKcQT2pa`, а PyBitmessage — единственная программа, которая может передавать сообщения. Проверка синтаксиса или валидности адресов передачи системой MMS не производится. Если вы введёте неправильно оформленный адрес, то при первой попытке использования получите от PyBitmessage сообщение об ошибке.
Если вами будет введён неверный адрес, то есть некорректный для соответствующего подписанта адрес, наиболее вероятно, что ничего не произойдёт. Сообщения просто не дойдут до получателя. Если ни у кого не окажется ключа для этого адреса и клиента Bitmessage, сконфигурированного для получения сообщений на такой адрес, сообщение просто будет «барражировать» по сети Bitmessage какое-то время, пока в конечном счёте не исчезнет.
### mms list
mms list
Составляет список всех сохранённых сообщений. Нет никакой отдельной папки «входящие» или «исходящие». Все сообщения вносятся в один хронологически организованный список. Вот подробное описание колонок такого списка:
* `Id`: уникальный идентификатор сообщения, который можно использовать для связи с такими командами, как `mms show` и `mms send`. Идентификаторы сообщений нумеруются строго, начиная с 1 и выше. Идентификаторы удалённых сообщений не используются повторно.
* `I/O`: указывается направление сообщения. `in` обозначает полученные сообщения, а `out` обозначает отправленные сообщения. Следует отметить, что в случае с некоторыми типами сообщений вы можете получить сообщение от самого себя, например, частично подписанную транзакцию, инициированную вами же.
* `Authorized Signer`: в случае полученного сообщения обозначает отправителя, а в случае отправленного сообщения — получателя. Указываются ярлык и в пределах доступной ширины колонки адрес передачи подписанта.
* `Message Type`: тип сообщения, который указывает на то, какие данные содержатся в нём. Полный список возможных типов сообщений приводится ниже.
* `Height`: количество передач, которое содержит кошелёк на момент создания или получения сообщения. Используется для группировки сообщения с «правильными» данными синхронизации, которые должны быть все одинаковой «высоты» для всех остальных подписантов, чтобы синхронизация прошла успешно. Такая высота не особо важна, если только что-то не пойдёт не так. Более подробная информация содержится в главе *«Устранение ошибок»*.
* `R`: номер раунда обмена ключами, к которому относится набор ключей, если тип multisig требует более одного раунда, как, например, 2/3. 0 в случае со всеми остальными типами сообщений.
* `Message State`: текущее состояние сообщения: `waiting` или `sent` для исходящих сообщения, `waiting` или `processed` для входящих сообщений. Изменить это состояние напрямую нельзя. Это всегда происходит с использованием команд.
* `Since`: точка на определённом отрезке времени, начиная с которой сообщение получило своё текущее состояние. Время указывается в UTC, а не как локальное время. Если сообщение пересылается, эта временная метка не корректируется, и отображается время первой отправки.
Полный список типов сообщений:
* `key_set`: данные о ключах, которыми кошельки должны обмениваться друг с другом для создания multisig-адресов.
* `additional_key_set`: набор ключей для дополнительного раунда обмена ключами, который следует за начальным. Требуется для несимметричных типов multisig, таких как 2/3, например.
* `multisig_sync_data`: данные, которыми кошельки должны обмениваться друг с другом, чтобы правильно и полностью интерпретировать входящие и исходящие транзакции (см. также главу *«Синхронизация кошельков»*).
* `partially_signed_tx`: транзакция, у которой пока нет необходимого количества подписей (равноценно необходимому количеству подписантов), чтобы совершить её.
* `fully_signed_tx`: Транзакция с полным набором необходимых подписей, готовая к передаче в сеть Monero любым подписантом.
* `note`: сообщение с примечанием (см. команду `mms note`)
* `signer_config`: полная информация обо всех подписантах, которая отправляется в рамках процесса автоконфигурирования или при вводе команды `mms send_signer_config`.
* `auto_config_data`: Данные адреса, получаемые от подписанта и отправляемые обратно менеджеру автоконфигурирования после ввода токена командой `mms auto_config`.
### mms next
mms next [sync]
*Центральная* и, пожалуй, наиболее полезная команда MMS, отвечающая за проверку состояния кошелька, полученных и отправленных сообщений и их состояния, а также решение, какое действие будет следующим, и его фактическое выполнение.
Если возникли какие-либо сомнения, следует ввести команду `mms next`. MMS либо выполнит следующую соответствующую команду в соответствии с «правилами порядка выполнения операций» Monero, либо скажет, что необходимо сделать перед тем, как продолжить. Во избежание «опасностей», перед тем как будет произведено фактическое действие, будет запрошено подтверждение. В худшем случае `mms next` может выполнить что-то раньше, чем вы намеревались сделать это. В остальном эта команда едва ли может как-то навредить.
Следует отметить, что при совершении многих действий **не предусмотрено** какой-либо специальной команды, и `mms next` является **единственным** способом, чтобы продолжить. Например, можно не искать команды для выборочной проверки определённых сообщений. Если придёт время для обработки каких-либо полученных сообщений, находящихся в состоянии ожидания, команда сделает это.
Интересно и даже, наверное, удивительно, но в случае с Monero **всегда** ясно, что произойдёт в следующую очередь, если речь идёт о multisig. Исключение составляют частично подписанные транзакции, когда вы решаете, **кому** из подписантов отправить такую транзакцию, а также полностью подписанные транзакции, которые вы сами можете передать в сеть или отправить другому подписанту, который сделает это.
Специальная форма команды `mms next sync` предназначена для тех случаев, когда есть данные синхронизации, которые MMS не может обработать сама, поскольку «считает», что кошелёк находится в состоянии, не требующем новой синхронизации, что может быть и не так. Подробная информация по этому вопросу содержится в главе *«Устранение ошибок»*.
### mms sync
mms sync
Принудительный ручной запуск синхронизации, то есть, даже если система MMS считает, что в данный момент нет никакой необходимости в обмене данными синхронизации. Более подробная информация содержится в главе *«Устранение ошибок»*.
### mms transfer
mms transfer <transfer_command_arguments>
Запуск передачи под управлением MMS. Отличается от стандартной команды `transfer` тем, что в результате частично подписанная транзакция не будет записана в файл, который вы далее передадите сами, а будет создано сообщение, содержащее транзакцию. Чтобы MMS начала обработку сообщения после команды `mms transfer`, следует использовать `mms next`, что, по сути, означает решение, кому из подписантов отправить его для получения следующей подписи, а также создание для этого другого сообщения.
Аргументы команды `mms transfer` те же, что и у стандартной команды `transfer`. Чтобы узнать все возможные параметры и комбинации параметров команды, следует использовать `help transfer`.
Следует отметить, что в целом для MMS не особо важны адреса, подадреса и учётные записи. Независимо от того, что будет указано для команды `mms transfer`, впоследствии всегда будет создано одно новое сообщение, содержащее частично подписанную транзакцию.
Даже при активной системе MMS по-прежнему можно использовать стандартную команду `transfer`, но ответственность за доставку транзакции в этом случае полностью ложится на вас. Следует попробовать использовать правильный вариант команды `transfer`. Передача не потребует подтверждения, если вы действительно используете его вместо `mms transfer`. Если вы выбрали вариант `transfer`, но на самом деле вам был нужен вариант MMS, следует проигнорировать записанный файл транзакции и просто продолжить, используя `mms transfer`.
MMS, по крайней мере пока, не отслеживает, сколько подписей фактически имеется у транзакции, а также, кто уже подписал её, а кто нет. Из-за этого недочёта существует вероятность включения не имеющих смысла «выборов», например, выбора отправить частично подписанную транзакцию кому-то, кто уже подписал её.
Это играет важную роль в случае с такими типами multisig, как 2/2 или 2/3. Но, безусловно, чем больше будет число правомочных подписантов, тем острее станет проблема. Подписантам нужно немного внимания, чтобы всё сделать правильно. Тем не менее невозможно допустить ошибку в полном смысле: CLI-кошелёк, а точнее, команды CLI, которые внутренне вызываются MMS, отклонят любые попытки сделать что-либо неправильно.
### mms delete
mms delete (<message_id> | all)
Удаление отдельно взятого сообщения по его идентификатору или же удаление всех сообщений при помощи параметра `all`. Отдельные сообщения удаляются без подтверждения, даже если они ещё не были отправлены или не были обработаны. Сообщение удаляется навсегда. Действие отменить нельзя, и оно удаляется также и из памяти PyBitmessage. (Если вы потеряете сообщение, вы можете отправителя попросить отправить его вам повторно).
Бывает возникают ситуации, когда необходимо расчистить место, удаляя сообщения, которые ещё не были обработаны, которые уже невозможно обработать и которые теперь «мешают порядку выполнения операций». Подробности содержатся в главе *«Устранение ошибок»*. Удаление также полезно, если кто-то повторно отправляет вам сообщение, а оригинальное сообщение приходит к вам позже.
Вы можете возразить, что ценность отправленного или обработанного сообщения не так уж и велика, так как в большинстве случаев оно уже никогда вам не понадобится, а для повторной обработки многих сообщений по запросу вообще нет каких-либо команд. Но, безусловно, сам по себе список сообщений довольно ценен с точки зрения проверки, что происходило и когда. Поэтому лучше не удалять сообщения без веской причины.
### mms send
mms send [<message_id>]
Пример:
mms send 14
Без каких-либо параметров отправляет любое сообщение, находящееся в состоянии *готовности к отправке*. При наличии идентификатора сообщения в качестве параметра, отправляется это конкретное сообщение. Также используется, чтобы повторно отправлять сообщения в качестве части «системы передачи сообщений UX» и для обеспечения устойчивости обработки, так как существует совсем немного ситуаций, в которых восстановление становится невозможным: сеть Bitmessage «съела» ваше сообщение? Нет проблем — отправьте его повторно. Упал PyBitmessage? Нет проблем — перезапустите PyBitmessage и повторно отправьте своё сообщение.
Отправляются ли сообщения незамедлительно, или же система MMS запрашивает подтверждение отправки зависит от значения параметра `auto-send` (см. команду `mms set`). Такое предложение сообщений к отправке может оказаться полезным для новичков, поскольку так очевидней, что происходит. С другой стороны, едва ли имеет смысл откладывать отправку, если есть что-то, что нужно отправить в первую очередь.
«Отправка» не означает реальной отправки. MMS просто передаёт сообщение PyBitmessage, и именно *эта* программа фактически отправит сообщение. Система MMS никак не может сообщить, ожидает ли сообщение отправки в сеть Bitmessage, или же оно уже было туда отправлено. Если сомневаетесь, проверьте PyBitmessage сами.
Любые ошибки в адресах Bitmessage будут удалены только в момент отправки. Сама MMS не проверяет эти адреса.
### mms receive
mms receive
Запускает немедленную проверку полученных сообщений или, если быть более точными, передаёт немедленный запрос MMS программе PyBitmessage, имеются ли новые сообщения.
MMS проверяет наличие новых входящих сообщений с той же частотой, что CLI-кошелёк проверяет наличие входящих транзакций: каждые 90 секунд. А настройка, определяющая, должна быть проверка автоматической или нет, будет точно такой же: `auto-refresh`.
### mms note
mms note [<label> <text>]
Пример:
mms note
mms note bob Did you already submit the last transaction?
mms note alice Yes, just waiting for the next block :)
При отсутствии параметров показывает любые ещё непрочитанные комментарии. При наличии ярлыка и дальнейшего текста в качестве параметров отправляет подписанту текст с ярлыком как сообщение типа `note`.
Отправка комментариев друг другу напрямую из кошелька Monero к тому же может оказаться довольно забавным способом избежать использования дополнительных каналов связи для общения с подписантами.
Если вы хотите прочитать или перечитать определённый комментарий, следует использовать команду `mms show` и искать последнюю строку содержания сообщения, где будет примечание.
### mms show
mms show <message_id>
Показывает подробную информацию о сообщении с идентификатором, используемым в качестве параметра команды. Полезно читать или перечитывать примечания. Двоичное содержимое сообщений не отображается. Команда `mms export` используется для проверки полученных файлов, если есть необходимость в проверке содержания такого сообщения.
### mms export
mms export <message_id>
Экспорт содержания сообщения с определённым идентификатором в файл с фиксированным именем `mms_message_content` в текущей директории. Уже существующий файл будет просто переписан.
Противоположной команды `mms import` пока не существует.
### mms set
mms set <option_name> [<option_value>]
Пример:
mms set auto-send 1
Эквивалент MMS общей команде `set`. При наличии только имени в качестве опции показывает текущее значение этой опции. При наличии имени опции и заданного значения присваивает этой опции заданное значение.
К этому моменту единственная специфическая для MMS настройка, за которую отвечает эта команда, это настройка `auto-send`. При такой настройке сообщения не отправляются автоматически сразу после того, как они были созданы, а MMS сначала запрашивает подтверждение. Также см. команду `mms send`. Как только вы освоите MMS, и эта система станет для вас удобна в использовании, возможно, будет лучше установить настройку `auto-send` в значение 1, чтобы уменьшить количество подсказок и ускорить процесс в целом.
### mms start\_auto\_config
mms start_auto_config [<label> <label> ...]
Пример:
mms start_auto_config bob trent
Запуск процесса автоконфигурирования кошелька «менеджера конфигурирования» путём создания токенов автоконфигурирования для каждого подписанта, кроме «себя», то есть первого, а также выдача команды `mms signer` для отображения токенов. Запрос подтверждения происходит, если у процесса есть подозрение, что процесс автоконфигурирования уже запущен, так как в конфигурации подписантов уже имеются токены.
Менеджер должен передавать токены автоконфигурирования соответствующим подписантам вне MMS. Следует отметить, что эти токены являются чувствительной информацией. Такой токен в руках лица, не являющегося подписантом, или же в руках не того подписанта позволит такому человеку выдавать себя за правомочного подписанта, то есть принимать участие во всех транзакциях вместо настоящего подписанта.
Предварительным условием для запуска процесса автоконфигурирования является наличие присвоенного ярлыка у *всех* подписантов. Идея состоит в том, чтобы при автоконфигурировании в кошельках всех подписантов появлялись **те же** ярлыки, чтобы каждый знал, кто есть кто. (Будет отличаться только порядок подписантов в каждом кошельке, поскольку владелец кошелька всегда будет подписантом #1). Позднее подписанты могут изменить ярлыки, которые им не нравятся, поскольку, конечно, они уже не спутают подписантов.
Вы можете заранее назначить ярлыки всем подписантам, используя команду `mms signer` или же саму команду `mms start_auto_config`, что будет удобнее, составив таким образом список всех ярлыков, за исключением «своего» ярлыка, и эти ярлыки будут расположены в правильном порядке в качестве аргументов команд.
По сути, команда может быть выдана в любой момент. Вместе с тем разумнее всего делать это в самом начале для кошельков всех подписантов, когда были выданы только команды `mms init`.
Описание шагов, которые реализуются после выдачи этой команды, содержится в главе *«Автоконфигурирование»*.
### mms auto\_config
mms auto_config <auto_config_token>
Пример:
mms auto_config mms561832e3eb
Обработка токена автоконфигурирования, полученного от «менеджера конфигурирования» в процессе автоконфигурирования по какому-либо приемлемому безопасному каналу связи вне MMS, например, в SMS-сообщении, через мессенджер, установленный в смартфоне, зашифрованным сообщением по электронной почте или же устно по телефону. Каждый подписант получает свой собственный, индивидуальный токен. К каждому токену автоконфигурирования MMS следует относиться как к конфиденциальной информации.
В результате ваш адрес Bitmessage и адрес Monero отправляются менеджеру с сообщением типа `auto-config data`. (Передача такого сообщения уже безопасна настолько же, насколько и передача любого последующего сообщения MMS, так как никому более не известен ваш токен).
Существуют некоторые допуски, связанные с тем, как система MS интерпретирует введённые токены (например, они не чувствительны к регистру), а любая опечатка с высокой степенью вероятности приведёт к созданию недействительного токена и будет обнаружена.
Если было решено провести автоконфигурирование, то лучше воздержаться от ручного ввода информации подписантов, используя `mms signer` (тем не менее система MMS не запрещает этого).
Полный список всех шагов процесса автоконфигурирования содержится в главе *«Автоконфигурирование»*.
### mms stop\_auto\_config
mms stop_auto_config
Удаляет любые токены автоконфигурирования из конфигурации подписанта и таким образом останавливает любой запущенный процесс автоконфигурирования.
Удалённые токены невозможно восстановить или воссоздать, так как они создаются в произвольном режиме. Если вы являетесь «менеджером конфигурирования» и удаляете токены, то вы более никогда не сможете получать сообщения автоконфигурирования, которые отправят вам другие подписанты, используя эти удалённые токены (тем не менее и никто другой также не получит их). Всем понадобятся новые токены, созданные вами.
### mms send\_signer\_config
mms send_signer_config
Ручная отправка вашей конфигурации подписанта всем остальным подписантам в виде сообщений типа `signer config`. После получения вашего сообщения подписанты смогут заменить свою конфигурацию подписанта вашей, используя команду `mms next`. Перед тем как это произойдёт, должно появиться предупреждение по безопасности.
Ярлык каждого подписанта будет переписан введённым вами ярлыком, но собственные адреса Bitmessage и адреса Monero подписантов останутся без изменений.
Эта команда и возможность «широкой рассылки» определённой конфигурации подписанта, которую она обеспечивает, могут служить составным элементом процесса под названием *«полуавтономного конфигурирования»*. См. Также главу «Отправка конфигурации подписанта». Отправка полной конфигурации подписанта также является частью процесса полностью автономного конфигурирования, несмотря на то, что при этом не требуется использования отдельной команды `mms send_signer_config`.
## Безопасность
MMS была тщательно разработана и реализована как система, обеспечивающая высокий уровень безопасности.
Это было непросто сделать. Применение мультиподписей Monero само по себе является многогранным, если не сказать сложным процессом, и поэтому нетривиальным с точки зрения безопасности, а MMS представляет собой мощную, если не сказать сложную систему поверх всего этого. Так что совершенно не удивительно наличие самых разнообразных вопросов, связанных с безопасностью.
Следует отметить, что это самая **первая** версия MMS, и вполне возможно, что люди, использующие эту систему в различных условиях, обнаружат новые проблемы безопасности кроме тех, что указаны в этом руководстве, или же некоторые из упомянутых проблем будут рассмотрены в новом свете. Тем не менее есть надежда, что глубокие и в целом «непоправимые» концептуальные недостатки в системе MMS отсутствуют.
TL;DR: Если у вас есть какие-либо сомнения, используйте MMS только после того, как самостоятельно конфигурируете свои multisig-кошельки предположительно более безопасным способом, чем может обеспечить MMS (не тривиальным, но выполнимым). Если же вы сомневаетесь очень сильно, не используйте MMS.
### Использование шифрования и подписей
Всё содержимое сообщения шифруется либо при помощи ключей просмотра Monero, связанных с кошельками Monero подписантов, либо при помощи произвольно генерируемых ключей, обеспечивающих такой же уровень защиты в случае с содержанием сообщений автоконфигурирования. Возможно, это покажется несколько излишним, учитывая, что сообщения шифруются уже самой программой PyBitmessage, но, во-первых, PyBitmessage является программным обеспечением третьей стороны, которой вы можете не доверять, а во-вторых, благодаря такой защите система MMS готова к использованию с менее безопасными системами связи, не использующими шифрования.
Сообщения подписываются с использованием приватных ключей просмотра подписантов. Это делается в целях аутентификации: MMS отклонит сообщение от подписанта, в котором будет отсутствовать действительная подпись, которая может принадлежать только этому подписанту и никому более. Кроме того, хэш-функция не даёт каким-либо образом изменить содержание сообщения. И наконец, принимаются только сообщения от подписантов: сообщение, полученное с адреса Monero, но не указанное в конфигурации подписанта, будет отклонено, даже если у него будет действительная подпись.
Также для шифрования файла `.mms`, содержащего конфигурацию подписантов, а также все отправленные и полученные сообщения, используется ключ просмотра.
И всё же следует быть реалистичными в отношении требований к безопасности передачи данных. Безусловно, никому не хотелось бы, чтобы различные пакеты данных курсировали бы туда и обратно между кошельками подписантов, пока они не попадут не в те руки, хотя и непросто было бы злоумышленнику причинить какой-либо вред, используя что-то из этих данных. В конечном счёте суть мультиподписей состоит в том, что только группа людей, **взаимодействуя**, может подписать и выложить транзакцию в сеть. Злоумышленник, заполучивший частично подписанную транзакцию, мало что сможет с ней сделать.
(Злоумышленник, который перехватывал **все передаваемые данные** с самого начала, возможно, и мог бы что-то сделать, если бы эти данные не были зашифрованы. Он мог бы собрать все ключи и создать рабочий «single-sig» кошелёк для multisig-адреса и украсть монеты, но **это** довольно крутой сценарий, а данные, передаваемые MMS, шифруются).
### Связь между MMS и PyBitmessage
Данные, передаваемые между MMS и PyBitmessage, к сожалению, не шифруются. В данном случае используется протокол HTTP, а не его зашифрованный эквивалент HTTPS. Содержание сообщения, безусловно, шифруется **до того**, как MMS передаст сообщение программе PyBitmessage, и любые изменения в содержании будут обнаружены при получении сообщений, но никто из возможных наблюдателей не сможет узнать что-либо, используя «метаданные»: ни кто отправил сообщение, ни кому оно отправлено, ни когда это было сделано.
Поскольку ваш кошелёк Monero с системой MS и программой PyBitmessage запускаются на одной и той же машине, это уже само по себе представляет довольно большую опасность, поскольку любой, кто может просматривать такую строго исключительную связь типа `«localhost — localhost»`, уже сидит внутри вашего компьютера, и в этом случае, возможно, вы уже пропустили опасность, и «троян», следящий за трафиком между MMS и PyBitmessage, станет наименьшей из ваших проблем.
И вот именно поэтому связь с PyBitmessage через сеть Internet, как с каким-либо «публичным узлом», не самая лучшая идея.
Есть и вторая проблема: API программы PyBitmessage защищёны только именем пользователя и паролем, которые передаются открытым текстом по каждому запросу HTTP. Злоумышленнику не составит труда перехватить имя пользователя и пароль и провести какую-нибудь DOS-атаку, например, направленную на удаление всех сообщений с интервалом в 10 секунд.
(В защиту PyBitmessage можно сказать, что программа **не была** разработана в качестве сервера, которому предстояло бы противостоять большому и злому интернету. Это программа для локального использования. Едва ли стоит удивляться тому, что её использование за пределами области предназначения может стать причиной возникновения проблем).
### Подражание
Если Элис (покупатель) и Боб (продавец) используют схему multisig 2/3 для *доверенного хранения*, должен быть и Трент, выступающий в качестве доверенного третьего лица, который сможет разрешить спор в случае возникновения такой ситуации, и либо помочь Элис вернуть её деньги, если Боб не выполнит условия доставки, подписав транзакцию, начатую Элис, либо помочь Бобу получить деньги, если Элис получит свой товар, но сделает вид, что ничего не получала и откажется подписывать платёж Бобу.
В подобной ситуации *доверенного хранения* должно участвовать **три** разных лица. Если Боб каким-либо образом сможет *притвориться* Трентом, выдавая себя за него, а для Элис сразу за двух людей: Боба и Трента, и настроит **два** разных кошелька с двумя наборами ключей, Боб сможет сделать эти транзакции по схеме multisig 2/3 действительными самостоятельно и обманет всех.
Насколько серьёзной будет опасность такого «подражания», зависит от того, насколько безопасно будет осуществляться первый обмен наборами ключей в самом начале всего процесса при конфигурировании кошельков и окончательном «переходе на multisig». Если вы можете гарантировать, что только нужные люди получат правильные наборы ключей, и никто никоим образом не сможет притвориться другим человеком, то всё будет нормально. Если же это не так, вы можете проиграть.
Если вы пользуетесь всеми возможностями системы MMS, вы делаете это не только для проведения транзакций, но начинаете ещё раньше с обмена наборами ключей между всеми подписантами. Особенно в случае с высшими формами, такими как схема multisig 2/4 со множеством раундов обмена, они довольно полезны и обеспечивают сокращение количества ошибок, если сравнивать с ручным процессом. Таким образом, задача по предотвращению подмены личности смещается из области обмена ключами в область безопасной настройки адресов подписантов в MMS. Если Боб каким-либо образом может обмануть Элис, и она использует один из **его** адресов Bitmessage вместо адреса Трента, то Боб победил.
Существует три метода настройки адресов подписантов, поддерживаемых MMS: ручное конфигурирование подписантов, автоконфигурирование и «полуавтоматическая» отправка внесённой информации о подписантах. Все три метода связаны с соответствующими рисками с точки зрения подмены личности. Подробная информация по этой теме содержится в главах *«Ручное конфигурирование подписантов»*, *«Автоконфигурирование»* и *«Отправка информации подписанта»*.
Автоконфигурирование, несомненно, является самым простым способом обеспечения безопасности. У вас имеется только незначительный объём информации, токен автоконфигурирования размером в 1 символ, который безопасно передаётся каждому подписанту. И если вы можете сделать это, то вы победили. («Менеджер конфигурирования» в данном случае, безусловно, является надёжным).
Если всё это звучит слишком сложно, и поэтому вы не вызывает у вас доверия, вы можете конфигурировать кошельки и создать multisig-адрес, никак не затрагивая MS, и только потом использовать эту систему, чтобы спокойно отправить частично подписанную транзакцию, избегая утомительной ручной синхронизации кошельков после проведения каждой транзакции.
### Контролируемые злоумышленником данные
Есть две ситуации, когда ваш кошелёк, использующий MMS, получает данные от другого подписанта, и когда такой подписант, действующий со злым умыслом, может попытаться обмануть или вовлечь вас во что-то нехорошее.
Комментарии, передаваемые при помощи команды `mms note`, могут использоваться в целях «социальной инженерии». Злоумышленник, пытаясь обмануть, например, может попытаться сформулировать комментарий, который выглядел бы как ошибочное сообщение. Тем нем менее в данном случае технические возможности довольно ограничены. Комментарии передаются строго в форме текста, и при их отображении MMS отфильтровывает символы в кодировке ASCII мене 32, а также два символа, « < » и « > », которые могут использоваться для построения HTML или XML, которые могут интерпретироваться каким-либо образом (что весьма маловероятно в случае с CLI-кошельком, но вполне возможно с GUI-кошельками). Кроме того, длина комментариев ограничена.
Вторым способом является попытка обмана с применением ярлыков, которые передаются командой `mms send_signer_config`. Боб мог бы назначить Элис ярлык *trent*, а Тренту — *alice*, отправить такую конфигурацию подписантов Элис и каким-либо образом убедить Элис использовать её. Вот почему сообщения типа `singer config`, отправляемые вне процесса автоконфигурирования командой `mms send_signer_config`, не обрабатываются сразу, а отображаются сначала с запросом подтверждения.
## Устранение ошибок
### Решение проблем синхронизации
Как объяснялось в главе *«Синхронизация кошельков»*, схема мультиподписей Monero требует обмена некоторыми данными между кошельками как после отправки, так и после получения транзакций. В MMS такие данные называются *данными синхронизации multisig*.
Иногда происходит рассинхронизация. Существует четыре возможных признака этого:
* Команда `balance` выводит сообщение *Some owned outputs have partial key images - import\_multisig\_info needed* (У некоторых выходов частичные образы ключей – требуется import_multisig_info), которое «отказывается закрываться».
* Кошелёк выводит сообщение *That signature was made with stale data* (Подпись была создана с использованием устаревших данных), и отказывается от дальнейшей обработки транзакции.
* При попытке подписания транзакции кошелёк сообщает об отсутствии ключей.
* Кошелёк обвиняет вас в попытке двойной траты, хотя вы не пытаетесь сделать ничего подобного.
В некоторых подобных случаях MMS ничего не известно о возникновении проблемы, и после ввода команды `mms next` системе ничего не остаётся, кроме как начать раунд синхронизации.
В связи с этим есть способ **принудительно запустить синхронизацию** практически в любой момент:
* Все подписанты вместо команды `mms next` вводят команду `mms sync`, чтобы отправить друг другу данные синхронизации.
* После получения этих сообщений все подписанты вводят команду `mms next sync` (следует отметить наличие дополнительного аргумента `sync`).
Чтобы синхронизация сработала, необходимо, чтобы вся информация поступала с одной «высоты», то есть производилась с одинаковым количеством передач, записанных кошельками всех подписантов. Если, например, один из подписантов по каким-либо причинам не получит транзакции и отправит информацию синхронизации в этом состоянии, то она не будет иметь никакой ценности для остальных подписантов с их кошельками.
Если кажется, что MMS игнорирует ещё не обработанные сообщения данных синхронизации, находящиеся в состоянии `waiting` (ожидания), наиболее вероятно это происходит по этой причине. При наличии сомнений, следует проверить колонку `Height` (высота) в списке сообщений, который выводится командой `mms list`.
Иногда такие ещё необработанные сообщения, которые уже и не могут быть обработаны, не дают использовать команду `mms next`. В этом случае для удаления любого сообщения со слишком малой высотой используется команда `mms delete`.
### Переадресация транзакции другому подписанту
Если в случае со схемой multisig 2/3, например, вы отправляете кому-либо частично подписанную транзакцию, но позже меняете своё решение и решаете отправить её кому-либо ещё, есть небольшая хитрость, которая позволит сделать это. Необходимо найти сообщение типа `partially signed tx`, адресованное **самому себе**, и ввести команду `mms send` для этого сообщения. После получения необходимо ввести команду `mms next`. Вам снова будет предоставлен выбор, что делать с ним далее.
Конечно, вы можете проигнорировать эту транзакцию и начать новую. Но следует учитывать, что новая транзакция также может позднее наткнуться на препятствие, если первая будет подписана и попадёт в сеть до **того**, как туда доберётся вторая.
### Игнорирование невзаимодействующих подписантов при синхронизации
Нормальный процесс синхронизации кошельков, использующих MMS, подразумевает, что все подписанты взаимодействуют и отправляют сообщения с данными синхронизации после отправки или получения транзакции. Поэтому команда `mms next` будет ожидать до тех пор, пока не будут получены сообщения с данными синхронизации (для одной и той же «высоты») от **всех** остальных подписантов, и только после этого они будут обработаны.
Тем не менее, если в конфигурации подобной multisig 2/3 *M* окажется меньше *N*, синхронизация будет успешной только при наличии (количество необходимых подписантов минус 1) сообщений синхронизации. Команда `mms next` укажет, когда будет достигнут этот нижний порог, и даст подсказку, как обойти проблему и продолжить: использовать команду `mms next sync`.
Если же, несмотря на это, позже будут получены дополнительные сообщения с данными синхронизации, следует просто удалить их, используя команду `mms delete`. Они не нужны, их нельзя обработать, а в худшем случае они станут помехой для проведения следующего раунда синхронизации.
Обычно, когда запускается синхронизация, система MMS создаёт сообщения для *всех* остальных подписантов. Если вы хотите воспрепятствовать этому, чтобы другим подписантам было максимально сложно проводить транзакции в дальнейшем, необходимо установить параметр `auto-send` как ложный, ответить «нет» при первом запросе отправки и вручную удалить любые нежелательные сообщения до того, как остальные будут отправлены командой `mms send`.
### Восстановление состояния после потери или отправки идентичных сообщений
Если по какой-либо причине вы пропустили сообщение, потому что оно не было доставлено программой PyBitmessage, или же потому что вы удалили его слишком рано, следует попросить отправителя сообщения отправить его повторно, используя команду `mms send`.
Следует отметить, что сообщения, отправляемые множество раз, *не отменяют* друг друга автоматически по получению. Если вы отправили сообщение повторно, если, например, кто-то недостаточно терпелив, то подписант, являющийся адресатом, может получить *два* сообщения одного типа с одним и тем же содержанием.
Если в последствии с запозданием появится отсутствующее сообщение, то ничего хорошего в этом не будет, но эта проблема решается легко при помощи команды `mms delete`, позволяющей избавиться от одной из двух копий.
### Исправление / обновление информации подписантов
Для изменения ярлыка `bob`, который вам уже не нравится, можно использовать команду `mms signer`:
mms member 2 bob-the-builder
При необходимости, используя ещё один аргумент, можно изменять адреса Bitmessage:
mms member 2 bob BM-2cSrgmut9AD6bdU8b8GXd36iUYDjCS9xJb
Точно таким же образом можно изменять и адреса Monero (конечно, за исключением вашего собственного). Но тут есть ограничение: это можно делать только при отсутствии полученных сообщений. Как только кошельки перейдут на схему multisig, уже не будет никакого смысла изменять адреса Monero.
### Запуск с нуля
Если состояние MMS вашего кошелька такое, что отладка уже не поможет, и вы хотите начать всё с нуля, или же если вы более не хотите использовать систему MMS с каким-то определённым кошельком, необходимо найти файлы кошелька в файловой системе и просто удалить файл с расширением `.mms`.
### Взаимодействие MMS / PyBitmessage
Вот некоторые подробности взаимодействия MMS и PyBitmessage, которые помогут лучше понять любые проблемы, которые могут возникнуть.
MMS пытается ограничить количество сообщений, которые сохраняются в хранилище PyBitmessage, и удаляет их. Однако из соображений надёжности система не удаляет их сразу после получения, а только после того, как состояние сообщения изменится с `waiting` на `rocessed`, или же если вы удаляете такое сообщение из хранилища сообщений. Иногда сообщения «зависают», и MMS никак не может удалить их. Вы можете безопасно удалить такие сообщения интерактивно в самой программе PyBitmessage.
Если вы используете процесс автоконфигурирования, новые адреса / идентификационная информация для MMS будет создаваться PyBitmessage автоматически. Программа попытается удалить их после окончания конфигурирования, но необходимо отметить, что текущая версия PyBitmessage продолжает отображать удалённые адреса вплоть до перезапуска программы. Это не представляет никакой опасности, но, пожалуй, может запутать некоторым образом.
Если такие динамические адреса автоконфигурирования не будут удалены вовсе, например, если вы раньше удалите кошелёк, к сожалению, текущая версия PyBitmessage не предусматривает простого способа сделать это. Придётся вручную искать и редактировать файл `keys.dat`, и удалять соответствующие строки (при этом стараясь ничего не повредить в файле...)
Иногда сообщения зависают и не отправляются. В таких случаях следует перезапустить PyBitmessage.
_i18n/ru/resources/user-guides/png/prove-payment/check-payment.png

182 KiB | W: 0px | H: 0px

_i18n/ru/resources/user-guides/png/prove-payment/check-payment.png

203 KiB | W: 0px | H: 0px

_i18n/ru/resources/user-guides/png/prove-payment/check-payment.png
_i18n/ru/resources/user-guides/png/prove-payment/check-payment.png
_i18n/ru/resources/user-guides/png/prove-payment/check-payment.png
_i18n/ru/resources/user-guides/png/prove-payment/check-payment.png
  • 2-up
  • Swipe
  • Onion skin
_i18n/ru/resources/user-guides/png/prove-payment/history.png

133 KiB | W: 0px | H: 0px

_i18n/ru/resources/user-guides/png/prove-payment/history.png

158 KiB | W: 0px | H: 0px

_i18n/ru/resources/user-guides/png/prove-payment/history.png
_i18n/ru/resources/user-guides/png/prove-payment/history.png
_i18n/ru/resources/user-guides/png/prove-payment/history.png
_i18n/ru/resources/user-guides/png/prove-payment/history.png
  • 2-up
  • Swipe
  • Onion skin
_i18n/ru/resources/user-guides/png/prove-payment/payment-checked.png

51.6 KiB | W: 0px | H: 0px

_i18n/ru/resources/user-guides/png/prove-payment/payment-checked.png

52.5 KiB | W: 0px | H: 0px

_i18n/ru/resources/user-guides/png/prove-payment/payment-checked.png
_i18n/ru/resources/user-guides/png/prove-payment/payment-checked.png
_i18n/ru/resources/user-guides/png/prove-payment/payment-checked.png
_i18n/ru/resources/user-guides/png/prove-payment/payment-checked.png
  • 2-up
  • Swipe
  • Onion skin
_i18n/ru/resources/user-guides/png/prove-payment/payment-proof.png

64.3 KiB | W: 0px | H: 0px

_i18n/ru/resources/user-guides/png/prove-payment/payment-proof.png

62.3 KiB | W: 0px | H: 0px

_i18n/ru/resources/user-guides/png/prove-payment/payment-proof.png
_i18n/ru/resources/user-guides/png/prove-payment/payment-proof.png
_i18n/ru/resources/user-guides/png/prove-payment/payment-proof.png
_i18n/ru/resources/user-guides/png/prove-payment/payment-proof.png
  • 2-up
  • Swipe
  • Onion skin
_i18n/ru/resources/user-guides/png/remote_node/remote-node-screenshot.png

141 KiB | W: 0px | H: 0px

_i18n/ru/resources/user-guides/png/remote_node/remote-node-screenshot.png

168 KiB | W: 0px | H: 0px

_i18n/ru/resources/user-guides/png/remote_node/remote-node-screenshot.png
_i18n/ru/resources/user-guides/png/remote_node/remote-node-screenshot.png
_i18n/ru/resources/user-guides/png/remote_node/remote-node-screenshot.png
_i18n/ru/resources/user-guides/png/remote_node/remote-node-screenshot.png
  • 2-up
  • Swipe
  • Onion skin
_i18n/ru/resources/user-guides/png/view-only/Success.png

59.5 KiB | W: 0px | H: 0px

_i18n/ru/resources/user-guides/png/view-only/Success.png

64 KiB | W: 0px | H: 0px

_i18n/ru/resources/user-guides/png/view-only/Success.png
_i18n/ru/resources/user-guides/png/view-only/Success.png
_i18n/ru/resources/user-guides/png/view-only/Success.png
_i18n/ru/resources/user-guides/png/view-only/Success.png
  • 2-up
  • Swipe
  • Onion skin
_i18n/ru/resources/user-guides/png/view-only/settings.png

142 KiB | W: 0px | H: 0px

_i18n/ru/resources/user-guides/png/view-only/settings.png

174 KiB | W: 0px | H: 0px

_i18n/ru/resources/user-guides/png/view-only/settings.png
_i18n/ru/resources/user-guides/png/view-only/settings.png
_i18n/ru/resources/user-guides/png/view-only/settings.png
_i18n/ru/resources/user-guides/png/view-only/settings.png
  • 2-up
  • Swipe
  • Onion skin
......@@ -7,4 +7,4 @@
После ввода пароля от вашего кошелька вы увидите всплывающее окно - "use custom settings" (Использовать пользовательские настройки), которое даст вам возможность изменить настройки при первом запуске кошелька. Нажмите на него. Затем вы будете отправлены на страницу "Settings" (Настройки). На этом этапе вы должны переключится в режим "Remote node" (Удаленная нода). В первое поле "Address" (Адрес) вам нужно ввести адрес удаленной ноды, к которой вы хотите подключиться. Этот адрес может выглядеть как `node.moneroworld.com` или как IP-адрес. В поле "Port" (Порт) вы вводите порт для подключения к ноде. Порт по умолчанию - `18081`, но если вы используете случайную ноду, значение для порта подключения будет другим. Нода node.moneroworld.com использует порт `18089`.
### Данное окно должно выглядеть так:
<img src="png/remote_node/remote-node-screenshot.png" width="(600)">
![Node](png/remote_node/remote-node-screenshot.png){:width="600px"}
{% assign version = '1.1.0' | split: '.' %}
{% include disclaimer.html translated="false" version=page.version %}
Below we'll show an example configuration that allows you to run a Monero daemon (eg on a home server or VPS) that you can connect to from another computer running your wallet. We do this over the Tor anonymity network to retrieve the transaction information needed by your wallet. The benefit of this approach is that the daemon (`monerod`) can stay on all of the time sending / receiving blocks, while the wallet can connect when needed and have access to the full blockchain. [Monerujo](https://www.monerujo.io/) should also work via [Orbot](https://guardianproject.info/apps/org.torproject.android/). Because Tor hidden services provide encryption and authentication, you can be confident that your RPC credentials will not be sent in the clear. Tor also solves problems often seen on home servers related to port-forwarding, IP addresses changing, etc -- it just works. This setup will also obfuscate the fact that you are connecting to a remote Monero node. Tested with Monero `v0.15.0.1` connecting a Mac laptop wallet to a remote Linux node (Ubuntu 18.04.2).
## Create a Tor hidden service for RPC
Make sure [Tor is installed](https://community.torproject.org/relay/setup/bridge/debian-ubuntu/) and running correctly, then proceed.
We only need to configure the RPC server to run as a hidden service here on port `18081`.
File: `/etc/torrc`
```
HiddenServiceDir /var/lib/tor/monero-service/
HiddenServicePort 18081 127.0.0.1:18081
```
Restart Tor:
```
sudo systemctl restart tor@default
```
Make sure Tor started correctly:
```
sudo systemctl status tor@default.service
```
If everything looks good, make a note of the hidden service (onion address) name:
```
sudo cat /var/lib/tor/monero-service/hostname
```
It will be something like 4dcj312uxag2r6ye.onion -- use this for `HIDDEN_SERVICE` below.
### Configure Daemon to allow RPC
In this example, we don't use Tor for interacting with the p2p network, just to connect to the monero node, so only RPC hidden service is needed.
File: `~/.bitmonero/bitmonero.conf` (in the home directory of the Monero user)
```
no-igd=1
restricted-rpc=1
rpc-login=USERNAME:PASSWORD
```
(Make up a USERNAME and PASSWORD to use for RPC)
Restart the Daemon: `monerod stop_daemon; sleep 10; monerod --detach`
Make sure the daemon started correctly:
```
tail -f ~/.bitmonero/bitmonero.log
```
## Connecting to your node from a local wallet
Make sure you have Tor running locally so you can connect to the Tor network. One simple way on the Mac is to just start the Tor browser and use its Tor daemon.
Then test a simple RPC command, eg:
```
curl --socks5-hostname 127.0.0.1:9150 -u USERNAME:PASSWORD --digest -X POST http://HIDDEN_SERVICE.onion:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_info"}' -H 'Content-Type: application/json'
```
Replace `USERNAME`, `PASSWORD`, and `HIDDEN_SERVICE` with values from above. Change `9150` to another port if needed by your local Tor daemon.
When you execute the command, you should get some info about the remote daemon if everything is working correctly. If not, add a ` -v ` to the beginning and try to debug why it's not connecting, check firewalls, password, etc.
Once it is working, you can connect using your cli wallet:
```
./monero-wallet-cli --proxy 127.0.0.1:9150 --daemon-host HIDDEN_SERVICE.onion --trusted-daemon --daemon-login USERNAME:PASSWORD --wallet-file ~/PATH/TO/YOUR/WALLET
```
Replace values above as needed.
## GUI
If you are interested in experimenting with the GUI over Tor, you can try `torsocks` (note this may leak info -- do not rely on it if your life depends on maintaining anonymity). Here is an example on MacOS, adjust as needed for the Linux GUI:
```
torsocks --port 9150 /Applications/monero-wallet-gui.app/Contents/MacOS/monero-wallet-gui
```
This will allow the GUI to communicate with the Tor network. Once the GUI is open and a wallet loaded, you must configure it to connect to your Tor hidden service by adding your onion address to: "Settings > Node > Remote node > Address".
In future versions of the GUI, we expect to add direct Tor / I2P support so that `torsocks` + commandline are not needed.
# Additional resources
* [ANONYMITY_NETWORKS.md](https://github.com/monero-project/monero/blob/master/ANONYMITY_NETWORKS.md)
* [Using Tor](https://github.com/monero-project/monero#using-tor) (Monero README)
{% assign version = '1.1.0' | split: '.' %}
{% include disclaimer.html translated="true" version=page.version %}
{% assign version = '1.3.0' | split: '.' %}
{% include disclaimer.html translated="false" version=page.version %}
Кошелек для просмотра может видеть только то, какие входящие транзакции принадлежат вам. С помощью него нельзя потратить ваши Monero. На самом деле он даже не может видеть исходящие транзакции из этого кошелька. Это делает кошелек для просмотра исключительно интересным в следующих целях:
* Разработчикам, которые создают библиотеки для проверки платежей
......@@ -21,13 +21,7 @@
![settings](png/view-only/settings.png)
Нажмите `Create view only wallet` (Создать кошелек только для просмотра), затем укажите имя и путь для хранения кошелька, прежде чем нажимать стрелку `Right` (Вправо):
![create-view-only](png/view-only/create-view-only.png)
Дайте вашему кошельку надежный пароль и подтвердите его нажатием на `Create wallet` (Создать кошелек):
![wallet-password](png/view-only/wallet-password.png)
Click on `Create a view only wallet` > `Create wallet`, the wallet will be created within the same directory and using your current password.
При необходимости дважды щелкните по окну `Success` (Успешно), чтобы скопировать сообщение, затем нажмите `ОК`, чтобы закрыть окно:
......
_i18n/template/resources/user-guides/png/prove-payment/check-payment.png

182 KiB | W: 0px | H: 0px

_i18n/template/resources/user-guides/png/prove-payment/check-payment.png

182 KiB | W: 0px | H: 0px

_i18n/template/resources/user-guides/png/prove-payment/check-payment.png
_i18n/template/resources/user-guides/png/prove-payment/check-payment.png
_i18n/template/resources/user-guides/png/prove-payment/check-payment.png
_i18n/template/resources/user-guides/png/prove-payment/check-payment.png
  • 2-up
  • Swipe
  • Onion skin
_i18n/template/resources/user-guides/png/prove-payment/history.png

133 KiB | W: 0px | H: 0px

_i18n/template/resources/user-guides/png/prove-payment/history.png

153 KiB | W: 0px | H: 0px

_i18n/template/resources/user-guides/png/prove-payment/history.png
_i18n/template/resources/user-guides/png/prove-payment/history.png
_i18n/template/resources/user-guides/png/prove-payment/history.png
_i18n/template/resources/user-guides/png/prove-payment/history.png
  • 2-up
  • Swipe
  • Onion skin
_i18n/template/resources/user-guides/png/prove-payment/payment-checked.png

51.6 KiB | W: 0px | H: 0px

_i18n/template/resources/user-guides/png/prove-payment/payment-checked.png

50.1 KiB | W: 0px | H: 0px

_i18n/template/resources/user-guides/png/prove-payment/payment-checked.png
_i18n/template/resources/user-guides/png/prove-payment/payment-checked.png
_i18n/template/resources/user-guides/png/prove-payment/payment-checked.png
_i18n/template/resources/user-guides/png/prove-payment/payment-checked.png
  • 2-up
  • Swipe
  • Onion skin
_i18n/template/resources/user-guides/png/prove-payment/payment-proof.png

64.3 KiB | W: 0px | H: 0px

_i18n/template/resources/user-guides/png/prove-payment/payment-proof.png

59.9 KiB | W: 0px | H: 0px

_i18n/template/resources/user-guides/png/prove-payment/payment-proof.png
_i18n/template/resources/user-guides/png/prove-payment/payment-proof.png
_i18n/template/resources/user-guides/png/prove-payment/payment-proof.png
_i18n/template/resources/user-guides/png/prove-payment/payment-proof.png
  • 2-up
  • Swipe
  • Onion skin
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
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: To continue using Monero, make sure your software is up-to-date with the November 30th network upgrade.
moreinfo: Daha fazla bilgi
lang_tag: "@lang_tag_tr"
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: Blog
library: Kütüphane
index:
page_title: "Monero - güvenli, gizli, takip edilemez"
home:
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 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 kategorilere 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:
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.
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: monero-site
description: Where the development of this website is coordinated
- 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:
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
intro3:
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:
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:
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:
intro: On this page you can find and download the latest version available of the Monero software, as well as hardware, light and mobile wallets.
choose: Choose your download
gui: GUI Wallet
cli: CLI Wallet
blockchain: Blockchain Bootstrap
blockchain1: If you'd prefer to use a blockchain bootstrap, instead of syncing from scratch, you can use the most current bootstrap. It is typically much faster to sync from scratch, however, and it also takes a lot less RAM.
blockchainbutton: Download Blockchain
mobilelight: Mobile & Light Wallets
hardware: Hardware Wallets
gui_intro: The GUI wallet provides a nice user interface, adaptable to all kinds of users, but it is especially recommended for less technical people who want to quickly send and receive XMR.
simplemode: Simple mode
simplemode1: Created for less technical users who only want to use Monero in the easiest and quickest way possible. Open the wallet, automatically connect to a remote node, send/receive XMR, done!
advancedmode: Advanced mode
advancedmode1: With all the advanced features you could need. Ideal for seasoned Monero users who prefer to have full control of their wallet and node
merchantpage: Merchant page
merchantpage1: Receive XMR for your business, easily
hwcompatible: Compatible with hardware wallets
hwcompatible1: such Trezor and Ledger
fiatconv: in-app fiat conversion
fiatconv1: No longer a need to check the value of your XMR online
pruning: Blockchain pruning
pruning1: Not enough disk space? Just use pruning to download only 1/3 of the blockchain
langs: "<b>30+ languages</b> available"
cli_intro: The CLI wallet gives you the total control over your Monero node and funds. Highly customizable and includes various analysis tools, as well as an HTTP RPC and 0MQ interface.
currentversion: Current Version
sourcecode: Source Code
showissues: Show known issues for this release
noissues: This release has no known major issues
yesissues: >
This release has the following known issues:<br>
- Initial sync of the blockchain very slow. Will be fixed with a point release
helpsupport: Help and Support
helpsupport1: "A guide with an explanation of every section of the wallet is available:"
helpsupport2: "See latest release"
gui_helpsupport: "If you are experiencing issues or you need more info, feel free to reach out to the community. You can find the GUI team at #monero-gui, or else check out the Hangouts page for a more complete list of contacts and chatrooms"
cli_helpsupport: "If you are experiencing issues or you need more info, feel free to reach out to the community. You can find the CLI team at #monero or #monero-dev, or else check out the Hangouts page for a more complete list of contacts and chatrooms"
localremote: Local or remote node
localremote1: Use your own copy of the blockchain or a publicly available one
transacttor: Transactions over Tor/I2P
transacttor1: For an additional layer of privacy
bootstrapnode: Bootstrap node
bootstrapnode1: Use a remote node while downloading the blockchain locally, this will allow you to use Monero immediately and switch to your local node once it's completely synced
rpc: RPC Wallet and Daemon
rpc1: included in the archive
payforrpc: Pay-for-RPC
payforrpc1: A new feature that allows node operators to get rewarded when their node is used
verify: Verify
verify1: You are strongly advised to verify the hashes of the archive you downloaded. This will confirm that the files you downloaded perfectly match the files uploaded by the Monero development workgroup. Please don't underestimate this step, a corrupted archive could result in lost funds. Always verify your downloads!
showhash: Show hashes to verify your download
showhash1: These SHA256 hashes are listed for convenience, but a GPG-signed list of the hashes is at getmonero.org/downloads/hashes.txt and should be treated as canonical, with the signature checked against the appropriate GPG key
showhash2: in the source code
showhash3: "Two guides are available to guide you through the verification process:"
hardware1: The Monero community has funded a
hardware2: Dedicated Hardware Wallet (Kastelo)
hardware3: which is now in progress. Moreover, since CLI 0.12.1 and GUI 0.12.3 Ledger has
hardware4: integrated Monero into their hardware wallets.
hardware5: Trezor model T supports Monero since version 0.14.1.
mobilelight1: The following are mobile or light wallets that are deemed safe by respected members of the community. If there is a wallet that is not on here, you can request the community check it out. Go to our
mobilelight2: Hangouts
mobilelight3: page to see where we are.
installer: Installer
monero-project:
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:
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.
marketing:
- category: Marketing Material
publications:
- name: "The 'Don't buy Monero' sticker"
url_file: "https://github.com/monero-ecosystem/dont-buy-monero-sticker"
abstract: >
Spread Monero everywhere with the help of this sticker. Available in multiple languages and formats (vectors included).
- name: Guerrilla Toolkit
url_file: "https://www.monerooutreach.org/guerrilla-toolkit.php"
abstract: >
A document created by the Monero Outreach workgroup containing materials and tips for an effective guerrilla marketing campaign.
accepting:
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:
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:
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 boyutuna ve dinamik ücretlere, 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 adına 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:
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:
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:
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 mevcut 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 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:
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:
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:
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
tor_wallet: Connecting your local wallet to your own daemon over Tor
roadmap:
completed: Tamamlanmış görev
ongoing: Devam eden görev
upcoming: Yaklaşan görev
future: Gelecek
research-lab:
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
summary: Summary
mrlhtp: Understanding ge_fromfe_frombytes_vartime
mrlhtp_summary: Monero uses a unique hash function that transforms scalars into elliptic curve points. It is useful for creating key images, in particular. This document, authored by Shen Noether, translates its code implementation (the ge_fromfe_frombytes_vartime() function) into mathematical expressions.
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. Görünürde 2012’de Nicolas van Saberhagen tarafından 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 parametreler 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öntemini ö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ışılıyor. 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.
mrl11: Compact linkable ring signatures and applications
mrl11_abstract: We describe an efficient linkable ring signature scheme, compact linkable spontaneous anonymous group (CLSAG) signatures, for use in confidential transactions. Compared to the existing signature scheme used in Monero, CLSAG signatures are both smaller and more efficient to generate and verify for ring sizes of interest. We generalize the construction and show how it can be used to produce signatures with coins of different type in the same transaction.
iacr2020018: "Triptych: logarithmic-sized linkable ring signatures with applications"
iacr2020018_abstract: Ring signatures are a common construction used to provide signer ambiguity among a non-interactive set of public keys specified at the time of signing. Unlike early approaches where signature size is linear in the size of the signer anonymity set, current optimal solutions either require centralized trusted setups or produce signatures logarithmic in size. However, few also provide linkability, a property used to determine whether the signer of a message has signed any previous message, possibly with restrictions on the anonymity set choice. Here we introduce Triptych, a family of linkable ring signatures without trusted setup that is based on generalizations of zero-knowledge proofs of knowledge of commitment openings to zero. We demonstrate applications of Triptych in signer-ambiguous transaction protocols by extending the construction to openings of parallel commitments in independent anonymity sets. Signatures are logarithmic in the anonymity set size and, while verification complexity is linear, collections of proofs can be efficiently verified in batches. We show that for anonymity set sizes practical for use in distributed protocols, Triptych offers competitive performance with a straightforward construction.
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:
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, 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:
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"
file: "https://masteringmonero.com/free-download.html"
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:
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
pruning: Pruning
remote-node: Remote Node
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:
notags: Bu etiket için gönderi yok.
{% assign version = '2.3.0' | split: '.' %}
{% include disclaimer.html translated="false" version=page.version %}
## Introduction
This is a list of the monerod daemon RPC calls, their inputs and outputs, and examples of each.
Many RPC calls use the daemon's JSON RPC interface while others use their own interfaces, as demonstrated below.
Note: "@atomic-units" refer to the smallest fraction of 1 XMR according to the monerod implementation. **1 XMR = 1e12 @atomic-units.**
Note2: Guide updated as of network height of 1,562,465.
### [JSON RPC Methods](#json-rpc-methods):
* [get_block_count](#get_block_count)
* [on_get_block_hash](#on_get_block_hash)
* [get_block_template](#get_block_template)
* [submit_block](#submit_block)
* [get_last_block_header](#get_last_block_header)
* [get_block_header_by_hash](#get_block_header_by_hash)
* [get_block_header_by_height](#get_block_header_by_height)
* [get_block_headers_range](#get_block_headers_range)
* [get_block](#get_block)
* [get_connections](#get_connections)
* [get_info](#get_info)
* [hard_fork_info](#hard_fork_info)
* [set_bans](#set_bans)
* [get_bans](#get_bans)
* [flush_txpool](#flush_txpool)
* [get_output_histogram](#get_output_histogram)
* [get_version](#get_version)
* [get_coinbase_tx_sum](#get_coinbase_tx_sum)
* [get_fee_estimate](#get_fee_estimate)
* [get_alternate_chains](#get_alternate_chains)
* [relay_tx](#relay_tx)
* [sync_info](#sync_info)
* [get_txpool_backlog](#get_txpool_backlog)
* [get_output_distribution](#get_output_distribution)
### [Other RPC Methods](#other-daemon-rpc-calls):
* [/get_height](#get_height)
* [/get_blocks.bin](#get_blocksbin)
* [/get_blocks_by_height.bin](#get_blocks_by_heightbin)
* [/get_hashes.bin](#get_hashesbin)
* [/get_o_indexes.bin](#get_o_indexesbin)
* [/get_outs.bin](#get_outsbin)
* [/get_transactions](#get_transactions)
* [/get_alt_blocks_hashes](#get_alt_blocks_hashes)
* [/is_key_image_spent](#is_key_image_spent)
* [/send_raw_transaction](#send_raw_transaction)
* [/start_mining](#start_mining)
* [/stop_mining](#stop_mining)
* [/mining_status](#mining_status)
* [/save_bc](#save_bc)
* [/get_peer_list](#get_peer_list)
* [/set_log_hash_rate](#set_log_hash_rate)
* [/set_log_level](#set_log_level)
* [/set_log_categories](#set_log_categories)
* [/get_transaction_pool](#get_transaction_pool)
* [/get_transaction_pool_hashes.bin](#get_transaction_pool_hashesbin)
* [/get_transaction_pool_stats](#get_transaction_pool_stats)
* [/stop_daemon](#stop_daemon)
* [/get_info (not JSON)](#get_info-not-json)
* [/get_limit](#get_limit)
* [/set_limit](#set_limit)
* [/out_peers](#out_peers)
* [/in_peers](#in_peers)
* [/start_save_graph](#start_save_graph)
* [/stop_save_graph](#stop_save_graph)
* [/get_outs](#get_outs)
* [/update](#update)
---
## JSON RPC Methods
The majority of monerod RPC calls use the daemon's `json_rpc` interface to request various bits of information. These methods all follow a similar structure, for example:
```
IP=127.0.0.1
PORT=18081
METHOD='get_block_header_by_height'
ALIAS='getblockheaderbyheight'
PARAMS='{"height":912345}'
curl \
-X POST http://$IP:$PORT/json_rpc \
-d '{"jsonrpc":"2.0","id":"0","method":"'$METHOD'","params":'$PARAMS'}' \
-H 'Content-Type: application/json'
```
Some methods include parameters, while others do not. Examples of each JSON RPC method follow.
### **get_block_count**
Look up how many blocks are in the longest chain known to the node.
Alias: *getblockcount*.
Inputs: *None*.
Outputs:
* *count* - unsigned int; Number of blocks in longest chain seen by the node.
* *status* - string; General RPC error code. "OK" means everything looks good.
Example:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_block_count"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"count": 993163,
"status": "OK"
}
}
```
### **on_get_block_hash**
Look up a block's hash by its height.
Alias: *on_getblockhash*.
Inputs:
* block height (int array of length 1)
Outputs:
* block hash (string)
Example:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"on_get_block_hash","params":[912345]}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": "e22cf75f39ae720e8b71b3d120a5ac03f0db50bba6379e2850975b4859190bc6"
}
```
### **get_block_template**
Get a block template on which mining a new block.
Alias: *getblocktemplate*.
Inputs:
* *wallet_address* - string; Address of wallet to receive coinbase transactions if block is successfully mined.
* *reserve_size* - unsigned int; Reserve size.
Outputs:
* *blocktemplate_blob* - string; Blob on which to try to mine a new block.
* *blockhashing_blob* - string; Blob on which to try to find a valid nonce.
* *difficulty* - unsigned int; Difficulty of next block.
* *expected_reward* - unsigned int; Coinbase reward expected to be received if block is successfully mined.
* *height* - unsigned int; Height on which to mine.
* *prev_hash* - string; Hash of the most recent block on which to mine the next block.
* *reserved_offset* - unsigned int; Reserved offset.
* *status* - string; General RPC error code. "OK" means everything looks good.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
Example:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_block_template","params":{"wallet_address":"44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns","reserve_size":60}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"blockhashing_blob": "070786a498d705f8dc58791266179087907a2ff4cd883615216749b97d2f12173171c725a6f84a00000000fc751ea4a94c2f840751eaa36138eee66dda15ef554e7d6594395827994e31da10",
"blocktemplate_blob": "070786a498d705f8dc58791266179087907a2ff4cd883615216749b97d2f12173171c725a6f84a0000000002aeab5f01fff2aa5f01e0a9d0f2f08a01028fdb3d5b5a2c363d36ea17a4add99a23a3ec7935b4c3e1e0364fcc4295c7a2ef5f01f912b15f5d17c1539d4722f79d8856d8654c5af87f54cfb3a4ff7f6b512b2a08023c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f1755090c809421d69873c161e7969b8bf33cee3b451dd4859bfc244a705f0b4900498f804b6023e13fa023a0fb759e8b7c9a39506a21442bc47077beeedc6b78d34c4ebdae91bd96097ccc9a882bc5056568b0d2f1f06559368fea4acba8e745444e883e53156d5083c1fd260edf05292934c8b40c098b81fe4e261720bdd272b209e317247a1d2c55dc4718891af0d16273c5a610f36f382a3bf50f54808aaa6a508e51d4601dd0d8fbf8b3b1685066ce121666a1409e8ac7a4d673c1cc36d10b825f764af647441f53230518e4d2efbcf8791c6060912c76e90db4982a66d51bbd96290bbb34db8080b216c2940cec407260bf5e2c3a5ee280835f15298f0801e9d98c4d414792282fbc2c28c3e20bc0fcb1829b5c3ad8f8d20847be8fdb2a949fd96f0205fbd6d271c880c5d8c83e9813606cd803a44d377fdeae45bfa67112132af601e9b3b0613ba7dff2ec3d4b935c447b47bfe39f7b950981b2f4c66c0d853e2218f1f69229a9b608c3d98be09b6d4d640a9f6ff0e920dbacf7e58b59554c0b398b1ae4b1d497104b4e4e745d850eed7eddb8aa93437427bf442ae5beb22cbf10a8fa738ea38cfa5d86dfd30675d4be11a38016e36936fd5601e52643e8b8bc433702ea7ae6149309c95b898cc854850e73fe0b95c5b8879b7325ecd4",
"difficulty": 61043624293,
"expected_reward": 4771949057248,
"height": 1561970,
"prev_hash": "f8dc58791266179087907a2ff4cd883615216749b97d2f12173171c725a6f84a",
"reserved_offset": 129,
"status": "OK",
"untrusted": false
}
}
```
### **submit_block**
Submit a mined block to the network.
Alias: *submitblock*.
Inputs:
* Block blob data - array of strings; list of block blobs which have been mined. See [get_block_template](#get_block_template) to get a blob on which to mine.
Outputs:
* *status* - string; Block submit status.
In this example, a block blob which has not been mined is submitted:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"submit_block","params":["0707e6bdfedc053771512f1bc27c62731ae9e8f2443db64ce742f4e57f5cf8d393de28551e441a0000000002fb830a01ffbf830a018cfe88bee283060274c0aae2ef5730e680308d9c00b6da59187ad0352efe3c71d36eeeb28782f29f2501bd56b952c3ddc3e350c2631d3a5086cac172c56893831228b17de296ff4669de020200000000"]' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"error": {
"code": -7,
"message": "Block not accepted"
}
}
```
### **get_last_block_header**
Block header information for the most recent block is easily retrieved with this method. No inputs are needed.
Alias: *getlastblockheader*.
Inputs: *None*.
Outputs:
* *block_header* - A structure containing block header information.
* *block_size* - unsigned int; The block size in bytes.
* *depth* - unsigned int; The number of blocks succeeding this block on the blockchain. A larger number means an older block.
* *difficulty* - unsigned int; The strength of the Monero network based on mining power.
* *hash* - string; The hash of this block.
* *height* - unsigned int; The number of blocks preceding this block on the blockchain.
* *major_version* - unsigned int; The major version of the monero protocol at this block height.
* *minor_version* - unsigned int; The minor version of the monero protocol at this block height.
* *nonce* - unsigned int; a cryptographic random one-time number used in mining a Monero block.
* *num_txes* - unsigned int; Number of transactions in the block, not counting the coinbase tx.
* *orphan_status* - boolean; Usually `false`. If `true`, this block is not part of the longest chain.
* *prev_hash* - string; The hash of the block immediately preceding this block in the chain.
* *reward* - unsigned int; The amount of new @atomic-units generated in this block and rewarded to the miner. Note: 1 XMR = 1e12 @atomic-units.
* *timestamp* - unsigned int; The unix time at which the block was recorded into the blockchain.
* *status* - string; General RPC error code. "OK" means everything looks good.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
In this example, the most recent block (1562023 at the time) is returned:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_last_block_header"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"block_header": {
"block_size": 62774,
"depth": 0,
"difficulty": 60097900840,
"hash": "3a289b8fa88b10e2163826c230b45d79f2be37d14fa3153ee58ff8a427782d14",
"height": 1562023,
"major_version": 7,
"minor_version": 7,
"nonce": 3789681204,
"num_txes": 5,
"orphan_status": false,
"prev_hash": "743e5d0a26849efe27b96086f2c4ecc39a0bc744bf21473dad6710221aff6ac3",
"reward": 4724029079703,
"timestamp": 1525029411
},
"status": "OK",
"untrusted": false
}
}
```
### **get_block_header_by_hash**
Block header information can be retrieved using either a block's hash or height. This method includes a block's hash as an input parameter to retrieve basic information about the block.
Alias: *getblockheaderbyhash*.
Inputs:
* *hash* - string; The block's sha256 hash.
Outputs:
* *block_header* - A structure containing block header information. See [get_last_block_header](#get_last_block_header).
* *status* - string; General RPC error code. "OK" means everything looks good.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
In this example, block 912345 is looked up by its hash:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_block_header_by_hash","params":{"hash":"e22cf75f39ae720e8b71b3d120a5ac03f0db50bba6379e2850975b4859190bc6"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"block_header": {
"block_size": 210,
"depth": 649717,
"difficulty": 815625611,
"hash": "e22cf75f39ae720e8b71b3d120a5ac03f0db50bba6379e2850975b4859190bc6",
"height": 912345,
"major_version": 1,
"minor_version": 2,
"nonce": 1646,
"num_txes": 0,
"orphan_status": false,
"prev_hash": "b61c58b2e0be53fad5ef9d9731a55e8a81d972b8d90ed07c04fd37ca6403ff78",
"reward": 7388968946286,
"timestamp": 1452793716
},
"status": "OK",
"untrusted": false
}
}
```
### **get_block_header_by_height**
Similar to [get_block_header_by_hash](#get_block_header_by_hash) above, this method includes a block's height as an input parameter to retrieve basic information about the block.
Alias: *getblockheaderbyheight*.
Inputs:
* *height* - unsigned int; The block's height.
Outputs:
* *block_header* - A structure containing block header information. See [get_last_block_header](#get_last_block_header).
* *status* - string; General RPC error code. "OK" means everything looks good.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
In this example, block 912345 is looked up by its height (notice that the returned information is the same as in the previous example):
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_block_header_by_height","params":{"height":912345}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"block_header": {
"block_size": 210,
"depth": 649721,
"difficulty": 815625611,
"hash": "e22cf75f39ae720e8b71b3d120a5ac03f0db50bba6379e2850975b4859190bc6",
"height": 912345,
"major_version": 1,
"minor_version": 2,
"nonce": 1646,
"num_txes": 0,
"orphan_status": false,
"prev_hash": "b61c58b2e0be53fad5ef9d9731a55e8a81d972b8d90ed07c04fd37ca6403ff78",
"reward": 7388968946286,
"timestamp": 1452793716
},
"status": "OK",
"untrusted": false
}
}
```
### **get_block_headers_range**
Similar to [get_block_header_by_height](#get_block_header_by_height) above, but for a range of blocks. This method includes a starting block height and an ending block height as parameters to retrieve basic information about the range of blocks.
Alias: *getblockheadersrange*.
Inputs:
* *start_height* - unsigned int; The starting block's height.
* *end_height* - unsigned int; The ending block's height.
Outputs:
* *headers* - array of `block_header` (a structure containing block header information. See [get_last_block_header](#get_last_block_header)).
* *status* - string; General RPC error code. "OK" means everything looks good.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
In this example, blocks range from height 1545999 to 1546000 is looked up (notice that the returned informations are ascending order and that it is at the April 2018 network upgrade time):
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_block_headers_range","params":{"start_height":1545999,"end_height":1546000}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"headers": [{
"block_size": 301413,
"depth": 16085,
"difficulty": 134636057921,
"hash": "86d1d20a40cefcf3dd410ff6967e0491613b77bf73ea8f1bf2e335cf9cf7d57a",
"height": 1545999,
"major_version": 6,
"minor_version": 6,
"nonce": 3246403956,
"num_txes": 20,
"orphan_status": false,
"prev_hash": "0ef6e948f77b8f8806621003f5de24b1bcbea150bc0e376835aea099674a5db5",
"reward": 5025593029981,
"timestamp": 1523002893
},{
"block_size": 13322,
"depth": 16084,
"difficulty": 134716086238,
"hash": "b408bf4cfcd7de13e7e370c84b8314c85b24f0ba4093ca1d6eeb30b35e34e91a",
"height": 1546000,
"major_version": 7,
"minor_version": 7,
"nonce": 3737164176,
"num_txes": 1,
"orphan_status": false,
"prev_hash": "86d1d20a40cefcf3dd410ff6967e0491613b77bf73ea8f1bf2e335cf9cf7d57a",
"reward": 4851952181070,
"timestamp": 1523002931
}],
"status": "OK",
"untrusted": false
}
}
```
### **get_block**
Full block information can be retrieved by either block height or hash, like with the above block header calls. For full block information, both lookups use the same method, but with different input parameters.
Alias: *getblock*.
Inputs (pick one of the following):
* *height* - unsigned int; The block's height.
* *hash* - string; The block's hash.
Outputs:
* *blob* - string; Hexadecimal blob of block information.
* *block_header* - A structure containing block header information. See [get_last_block_header](#get_last_block_header).
* *json* - json string; JSON formatted block details:
* *major_version* - Same as in block header.
* *minor_version* - Same as in block header.
* *timestamp* - Same as in block header.
* *prev_id* - Same as `prev_hash` in block header.
* *nonce* - Same as in block header.
* *miner_tx* - Miner transaction information
* *version* - Transaction version number.
* *unlock_time* - The block height when the coinbase transaction becomes spendable.
* *vin* - List of transaction inputs:
* *gen* - Miner txs are coinbase txs, or "gen".
* *height* - This block height, a.k.a. when the coinbase is generated.
* *vout* - List of transaction outputs. Each output contains:
* *amount* - The amount of the output, in @atomic-units.
* *target* -
* *key* -
* *extra* - Usually called the "transaction ID" but can be used to include any random 32 byte/64 character hex string.
* *signatures* - Contain signatures of tx signers. Coinbased txs do not have signatures.
* *tx_hashes* - List of hashes of non-coinbase transactions in the block. If there are no other transactions, this will be an empty list.
* *status* - string; General RPC error code. "OK" means everything looks good.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
**Look up by height:**
In the following example, block 912345 is looked up by its height. Note that block 912345 does not have any non-coinbase transactions. (See the next example for a block with extra transactions):
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_block","params":{"height":912345}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"blob": "0102f4bedfb405b61c58b2e0be53fad5ef9d9731a55e8a81d972b8d90ed07c04fd37ca6403ff786e0600000195d83701ffd9d73704ee84ddb42102378b043c1724c92c69d923d266fe86477d3a5ddd21145062e148c64c5767700880c0fc82aa020273733cbd6e6218bda671596462a4b062f95cfe5e1dbb5b990dacb30e827d02f280f092cbdd080247a5dab669770da69a860acde21616a119818e1a489bb3c4b1b6b3c50547bc0c80e08d84ddcb01021f7e4762b8b755e3e3c72b8610cc87b9bc25d1f0a87c0c816ebb952e4f8aff3d2b01fd0a778957f4f3103a838afda488c3cdadf2697b3d34ad71234282b2fad9100e02080000000bdfc2c16c00",
"block_header": {
"block_size": 210,
"depth": 649772,
"difficulty": 815625611,
"hash": "e22cf75f39ae720e8b71b3d120a5ac03f0db50bba6379e2850975b4859190bc6",
"height": 912345,
"major_version": 1,
"minor_version": 2,
"nonce": 1646,
"num_txes": 0,
"orphan_status": false,
"prev_hash": "b61c58b2e0be53fad5ef9d9731a55e8a81d972b8d90ed07c04fd37ca6403ff78",
"reward": 7388968946286,
"timestamp": 1452793716
},
"json": "{\n \"major_version\": 1, \n \"minor_version\": 2, \n \"timestamp\": 1452793716, \n \"prev_id\": \"b61c58b2e0be53fad5ef9d9731a55e8a81d972b8d90ed07c04fd37ca6403ff78\", \n \"nonce\": 1646, \n \"miner_tx\": {\n \"version\": 1, \n \"unlock_time\": 912405, \n \"vin\": [ {\n \"gen\": {\n \"height\": 912345\n }\n }\n ], \n \"vout\": [ {\n \"amount\": 8968946286, \n \"target\": {\n \"key\": \"378b043c1724c92c69d923d266fe86477d3a5ddd21145062e148c64c57677008\"\n }\n }, {\n \"amount\": 80000000000, \n \"target\": {\n \"key\": \"73733cbd6e6218bda671596462a4b062f95cfe5e1dbb5b990dacb30e827d02f2\"\n }\n }, {\n \"amount\": 300000000000, \n \"target\": {\n \"key\": \"47a5dab669770da69a860acde21616a119818e1a489bb3c4b1b6b3c50547bc0c\"\n }\n }, {\n \"amount\": 7000000000000, \n \"target\": {\n \"key\": \"1f7e4762b8b755e3e3c72b8610cc87b9bc25d1f0a87c0c816ebb952e4f8aff3d\"\n }\n }\n ], \n \"extra\": [ 1, 253, 10, 119, 137, 87, 244, 243, 16, 58, 131, 138, 253, 164, 136, 195, 205, 173, 242, 105, 123, 61, 52, 173, 113, 35, 66, 130, 178, 250, 217, 16, 14, 2, 8, 0, 0, 0, 11, 223, 194, 193, 108\n ], \n \"signatures\": [ ]\n }, \n \"tx_hashes\": [ ]\n}",
"miner_tx_hash": "c7da3965f25c19b8eb7dd8db48dcd4e7c885e2491db77e289f0609bf8e08ec30",
"status": "OK",
"untrusted": false
}
}
```
**Look up by hash:**
In the following example, block 993056 is looked up by its hash. Note that block 993056 has 3 non-coinbase transactions:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_block","params":{"hash":"510ee3c4e14330a7b96e883c323a60ebd1b5556ac1262d0bc03c24a3b785516f"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"blob": "0102a3978cb7050ea4af6547c05c965afc8df6d31509ff3105dc7ae6b10172521d77e09711fd6df407000001dcce3c01ffa0ce3c049da8bece070259e9d685b3484886bc7b47c133e6099ecdf212d5eaa16ce19cd58e8c3c1e590a80d88ee16f024c5e2f542d25513c46b9e3b7d40140a22d0ae5314bfcae492ad9f56fff8185f080d0b8e1981a0213dd8ffdac9e6a2f71e327dad65328198dc879a492d145eae72677c0703a351580c0f9decfae010262bda00341681dccbc066757862da593734395745bdfe1fdc89b5948c86a5d4c2b01b691851cf057b9c302a3dbca879e1cba4cc45061ca55aaa6e03cdc67ab9e455002080000000c617fdf160379c6b9f00db027bde151705aafe85c495883aae2597d5cb8e1adb2e0f3ae1d07d715db73331abc3ec588ef07c7bb195786a4724b08dff431b51ffa32a4ce899bb197066426c0ed89f0b431fe171f7fd62bc95dd29943daa7cf3585cf1fdfc99d",
"block_header": {
"block_size": 3981,
"depth": 569068,
"difficulty": 964985344,
"hash": "510ee3c4e14330a7b96e883c323a60ebd1b5556ac1262d0bc03c24a3b785516f",
"height": 993056,
"major_version": 1,
"minor_version": 2,
"nonce": 2036,
"num_txes": 3,
"orphan_status": false,
"prev_hash": "0ea4af6547c05c965afc8df6d31509ff3105dc7ae6b10172521d77e09711fd6d",
"reward": 6932043647005,
"timestamp": 1457720227
},
"json": "{\n \"major_version\": 1, \n \"minor_version\": 2, \n \"timestamp\": 1457720227, \n \"prev_id\": \"0ea4af6547c05c965afc8df6d31509ff3105dc7ae6b10172521d77e09711fd6d\", \n \"nonce\": 2036, \n \"miner_tx\": {\n \"version\": 1, \n \"unlock_time\": 993116, \n \"vin\": [ {\n \"gen\": {\n \"height\": 993056\n }\n }\n ], \n \"vout\": [ {\n \"amount\": 2043647005, \n \"target\": {\n \"key\": \"59e9d685b3484886bc7b47c133e6099ecdf212d5eaa16ce19cd58e8c3c1e590a\"\n }\n }, {\n \"amount\": 30000000000, \n \"target\": {\n \"key\": \"4c5e2f542d25513c46b9e3b7d40140a22d0ae5314bfcae492ad9f56fff8185f0\"\n }\n }, {\n \"amount\": 900000000000, \n \"target\": {\n \"key\": \"13dd8ffdac9e6a2f71e327dad65328198dc879a492d145eae72677c0703a3515\"\n }\n }, {\n \"amount\": 6000000000000, \n \"target\": {\n \"key\": \"62bda00341681dccbc066757862da593734395745bdfe1fdc89b5948c86a5d4c\"\n }\n }\n ], \n \"extra\": [ 1, 182, 145, 133, 28, 240, 87, 185, 195, 2, 163, 219, 202, 135, 158, 28, 186, 76, 196, 80, 97, 202, 85, 170, 166, 224, 60, 220, 103, 171, 158, 69, 80, 2, 8, 0, 0, 0, 12, 97, 127, 223, 22\n ], \n \"signatures\": [ ]\n }, \n \"tx_hashes\": [ \"79c6b9f00db027bde151705aafe85c495883aae2597d5cb8e1adb2e0f3ae1d07\", \"d715db73331abc3ec588ef07c7bb195786a4724b08dff431b51ffa32a4ce899b\", \"b197066426c0ed89f0b431fe171f7fd62bc95dd29943daa7cf3585cf1fdfc99d\"\n ]\n}",
"miner_tx_hash": "372395aeac5e5ad2c40b4c546b0bad00c4242fb2bd88e2e25f4e43231876f81e",
"status": "OK",
"tx_hashes": ["79c6b9f00db027bde151705aafe85c495883aae2597d5cb8e1adb2e0f3ae1d07","d715db73331abc3ec588ef07c7bb195786a4724b08dff431b51ffa32a4ce899b","b197066426c0ed89f0b431fe171f7fd62bc95dd29943daa7cf3585cf1fdfc99d"],
"untrusted": false
}
}
```
### **get_connections**
Retrieve information about incoming and outgoing connections to your node.
Alias: *None*.
Inputs: *None*.
Outputs:
* *connections* - List of all connections and their info:
* *address* - string; The peer's address, actually IPv4 & port
* *avg_download* - unsigned int; Average bytes of data downloaded by node.
* *avg_upload* - unsigned int; Average bytes of data uploaded by node.
* *connection_id* - string; The connection ID
* *current_download* - unsigned int; Current bytes downloaded by node.
* *current_upload* - unsigned int; Current bytes uploaded by node.
* *height*- unsigned int; The peer height
* *host* - string; The peer host
* *incoming* - boolean; Is the node getting information from your node?
* *ip* - string; The node's IP address.
* *live_time* - unsigned int
* *local_ip* - boolean
* *localhost* - boolean
* *peer_id* - string; The node's ID on the network.
* *port* - string; The port that the node is using to connect to the network.
* *recv_count* - unsigned int
* *recv_idle_time* - unsigned int
* *send_count* - unsigned int
* *send_idle_time* - unsigned int
* *state* - string
* *support_flags* - unsigned int
Following is an example of `get_connections` and it's return:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_connections"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"connections": [{
"address": "173.90.69.136:62950",
"avg_download": 0,
"avg_upload": 2,
"connection_id": "083c301a3030329a487adb12ad981d2c",
"current_download": 0,
"current_upload": 2,
"height": 1562127,
"host": "173.90.69.136",
"incoming": true,
"ip": "173.90.69.136",
"live_time": 8,
"local_ip": false,
"localhost": false,
"peer_id": "c959fbfbed9e44fb",
"port": "62950",
"recv_count": 259,
"recv_idle_time": 8,
"send_count": 24342,
"send_idle_time": 8,
"state": "state_normal",
"support_flags": 0
},{
...
}],
"status": "OK"
}
}
```
### **get_info**
Retrieve general information about the state of your node and the network.
Alias:
* */get_info*
* */getinfo*
See other RPC Methods [/get_info (not JSON)](#get_info-not-json)
Inputs: *None*.
Outputs:
* *alt_blocks_count* - unsigned int; Number of alternative blocks to main chain.
* *block_size_limit* - unsigned int; Maximum allowed block size
* *block_size_median* - unsigned int; Median block size of latest 100 blocks
* *bootstrap_daemon_address* - string; @Bootstrap-node to give immediate usability to wallets while syncing by proxying RPC to it. (Note: the replies may be untrustworthy).
* *cumulative_difficulty* - unsigned int; Cumulative difficulty of all blocks in the blockchain.
* *difficulty* - unsigned int; Network difficulty (analogous to the strength of the network)
* *free_space* - unsigned int; Available disk space on the node.
* *grey_peerlist_size* - unsigned int; Grey Peerlist Size
* *height* - unsigned int; Current length of longest chain known to daemon.
* *height_without_bootstrap* - unsigned int; Current length of the local chain of the daemon.
* *incoming_connections_count* - unsigned int; Number of peers connected to and pulling from your node.
* *mainnet* - boolean; States if the node is on the mainnet (`true`) or not (`false`).
* *offline* - boolean; States if the node is offline (`true`) or online (`false`).
* *outgoing_connections_count* - unsigned int; Number of peers that you are connected to and getting information from.
* *rpc_connections_count* - unsigned int; Number of RPC client connected to the daemon (Including this RPC request).
* *stagenet* - boolean; States if the node is on the stagenet (`true`) or not (`false`).
* *start_time* - unsigned int; Start time of the daemon, as UNIX time.
* *status* - string; General RPC error code. "OK" means everything looks good.
* *target* - unsigned int; Current target for next proof of work.
* *target_height* - unsigned int; The height of the next block in the chain.
* *testnet* - boolean; States if the node is on the testnet (`true`) or not (`false`).
* *top_block_hash* - string; Hash of the highest block in the chain.
* *tx_count* - unsigned int; Total number of non-coinbase transaction in the chain.
* *tx_pool_size* - unsigned int; Number of transactions that have been broadcast but not included in a block.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
* *was_bootstrap_ever_used* - boolean; States if a bootstrap node has ever been used since the daemon started.
* *white_peerlist_size* - unsigned int; White Peerlist Size
Following is an example `get_info` call and its return:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_info"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"alt_blocks_count": 6,
"block_size_limit": 600000,
"block_size_median": 129017,
"bootstrap_daemon_address": "",
"cumulative_difficulty": 14121125493385685,
"difficulty": 60580751777,
"free_space": 138758750208,
"grey_peerlist_size": 4998,
"height": 1562168,
"height_without_bootstrap": 1562168,
"incoming_connections_count": 2,
"mainnet": true,
"offline": false,
"outgoing_connections_count": 8,
"rpc_connections_count": 2,
"stagenet": false,
"start_time": 1524751757,
"status": "OK",
"target": 120,
"target_height": 1562063,
"testnet": false,
"top_block_hash": "7a7ba647080844073fdd8e3a069e00554c773d6e6863354dba1dec45a43f5592",
"tx_count": 2759894,
"tx_pool_size": 755,
"untrusted": false,
"was_bootstrap_ever_used": false,
"white_peerlist_size": 1000
}
}
```
### **hard_fork_info**
Look up information regarding hard fork voting and readiness.
Alias: *None*.
Inputs: *None*.
Outputs:
* *earliest_height* - unsigned int; Block height at which hard fork would be enabled if voted in.
* *enabled* - boolean; Tells if hard fork is enforced.
* *state* - unsigned int; Current hard fork state: 0 (There is likely a hard fork), 1 (An update is needed to fork properly), or 2 (Everything looks good).
* *status* - string; General RPC error code. "OK" means everything looks good.
* *threshold* - unsigned int; Minimum percent of votes to trigger hard fork. Default is 80.
* *version* - unsigned int; The major block version for the fork.
* *votes* - unsigned int; Number of votes towards hard fork.
* *voting* - unsigned int; Hard fork voting status.
* *window* - unsigned int; Number of blocks over which current votes are cast. Default is 10080 blocks.
Example:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"hard_fork_info"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"earliest_height": 1009827,
"enabled": false,
"state": 2,
"status": "OK",
"threshold": 0,
"version": 1,
"votes": 7277,
"voting": 2,
"window": 10080
}
}
```
### **set_bans**
Ban another node by IP.
Alias: *None*.
Inputs:
* *bans* - A list of nodes to ban:
* *host* - string; Host to ban (IP in A.B.C.D form - will support I2P address in the future).
* *ip* - unsigned int; IP address to ban, in Int format.
* *ban* - boolean; Set `true` to ban.
* *seconds* - unsigned int; Number of seconds to ban node.
Outputs:
* *status* - string; General RPC error code. "OK" means everything looks good.
Examples:
**banning by host**
In the following example, host is banned with its IP address string-formatted as A.B.C.D:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"set_bans","params":{"bans":[{"host":"192.168.1.51","ban":true,"seconds":30}]}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"status": "OK"
}
}
```
**banning by ip**
In the following example, integer-formatted IP is banned:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"set_bans","params":{"bans":[{"ip":838969536,"ban":true,"seconds":30}]}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"status": "OK"
}
}
```
### **get_bans**
Get list of banned IPs.
Alias: *None*.
Inputs: *None*.
Outputs:
* *bans* - List of banned nodes:
* *host* - string; Banned host (IP in A.B.C.D form).
* *ip* - unsigned int; Banned IP address, in Int format.
* *seconds* - unsigned int; Local Unix time that IP is banned until.
* *status* - string; General RPC error code. "OK" means everything looks good.
Example:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_bans"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"bans": [{
"host": "102.168.1.51",
"ip": 855746662,
"seconds": 22
},{
"host": "192.168.1.50",
"ip": 838969536,
"seconds": 28
}],
"status": "OK"
}
}
```
### **flush_txpool**
Flush tx ids from transaction pool
Alias: *None*.
Inputs:
* *txids* - array of strings; Optional, list of transactions IDs to flush from pool (all tx ids flushed if empty).
Outputs:
* *status* - string; General RPC error code. "OK" means everything looks good.
Example:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"flush_txpool","params":{"txids":["dc16fa8eaffe1484ca9014ea050e13131d3acf23b419f33bb4cc0b32b6c49308",""]}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"status": "OK"
}
}
```
### **get_output_histogram**
Get a histogram of output amounts. For all amounts (possibly filtered by parameters), gives the number of outputs on the chain for that amount.
RingCT outputs counts as 0 amount.
Inputs:
* *amounts* - list of unsigned int
* *min_count* - unsigned int
* *max_count* - unsigned int
* *unlocked* - boolean
* *recent_cutoff* - unsigned int
Outputs:
* *histogram* - list of histogram entries, in the following structure:
* *amount* - unsigned int; Output amount in @atomic-units
* *total_instances* - unsigned int;
* *unlocked_instances* - unsigned int;
* *recent_instances* - unsigned int;
* *status* - string; General RPC error code. "OK" means everything looks good.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
Example:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_output_histogram","params":{"amounts":[20000000000]}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"histogram": [{
"amount": 20000000000,
"recent_instances": 0,
"total_instances": 381458,
"unlocked_instances": 0
}],
"status": "OK",
"untrusted": false
}
}
```
### **get_coinbase_tx_sum**
Get the coinbase amount and the fees amount for n last blocks starting at particular height
Alias: *None*.
Inputs:
* *height* - unsigned int; Block height from which getting the amounts
* *count* - unsigned int; number of blocks to include in the sum
Outputs:
* *emission_amount* - unsigned int; amount of coinbase reward in @atomic-units
* *fee_amount* - unsigned int; amount of fees in @atomic-units
* *status* - string; General RPC error code. "OK" means everything looks good.
Example:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_coinbase_tx_sum","params":{"height":1563078,"count":2}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"emission_amount": 9387854817320,
"fee_amount": 83981380000,
"status": "OK"
}
}
```
### **get_version**
Give the node current version
Alias: *None*.
Inputs: *None*.
Outputs:
* *status* - string; General RPC error code. "OK" means everything looks good.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
* *version* - unsigned int;
Example:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_version"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"status": "OK",
"untrusted": false,
"version": 65555
}
}
```
### **get_fee_estimate**
Gives an estimation on fees per byte.
Alias: *None*.
Inputs:
* *grace_blocks* - unsigned int; Optional
Outputs:
* *fee* - unsigned int; Amount of fees estimated per byte in @atomic-units
* *quantization_mask* - unsigned int; Final fee should be rounded up to an even multiple of this value
* *status* - string; General RPC error code. "OK" means everything looks good.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
Example:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_fee_estimate"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"fee": 187610000,
"status": "OK",
"untrusted": false
}
}
```
### **get_alternate_chains**
Display alternative chains seen by the node.
Alias: *None*.
Inputs: *None*.
Outputs:
* *chains* - array of chains, the following structure:
* *block_hash* - string; the block hash of the first diverging block of this alternative chain.
* *difficulty* - unsigned int; the cumulative difficulty of all blocks in the alternative chain.
* *height* - unsigned int; the block height of the first diverging block of this alternative chain.
* *length* - unsigned int; the length in blocks of this alternative chain, after divergence.
* *status* - string; General RPC error code. "OK" means everything looks good.
Example:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_alternate_chains"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"chains": [{
"block_hash": "697cf03c89a9b118f7bdf11b1b3a6a028d7b3617d2d0ed91322c5709acf75625",
"difficulty": 14114729638300280,
"height": 1562062,
"length": 2
}],
"status": "OK"
}
}
```
### **relay_tx**
Relay a list of transaction IDs.
Alias: *None*.
Inputs:
* *txids* - array of string; list of transaction IDs to relay
Outputs:
* *status* - string; General RPC error code. "OK" means everything looks good.
Example:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"relay_tx","params":{"txids":["9fd75c429cbe52da9a52f2ffc5fbd107fe7fd2099c0d8de274dc8a67e0c98613"]}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"status": "OK"
}
}
```
### **sync_info**
Get synchronisation informations
Alias: *None*.
Inputs: *None*.
Outputs:
* *height* - unsigned int;
* *peers* - array of peer structure, defined as follows:
* *info* - structure of connection info, as defined in [get_connections](#get_connections)
* *spans* - array of span structure, defined as follows (optional, absent if node is fully synced):
* *connection_id* - string; Id of connection
* *nblocks* - unsigned int; number of blocks in that span
* *rate* - unsigned int; connection rate
* *remote_address* - string; peer address the node is downloading (or has downloaded) than span from
* *size* - unsigned int; total number of bytes in that span's blocks (including txes)
* *speed* - unsigned int; connection speed
* *start_block_height* - unsigned int; block height of the first block in that span
* *status* - string; General RPC error code. "OK" means everything looks good.
* *target_height* - unsigned int; target height the node is syncing from (optional, absent if node is fully synced)
Example:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"sync_info"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"height": 1563543,
"peers": [{
"info": {
"address": "70.109.53.128:60064",
"avg_download": 0,
"avg_upload": 5,
"connection_id": "204067223b9b3415c265dd25ad29ee48",
"current_download": 0,
"current_upload": 1,
"height": 1559975,
"host": "70.109.53.128",
"incoming": true,
"ip": "70.109.53.128",
"live_time": 38,
"local_ip": false,
"localhost": false,
"peer_id": "96b8545dbc7a8866",
"port": "60064",
"recv_count": 1580,
"recv_idle_time": 28,
"send_count": 203603,
"send_idle_time": 8,
"state": "state_normal",
"support_flags": 1
}
},{
"info": {
...
}
},{
...
},{
...
},{
...
}],
"status": "OK",
"target_height": 1564067
}
}
```
### **get_txpool_backlog**
Get all transaction pool backlog
Alias: *None*.
Inputs: *None*.
Outputs:
* *backlog*: array of structures *tx_backlog_entry* (in binary form):
* *blob_size* - unsigned int (in binary form)
* *fee* - unsigned int (in binary form)
* *time_in_pool* - unsigned int (in binary form)
* *status* - string; General RPC error code. "OK" means everything looks good.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
Example:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_txpool_backlog"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"backlog": "...Binary...",
"status": "OK",
"untrusted": false
}
}
```
### **get_output_distribution**
Alias: *None*.
Inputs:
* *amounts* - array of unsigned int; amounts to look for
* *cumulative* - boolean; (optional, default is `false`) States if the result should be cumulative (`true`) or not (`false`)
* *from_height* - unsigned int; (optional, default is 0) starting height to check from
* *to_height* - unsigned int; (optional, default is 0) ending height to check up to
Outputs:
* *distributions* - array of structure distribution as follows:
* *amount* - unsigned int
* *base* - unsigned int
* *distribution* - array of unsigned int
* *start_height* - unsigned int
* *status* - string; General RPC error code. "OK" means everything looks good.
Example:
```
$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_output_distribution","params":{"amounts":[628780000],"from_height":1462078}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"distributions": [{
"amount": 2628780000,
"base": 0,
"distribution": "",
"start_height": 1462078
}],
"status": "OK"
}
}
```
---
## Other Daemon RPC Calls
Not all daemon RPC calls use the JSON_RPC interface. This section gives examples of these calls.
The data structure for these calls is different than the JSON RPC calls. Whereas the JSON RPC methods were called using the `/json_rpc` extension and specifying a method, these methods are called at their own extensions. For example:
IP=127.0.0.1
PORT=18081
METHOD='gettransactions'
PARAMS='{"txs_hashes":["d6e48158472848e6687173a91ae6eebfa3e1d778e65252ee99d7515d63090408"]}'
curl \
-X POST http://$IP:$PORT/$METHOD \
-d $PARAMS \
-H 'Content-Type: application/json'
Note: It is recommended to use JSON RPC where such alternatives exist, rather than the following methods. For example, the recommended way to get a node's height is via the JSON RPC methods [get_info](#getinfo) or [get_last_block_header](#get_last_block_header), rather than [getheight](#getheight) below.
For calls that end with **.bin**, the data is exchanged in the form of binary, serialized objects, as defined in the [Core RPC Server](https://github.com/monero-project/monero/blob/master/src/rpc/core_rpc_server_commands_defs.h).
### **/get_height**
Get the node's current height.
Alias: */getheight*.
Inputs: *None*.
Outputs:
* *height* - unsigned int; Current length of longest chain known to daemon.
* *status* - string; General RPC error code. "OK" means everything looks good.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
```
$ curl -X POST http://127.0.0.1:18081/get_height -H 'Content-Type: application/json'
{
"height": 1564055,
"status": "OK",
"untrusted": false
}
```
### **/get_blocks.bin**
Get all blocks info. Binary request.
Alias: */getblocks.bin*.
Inputs:
* *block_ids* - binary array of hashes; first 10 blocks id goes sequential, next goes in pow(2,n) offset, like 2, 4, 8, 16, 32, 64 and so on, and the last one is always genesis block
* *start_height* - unsigned int
* *prune* - boolean
Outputs:
* *blocks* - array of block complete entries
* *current_height* - unsigned int
* *output_indices* - structure as follows:
* *indices* - array of tx output indices, structure as follows:
* *indices* - array of unsigned int
* *start_height* - unsigned int
* *status* - string; General RPC error code. "OK" means everything looks good.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
<!-- Cannot get this working
Example:
```
$ curl -X POST http://127.0.0.1:18081/get_blocks.bin -d '{"block_ids":["d109a406528a7b44fef8bc03e75eaabb0f919f852884b43b550b8b3be80a49e7"],"start_height":1562062}' -H 'Content-Type: application/json'
```
--->
### **/get_blocks_by_height.bin**
Get blocks by height. Binary request.
Alias: */getblocks_by_height.bin*.
Inputs:
* *heights* - array of unsigned int; list of block heights
Outputs:
* *blocks* - array of block complete entries
* *status* - string; General RPC error code. "OK" means everything looks good.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
<!-- Cannot get this working
Example:
```
$ echo -e '\x7B\x22\x68\x65\x69\x67\x68\x74\x73\x22\x3A\x5B\x31\x35\x36\x34\x32\x34\x36\x5D\x7D\x' | curl -X POST --data-binary @- http://127.0.0.1:18081/get_blocks_by_height.bin
$ echo -e '1564246' | curl -X POST --data-binary @- http://127.0.0.1:18081/get_blocks_by_height.bin
curl -X POST http://127.0.0.1:18081/get_blocks_by_height.bin --data-binary '{"heights":[1564246]}'
```
--->
### **/get_hashes.bin**
Get hashes. Binary request.
Alias: */gethashes.bin*.
Inputs:
* *block_ids* - binary array of hashes; first 10 blocks id goes sequential, next goes in pow(2,n) offset, like 2, 4, 8, 16, 32, 64 and so on, and the last one is always genesis block
* *start_height* - unsigned int
Outputs:
* *current_height* - unsigned int
* *m_block_ids* - binary array of hashes; see *block_ids* above.
* *start_height* - unsigned int
* *status* - string; General RPC error code. "OK" means everything looks good.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
<!-- Cannot get this working
Example:
```
$ curl -X POST http://127.0.0.1:18081/get_hashes.bin -d '{"block_ids":["d109a406528a7b44fef8bc03e75eaabb0f919f852884b43b550b8b3be80a49e7"],"start_height":1562062}' -H 'Content-Type: application/json'
```
--->
### **/get_o_indexes.bin**
Get global outputs of transactions. Binary request.
Alias: *None*.
Inputs:
* *txid* - binary txid
Outputs:
* *o_indexes* - array of unsigned int; List of output indexes
* *status* - string; General RPC error code. "OK" means everything looks good.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
<!-- Cannot get this working
Example:
```
$ curl -X POST http://127.0.0.1:18081/get_o_indexes.bin --data-binary '{"txid":"d6e48158472848e6687173a91ae6eebfa3e1d778e65252ee99d7515d63090408"}'
```
--->
### **/get_outs.bin**
Get outputs. Binary request.
Alias: *None*.
Inputs:
* *outputs* - array of structure *get_outputs_out* as follows:
* *amount* - unsigned int;
* *index* - unsigned int;
Outputs:
* *outs* - array of structure *outkey* as follows:
* *amount* - unsigned int;
* *height* - unsigned int; block height of the output
* *key* - the public key of the output
* *mask*
* *txid* - transaction id
* *unlocked* - boolean; States if output is locked (`false`) or not (`true`)
* *status* - string; General RPC error code. "OK" means everything looks good.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
<!-- Cannot get this working
Example:
```
$ curl -X POST http://127.0.0.1:18081/get_o_indexes.bin --data-binary '{"txid":"d6e48158472848e6687173a91ae6eebfa3e1d778e65252ee99d7515d63090408"}'
```
--->
### **/get_transactions**
Look up one or more transactions by hash.
Alias: */gettransactions*.
Inputs:
* *txs_hashes* - string list; List of transaction hashes to look up.
* *decode_as_json* - boolean; Optional (`false` by default). If set `true`, the returned transaction information will be decoded rather than binary.
* *prune* - boolean; Optional (`false` by default).
Outputs:
* *missed_tx* - array of strings. (Optional - returned if not empty) Transaction hashes that could not be found.
* *status* - General RPC error code. "OK" means everything looks good.
* *txs* - array of structure *entry* as follows:
* *as_hex* - string; Full transaction information as a hex string.
* *as_json* - json string; List of transaction info:
* *version* - Transaction version
* *unlock_time* - If not 0, this tells when a transaction output is spendable.
* *vin* - List of inputs into transaction:
* *key* - The public key of the previous output spent in this transaction.
* *amount* - The amount of the input, in @atomic-units.
* *key_offsets* - A list of integer offets to the input.
* *k_image* - The key image for the given input
* *vout* - List of outputs from transaction:
* *amount* - Amount of transaction output, in @atomic-units.
* *target* - Output destination information:
* *key* - The stealth public key of the receiver. Whoever owns the private key associated with this key controls this transaction output.
* *extra* - Usually called the "payment ID" but can be used to include any random 32 bytes.
* *signatures* - List of signatures used in ring signature to hide the true origin of the transaction.
* *block_height* - unsigned int; block height including the transaction
* *block_timestamp* - unsigned int; Unix time at chich the block has been added to the blockchain
* *double_spend_seen* - boolean; States if the transaction is a double-spend (`true`) or not (`false`)
* *in_pool* - boolean; States if the transaction is in pool (`true`) or included in a block (`false`)
* *output_indices* - array of unsigned int; transaction indexes
* *tx_hash* - string; transaction hash
* *txs_as_hex* - string; Full transaction information as a hex string (old compatibility parameter)
* *txs_as_json* - json string; (Optional - returned if set in inputs. Old compatibility parameter) List of transaction as in *as_json* above:
Example 1: Return transaction information in binary format.
```
$ curl -X POST http://127.0.0.1:18081/get_transactions -d '{"txs_hashes":["d6e48158472848e6687173a91ae6eebfa3e1d778e65252ee99d7515d63090408"]}' -H 'Content-Type: application/json'
{
"status": "OK",
"txs": [{
"as_hex": "...",
"as_json": "",
"block_height": 993442,
"block_timestamp": 1457749396,
"double_spend_seen": false,
"in_pool": false,
"output_indices": [198769,418598,176616,50345,509],
"tx_hash": "d6e48158472848e6687173a91ae6eebfa3e1d778e65252ee99d7515d63090408"
}],
"txs_as_hex": ["..."],
"untrusted": false
}
```
Example 2: Decode returned transaction information in JSON format. Note: the "vin", "vout" and "signatures" list have been truncated in the displayed return for space considerations.
```
$ curl -X POST http://127.0.0.1:18081/get_transactions -d '{"txs_hashes":["d6e48158472848e6687173a91ae6eebfa3e1d778e65252ee99d7515d63090408"],"decode_as_json":true}' -H 'Content-Type: application/json'
{
"status": "OK",
"txs": [{
"as_hex": "...",
"as_json": "{\n \"version\": 1, \n \"unlock_time\": 0, \n \"vin\": [ {\n \"key\": {\n \"amount\": 9999999999, \n \"key_offsets\": [ 691\n ], \n \"k_image\": \"6ebee1b651a8da723462b4891d471b990ddc226049a0866d3029b8e2f75b7012\"\n }\n }, {\n \"key\": {\n \"amount\": 9000000000000, \n \"key_offsets\": [ 175760\n ], \n \"k_image\": \"200bd02b70ee707441a8863c5279b4e4d9f376dc97a140b1e5bc7d72bc508069\"\n }\n }, ... \n ], \n \"vout\": [ {\n \"amount\": 60000000000, \n \"target\": {\n \"key\": \"8c792dea94dab48160e067fb681edd6247ba375281fbcfedc03cb970f3b98e2d\"\n }\n }, {\n \"amount\": 700000000000, \n \"target\": {\n \"key\": \"1ab33e69737e157d23e33274c42793be06a8711670e73fa10ecebc604f87cc71\"\n }\n }, ... \n ], \n \"extra\": [ 1, 3, 140, 109, 156, 205, 47, 148, 153, 9, 17, 93, 83, 33, 162, 110, 152, 1, 139, 70, 121, 19, 138, 10, 44, 6, 55, 140, 242, 124, 143, 219, 172\n ], \n \"signatures\": [ \"fd82214a59c99d9251fa00126d353f9cf502a80d8993a6c223e3c802a40ab405555637f495903d3ba558312881e586d452e6e95826d8e128345f6c0a8f9f350e\", \"8c04ef50cf34afa3a9ec19c457143496f8cf7045ed869b581f9efa2f1d65e30f1cec5272b00e9c61a34bdd3c78cf82ae8ef4df3132f70861391069b9c255cd08\", ... ]\n}",
"block_height": 993442,
"block_timestamp": 1457749396,
"double_spend_seen": false,
"in_pool": false,
"output_indices": [198769,418598,176616,50345,509],
"tx_hash": "d6e48158472848e6687173a91ae6eebfa3e1d778e65252ee99d7515d63090408"
}],
"txs_as_hex": ["..."],
"txs_as_json": ["{\n \"version\": 1, \n \"unlock_time\": 0, \n \"vin\": [ {\n \"key\": {\n \"amount\": 9999999999, \n \"key_offsets\": [ 691\n ], \n \"k_image\": \"6ebee1b651a8da723462b4891d471b990ddc226049a0866d3029b8e2f75b7012\"\n }\n }, {\n \"key\": {\n \"amount\": 9000000000000, \n \"key_offsets\": [ 175760\n ], \n \"k_image\": \"200bd02b70ee707441a8863c5279b4e4d9f376dc97a140b1e5bc7d72bc508069\"\n }\n }, ... \n ], \n \"vout\": [ {\n \"amount\": 60000000000, \n \"target\": {\n \"key\": \"8c792dea94dab48160e067fb681edd6247ba375281fbcfedc03cb970f3b98e2d\"\n }\n }, {\n \"amount\": 700000000000, \n \"target\": {\n \"key\": \"1ab33e69737e157d23e33274c42793be06a8711670e73fa10ecebc604f87cc71\"\n }\n }, ... \n ], \n \"extra\": [ 1, 3, 140, 109, 156, 205, 47, 148, 153, 9, 17, 93, 83, 33, 162, 110, 152, 1, 139, 70, 121, 19, 138, 10, 44, 6, 55, 140, 242, 124, 143, 219, 172\n ], \n \"signatures\": [ \"fd82214a59c99d9251fa00126d353f9cf502a80d8993a6c223e3c802a40ab405555637f495903d3ba558312881e586d452e6e95826d8e128345f6c0a8f9f350e\", \"8c04ef50cf34afa3a9ec19c457143496f8cf7045ed869b581f9efa2f1d65e30f1cec5272b00e9c61a34bdd3c78cf82ae8ef4df3132f70861391069b9c255cd08\", ... ]\n}"],
"untrusted": false
}
```
Example 3: Returned a missed (unexisting) transaction.
```
curl -X POST http://127.0.0.1:18081/get_transactions -d '{"txs_hashes":["d6e48158472848e6687173a91ae6eebfa3e1d778e65252ee99d7515d63090409"]}' -H 'Content-Type: application/json'
{
"missed_tx": ["d6e48158472848e6687173a91ae6eebfa3e1d778e65252ee99d7515d63090409"],
"status": "OK",
"untrusted": false
}
```
### **/get_alt_blocks_hashes**
Get the known blocks hashes which are not on the main chain.
Alias: *None*.
Inputs: *None*
Outputs:
* *blks_hashes* - array of strings; list of alternative blocks hashes to main chain
* *status* - string; General RPC error code. "OK" means everything looks good.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
Example:
```
$ curl -X POST http://127.0.0.1:18081/get_alt_blocks_hashes -H 'Content-Type: application/json'
{
"blks_hashes": ["9c2277c5470234be8b32382cdf8094a103aba4fcd5e875a6fc159dc2ec00e011","637c0e0f0558e284493f38a5fcca3615db59458d90d3a5eff0a18ff59b83f46f","6f3adc174a2e8082819ebb965c96a095e3e8b63929ad9be2d705ad9c086a6b1c","697cf03c89a9b118f7bdf11b1b3a6a028d7b3617d2d0ed91322c5709acf75625","d99b3cf3ac6f17157ac7526782a3c3b9537f89d07e069f9ce7821d74bd9cad0e","e97b62109a6303233dcd697fa8545c9fcbc0bf8ed2268fede57ddfc36d8c939c","70ff822066a53ad64b04885c89bbe5ce3e537cdc1f7fa0dc55317986f01d1788","b0d36b209bd0d4442b55ea2f66b5c633f522401f921f5a85ea6f113fd2988866"],
"status": "OK",
"untrusted": false
}
```
### **/is_key_image_spent**
Check if outputs have been spent using the key image associated with the output.
Alias: *None*.
Inputs:
* *key_images* - string list; List of key image hex strings to check.
Outputs:
* *spent_status* - unsigned int list; List of statuses for each image checked. Statuses are follows: 0 = unspent, 1 = spent in blockchain, 2 = spent in transaction pool
* *status* - string; General RPC error code. "OK" means everything looks good.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
Example:
```
$ curl -X POST http://127.0.0.1:18081/is_key_image_spent -d '{"key_images":["8d1bd8181bf7d857bdb281e0153d84cd55a3fcaa57c3e570f4a49f935850b5e3","7319134bfc50668251f5b899c66b005805ee255c136f0e1cecbb0f3a912e09d4"]}' -H 'Content-Type: application/json'
{
"spent_status": [1,2],
"status": "OK"
"untrusted": false
}
```
### **/send_raw_transaction**
Broadcast a raw transaction to the network.
Alias: */sendrawtransaction*.
Inputs:
* *tx_as_hex* - string; Full transaction information as hexidecimal string.
* *do_not_relay* - boolean; Stop relaying transaction to other nodes (default is `false`).
Outputs:
* *double_spend* - boolean; Transaction is a double spend (`true`) or not (`false`).
* *fee_too_low* - boolean; Fee is too low (`true`) or OK (`false`).
* *invalid_input* - boolean; Input is invalid (`true`) or valid (`false`).
* *invalid_output* - boolean; Output is invalid (`true`) or valid (`false`).
* *low_mixin* - boolean; Mixin count is too low (`true`) or OK (`false`).
* *not_rct* - boolean; Transaction is a standard ring transaction (`true`) or a ring confidential transaction (`false`).
* *not_relayed* - boolean; Transaction was not relayed (`true`) or relayed (`false`).
* *overspend* - boolean; Transaction uses more money than available (`true`) or not (`false`).
* *reason* - string; Additional information. Currently empty or "Not relayed" if transaction was accepted but not relayed.
* *status* - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.
* *too_big* - boolean; Transaction size is too big (`true`) or OK (`false`).
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
Example (No return information included here.):
```
$ curl -X POST http://127.0.0.1:18081/send_raw_transaction -d '{"tx_as_hex":"de6a3...", "do_not_relay":false}' -H 'Content-Type: application/json'
```
### **/start_mining**
Start mining on the daemon.
Alias: *None*.
Inputs:
* *do_background_mining* - boolean; States if the mining should run in background (`true`) or foreground (`false`).
* *ignore_battery* - boolean; States if batery state (on laptop) should be ignored (`true`) or not (`false`).
* *miner_address* - string; Account address to mine to.
* *threads_count* - unsigned int; Number of mining thread to run.
Outputs:
* *status* - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.
Example:
```
$ curl -X POST http://127.0.0.1:18081/start_mining -d '{"do_background_mining":false,"ignore_battery":true,"miner_address":"47xu3gQpF569au9C2ajo5SSMrWji6xnoE5vhr94EzFRaKAGw6hEGFXYAwVADKuRpzsjiU1PtmaVgcjUJF89ghGPhUXkndHc","threads_count":1}' -H 'Content-Type: application/json'
{
"status": "OK"
}
```
### **/stop_mining**
Stop mining on the daemon.
Alias: *None*.
Inputs: *None*.
Outputs:
* *status* - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.
Example:
```
$ curl -X POST http://127.0.0.1:18081/stop_mining -H 'Content-Type: application/json'
{
"status": "OK"
}
```
### **/mining_status**
Get the mining status of the daemon.
Alias: *None*.
Inputs: *None*.
Outputs:
* *active* - boolean; States if mining is enabled (`true`) or disabled (`false`).
* *address* - string; Account address daemon is mining to. Empty if not mining.
* *is_background_mining_enabled* - boolean; States if the mining is running in background (`true`) or foreground (`false`).
* *speed* - unsigned int; Mining power in hashes per seconds.
* *status* - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.
* *threads_count* - unsigned int; Number of running mining threads.
Example while mining:
```
$ curl -X POST http://127.0.0.1:18081/mining_status -H 'Content-Type: application/json'
{
"active": true,
"address": "47xu3gQpF569au9C2ajo5SSMrWji6xnoE5vhr94EzFRaKAGw6hEGFXYAwVADKuRpzsjiU1PtmaVgcjUJF89ghGPhUXkndHc",
"is_background_mining_enabled": false,
"speed": 20,
"status": "OK",
"threads_count": 1
}
```
Example while not mining:
```
$ curl -X POST http://127.0.0.1:18081/mining_status -H 'Content-Type: application/json'
{
"active": false,
"address": "",
"is_background_mining_enabled": false,
"speed": 0,
"status": "OK",
"threads_count": 0
}
```
### **/save_bc**
Save the blockchain. The blockchain does not need saving and is always saved when modified, however it does a sync to flush the filesystem cache onto the disk for safety purposes against Operating System or Harware crashes.
Alias: *None*.
Inputs: *None*.
Outputs:
* *status* - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.
Example:
```
$ curl -X POST http://127.0.0.1:18081/save_bc -H 'Content-Type: application/json'
{
"status": "OK"
}
```
### **/get_peer_list**
Get the known peers list.
Alias: *None*.
Inputs: *None*.
Outputs:
* *gray_list* - array of offline *peer* structure as follows:
* *host* - unsigned int; IP address in integer format
* *id* - string; Peer id
* *ip* - unsigned int; IP address in integer format
* *last_seen* - unsigned int; unix time at which the peer has been seen for the last time
* *port* - unsigned int; TCP port the peer is using to connect to monero network.
* *status* - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.
* *white_list* - array of online *peer* structure, as above.
Example (truncated lists):
```
$ curl -X POST http://127.0.0.1:18081/get_peer_list -H 'Content-Type: application/json'
{
"gray_list": [{
"host": "640304833",
"id": 5345237316225602120,
"ip": 640304833,
"last_seen": 1525540510,
"port": 18080
},{
"host": "2183731038",
"id": 14955030573998424430,
"ip": 2183731038,
"last_seen": 1525540499,
"port": 28080
}, ...
],
"status": "OK",
"white_list": [{
"host": "1221637955",
"id": 10354694710033118926,
"ip": 1221637955,
"last_seen": 1525540511,
"port": 18080
},{
"host": "1780407354",
"id": 17193661050352240890,
"ip": 1780407354,
"last_seen": 1525540510,
"port": 18080
}, ...
]
}
```
### **/set_log_hash_rate**
Set the log hash rate display mode.
Alias: *None*.
Inputs:
* *visible* - boolean; States if hash rate logs should be visible (`true`) or hidden (`false`)
Outputs:
* *status* - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.
Example while mining:
```
$ curl -X POST http://127.0.0.1:18081/set_log_hash_rate -d '{"visible":true}' -H 'Content-Type: application/json'
{
"status": "OK"
}
```
Error while not mining:
```
$ curl -X POST http://127.0.0.1:18081/set_log_hash_rate -d '{"visible":true}' -H 'Content-Type: application/json'
{
"status": "NOT MINING"
}
```
### **/set_log_level**
Set the daemon log level.
By default, log level is set to `0`.
Alias: *None*.
Inputs:
* *level* - integer; daemon log level to set from `0` (less verbose) to `4` (most verbose)
Outputs:
* *status* - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.
Example:
```
$ curl -X POST http://127.0.0.1:18081/set_log_level -d '{"level":1}' -H 'Content-Type: application/json'
{
"status": "OK"
}
```
### **/set_log_categories**
Set the daemon log categories.
Categories are represented as a comma separated list of `<Category>:<level>` (similarly to syslog standard `<Facility>:<Severity-level>`), where:
* *Category* is one of the following:
* *\** - All facilities
* *default*
* *net*
* *net.http*
* *net.p2p*
* *logging*
* *net.throttle*
* *blockchain.db*
* *blockchain.db.lmdb*
* *bcutil*
* *checkpoints*
* *net.dns*
* *net.dl*
* *i18n*
* *perf*
* *stacktrace*
* *updates*
* *account*
* *cn*
* *difficulty*
* *hardfork*
* *miner*
* *blockchain*
* *txpool*
* *cn.block_queue*
* *net.cn*
* *daemon*
* *debugtools.deserialize*
* *debugtools.objectsizes*
* *device.ledger*
* *wallet.gen_multisig*
* *multisig*
* *bulletproofs*
* *ringct*
* *daemon.rpc*
* *wallet.simplewallet*
* *WalletAPI*
* *wallet.ringdb*
* *wallet.wallet2*
* *wallet.rpc*
* *tests.core*
* *Level* is one of the following:
* *FATAL* - higher level
* *ERROR*
* *WARNING*
* *INFO*
* *DEBUG*
* *TRACE* - lower level
A level automatically includes higher level.
By default, categories are set to `*:WARNING,net:FATAL,net.p2p:FATAL,net.cn:FATAL,global:INFO,verify:FATAL,stacktrace:INFO,logging:INFO,msgwriter:INFO`.
Setting the categories to "" prevent any logs to be outputed.
Alias: *None*.
Inputs:
* *categories* - string; Optional, daemon log categories to enable
Outputs:
* *categories* - string; daemon log enabled categories
* *status* - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.
Example to set all facilities to Security Level `Info`:
```
$ curl -X POST http://127.0.0.1:18081/set_log_categories -d '{"categories": "*:INFO"}' -H 'Content-Type: application/json'
{
"categories": "*:INFO",
"status": "OK"
}
```
Example without input to set the default categories:
```
$ curl -X POST http://127.0.0.1:18081/set_log_categories -H 'Content-Type: application/json'
{
"categories": "*:WARNING,net:FATAL,net.p2p:FATAL,net.cn:FATAL,global:INFO,verify:FATAL,stacktrace:INFO,logging:INFO,msgwriter:INFO",
"status": "OK"
}
```
### **/get_transaction_pool**
Show information about valid transactions seen by the node but not yet mined into a block, as well as spent key image information for the txpool in the node's memory.
Alias: *None*.
Inputs: *None*.
Outputs:
* *spent_key_images* - List of spent output key images:
* *id_hash* - string; Key image.
* *txs_hashes* - string list; tx hashes of the txes (usually one) spending that key image.
* *status* - string; General RPC error code. "OK" means everything looks good.
* *transactions* - List of transactions in the mempool are not in a block on the main chain at the moment:
* *blob_size* - unsigned int; The size of the full transaction blob.
* *double_spend_seen* - boolean; States if this transaction has been seen as double spend.
* *do_not_relay*; boolean; States if this transaction should not be relayed
* *fee* - unsigned int; The amount of the mining fee included in the transaction, in @atomic-units.
* *id_hash* - string; The transaction ID hash.
* *kept_by_block* - boolean; States if the tx was included in a block at least once (`true`) or not (`false`).
* *last_failed_height* - unsigned int; If the transaction validation has previously failed, this tells at what height that occured.
* *last_failed_id_hash* - string; Like the previous, this tells the previous transaction ID hash.
* *last_relayed_time* - unsigned int; Last unix time at which the transaction has been relayed.
* *max_used_block_height* - unsigned int; Tells the height of the most recent block with an output used in this transaction.
* *max_used_block_hash* - string; Tells the hash of the most recent block with an output used in this transaction.
* *receive_time* - unsigned int; The Unix time that the transaction was first seen on the network by the node.
* *relayed* - boolean; States if this transaction has been relayed
* *tx_blob* - unsigned int; Hexadecimal blob represnting the transaction.
* *tx_json* - json string; JSON structure of all information in the transaction:
* *version* - Transaction version
* *unlock_time* - If not 0, this tells when a transaction output is spendable.
* *vin* - List of inputs into transaction:
* *key* - The public key of the previous output spent in this transaction.
* *amount* - The amount of the input, in @atomic-units.
* *key_offsets* - A list of integer offets to the input.
* *k_image* - The key image for the given input
* *vout* - List of outputs from transaction:
* *amount* - Amount of transaction output, in @atomic-units.
* *target* - Output destination information:
* *key* - The stealth public key of the receiver. Whoever owns the private key associated with this key controls this transaction output.
* *extra* - Usually called the "transaction ID" but can be used to include any random 32 bytes.
* *rct_signatures* - Ring signatures:
* *type*
* *txnFee*
* *ecdhInfo* - array of Diffie Helman Elipctic curves structures as follows:
* *mask* - String
* *amount* - String
* *outPk*
* *rctsig_prunable*
* *rangeSigs* - array of structures as follows:
* *asig*
* *Ci*
* *MGs* - array of structures as follows:
* *ss* - array of arrays of two strings.
* *cc* - String
Example (Note: Some lists in the returned information have been truncated for display reasons):
```
$ curl -X POST http://127.0.0.1:18081/get_transaction_pool -H 'Content-Type: application/json'
{
"spent_key_images": [{
"id_hash": "a2af919609db4ff5ab8d4ba18502e647d521760e1cbc30288f06fa87bf9a0c1c",
"txs_hashes": ["1ee6a4873b638711795fc3b0b73fc7146505a09a7f4749534fd408d571a273cf"]
},{
"id_hash": "02d5f6559e9bca5ae5a335130aeeb05df2db518ab9837fa64ebbab276c100792",
"txs_hashes": ["531aacc0ceb8514cdde5f104285202ccc3e969c77584e3c6fa614c987c583965"]
},
...],
"status": "OK",
"transactions": [{
"blob_size": 13193,
"do_not_relay": false,
"double_spend_seen": false,
"fee": 9694360000,
"id_hash": "f8fb875cfc9e2e59bcf96a42474c79e01d50b69e6548d445d45984f7db66e50f",
"kept_by_block": false,
"last_failed_height": 0,
"last_failed_id_hash": "0000000000000000000000000000000000000000000000000000000000000000",
"last_relayed_time": 1525615049,
"max_used_block_height": 1564924,
"max_used_block_id_hash": "4bae7856979f46c7de31f3fb58cac36d4dfd2765bf33f876edf33d0e05ebb4a7",
"receive_time": 1525615049,
"relayed": true,
"tx_blob": " ... ",
"tx_json": "{\n \"version\": 2, \n \"unlock_time\": 0, \n \"vin\": [ {\n \"key\": {\n \"amount\": 0, \n \"key_offsets\": [ 2630347, 594429, 1047509, 758973, 464501, 61971, 22268\n ], \n \"k_image\": \"0731363c58dd4492f031fa20c82fe6ddcb9cc070d73938afe8a5f7f77897f8b4\"\n }\n }\n ], \n \"vout\": [ {\n \"amount\": 0, \n \"target\": {\n \"key\": \"f3b3dd09483616e343b9866eed50a0ce01d5c0d0f2612ce2c4d0e9cce5c218cd\"\n }\n }, {\n \"amount\": 0, \n \"target\": {\n \"key\": \"9796f2d477a696b6282bf3cb1a41cefba0c4604eedcc2e7a44904d7033643e0e\"\n }\n }\n ], \n \"extra\": [ 1, 25, 228, 80, 5, 214, 117, 150, 9, 125, 98, 17, 113, 208, 89, 223, 242, 227, 188, 197, 141, 190, 135, 140, 152, 117, 240, 150, 21, 93, 62, 108, 124\n ], \n \"rct_signatures\": {\n \"type\": 1, \n \"txnFee\": 9694360000, \n \"ecdhInfo\": [ {\n \"mask\": \"645f06a2816aecf83d5041c3320eb31092b994fb2733bb74c8c47e288d452c04\", \n \"amount\": \"3908f14d39dcb3831331cb255eeadc5b0aea0143645b9cd3034abf613995740d\"\n }, {\n \"mask\": \"0785b5df0a994b14d59da810503a022721d8f629720f526e15bd848ad3c2c509\", \n \"amount\": \"fbd81cf2368dcd742905ded5287457030467aaf5bc9939e13f1d6bf8d4c8ca09\"\n }], \n \"outPk\": [ \"c19f5fa052859126e0eed0e3c860aadab049677b2b3dd14cc74d02f92f1d013f\", \"1581ef6368de1608ea366566b88272db220479cf215f6d88d7b60ec221d11e0a\"]\n }, \n \"rctsig_prunable\": {\n \"rangeSigs\": [ {\n \"asig\": \" ... \", \n \"Ci\": \" .. \"\n }, {\n \"asig\": \" ... \", \n \"Ci\": \" ... \"\n }], \n \"MGs\": [ {\n \"ss\": [ [ \"218a10a29e0f66e5a324af67b7734708a8a4cc8f16b28acd8cda538aaa495a02\", \"b368b4e956df5808c5c257f0dc3f7eff8c28463d0bb20759d19977fa02d6f205\"], [ \"f741d2c96bc23b362b4155a03fb6f1351ab5bf4445a43b3e52ba776f526af305\", \"a10ad1ee80dce3f311dd3dc141803daeecaa4d2a25a390cd9c35e4161b7c9e0c\"],
...], \n \"cc\": \"e93801b707261ca76e146fdf2085abae71ad9203a00edc843c74f4ead8a39601\"\n }]\n }\n}"
},
...]
}
```
### **/get_transaction_pool_hashes.bin**
Get hashes from transaction pool. Binary request.
Alias: *None*.
Inputs: *None*.
Outputs:
* *status* - string; General RPC error code. "OK" means everything looks good.
* *tx_hashes* - binary array of transaction hashes.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
Example:
```
$ curl -X POST http://127.0.0.1:18081/get_transaction_pool_hashes.bin -H 'Content-Type: application/json'
{
"status": "OK",
"tx_hashes": " ... ",
"untrusted": false
}
```
### **/get_transaction_pool_stats**
Get the transaction pool statistics.
Alias: *None*.
Inputs: *None*.
Outputs:
* *pool_stats* - Structure as follows:
* *bytes_max* - unsigned int; Max transaction size in pool
* *bytes_med* - unsigned int; Median transaction size in pool
* *bytes_min* - unsigned int; Min transaction size in pool
* *bytes_total* - unsigned int; total size of all transactions in pool
* *histo* - structure *txpool_histo* as follows:
* *txs* - unsigned int; number of transactions
* *bytes* - unsigned int; size in bytes.
* *histo_98pc* unsigned int; the time 98% of txes are "younger" than
* *num_10m* unsigned int; number of transactions in pool for more than 10 minutes
* *num_double_spends* unsigned int; number of double spend transactions
* *num_failing* unsigned int; number of failing transactions
* *num_not_relayed* unsigned int; number of non-relayed transactions
* *oldest* unsigned int; unix time of the oldest transaction in the pool
* *txs_total* unsigned int; total number of transactions.
* *status* - string; General RPC error code. "OK" means everything looks good.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
Example:
```
$ curl -X POST http://127.0.0.1:18081/get_transaction_pool_stats -H 'Content-Type: application/json'
{
"pool_stats": {
"bytes_max": 47222,
"bytes_med": 13290,
"bytes_min": 13092,
"bytes_total": 449511,
"fee_total": 289715320000,
"histo": "\t▒'▒5▒4▒\/▒▒▒$3",
"histo_98pc": 0,
"num_10m": 18,
"num_double_spends": 1,
"num_failing": 17,
"num_not_relayed": 0,
"oldest": 1525457001,
"txs_total": 26
},
"status": "OK",
"untrusted": false
}
```
### **/stop_daemon**
Send a command to the daemon to safely disconnect and shut down.
Alias: *None*.
Inputs: *None*.
Outputs:
* *status* - string; General RPC error code. "OK" means everything looks good.
Example:
```
$ curl -X POST http://127.0.0.1:18081/stop_daemon -H 'Content-Type: application/json'
{
"status": "OK"
}
```
### **/get_info (not JSON)**
This method is a convenient backward support and should not be used anymore. See [get_info](#get_info) JSON RPC for details.
Alias:
* */getinfo*
* *get_info*
### **/get_limit**
Get daemon bandwidth limits.
Alias: *None*.
Inputs: *None*.
Outputs:
* *limit_down* - unsigned int; Download limit in kBytes per second
* *limit_up* - unsigned int; Upload limit in kBytes per second
* *status* - string; General RPC error code. "OK" means everything looks good.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
Example:
```
$ curl -X POST http://127.0.0.1:18081/get_limit -H 'Content-Type: application/json'
{
"limit_down": 8192,
"limit_up": 128,
"status": "OK",
"untrusted": false
}
```
### **/set_limit**
Set daemon bandwidth limits.
Alias: *None*.
Inputs:
* *limit_down* - signed int; Download limit in kBytes per second (-1 reset to default, 0 don't change the current limit)
* *limit_up* - signed int; Upload limit in kBytes per second (-1 reset to default, 0 don't change the current limit)
Outputs:
* *limit_down* - unsigned int; Download limit in kBytes per second
* *limit_up* - unsigned int; Upload limit in kBytes per second
* *status* - string; General RPC error code. "OK" means everything looks good.
Example:
```
$ curl -X POST http://127.0.0.1:18081/set_limit -d '{"limit_down": 1024}' -H 'Content-Type: application/json'
{
"limit_down": 1024,
"limit_up": 128,
"status": "OK"
}
```
### **/out_peers**
Limit number of Outgoing peers.
Alias: *None*.
Inputs:
* *out_peers* - unsigned int; Max number of outgoing peers
Outputs:
* *status* - string; General RPC error code. "OK" means everything looks good.
Example:
```
$ curl -X POST http://127.0.0.1:18081/out_peers -d '{"out_peers": 3232235535}' -H 'Content-Type: application/json'
{
"status": "OK"
}
```
### **/in_peers**
Limit number of Incoming peers.
Alias: *None*.
Inputs:
* *in_peers* - unsigned int; Max number of incoming peers
Outputs:
* *status* - string; General RPC error code. "OK" means everything looks good.
Example:
```
$ curl -X POST http://127.0.0.1:18081/out_peers -d '{"in_peers": 3232235535}' -H 'Content-Type: application/json'
{
"status": "OK"
}
```
### **/start_save_graph**
Obsolete. Conserved here for reference.
Alias: *None*.
Inputs: *None*.
Outputs:
* *status* - string; General RPC error code. "OK" means everything looks good.
Example:
```
$ curl -X POST http://127.0.0.1:18081/start_save_graph -H 'Content-Type: application/json'
{
"status": "OK"
}
```
### **/stop_save_graph**
Obsolete. Conserved here for reference.
Alias: *None*.
Inputs: *None*.
Outputs:
* *status* - string; General RPC error code. "OK" means everything looks good.
Example:
```
$ curl -X POST http://127.0.0.1:18081/stop_save_graph -H 'Content-Type: application/json'
{
"status": "OK"
}
```
### **/get_outs**
Get outputs.
Alias: *None*.
Inputs:
* *outputs* array of *get_outputs_out* structure as follows:
* *amount* - unsigned int;
* *index* - unsigned int;
Outputs:
* *outs* - array of structure *outkey* as follows:
* *height* - unsigned int; block height of the output
* *key* - String; the public key of the output
* *mask* - String
* *txid* - String; transaction id
* *unlocked* - boolean; States if output is locked (`false`) or not (`true`)
* *status* - string; General RPC error code. "OK" means everything looks good.
* *untrusted* - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (`true`), or when the daemon is fully synced (`false`).
### **/update**
Update daemon.
Alias: *None*.
Inputs:
* *command* - String; command to use, either `check` or `download`
* *path* - String; Optional, path where to download the update.
Outputs:
* *auto_uri* - string;
* *hash* - string;
* *path* - String; path to download the update
* *status* - string; General RPC error code. "OK" means everything looks good.
* *update* - boolean; States if an update is available to download (`true`) or not (`false`)
* *user_uri* - string;
* *version* - string; Version available for download.
Example:
```
$ curl -X POST http://127.0.0.1:18081/update -d '{"command":"check"}' -H 'Content-Type: application/json'
{
"auto_uri": "",
"hash": "",
"path": "",
"status": "OK",
"update": false,
"user_uri": "",
"version": ""
}
```
{% assign version = '2.2.0' | split: '.' %}
{% include disclaimer.html translated="false" version=page.version %}
## Introduction
This is a list of the monero-wallet-rpc calls, their inputs and outputs, and examples of each. The program monero-wallet-rpc replaced the rpc interface that was in simplewallet and then monero-wallet-cli.
All monero-wallet-rpc methods use the same JSON RPC interface. For example:
```
IP=127.0.0.1
PORT=18082
METHOD="make_integrated_address"
PARAMS="{\"payment_id\":\"1234567890123456789012345678900012345678901234567890123456789000\"}"
curl \
-X POST http://$IP:$PORT/json_rpc \
-d '{"jsonrpc":"2.0","id":"0","method":"'$METHOD'","params":'"$PARAMS"'}' \
-H 'Content-Type: application/json'
```
If the monero-wallet-rpc was executed with the `--rpc-login` argument as `username:password`, then follow this example:
```
IP=127.0.0.1
PORT=18082
METHOD="make_integrated_address"
PARAMS="{\"payment_id\":\"1234567890123456789012345678900012345678901234567890123456789000\"}"
curl \
-u username:password --digest \
-X POST http://$IP:$PORT/json_rpc \
-d '{"jsonrpc":"2.0","id":"0","method":"'$METHOD'","params":'"$PARAMS"'}' \
-H 'Content-Type: application/json'
```
Note: "@atomic-units" refer to the smallest fraction of 1 XMR according to the monerod implementation. **1 XMR = 1e12 @atomic-units.**
This list has been updated on a frozen code on 2018-09-14 after merged commit bb30a7236725e456138f055f96a634c75ce2b491 (Wallet RPC version 1.3), and at block height 1643308.
### Index of JSON RPC Methods:
* [get_balance](#get_balance)
* [get_address](#get_address)
* [get_address_index](#get_address_index)
* [create_address](#create_address)
* [label_address](#label_address)
* [get_accounts](#get_accounts)
* [create_account](#create_account)
* [label_account](#label_account)
* [get_account_tags](#get_account_tags)
* [tag_accounts](#tag_accounts)
* [untag_accounts](#untag_accounts)
* [set_account_tag_description](#set_account_tag_description)
* [get_height](#get_height)
* [transfer](#transfer)
* [transfer_split](#transfer_split)
* [sign_transfer](#sign_transfer)
* [submit_transfer](#submit_transfer)
* [sweep_dust](#sweep_dust)
* [sweep_all](#sweep_all)
* [sweep_single](#sweep_single)
* [relay_tx](#relay_tx)
* [store](#store)
* [get_payments](#get_payments)
* [get_bulk_payments](#get_bulk_payments)
* [incoming_transfers](#incoming_transfers)
* [query_key](#query_key)
* [make_integrated_address](#make_integrated_address)
* [split_integrated_address](#split_integrated_address)
* [stop_wallet](#stop_wallet)
* [rescan_blockchain](#rescan_blockchain)
* [set_tx_notes](#set_tx_notes)
* [get_tx_notes](#get_tx_notes)
* [set_attribute](#set_attribute)
* [get_attribute](#get_attribute)
* [get_tx_key](#get_tx_key)
* [check_tx_key](#check_tx_key)
* [get_tx_proof](#get_tx_proof)
* [check_tx_proof](#check_tx_proof)
* [get_spend_proof](#get_spend_proof)
* [check_spend_proof](#check_spend_proof)
* [get_reserve_proof](#get_reserve_proof)
* [check_reserve_proof](#check_reserve_proof)
* [get_transfers](#get_transfers)
* [get_transfer_by_txid](#get_transfer_by_txid)
* [sign](#sign)
* [verify](#verify)
* [export_outputs](#export_outputs)
* [import_outputs](#import_outputs)
* [export_key_images](#export_key_images)
* [import_key_images](#import_key_images)
* [make_uri](#make_uri)
* [parse_uri](#parse_uri)
* [get_address_book](#get_address_book)
* [add_address_book](#add_address_book)
* [delete_address_book](#delete_address_book)
* [refresh](#refresh)
* [rescan_spent](#rescan_spent)
* [start_mining](#start_mining)
* [stop_mining](#stop_mining)
* [get_languages](#get_languages)
* [create_wallet](#create_wallet)
* [open_wallet](#open_wallet)
* [close_wallet](#close_wallet)
* [change_wallet_password](#change_wallet_password)
* [is_multisig](#is_multisig)
* [prepare_multisig](#prepare_multisig)
* [make_multisig](#make_multisig)
* [export_multisig_info](#export_multisig_info)
* [import_multisig_info](#import_multisig_info)
* [finalize_multisig](#finalize_multisig)
* [sign_multisig](#sign_multisig)
* [submit_multisig](#submit_multisig)
* [get_version](#get_version)
---
## JSON RPC Methods:
### **get_balance**
Return the wallet's balance.
Alias: *getbalance*.
Inputs:
* *account_index* - unsigned int; Return balance for this account.
* *address_indices* - array of unsigned int; (Optional) Return balance detail for those subaddresses.
Outputs:
* *balance* - unsigned int; The total balance of the current monero-wallet-rpc in session.
* *unlocked_balance* - unsigned int; Unlocked funds are those funds that are sufficiently deep enough in the Monero blockchain to be considered safe to spend.
* *multisig_import_needed* - boolean; True if importing multisig data is needed for returning a correct balance.
* *per_subaddress* - array of subaddress information; Balance information for each subaddress in an account.
* *address_index* - unsigned int; Index of the subaddress in the account.
* *address* - string; Address at this index. Base58 representation of the public keys.
* *balance* - unsigned int; Balance for the subaddress (locked or unlocked).
* *unlocked_balance* - unsigned int; Unlocked balance for the subaddress.
* *label* - string; Label for the subaddress.
* *num_unspent_outputs* - unsigned int; Number of unspent outputs available for the subaddress.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_balance","params":{"account_index":0,"address_indices":[0,1]}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"balance": 157443303037455077,
"multisig_import_needed": false,
"per_subaddress": [{
"address": "55LTR8KniP4LQGJSPtbYDacR7dz8RBFnsfAKMaMuwUNYX6aQbBcovzDPyrQF9KXF9tVU6Xk3K8no1BywnJX6GvZX8yJsXvt",
"address_index": 0,
"balance": 157360317826255077,
"label": "Primary account",
"num_unspent_outputs": 5281,
"unlocked_balance": 157360317826255077
},{
"address": "7BnERTpvL5MbCLtj5n9No7J5oE5hHiB3tVCK5cjSvCsYWD2WRJLFuWeKTLiXo5QJqt2ZwUaLy2Vh1Ad51K7FNgqcHgjW85o",
"address_index": 1,
"balance": 59985211200000,
"label": "",
"num_unspent_outputs": 1,
"unlocked_balance": 59985211200000
}],
"unlocked_balance": 157443303037455077
}
}
```
### **get_address**
Return the wallet's addresses for an account. Optionally filter for specific set of subaddresses.
Alias: *getaddress*.
Inputs:
* *account_index* - unsigned int; Return subaddresses for this account.
* *address_index* - array of unsigned int; (Optional) List of subaddresses to return from an account.
Outputs:
* *address* - string; The 95-character hex address string of the monero-wallet-rpc in session.
* *addresses* array of addresses informations
* *address* string; The 95-character hex (sub)address string.
* *label* string; Label of the (sub)address
* *address_index* unsigned int; index of the subaddress
* *used* boolean; states if the (sub)address has already received funds
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_address","params":{"account_index":0,"address_index":[0,1,4]}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"address": "55LTR8KniP4LQGJSPtbYDacR7dz8RBFnsfAKMaMuwUNYX6aQbBcovzDPyrQF9KXF9tVU6Xk3K8no1BywnJX6GvZX8yJsXvt",
"addresses": [{
"address": "55LTR8KniP4LQGJSPtbYDacR7dz8RBFnsfAKMaMuwUNYX6aQbBcovzDPyrQF9KXF9tVU6Xk3K8no1BywnJX6GvZX8yJsXvt",
"address_index": 0,
"label": "Primary account",
"used": true
},{
"address": "7BnERTpvL5MbCLtj5n9No7J5oE5hHiB3tVCK5cjSvCsYWD2WRJLFuWeKTLiXo5QJqt2ZwUaLy2Vh1Ad51K7FNgqcHgjW85o",
"address_index": 1,
"label": "",
"used": true
},{
"address": "77xa6Dha7kzCQuvmd8iB5VYoMkdenwCNRU9khGhExXQ8KLL3z1N1ZATBD1sFPenyHWT9cm4fVFnCAUApY53peuoZFtwZiw5",
"address_index": 4,
"label": "test2",
"used": true
}]
}
}
```
### **get_address_index**
Get account and address indexes from a specific (sub)address
Alias: *None*.
Inputs:
* *address* - String; (sub)address to look for.
Outputs:
* *index* - subaddress informations
* *major* unsigned int; Account index.
* *minor* unsigned int; Address index.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_address_index","params":{"address":"7BnERTpvL5MbCLtj5n9No7J5oE5hHiB3tVCK5cjSvCsYWD2WRJLFuWeKTLiXo5QJqt2ZwUaLy2Vh1Ad51K7FNgqcHgjW85o"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"index": {
"major": 0,
"minor": 1
}
}
}
```
### **create_address**
Create a new address for an account. Optionally, label the new address.
Alias: *None*.
Inputs:
* *account_index* - unsigned int; Create a new address for this account.
* *label* - string; (Optional) Label for the new address.
Outputs:
* *address* - string; Newly created address. Base58 representation of the public keys.
* *address_index* - unsigned int; Index of the new address under the input account.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"create_address","params":{"account_index":0,"label":"new-sub"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"address": "7BG5jr9QS5sGMdpbBrZEwVLZjSKJGJBsXdZLt8wiXyhhLjy7x2LZxsrAnHTgD8oG46ZtLjUGic2pWc96GFkGNPQQDA3Dt7Q",
"address_index": 5
}
}
```
### **label_address**
Label an address.
Alias: *None*.
Inputs:
* *index* - subaddress index; JSON Object containing the major & minor address index:
* *major* - unsigned int; Account index for the subaddress.
* *minor* - unsigned int; Index of the subaddress in the account.
* *label* - string; Label for the address.
Outputs: *None*.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"label_address","params":{"index":{"major":0,"minor":5},"label":"myLabel"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
}
}
```
### **get_accounts**
Get all accounts for a wallet. Optionally filter accounts by tag.
Alias: *None*.
Inputs:
* *tag* - string; (Optional) Tag for filtering accounts.
Outputs:
* *subaddress_accounts* - array of subaddress account information:
* *account_index* - unsigned int; Index of the account.
* *balance* - unsigned int; Balance of the account (locked or unlocked).
* *base_address* - string; Base64 representation of the first subaddress in the account.
* *label* - string; (Optional) Label of the account.
* *tag* - string; (Optional) Tag for filtering accounts.
* *unlocked_balance* - unsigned int; Unlocked balance for the account.
* *total_balance* - unsigned int; Total balance of the selected accounts (locked or unlocked).
* *total_unlocked_balance* - unsigned int; Total unlocked balance of the selected accounts.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_accounts","params":{"tag":"myTag"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"subaddress_accounts": [{
"account_index": 0,
"balance": 157663195572433688,
"base_address": "55LTR8KniP4LQGJSPtbYDacR7dz8RBFnsfAKMaMuwUNYX6aQbBcovzDPyrQF9KXF9tVU6Xk3K8no1BywnJX6GvZX8yJsXvt",
"label": "Primary account",
"tag": "myTag",
"unlocked_balance": 157443303037455077
},{
"account_index": 1,
"balance": 0,
"base_address": "77Vx9cs1VPicFndSVgYUvTdLCJEZw9h81hXLMYsjBCXSJfUehLa9TDW3Ffh45SQa7xb6dUs18mpNxfUhQGqfwXPSMrvKhVp",
"label": "Secondary account",
"tag": "myTag",
"unlocked_balance": 0
}],
"total_balance": 157663195572433688,
"total_unlocked_balance": 157443303037455077
}
}
```
### **create_account**
Create a new account with an optional label.
Alias: *None*.
Inputs:
* *label* - string; (Optional) Label for the account.
Outputs:
* *account_index* - unsigned int; Index of the new account.
* *address* - string; Address for this account. Base58 representation of the public keys.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"create_account","params":{"label":"Secondary account"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"account_index": 1,
"address": "77Vx9cs1VPicFndSVgYUvTdLCJEZw9h81hXLMYsjBCXSJfUehLa9TDW3Ffh45SQa7xb6dUs18mpNxfUhQGqfwXPSMrvKhVp"
}
}
```
### **label_account**
Label an account.
Alias: *None*.
Inputs:
* *account_index* - unsigned int; Apply label to account at this index.
* *label* - string; Label for the account.
Outputs: *None*.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"label_account","params":{"account_index":0,"label":"Primary account"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"account_tags": [{
"accounts": [0,1],
"label": "",
"tag": "myTag"
}]
}
}
```
### **get_account_tags**
Get a list of user-defined account tags.
Alias: *None*.
Inputs: *None*.
Outputs:
* *account_tags* - array of account tag information:
* *tag* - string; Filter tag.
* *label* - string; Label for the tag.
* *accounts* - array of int; List of tagged account indices.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_account_tags","params":""}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"account_tags": [{
"accounts": [0],
"label": "Test tag",
"tag": "myTag"
}]
}
}
```
### **tag_accounts**
Apply a filtering tag to a list of accounts.
Alias: *None*.
Inputs:
* *tag* - string; Tag for the accounts.
* *accounts* - array of unsigned int; Tag this list of accounts.
Outputs: *None*.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"tag_accounts","params":{"tag":"myTag","accounts":[0,1]}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
}
}
```
### **untag_accounts**
Remove filtering tag from a list of accounts.
Alias: *None*.
Inputs:
* *accounts* - array of unsigned int; Remove tag from this list of accounts.
Outputs: *None*.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"untag_accounts","params":{"accounts":[1]}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
}
}
```
### **set_account_tag_description**
Set description for an account tag.
Alias: *None*.
Inputs:
* *tag* - string; Set a description for this tag.
* *description* - string; Description for the tag.
Outputs: *None*.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"set_account_tag_description","params":{"tag":"myTag","description":"Test tag"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
}
}
```
### **get_height**
Returns the wallet's current block height.
Alias: *getheight*.
Inputs: *None*.
Outputs:
* *height* - unsigned int; The current monero-wallet-rpc's blockchain height. If the wallet has been offline for a long time, it may need to catch up with the daemon.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_height"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"height": 145545
}
}
```
### **transfer**
Send monero to a number of recipients.
Alias: *None*.
Inputs:
* *destinations* - array of destinations to receive XMR:
* *amount* - unsigned int; Amount to send to each destination, in @atomic-units.
* *address* - string; Destination public address.
* *account_index* - unsigned int; (Optional) Transfer from this account index. (Defaults to 0)
* *subaddr_indices* - array of unsigned int; (Optional) Transfer from this set of subaddresses. (Defaults to empty - all indices)
* *priority* - unsigned int; Set a priority for the transaction. Accepted Values are: 0-3 for: default, unimportant, normal, elevated, priority.
* *mixin* - unsigned int; Number of outputs from the blockchain to mix with (0 means no mixing).
* *ring_size* - unsigned int; Number of outputs to mix in the transaction (this output + N decoys from the blockchain).
* *unlock_time* - unsigned int; Number of blocks before the monero can be spent (0 to not add a lock).
* *payment_id* - string; (Optional) Random 32-byte/64-character hex string to identify a transaction.
* *get_tx_key* - boolean; (Optional) Return the transaction key after sending.
* *do_not_relay* - boolean; (Optional) If true, the newly created transaction will not be relayed to the monero network. (Defaults to false)
* *get_tx_hex* - boolean; Return the transaction as hex string after sending (Defaults to false)
* *get_tx_metadata* - boolean; Return the metadata needed to relay the transaction. (Defaults to false)
Outputs:
* *amount* - Amount transferred for the transaction.
* *fee* - Integer value of the fee charged for the txn.
* *multisig_txset* - Set of multisig transactions in the process of being signed (empty for non-multisig).
* *tx_blob* - Raw transaction represented as hex string, if get_tx_hex is true.
* *tx_hash* - String for the publically searchable transaction hash.
* *tx_key* - String for the transaction key if get_tx_key is true, otherwise, blank string.
* *tx_metadata* - Set of transaction metadata needed to relay this transfer later, if get_tx_metadata is true.
* *unsigned_txset* - String. Set of unsigned tx for cold-signing purposes.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"transfer","params":{"destinations":[{"amount":100000000000,"address":"7BnERTpvL5MbCLtj5n9No7J5oE5hHiB3tVCK5cjSvCsYWD2WRJLFuWeKTLiXo5QJqt2ZwUaLy2Vh1Ad51K7FNgqcHgjW85o"},{"amount":200000000000,"address":"75sNpRwUtekcJGejMuLSGA71QFuK1qcCVLZnYRTfQLgFU5nJ7xiAHtR5ihioS53KMe8pBhH61moraZHyLoG4G7fMER8xkNv"}],"account_index":0,"subaddr_indices":[0],"priority":0,"ring_size":7,"get_tx_key": true}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"amount": 300000000000,
"fee": 86897600000,
"multisig_txset": "",
"tx_blob": "",
"tx_hash": "7663438de4f72b25a0e395b770ea9ecf7108cd2f0c4b75be0b14a103d3362be9",
"tx_key": "25c9d8ec20045c80c93d665c9d3684aab7335f8b2cd02e1ba2638485afd1c70e236c4bdd7a2f1cb511dbf466f13421bdf8df988b7b969c448ca6239d7251490e4bf1bbf9f6ffacffdcdc93b9d1648ec499eada4d6b4e02ce92d4a1c0452e5d009fbbbf15b549df8856205a4c7bda6338d82c823f911acd00cb75850b198c5803",
"tx_metadata": "",
"unsigned_txset": ""
}
}
```
### **transfer_split**
Same as transfer, but can split into more than one tx if necessary.
Alias: *None*.
Inputs:
* *destinations* - array of destinations to receive XMR:
* *amount* - unsigned int; Amount to send to each destination, in @atomic-units.
* *address* - string; Destination public address.
* *account_index* - unsigned int; (Optional) Transfer from this account index. (Defaults to 0)
* *subaddr_indices* - array of unsigned int; (Optional) Transfer from this set of subaddresses. (Defaults to empty - all indices)
* *mixin* - unsigned int; Number of outputs from the blockchain to mix with (0 means no mixing).
* *ring_size* - unsigned int; Sets ringsize to n (mixin + 1).
* *unlock_time* - unsigned int; Number of blocks before the monero can be spent (0 to not add a lock).
* *payment_id* - string; (Optional) Random 32-byte/64-character hex string to identify a transaction.
* *get_tx_keys* - boolean; (Optional) Return the transaction keys after sending.
* *priority* - unsigned int; Set a priority for the transactions. Accepted Values are: 0-3 for: default, unimportant, normal, elevated, priority.
* *do_not_relay* - boolean; (Optional) If true, the newly created transaction will not be relayed to the monero network. (Defaults to false)
* *get_tx_hex* - boolean; Return the transactions as hex string after sending
* *new_algorithm* - boolean; True to use the new transaction construction algorithm, defaults to false.
* *get_tx_metadata* - boolean; Return list of transaction metadata needed to relay the transfer later.
Outputs:
* *tx_hash_list* - array of: string. The tx hashes of every transaction.
* *tx_key_list* - array of: string. The transaction keys for every transaction.
* *amount_list* - array of: integer. The amount transferred for every transaction.
* *fee_list* - array of: integer. The amount of fees paid for every transaction.
* *tx_blob_list* - array of: string. The tx as hex string for every transaction.
* *tx_metadata_list* - array of: string. List of transaction metadata needed to relay the transactions later.
* *multisig_txset* - string. The set of signing keys used in a multisig transaction (empty for non-multisig).
* *unsigned_txset* - string. Set of unsigned tx for cold-signing purposes.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"transfer_split","params":{"destinations":[{"amount":1000000000000,"address":"7BnERTpvL5MbCLtj5n9No7J5oE5hHiB3tVCK5cjSvCsYWD2WRJLFuWeKTLiXo5QJqt2ZwUaLy2Vh1Ad51K7FNgqcHgjW85o"},{"amount":2000000000000,"address":"75sNpRwUtekcJGejMuLSGA71QFuK1qcCVLZnYRTfQLgFU5nJ7xiAHtR5ihioS53KMe8pBhH61moraZHyLoG4G7fMER8xkNv"}],"account_index":0,"subaddr_indices":[0],"priority":0,"ring_size":7,"get_tx_keys": true}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"amount_list": [3000000000000],
"fee_list": [473710000],
"multisig_txset": "",
"tx_hash_list": ["4adcdc1af3f665770cdf8fb7a380887cd07ac53c2b771bd18df5ca375d5e7540"],
"tx_key_list": ["5b455c0f97168be652a2c03c5c68a064bb84cdae4ddef01b5c48d73a0bbb27075fb714f2ca19ea6c8ff592417e606addea6deb1d6530e2969f75681ffcbfc4075677b94a8c9197963ae38fa6f543ee68f0a4c4bbda4c453f39538f00b28e980ea08509730b51c004960101ba2f3adbc34cbbdff0d5af9dba061b523090debd06"],
"unsigned_txset": ""
}
}
```
### **sign_transfer**
Sign a transaction created on a read-only wallet (in cold-signing process)
Alias: *None*.
Inputs:
* *unsigned_txset* - string. Set of unsigned tx returned by "transfer" or "transfer_split" methods.
* *export_raw* - boolean; (Optional) If true, return the raw transaction data. (Defaults to false)
Outputs:
* *signed_txset* - string. Set of signed tx to be used for submitting transfer.
* *tx_hash_list* - array of: string. The tx hashes of every transaction.
* *tx_raw_list* - array of: string. The tx raw data of every transaction.
In the example below, we first generate an unsigned_txset on a read only wallet before signing it:
Generate unsigned_txset using the above "transfer" method on read-only wallet:
```
curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"transfer","params":{"destinations":[{"amount":1000000000000,"address":"7BnERTpvL5MbCLtj5n9No7J5oE5hHiB3tVCK5cjSvCsYWD2WRJLFuWeKTLiXo5QJqt2ZwUaLy2Vh1Ad51K7FNgqcHgjW85o"}],"account_index":0,"subaddr_indices":[0],"priority":0,"ring_size":7,"do_not_relay":true,"get_tx_hex":true}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"amount": 1000000000000,
"fee": 15202740000,
"multisig_txset": "",
"tx_blob": "...long_hex...",
"tx_hash": "c648ba0a049e5ce4ec21361dbf6e4b21eac0f828eea9090215de86c76b31d0a4",
"tx_key": "",
"tx_metadata": "",
"unsigned_txset": "...long_hex..."
}
}
```
Sign tx using the previously generated unsigned_txset
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"sign_transfer","params":{"unsigned_txset":...long_hex..."}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"signed_txset": "...long_hex...",
"tx_hash_list": ["ff2e2d49fbfb1c9a55754f786576e171c8bf21b463a74438df604b7fa6cebc6d"]
}
}
```
### **submit_transfer**
Submit a previously signed transaction on a read-only wallet (in cold-signing process).
Alias: *None*.
Inputs:
* *tx_data_hex* - string; Set of signed tx returned by "sign_transfer"
Outputs:
* *tx_hash_list* - array of: string. The tx hashes of every transaction.
In the example below, we submit the transfer using the signed_txset generated above:
```
curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"submit_transfer","params":{"tx_data_hex":...long_hex..."}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"tx_hash_list": ["40fad7c828bb383ac02648732f7afce9adc520ba5629e1f5d9c03f584ac53d74"]
}
}
```
### **sweep_dust**
Send all dust outputs back to the wallet's, to make them easier to spend (and mix).
Alias: *sweep_unmixable*.
Inputs:
* *get_tx_keys* - boolean; (Optional) Return the transaction keys after sending.
* *do_not_relay* - boolean; (Optional) If true, the newly created transaction will not be relayed to the monero network. (Defaults to false)
* *get_tx_hex* - boolean; (Optional) Return the transactions as hex string after sending. (Defaults to false)
* *get_tx_metadata* - boolean; (Optional) Return list of transaction metadata needed to relay the transfer later. (Defaults to false)
Outputs:
* *tx_hash_list* - array of: string. The tx hashes of every transaction.
* *tx_key_list* - array of: string. The transaction keys for every transaction.
* *amount_list* - array of: integer. The amount transferred for every transaction.
* *fee_list* - array of: integer. The amount of fees paid for every transaction.
* *tx_blob_list* - array of: string. The tx as hex string for every transaction.
* *tx_metadata_list* - array of: string. List of transaction metadata needed to relay the transactions later.
* *multisig_txset* - string. The set of signing keys used in a multisig transaction (empty for non-multisig).
* *unsigned_txset* - string. Set of unsigned tx for cold-signing purposes.
Example (In this example, `sweep_dust` returns nothing because there are no funds to sweep):
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"sweep_dust","params":{"get_tx_keys":true}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"multisig_txset": "",
"unsigned_txset": ""
}
}
```
### **sweep_all**
Send all unlocked balance to an address.
Alias: *None*.
Inputs:
* *address* - string; Destination public address.
* *account_index* - unsigned int; Sweep transactions from this account.
* *subaddr_indices* - array of unsigned int; (Optional) Sweep from this set of subaddresses in the account.
* *priority* - unsigned int; (Optional) Priority for sending the sweep transfer, partially determines fee.
* *mixin* - unsigned int; Number of outputs from the blockchain to mix with (0 means no mixing).
* *ring_size* - unsigned int; Sets ringsize to n (mixin + 1).
* *unlock_time* - unsigned int; Number of blocks before the monero can be spent (0 to not add a lock).
* *payment_id* - string; (Optional) Random 32-byte/64-character hex string to identify a transaction.
* *get_tx_keys* - boolean; (Optional) Return the transaction keys after sending.
* *below_amount* - unsigned int; (Optional) Include outputs below this amount.
* *do_not_relay* - boolean; (Optional) If true, do not relay this sweep transfer. (Defaults to false)
* *get_tx_hex* - boolean; (Optional) return the transactions as hex encoded string. (Defaults to false)
* *get_tx_metadata* - boolean; (Optional) return the transaction metadata as a string. (Defaults to false)
Outputs:
* *tx_hash_list* - array of: string. The tx hashes of every transaction.
* *tx_key_list* - array of: string. The transaction keys for every transaction.
* *amount_list* - array of: integer. The amount transferred for every transaction.
* *fee_list* - array of: integer. The amount of fees paid for every transaction.
* *tx_blob_list* - array of: string. The tx as hex string for every transaction.
* *tx_metadata_list* - array of: string. List of transaction metadata needed to relay the transactions later.
* *multisig_txset* - string. The set of signing keys used in a multisig transaction (empty for non-multisig).
* *unsigned_txset* - string. Set of unsigned tx for cold-signing purposes.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"sweep_all","params":{"address":"55LTR8KniP4LQGJSPtbYDacR7dz8RBFnsfAKMaMuwUNYX6aQbBcovzDPyrQF9KXF9tVU6Xk3K8no1BywnJX6GvZX8yJsXvt","subaddr_indices":[4],"ring_size":7,"unlock_time":0,"get_tx_keys":true}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"amount_list": [9985885770000],
"fee_list": [14114230000],
"multisig_txset": "",
"tx_hash_list": ["ab4b6b65cc8cd8c9dd317d0b90d97582d68d0aa1637b0065b05b61f9a66ea5c5"],
"tx_key_list": ["b9b4b39d3bb3062ddb85ec0266d4df39058f4c86077d99309f218ce4d76af607"],
"unsigned_txset": ""
}
}
```
### **sweep_single**
Send all of a specific unlocked output to an address.
Alias: *None*.
Inputs:
* *address* - string; Destination public address.
* *account_index* - unsigned int; Sweep transactions from this account.
* *subaddr_indices* - array of unsigned int; (Optional) Sweep from this set of subaddresses in the account.
* *priority* - unsigned int; (Optional) Priority for sending the sweep transfer, partially determines fee.
* *mixin* - unsigned int; Number of outputs from the blockchain to mix with (0 means no mixing).
* *ring_size* - unsigned int; Sets ringsize to n (mixin + 1).
* *unlock_time* - unsigned int; Number of blocks before the monero can be spent (0 to not add a lock).
* *payment_id* - string; (Optional) Random 32-byte/64-character hex string to identify a transaction.
* *get_tx_keys* - boolean; (Optional) Return the transaction keys after sending.
* *key_image* - string; Key image of specific output to sweep.
* *below_amount* - unsigned int; (Optional) Include outputs below this amount.
* *do_not_relay* - boolean; (Optional) If true, do not relay this sweep transfer. (Defaults to false)
* *get_tx_hex* - boolean; (Optional) return the transactions as hex encoded string. (Defaults to false)
* *get_tx_metadata* - boolean; (Optional) return the transaction metadata as a string. (Defaults to false)
Outputs:
* *tx_hash_list* - array of: string. The tx hashes of every transaction.
* *tx_key_list* - array of: string. The transaction keys for every transaction.
* *amount_list* - array of: integer. The amount transferred for every transaction.
* *fee_list* - array of: integer. The amount of fees paid for every transaction.
* *tx_blob_list* - array of: string. The tx as hex string for every transaction.
* *tx_metadata_list* - array of: string. List of transaction metadata needed to relay the transactions later.
* *multisig_txset* - string. The set of signing keys used in a multisig transaction (empty for non-multisig).
* *unsigned_txset* - string. Set of unsigned tx for cold-signing purposes.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"sweep_single","params":{"address":"74Jsocx8xbpTBEjm3ncKE5LBQbiJouyCDaGhgSiebpvNDXZnTAbW2CmUR5SsBeae2pNk9WMVuz6jegkC4krUyqRjA6VjoLD","ring_size":7,"unlock_time":0,"key_image":"a7834459ef795d2efb6f665d2fd758c8d9288989d8d4c712a68f8023f7804a5e","get_tx_keys":true}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"amount": 27126892247503,
"fee": 14111630000,
"multisig_txset": "",
"tx_blob": "",
"tx_hash": "106d4391a031e5b735ded555862fec63233e34e5fa4fc7edcfdbe461c275ae5b",
"tx_key": "",
"tx_metadata": "",
"unsigned_txset": ""
}
}
```
### **relay_tx**
Relay a transaction previously created with `"do_not_relay":true`.
Alias: *None*.
Inputs:
* *hex* - string; transaction metadata returned from a `transfer` method with `get_tx_metadata` set to `true`.
Outputs:
* *tx_hash* - String for the publically searchable transaction hash.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"relay_tx","params":{"hex":"...tx_metadata..."}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"tx_hash": "1c42dcc5672bb09bccf33fb1e9ab4a498af59a6dbd33b3d0cfb289b9e0e25fa5"
}
}
```
### **store**
Save the wallet file.
Alias: *None*.
Inputs: *None*.
Outputs: *None*.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"store"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
}
}
```
### **get_payments**
Get a list of incoming payments using a given payment id.
Alias: *None*.
Inputs:
* *payment_id* - string; Payment ID used to find the payments (16 characters hex).
Outputs:
* *payments* - list of:
* *payment_id* - string; Payment ID matching the input parameter.
* *tx_hash* - string; Transaction hash used as the transaction ID.
* *amount* - unsigned int; Amount for this payment.
* *block_height* - unsigned int; Height of the block that first confirmed this payment.
* *unlock_time* - unsigned int; Time (in block height) until this payment is safe to spend.
* *subaddr_index* - subaddress index:
* *major* - unsigned int; Account index for the subaddress.
* *minor* - unsigned int; Index of the subaddress in the account.
* *address* - string; Address receiving the payment; Base58 representation of the public keys.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_payments","params":{"payment_id":"60900e5603bf96e3"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"payments": [{
"address": "55LTR8KniP4LQGJSPtbYDacR7dz8RBFnsfAKMaMuwUNYX6aQbBcovzDPyrQF9KXF9tVU6Xk3K8no1BywnJX6GvZX8yJsXvt",
"amount": 1000000000000,
"block_height": 127606,
"payment_id": "60900e5603bf96e3",
"subaddr_index": {
"major": 0,
"minor": 0
},
"tx_hash": "3292e83ad28fc1cc7bc26dbd38862308f4588680fbf93eae3e803cddd1bd614f",
"unlock_time": 0
}]
}
}
```
### **get_bulk_payments**
Get a list of incoming payments using a given payment id, or a list of payments ids, from a given height. This method is the preferred method over `get_payments` because it has the same functionality but is more extendable. Either is fine for looking up transactions by a single payment ID.
Alias: *None*.
Inputs:
* *payment_ids* - array of: string; Payment IDs used to find the payments (16 characters hex).
* *min_block_height* - unsigned int; The block height at which to start looking for payments.
Outputs:
* *payments* - list of:
* *payment_id* - string; Payment ID matching one of the input IDs.
* *tx_hash* - string; Transaction hash used as the transaction ID.
* *amount* - unsigned int; Amount for this payment.
* *block_height* - unsigned int; Height of the block that first confirmed this payment.
* *unlock_time* - unsigned int; Time (in block height) until this payment is safe to spend.
* *subaddr_index* - subaddress index:
* *major* - unsigned int; Account index for the subaddress.
* *minor* - unsigned int; Index of the subaddress in the account.
* *address* - string; Address receiving the payment; Base58 representation of the public keys.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_bulk_payments","params":{"payment_ids":["60900e5603bf96e3"],"min_block_height":"120000"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"payments": [{
"address": "55LTR8KniP4LQGJSPtbYDacR7dz8RBFnsfAKMaMuwUNYX6aQbBcovzDPyrQF9KXF9tVU6Xk3K8no1BywnJX6GvZX8yJsXvt",
"amount": 1000000000000,
"block_height": 127606,
"payment_id": "60900e5603bf96e3",
"subaddr_index": {
"major": 0,
"minor": 0
},
"tx_hash": "3292e83ad28fc1cc7bc26dbd38862308f4588680fbf93eae3e803cddd1bd614f",
"unlock_time": 0
}]
}
}
```
### **incoming_transfers**
Return a list of incoming transfers to the wallet.
Inputs:
* *transfer_type* - string; "all": all the transfers, "available": only transfers which are not yet spent, OR "unavailable": only transfers which are already spent.
* *account_index* - unsigned int; (Optional) Return transfers for this account. (defaults to 0)
* *subaddr_indices* - array of unsigned int; (Optional) Return transfers sent to these subaddresses.
* *verbose* - boolean; (Optional) Enable verbose output, return key image if true.
Outputs:
* *transfers* - list of:
* *amount* - unsigned int; Amount of this transfer.
* *global_index* - unsigned int; Mostly internal use, can be ignored by most users.
* *key_image* - string; Key image for the incoming transfer's unspent output (empty unless verbose is true).
* *spent* - boolean; Indicates if this transfer has been spent.
* *subaddr_index* - unsigned int; Subaddress index for incoming transfer.
* *tx_hash* - string; Several incoming transfers may share the same hash if they were in the same transaction.
* *tx_size* - unsigned int; Size of transaction in bytes.
Example, get all transfers:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"incoming_transfers","params":{"transfer_type":"all","account_index":0,"subaddr_indices":[3],"verbose":true}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"transfers": [{
"amount": 60000000000000,
"global_index": 122405,
"key_image": "768f5144777eb23477ab7acf83562581d690abaf98ca897c03a9d2b900eb479b",
"spent": true,
"subaddr_index": 3,
"tx_hash": "f53401f21c6a43e44d5dd7a90eba5cf580012ad0e15d050059136f8a0da34f6b",
"tx_size": 159
},{
"amount": 27126892247503,
"global_index": 594994,
"key_image": "7e561394806afd1be61980cc3431f6ef3569fa9151cd8d234f8ec13aa145695e",
"spent": false,
"subaddr_index": 3,
"tx_hash": "106d4391a031e5b735ded555862fec63233e34e5fa4fc7edcfdbe461c275ae5b",
"tx_size": 157
},{
"amount": 27169374733655,
"global_index": 594997,
"key_image": "e76c0a3bfeaae35e4173712f782eb34011198e26b990225b71aa787c8ba8a157",
"spent": false,
"subaddr_index": 3,
"tx_hash": "0bd959b59117ee1254bd8e5aa8e77ec04ef744144a1ffb2d5c1eb9380a719621",
"tx_size": 158
}]
}
}
```
Example, get available transfers:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"incoming_transfers","params":{"transfer_type":"available","account_index":0,"subaddr_indices":[3],"verbose":true}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"transfers": [{
"amount": 27126892247503,
"global_index": 594994,
"key_image": "7e561394806afd1be61980cc3431f6ef3569fa9151cd8d234f8ec13aa145695e",
"spent": false,
"subaddr_index": 3,
"tx_hash": "106d4391a031e5b735ded555862fec63233e34e5fa4fc7edcfdbe461c275ae5b",
"tx_size": 157
},{
"amount": 27169374733655,
"global_index": 594997,
"key_image": "e76c0a3bfeaae35e4173712f782eb34011198e26b990225b71aa787c8ba8a157",
"spent": false,
"subaddr_index": 3,
"tx_hash": "0bd959b59117ee1254bd8e5aa8e77ec04ef744144a1ffb2d5c1eb9380a719621",
"tx_size": 158
}]
}
}
```
Example, get unavailable transfers:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"incoming_transfers","params":{"transfer_type":"unavailable","account_index":0,"subaddr_indices":[3],"verbose":true}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"transfers": [{
"amount": 60000000000000,
"global_index": 122405,
"key_image": "768f5144777eb23477ab7acf83562581d690abaf98ca897c03a9d2b900eb479b",
"spent": true,
"subaddr_index": 3,
"tx_hash": "f53401f21c6a43e44d5dd7a90eba5cf580012ad0e15d050059136f8a0da34f6b",
"tx_size": 159
}]
}
}
```
### **query_key**
Return the spend or view private key.
Alias: *None*.
Inputs:
* *key_type* - string; Which key to retrieve: "mnemonic" - the mnemonic seed (older wallets do not have one) OR "view_key" - the view key
Outputs:
* *key* - string; The view key will be hex encoded, while the mnemonic will be a string of words.
Example (Query view key):
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"query_key","params":{"key_type":"view_key"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"key": "0a1a38f6d246e894600a3e27238a064bf5e8d91801df47a17107596b1378e501"
}
}
```
Example (Query mnemonic key):
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"query_key","params":{"key_type":"mnemonic"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"key": "vocal either anvil films dolphin zeal bacon cuisine quote syndrome rejoices envy okay pancakes tulips lair greater petals organs enmity dedicated oust thwart tomorrow tomorrow"
}
}
```
### **make_integrated_address**
Make an integrated address from the wallet address and a payment id.
Alias: *None*.
Inputs:
* *standard_address* - string; (Optional, defaults to primary address) Destination public address.
* *payment_id* - string; (Optional, defaults to a random ID) 16 characters hex encoded.
Outputs:
* *integrated_address* - string
* *payment_id* - string; hex encoded;
Example (Payment ID is empty, use a random ID):
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"make_integrated_address","params":{"standard_address":"55LTR8KniP4LQGJSPtbYDacR7dz8RBFnsfAKMaMuwUNYX6aQbBcovzDPyrQF9KXF9tVU6Xk3K8no1BywnJX6GvZX8yJsXvt"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"integrated_address": "5F38Rw9HKeaLQGJSPtbYDacR7dz8RBFnsfAKMaMuwUNYX6aQbBcovzDPyrQF9KXF9tVU6Xk3K8no1BywnJX6GvZXCkbHUXdPHyiUeRyokn",
"payment_id": "420fa29b2d9a49f5"
}
}
```
### **split_integrated_address**
Retrieve the standard address and payment id corresponding to an integrated address.
Alias: *None*.
Inputs:
* *integrated_address* - string
Outputs:
* *is_subaddress* - boolean; States if the address is a subaddress
* *payment* - string; hex encoded
* *standard_address* - string
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"split_integrated_address","params":{"integrated_address": "5F38Rw9HKeaLQGJSPtbYDacR7dz8RBFnsfAKMaMuwUNYX6aQbBcovzDPyrQF9KXF9tVU6Xk3K8no1BywnJX6GvZXCkbHUXdPHyiUeRyokn"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"is_subaddress": false,
"payment_id": "420fa29b2d9a49f5",
"standard_address": "55LTR8KniP4LQGJSPtbYDacR7dz8RBFnsfAKMaMuwUNYX6aQbBcovzDPyrQF9KXF9tVU6Xk3K8no1BywnJX6GvZX8yJsXvt"
}
}
```
### **stop_wallet**
Stops the wallet, storing the current state.
Alias: *None*.
Inputs: *None*.
Outputs: *None*.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"stop_wallet"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
}
}
```
### **rescan_blockchain**
Rescan the blockchain from scratch, losing any information which can not be recovered from the blockchain itself.
This includes destination addresses, tx secret keys, tx notes, etc.
Alias: *None*.
Inputs: *None*.
Outputs: *None*.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"rescan_blockchain"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
}
}
```
### **set_tx_notes**
Set arbitrary string notes for transactions.
Alias: *None*.
Inputs:
* *txids* - array of string; transaction ids
* *notes* - array of string; notes for the transactions
Outputs: *None*.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"set_tx_notes","params":{"txids":["3292e83ad28fc1cc7bc26dbd38862308f4588680fbf93eae3e803cddd1bd614f"],"notes":["This is an example"]}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
}
}
```
### **get_tx_notes**
Get string notes for transactions.
Alias: *None*.
Inputs:
* *txids* - array of string; transaction ids
Outputs:
* *notes* - array of string; notes for the transactions
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_tx_notes","params":{"txids":["3292e83ad28fc1cc7bc26dbd38862308f4588680fbf93eae3e803cddd1bd614f"]}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"notes": ["This is an example"]
}
}
```
### **set_attribute**
Set arbitrary attribute.
Alias: *None*.
Inputs:
* *key* - string; attribute name
* *value* - string; attribute value
Outputs: *None*.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"set_attribute","params":{"key":"my_attribute","value":"my_value"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
}
}
```
### **get_attribute**
Get attribute value by name.
Alias: *None*.
Inputs:
* *key* - string; attribute name
Outputs:
* *value* - string; attribute value
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_attribute","params":{"key":"my_attribute"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"value": "my_value"
}
}
```
### **get_tx_key**
Get transaction secret key from transaction id.
Alias: *None*.
Inputs:
* *txid* - string; transaction id.
Outputs:
* *tx_key* - string; transaction secret key.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_tx_key","params":{"txid":"19d5089f9469db3d90aca9024dfcb17ce94b948300101c8345a5e9f7257353be"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"tx_key": "feba662cf8fb6d0d0da18fc9b70ab28e01cc76311278fdd7fe7ab16360762b06"
}
}
```
### **check_tx_key**
Check a transaction in the blockchain with its secret key.
Alias: *None*.
Inputs:
* *txid* - string; transaction id.
* *tx_key* - string; transaction secret key.
* *address* - string; destination public address of the transaction.
Outputs:
* *confirmations* - unsigned int; Number of block mined after the one with the transaction.
* *in_pool* - boolean; States if the transaction is still in pool or has been added to a block.
* *received* - unsigned int; Amount of the transaction.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"check_tx_key","params":{"txid":"19d5089f9469db3d90aca9024dfcb17ce94b948300101c8345a5e9f7257353be","tx_key":"feba662cf8fb6d0d0da18fc9b70ab28e01cc76311278fdd7fe7ab16360762b06","address":"7BnERTpvL5MbCLtj5n9No7J5oE5hHiB3tVCK5cjSvCsYWD2WRJLFuWeKTLiXo5QJqt2ZwUaLy2Vh1Ad51K7FNgqcHgjW85o"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"confirmations": 0,
"in_pool": false,
"received": 1000000000000
}
}
```
### **get_tx_proof**
Get transaction signature to prove it.
Alias: *None*.
Inputs:
* *txid* - string; transaction id.
* *address* - string; destination public address of the transaction.
* *message* - string; (Optional) add a message to the signature to further authenticate the prooving process.
Outputs:
* *signature* - string; transaction signature.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_tx_proof","params":{"txid":"19d5089f9469db3d90aca9024dfcb17ce94b948300101c8345a5e9f7257353be","address":"7BnERTpvL5MbCLtj5n9No7J5oE5hHiB3tVCK5cjSvCsYWD2WRJLFuWeKTLiXo5QJqt2ZwUaLy2Vh1Ad51K7FNgqcHgjW85o","message":"this is my transaction"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"signature": "InProofV13vqBCT6dpSAXkypZmSEMPGVnNRFDX2vscUYeVS4WnSVnV5BwLs31T9q6Etfj9Wts6tAxSAS4gkMeSYzzLS7Gt4vvCSQRh9niGJMUDJsB5hTzb2XJiCkUzWkkcjLFBBRVD5QZ"
}
}
```
### **check_tx_proof**
Prove a transaction by checking its signature.
Alias: *None*.
Inputs:
* *txid* - string; transaction id.
* *address* - string; destination public address of the transaction.
* *message* - string; (Optional) Should be the same message used in `get_tx_proof`.
* *signature* - string; transaction signature to confirm.
Outputs:
* *confirmations* - unsigned int; Number of block mined after the one with the transaction.
* *good* - boolean; States if the inputs proves the transaction.
* *in_pool* - boolean; States if the transaction is still in pool or has been added to a block.
* *received* - unsigned int; Amount of the transaction.
In the example below, the transaction has been proven:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"check_tx_proof","params":{"txid":"19d5089f9469db3d90aca9024dfcb17ce94b948300101c8345a5e9f7257353be","address":"7BnERTpvL5MbCLtj5n9No7J5oE5hHiB3tVCK5cjSvCsYWD2WRJLFuWeKTLiXo5QJqt2ZwUaLy2Vh1Ad51K7FNgqcHgjW85o","message":"this is my transaction","signature":"InProofV13vqBCT6dpSAXkypZmSEMPGVnNRFDX2vscUYeVS4WnSVnV5BwLs31T9q6Etfj9Wts6tAxSAS4gkMeSYzzLS7Gt4vvCSQRh9niGJMUDJsB5hTzb2XJiCkUzWkkcjLFBBRVD5QZ"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"confirmations": 482,
"good": true,
"in_pool": false,
"received": 1000000000000
}
}
```
In the example below, the wrong message is used, avoiding the transaction to be proved:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"check_tx_proof","params":{"txid":"19d5089f9469db3d90aca9024dfcb17ce94b948300101c8345a5e9f7257353be","address":"7BnERTpvL5MbCLtj5n9No7J5oE5hHiB3tVCK5cjSvCsYWD2WRJLFuWeKTLiXo5QJqt2ZwUaLy2Vh1Ad51K7FNgqcHgjW85o","message":"wrong message","signature":"InProofV13vqBCT6dpSAXkypZmSEMPGVnNRFDX2vscUYeVS4WnSVnV5BwLs31T9q6Etfj9Wts6tAxSAS4gkMeSYzzLS7Gt4vvCSQRh9niGJMUDJsB5hTzb2XJiCkUzWkkcjLFBBRVD5QZ"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"confirmations": 0,
"good": false,
"in_pool": false,
"received": 0
}
}
```
### **get_spend_proof**
Generate a signature to prove a spend. Unlike proving a transaction, it does not requires the destination public address.
Alias: *None*.
Inputs:
* *txid* - string; transaction id.
* *message* - string; (Optional) add a message to the signature to further authenticate the prooving process.
Outputs:
* *signature* - string; spend signature.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_spend_proof","params":{"txid":"19d5089f9469db3d90aca9024dfcb17ce94b948300101c8345a5e9f7257353be","message":"this is my transaction"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"signature": "SpendProofV1aSh8Todhk54736iXgV6vJAFP7egxByuMWZeyNDaN2JY737S95X5zz5mNMQSuCNSLjjhi5HJCsndpNWSNVsuThxwv285qy1KkUrLFRkxMSCjfL6bbycYN33ScZ5UB4Fzseceo1ndpL393T1q638VmcU3a56dhNHF1RPZFiGPS61FA78nXFSqE9uoKCCoHkEz83M1dQVhxZV5CEPF2P6VioGTKgprLCH9vvj9k1ivd4SX19L2VSMc3zD1u3mkR24ioETvxBoLeBSpxMoikyZ6inhuPm8yYo9YWyFtQK4XYfAV9mJ9knz5fUPXR8vvh7KJCAg4dqeJXTVb4mbMzYtsSZXHd6ouWoyCd6qMALdW8pKhgMCHcVYMWp9X9WHZuCo9rsRjRpg15sJUw7oJg1JoGiVgj8P4JeGDjnZHnmLVa5bpJhVCbMhyM7JLXNQJzFWTGC27TQBbthxCfQaKdusYnvZnKPDJWSeceYEFzepUnsWhQtyhbb73FzqgWC4eKEFKAZJqT2LuuSoxmihJ9acnFK7Ze23KTVYgDyMKY61VXADxmSrBvwUtxCaW4nQtnbMxiPMNnDMzeixqsFMBtN72j5UqhiLRY99k6SE7Qf5f29haNSBNSXCFFHChPKNTwJrehkofBdKUhh2VGPqZDNoefWUwfudeu83t85bmjv8Q3LrQSkFgFjRT5tLo8TMawNXoZCrQpyZrEvnodMDDUUNf3NL7rxyv3gM1KrTWjYaWXFU2RAsFee2Q2MTwUW7hR25cJvSFuB1BX2bfkoCbiMk923tHZGU2g7rSKF1GDDkXAc1EvFFD4iGbh1Q5t6hPRhBV8PEncdcCWGq5uAL5D4Bjr6VXG8uNeCy5oYWNgbZ5JRSfm7QEhPv8Fy9AKMgmCxDGMF9dVEaU6tw2BAnJavQdfrxChbDBeQXzCbCfep6oei6n2LZdE5Q84wp7eoQFE5Cwuo23tHkbJCaw2njFi3WGBbA7uGZaGHJPyB2rofTWBiSUXZnP2hiE9bjJghAcDm1M4LVLfWvhZmFEnyeru3VWMETnetz1BYLUC5MJGFXuhnHwWh7F6r74FDyhdswYop4eWPbyrXMXmUQEccTGd2NaT8g2VHADZ76gMC6BjWESvcnz2D4n8XwdmM7ZQ1jFwhuXrBfrb1dwRasyXxxHMGAC2onatNiExyeQ9G1W5LwqNLAh9hvcaNTGaYKYXoceVzLkgm6e5WMkLsCwuZXvB"
}
}
```
### **check_spend_proof**
Prove a spend using a signature. Unlike proving a transaction, it does not requires the destination public address.
Alias: *None*.
Inputs:
* *txid* - string; transaction id.
* *message* - string; (Optional) Should be the same message used in `get_spend_proof`.
* *signature* - string; spend signature to confirm.
Outputs:
* *good* - boolean; States if the inputs proves the spend.
In the example below, the spend has been proven:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"check_spend_proof","params":{"txid":"19d5089f9469db3d90aca9024dfcb17ce94b948300101c8345a5e9f7257353be","message":"this is my transaction","signature":"SpendProofV1aSh8Todhk54736iXgV6vJAFP7egxByuMWZeyNDaN2JY737S95X5zz5mNMQSuCNSLjjhi5HJCsndpNWSNVsuThxwv285qy1KkUrLFRkxMSCjfL6bbycYN33ScZ5UB4Fzseceo1ndpL393T1q638VmcU3a56dhNHF1RPZFiGPS61FA78nXFSqE9uoKCCoHkEz83M1dQVhxZV5CEPF2P6VioGTKgprLCH9vvj9k1ivd4SX19L2VSMc3zD1u3mkR24ioETvxBoLeBSpxMoikyZ6inhuPm8yYo9YWyFtQK4XYfAV9mJ9knz5fUPXR8vvh7KJCAg4dqeJXTVb4mbMzYtsSZXHd6ouWoyCd6qMALdW8pKhgMCHcVYMWp9X9WHZuCo9rsRjRpg15sJUw7oJg1JoGiVgj8P4JeGDjnZHnmLVa5bpJhVCbMhyM7JLXNQJzFWTGC27TQBbthxCfQaKdusYnvZnKPDJWSeceYEFzepUnsWhQtyhbb73FzqgWC4eKEFKAZJqT2LuuSoxmihJ9acnFK7Ze23KTVYgDyMKY61VXADxmSrBvwUtxCaW4nQtnbMxiPMNnDMzeixqsFMBtN72j5UqhiLRY99k6SE7Qf5f29haNSBNSXCFFHChPKNTwJrehkofBdKUhh2VGPqZDNoefWUwfudeu83t85bmjv8Q3LrQSkFgFjRT5tLo8TMawNXoZCrQpyZrEvnodMDDUUNf3NL7rxyv3gM1KrTWjYaWXFU2RAsFee2Q2MTwUW7hR25cJvSFuB1BX2bfkoCbiMk923tHZGU2g7rSKF1GDDkXAc1EvFFD4iGbh1Q5t6hPRhBV8PEncdcCWGq5uAL5D4Bjr6VXG8uNeCy5oYWNgbZ5JRSfm7QEhPv8Fy9AKMgmCxDGMF9dVEaU6tw2BAnJavQdfrxChbDBeQXzCbCfep6oei6n2LZdE5Q84wp7eoQFE5Cwuo23tHkbJCaw2njFi3WGBbA7uGZaGHJPyB2rofTWBiSUXZnP2hiE9bjJghAcDm1M4LVLfWvhZmFEnyeru3VWMETnetz1BYLUC5MJGFXuhnHwWh7F6r74FDyhdswYop4eWPbyrXMXmUQEccTGd2NaT8g2VHADZ76gMC6BjWESvcnz2D4n8XwdmM7ZQ1jFwhuXrBfrb1dwRasyXxxHMGAC2onatNiExyeQ9G1W5LwqNLAh9hvcaNTGaYKYXoceVzLkgm6e5WMkLsCwuZXvB"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"good": true
}
}
```
In the example below, the wrong message is used, avoiding the spend to be proved:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"check_spend_proof","params":{"txid":"19d5089f9469db3d90aca9024dfcb17ce94b948300101c8345a5e9f7257353be","message":"wrong message","signature":"SpendProofV1aSh8Todhk54736iXgV6vJAFP7egxByuMWZeyNDaN2JY737S95X5zz5mNMQSuCNSLjjhi5HJCsndpNWSNVsuThxwv285qy1KkUrLFRkxMSCjfL6bbycYN33ScZ5UB4Fzseceo1ndpL393T1q638VmcU3a56dhNHF1RPZFiGPS61FA78nXFSqE9uoKCCoHkEz83M1dQVhxZV5CEPF2P6VioGTKgprLCH9vvj9k1ivd4SX19L2VSMc3zD1u3mkR24ioETvxBoLeBSpxMoikyZ6inhuPm8yYo9YWyFtQK4XYfAV9mJ9knz5fUPXR8vvh7KJCAg4dqeJXTVb4mbMzYtsSZXHd6ouWoyCd6qMALdW8pKhgMCHcVYMWp9X9WHZuCo9rsRjRpg15sJUw7oJg1JoGiVgj8P4JeGDjnZHnmLVa5bpJhVCbMhyM7JLXNQJzFWTGC27TQBbthxCfQaKdusYnvZnKPDJWSeceYEFzepUnsWhQtyhbb73FzqgWC4eKEFKAZJqT2LuuSoxmihJ9acnFK7Ze23KTVYgDyMKY61VXADxmSrBvwUtxCaW4nQtnbMxiPMNnDMzeixqsFMBtN72j5UqhiLRY99k6SE7Qf5f29haNSBNSXCFFHChPKNTwJrehkofBdKUhh2VGPqZDNoefWUwfudeu83t85bmjv8Q3LrQSkFgFjRT5tLo8TMawNXoZCrQpyZrEvnodMDDUUNf3NL7rxyv3gM1KrTWjYaWXFU2RAsFee2Q2MTwUW7hR25cJvSFuB1BX2bfkoCbiMk923tHZGU2g7rSKF1GDDkXAc1EvFFD4iGbh1Q5t6hPRhBV8PEncdcCWGq5uAL5D4Bjr6VXG8uNeCy5oYWNgbZ5JRSfm7QEhPv8Fy9AKMgmCxDGMF9dVEaU6tw2BAnJavQdfrxChbDBeQXzCbCfep6oei6n2LZdE5Q84wp7eoQFE5Cwuo23tHkbJCaw2njFi3WGBbA7uGZaGHJPyB2rofTWBiSUXZnP2hiE9bjJghAcDm1M4LVLfWvhZmFEnyeru3VWMETnetz1BYLUC5MJGFXuhnHwWh7F6r74FDyhdswYop4eWPbyrXMXmUQEccTGd2NaT8g2VHADZ76gMC6BjWESvcnz2D4n8XwdmM7ZQ1jFwhuXrBfrb1dwRasyXxxHMGAC2onatNiExyeQ9G1W5LwqNLAh9hvcaNTGaYKYXoceVzLkgm6e5WMkLsCwuZXvB"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"good": false
}
}
```
### **get_reserve_proof**
Generate a signature to prove of an available amount in a wallet.
Alias: *None*.
Inputs:
* *all* - boolean; Proves all wallet balance to be disposable.
* *account_index* - unsigned int; Specify the account from witch to prove reserve. (ignored if `all` is set to true)
* *amount* - unsigned int; Amount (in @atomic-units) to prove the account has for reserve. (ignored if `all` is set to true)
* *message* - string; (Optional) add a message to the signature to further authenticate the prooving process.
Outputs:
* *signature* - string; reserve signature.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_reserve_proof","params":{"all":false,"account_index":0,"amount":100000000000}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"signature": "ReserveProofV11BZ23sBt9sZJeGccf84mzyAmNCP3KzYbE1111112VKmH111118NfCYJQjZ6c46gT2kXgcHCaSSZeL8sRdzqjqx7i1e7FQfQGu2o113UYFVdwzHQi3iENDPa76Kn1BvywbKz3bMkXdZkBEEhBSF4kjjGaiMJ1ucKb6wvMVC4A8sA4nZEdL2Mk3wBucJCYTZwKqA8i1M113kqakDkG25FrjiDqdQTCYz2wDBmfKxF3eQiV5FWzZ6HmAyxnqTWUiMWukP9A3Edy3ZXqjP1b23dhz7Mbj39bBxe3ZeDNu9HnTSqYvHNRyqCkeUMJpHyQweqjGUJ1DSfFYr33J1E7MkhMnEi1o7trqWjVix32XLetYfePG73yvHbS24837L7Q64i5n1LSpd9yMiQZ3Dyaysi5y6jPx7TpAvnSqBFtuCciKoNzaXoA3dqt9cuVFZTXzdXKqdt3cXcVJMNxY8RvKPVQHhUur94Lpo1nSpxf7BN5a5rHrbZFqoZszsZmiWikYPkLX72XUdw6NWjLrTBxSy7KuPYH86c6udPEXLo2xgN6XHMBMBJzt8FqqK7EcpNUBkuHm2AtpGkf9CABY3oSjDQoRF5n4vNLd3qUaxNsG4XJ12L9gJ7GrK273BxkfEA8fDdxPrb1gpespbgEnCTuZHqj1A"
}
}
```
### **check_reserve_proof**
Proves a wallet has a disposable reserve using a signature.
Alias: *None*.
Inputs:
* *address* - string; Public address of the wallet.
* *message* - string; (Optional) Should be the same message used in `get_reserve_proof`.
* *signature* - string; reserve signature to confirm.
Outputs:
* *good* - boolean; States if the inputs proves the reserve.
In the example below, the reserve has been proven:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"check_reserve_proof","params":{"address":"55LTR8KniP4LQGJSPtbYDacR7dz8RBFnsfAKMaMuwUNYX6aQbBcovzDPyrQF9KXF9tVU6Xk3K8no1BywnJX6GvZX8yJsXvt","signature":"ReserveProofV11BZ23sBt9sZJeGccf84mzyAmNCP3KzYbE1111112VKmH111118NfCYJQjZ6c46gT2kXgcHCaSSZeL8sRdzqjqx7i1e7FQfQGu2o113UYFVdwzHQi3iENDPa76Kn1BvywbKz3bMkXdZkBEEhBSF4kjjGaiMJ1ucKb6wvMVC4A8sA4nZEdL2Mk3wBucJCYTZwKqA8i1M113kqakDkG25FrjiDqdQTCYz2wDBmfKxF3eQiV5FWzZ6HmAyxnqTWUiMWukP9A3Edy3ZXqjP1b23dhz7Mbj39bBxe3ZeDNu9HnTSqYvHNRyqCkeUMJpHyQweqjGUJ1DSfFYr33J1E7MkhMnEi1o7trqWjVix32XLetYfePG73yvHbS24837L7Q64i5n1LSpd9yMiQZ3Dyaysi5y6jPx7TpAvnSqBFtuCciKoNzaXoA3dqt9cuVFZTXzdXKqdt3cXcVJMNxY8RvKPVQHhUur94Lpo1nSpxf7BN5a5rHrbZFqoZszsZmiWikYPkLX72XUdw6NWjLrTBxSy7KuPYH86c6udPEXLo2xgN6XHMBMBJzt8FqqK7EcpNUBkuHm2AtpGkf9CABY3oSjDQoRF5n4vNLd3qUaxNsG4XJ12L9gJ7GrK273BxkfEA8fDdxPrb1gpespbgEnCTuZHqj1A"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"good": true,
"spent": 0,
"total": 100000000000
}
}
```
In the example below, all wallet reserve has been proven:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"check_reserve_proof","params":{"address":"55LTR8KniP4LQGJSPtbYDacR7dz8RBFnsfAKMaMuwUNYX6aQbBcovzDPyrQF9KXF9tVU6Xk3K8no1BywnJX6GvZX8yJsXvt","message":"I have 10 at least","signature":"...signature..."}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"good": true,
"spent": 0,
"total": 164113855714662789
}
}
```
In the example below, the wrong message is used, avoiding the reserve to be proved:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"check_spend_proof","params":{"txid":"19d5089f9469db3d90aca9024dfcb17ce94b948300101c8345a5e9f7257353be","message":"wrong message","signature":"SpendProofV1aSh8Todhk54736iXgV6vJAFP7egxByuMWZeyNDaN2JY737S95X5zz5mNMQSuCNSLjjhi5HJCsndpNWSNVsuThxwv285qy1KkUrLFRkxMSCjfL6bbycYN33ScZ5UB4Fzseceo1ndpL393T1q638VmcU3a56dhNHF1RPZFiGPS61FA78nXFSqE9uoKCCoHkEz83M1dQVhxZV5CEPF2P6VioGTKgprLCH9vvj9k1ivd4SX19L2VSMc3zD1u3mkR24ioETvxBoLeBSpxMoikyZ6inhuPm8yYo9YWyFtQK4XYfAV9mJ9knz5fUPXR8vvh7KJCAg4dqeJXTVb4mbMzYtsSZXHd6ouWoyCd6qMALdW8pKhgMCHcVYMWp9X9WHZuCo9rsRjRpg15sJUw7oJg1JoGiVgj8P4JeGDjnZHnmLVa5bpJhVCbMhyM7JLXNQJzFWTGC27TQBbthxCfQaKdusYnvZnKPDJWSeceYEFzepUnsWhQtyhbb73FzqgWC4eKEFKAZJqT2LuuSoxmihJ9acnFK7Ze23KTVYgDyMKY61VXADxmSrBvwUtxCaW4nQtnbMxiPMNnDMzeixqsFMBtN72j5UqhiLRY99k6SE7Qf5f29haNSBNSXCFFHChPKNTwJrehkofBdKUhh2VGPqZDNoefWUwfudeu83t85bmjv8Q3LrQSkFgFjRT5tLo8TMawNXoZCrQpyZrEvnodMDDUUNf3NL7rxyv3gM1KrTWjYaWXFU2RAsFee2Q2MTwUW7hR25cJvSFuB1BX2bfkoCbiMk923tHZGU2g7rSKF1GDDkXAc1EvFFD4iGbh1Q5t6hPRhBV8PEncdcCWGq5uAL5D4Bjr6VXG8uNeCy5oYWNgbZ5JRSfm7QEhPv8Fy9AKMgmCxDGMF9dVEaU6tw2BAnJavQdfrxChbDBeQXzCbCfep6oei6n2LZdE5Q84wp7eoQFE5Cwuo23tHkbJCaw2njFi3WGBbA7uGZaGHJPyB2rofTWBiSUXZnP2hiE9bjJghAcDm1M4LVLfWvhZmFEnyeru3VWMETnetz1BYLUC5MJGFXuhnHwWh7F6r74FDyhdswYop4eWPbyrXMXmUQEccTGd2NaT8g2VHADZ76gMC6BjWESvcnz2D4n8XwdmM7ZQ1jFwhuXrBfrb1dwRasyXxxHMGAC2onatNiExyeQ9G1W5LwqNLAh9hvcaNTGaYKYXoceVzLkgm6e5WMkLsCwuZXvB"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"good": false
}
}
```
### **get_transfers**
Returns a list of transfers.
Alias: *None*.
Inputs:
* *in* - boolean; (Optional) Include incoming transfers.
* *out* - boolean; (Optional) Include outgoing transfers.
* *pending* - boolean; (Optional) Include pending transfers.
* *failed* - boolean; (Optional) Include failed transfers.
* *pool* - boolean; (Optional) Include transfers from the daemon's transaction pool.
* *filter_by_height* - boolean; (Optional) Filter transfers by block height.
* *min_height* - unsigned int; (Optional) Minimum block height to scan for transfers, if filtering by height is enabled.
* *max_height* - unsigned int; (Opional) Maximum block height to scan for transfers, if filtering by height is enabled (defaults to max block height).
* *account_index* - unsigned int; (Optional) Index of the account to query for transfers. (defaults to 0)
* *subaddr_indices* - array of unsigned int; (Optional) List of subaddress indices to query for transfers. (Defaults to empty - all indices)
Outputs:
* *in* array of transfers:
* *address* - string; Public address of the transfer.
* *amount* - unsigned int; Amount transferred.
* *confirmations* - unsigned int; Number of block mined since the block containing this transaction (or block height at which the transaction should be added to a block if not yet confirmed).
* *double_spend_seen* - boolean; True if the key image(s) for the transfer have been seen before.
* *fee* - unsigned int; Transaction fee for this transfer.
* *height* - unsigned int; Height of the first block that confirmed this transfer (0 if not mined yet).
* *note* - string; Note about this transfer.
* *payment_id* - string; Payment ID for this transfer.
* *subaddr_index* - JSON object containing the major & minor subaddress index:
* *major* - unsigned int; Account index for the subaddress.
* *minor* - unsigned int; Index of the subaddress under the account.
* *suggested_confirmations_threshold* - unsigned int; Estimation of the confirmations needed for the transaction to be included in a block.
* *timestamp* - unsigned int; POSIX timestamp for when this transfer was first confirmed in a block (or timestamp submission if not mined yet).
* *txid* - string; Transaction ID for this transfer.
* *type* - string; Transfer type: "in"
* *unlock_time* - unsigned int; Number of blocks until transfer is safely spendable.
* *out* array of transfers (see above).
* *pending* array of transfers (see above).
* *failed* array of transfers (see above).
* *pool* array of transfers (see above).
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_transfers","params":{"in":true,"account_index":1}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"in": [{
"address": "77Vx9cs1VPicFndSVgYUvTdLCJEZw9h81hXLMYsjBCXSJfUehLa9TDW3Ffh45SQa7xb6dUs18mpNxfUhQGqfwXPSMrvKhVp",
"amount": 200000000000,
"confirmations": 1,
"double_spend_seen": false,
"fee": 21650200000,
"height": 153624,
"note": "",
"payment_id": "0000000000000000",
"subaddr_index": {
"major": 1,
"minor": 0
},
"suggested_confirmations_threshold": 1,
"timestamp": 1535918400,
"txid": "c36258a276018c3a4bc1f195a7fb530f50cd63a4fa765fb7c6f7f49fc051762a",
"type": "in",
"unlock_time": 0
}]
}
}
```
### **get_transfer_by_txid**
Show information about a transfer to/from this address.
Alias: *None*.
Inputs:
* *txid* - string; Transaction ID used to find the transfer.
* *account_index* - unsigned int; (Optional) Index of the account to query for the transfer.
Outputs:
* *transfer* - JSON object containing payment information:
* *address* - string; Address that transferred the funds. Base58 representation of the public keys.
* *amount* - unsigned int; Amount of this transfer.
* *confirmations* - unsigned int; Number of block mined since the block containing this transaction (or block height at which the transaction should be added to a block if not yet confirmed).
* *destinations* - array of JSON objects containing transfer destinations:
* *amount* - unsigned int; Amount transferred to this destination.
* *address* - string; Address for this destination. Base58 representation of the public keys.
* *double_spend_seen* - boolean; True if the key image(s) for the transfer have been seen before.
* *fee* - unsigned int; Transaction fee for this transfer.
* *height* - unsigned int; Height of the first block that confirmed this transfer.
* *note* - string; Note about this transfer.
* *payment_id* - string; Payment ID for this transfer.
* *subaddr_index* - JSON object containing the major & minor subaddress index:
* *major* - unsigned int; Account index for the subaddress.
* *minor* - unsigned int; Index of the subaddress under the account.
* *suggested_confirmations_threshold* - unsigned int; Estimation of the confirmations needed for the transaction to be included in a block.
* *timestamp* - unsigned int; POSIX timestamp for the block that confirmed this transfer (or timestamp submission if not mined yet).
* *txid* - string; Transaction ID of this transfer (same as input TXID).
* *type* - string; Type of transfer, one of the following: "in", "out", "pending", "failed", "pool"
* *unlock_time* - unsigned int; Number of blocks until transfer is safely spendable.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_transfer_by_txid","params":{"txid":"c36258a276018c3a4bc1f195a7fb530f50cd63a4fa765fb7c6f7f49fc051762a"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"transfer": {
"address": "55LTR8KniP4LQGJSPtbYDacR7dz8RBFnsfAKMaMuwUNYX6aQbBcovzDPyrQF9KXF9tVU6Xk3K8no1BywnJX6GvZX8yJsXvt",
"amount": 300000000000,
"confirmations": 1,
"destinations": [{
"address": "7BnERTpvL5MbCLtj5n9No7J5oE5hHiB3tVCK5cjSvCsYWD2WRJLFuWeKTLiXo5QJqt2ZwUaLy2Vh1Ad51K7FNgqcHgjW85o",
"amount": 100000000000
},{
"address": "77Vx9cs1VPicFndSVgYUvTdLCJEZw9h81hXLMYsjBCXSJfUehLa9TDW3Ffh45SQa7xb6dUs18mpNxfUhQGqfwXPSMrvKhVp",
"amount": 200000000000
}],
"double_spend_seen": false,
"fee": 21650200000,
"height": 153624,
"note": "",
"payment_id": "0000000000000000",
"subaddr_index": {
"major": 0,
"minor": 0
},
"suggested_confirmations_threshold": 1,
"timestamp": 1535918400,
"txid": "c36258a276018c3a4bc1f195a7fb530f50cd63a4fa765fb7c6f7f49fc051762a",
"type": "out",
"unlock_time": 0
}
}
}
```
### **sign**
Sign a string.
Alias: *None*.
Inputs:
* *data* - string; Anything you need to sign.
Outputs:
* *signature* - string; Signature generated against the "data" and the account public address.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"sign","params":{"data":"This is sample data to be signed"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"signature": "SigV14K6G151gycjiGxjQ74tKX6A2LwwghvuHjcDeuRFQio5LS6Gb27BNxjYQY1dPuUvXkEbGQUkiHSVLPj4nJAHRrrw3"
}
}
```
### **verify**
Verify a signature on a string.
Alias: *None*.
Inputs:
* *data* - string; What should have been signed.
* *address* - string; Public address of the wallet used to `sign` the data.
* *signature* - string; signature generated by `sign` method.
Outputs:
* *good* - boolean;
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"verify","params":{"data":"This is sample data to be signed","address":"55LTR8KniP4LQGJSPtbYDacR7dz8RBFnsfAKMaMuwUNYX6aQbBcovzDPyrQF9KXF9tVU6Xk3K8no1BywnJX6GvZX8yJsXvt","signature":"SigV14K6G151gycjiGxjQ74tKX6A2LwwghvuHjcDeuRFQio5LS6Gb27BNxjYQY1dPuUvXkEbGQUkiHSVLPj4nJAHRrrw3"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"good": true
}
}
```
### **export_outputs**
Export all outputs in hex format.
Alias: *None*.
Inputs: *None*.
Outputs:
* *outputs_data_hex* - string; wallet outputs in hex format.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"export_outputs"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"outputs_data_hex": "...outputs..."
}
}
```
### **import_outputs**
Import outputs in hex format.
Alias: *None*.
Inputs:
* *outputs_data_hex* - string; wallet outputs in hex format.
Outputs:
* *num_imported* - unsigned int; number of outputs imported.
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"import_outputs","params":{"outputs_data_hex":"...outputs..."}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"num_imported": 6400
}
}
```
### **export_key_images**
Export a signed set of key images.
Alias: *None*.
Inputs: *None*.
Outputs:
* *signed_key_images* - array of signed key images:
* *key_image* - string;
* *signature* - string;
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"export_key_images"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"signed_key_images": [{
"key_image": "cd35239b72a35e26a57ed17400c0b66944a55de9d5bda0f21190fed17f8ea876",
"signature": "c9d736869355da2538ab4af188279f84138c958edbae3c5caf388a63cd8e780b8c5a1aed850bd79657df659422c463608ea4e0c730ba9b662c906ae933816d00"
},{
"key_image": "65158a8ee5a3b32009b85a307d85b375175870e560e08de313531c7dbbe6fc19",
"signature": "c96e40d09dfc45cfc5ed0b76bfd7ca793469588bb0cf2b4d7b45ef23d40fd4036057b397828062e31700dc0c2da364f50cd142295a8405b9fe97418b4b745d0c"
},...]
}
}
```
### **import_key_images**
Import signed key images list and verify their spent status.
Alias: *None*.
Inputs:
* *signed_key_images* - array of signed key images:
* *key_image* - string;
* *signature* - string;
Outputs:
* *height* - unsigned int;
* *spent* - unsigned int; Amount (in @atomic-units) spent from those key images.
* *unspent* - unsigned int; Amount (in @atomic-units) still available from those key images.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"import_key_images", "params":{"signed_key_images":[{"key_image":"cd35239b72a35e26a57ed17400c0b66944a55de9d5bda0f21190fed17f8ea876","signature":"c9d736869355da2538ab4af188279f84138c958edbae3c5caf388a63cd8e780b8c5a1aed850bd79657df659422c463608ea4e0c730ba9b662c906ae933816d00"},{"key_image":"65158a8ee5a3b32009b85a307d85b375175870e560e08de313531c7dbbe6fc19","signature":"c96e40d09dfc45cfc5ed0b76bfd7ca793469588bb0cf2b4d7b45ef23d40fd4036057b397828062e31700dc0c2da364f50cd142295a8405b9fe97418b4b745d0c"}]}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"height": 76428,
"spent": 62708953408711,
"unspent": 0
}
}
```
### **make_uri**
Create a payment URI using the official URI spec.
Alias: *None*.
Inputs:
* *address* - string; Wallet address
* *amount* - unsigned int; (optional) the integer amount to receive, in **@atomic-units**
* *payment_id* - string; (optional) 16 or 64 character hexadecimal payment id
* *recipient_name* - string; (optional) name of the payment recipient
* *tx_description* - string; (optional) Description of the reason for the tx
Outputs:
* *uri* - string; This contains all the payment input information as a properly formatted payment URI
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"make_uri","params":{"address":"55LTR8KniP4LQGJSPtbYDacR7dz8RBFnsfAKMaMuwUNYX6aQbBcovzDPyrQF9KXF9tVU6Xk3K8no1BywnJX6GvZX8yJsXvt","amount":10,"payment_id":"420fa29b2d9a49f5","tx_description":"Testing out the make_uri function.","recipient_name":"el00ruobuob Stagenet wallet"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"uri": "monero:55LTR8KniP4LQGJSPtbYDacR7dz8RBFnsfAKMaMuwUNYX6aQbBcovzDPyrQF9KXF9tVU6Xk3K8no1BywnJX6GvZX8yJsXvt?tx_payment_id=420fa29b2d9a49f5&tx_amount=0.000000000010&recipient_name=el00ruobuob%20Stagenet%20wallet&tx_description=Testing%20out%20the%20make_uri%20function."
}
}
```
### **parse_uri**
Parse a payment URI to get payment information.
Alias: *None*.
Inputs:
* *uri* - string; This contains all the payment input information as a properly formatted payment URI
Outputs:
* *uri* - JSON object containing payment information:
* *address* - string; Wallet address
* *amount* - unsigned int; Integer amount to receive, in **@atomic-units** (0 if not provided)
* *payment_id* - string; 16 or 64 character hexadecimal payment id (empty if not provided)
* *recipient_name* - string; Name of the payment recipient (empty if not provided)
* *tx_description* - string; Description of the reason for the tx (empty if not provided)
Example:
```
$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"parse_uri","params":{"uri":"monero:55LTR8KniP4LQGJSPtbYDacR7dz8RBFnsfAKMaMuwUNYX6aQbBcovzDPyrQF9KXF9tVU6Xk3K8no1BywnJX6GvZX8yJsXvt?tx_payment_id=420fa29b2d9a49f5&tx_amount=0.000000000010&recipient_name=el00ruobuob%20Stagenet%20wallet&tx_description=Testing%20out%20the%20make_uri%20function."}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"uri": {
"address": "55LTR8KniP4LQGJSPtbYDacR7dz8RBFnsfAKMaMuwUNYX6aQbBcovzDPyrQF9KXF9tVU6Xk3K8no1BywnJX6GvZX8yJsXvt",
"amount": 10,
"payment_id": "420fa29b2d9a49f5",
"recipient_name": "el00ruobuob Stagenet wallet",
"tx_description": "Testing out the make_uri function."
}
}
}
```
### **get_address_book**
Retrieves entries from the address book.
Alias: *None*.
Inputs:
* *entries* - array of unsigned int; indices of the requested address book entries
Outputs:
* *entries* - array of entries:
* *address* - string; Public address of the entry
* *description* - string; Description of this address entry
* *index* - unsigned int;
* *payment_id* - string;
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_address_book","params":{"entries":[0,1]}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"entries": [{
"address": "77Vx9cs1VPicFndSVgYUvTdLCJEZw9h81hXLMYsjBCXSJfUehLa9TDW3Ffh45SQa7xb6dUs18mpNxfUhQGqfwXPSMrvKhVp",
"description": "Second account",
"index": 0,
"payment_id": "0000000000000000000000000000000000000000000000000000000000000000"
},{
"address": "78P16M3XmFRGcWFCcsgt1WcTntA1jzcq31seQX1Eg92j8VQ99NPivmdKam4J5CKNAD7KuNWcq5xUPgoWczChzdba5WLwQ4j",
"description": "Third account",
"index": 1,
"payment_id": "0000000000000000000000000000000000000000000000000000000000000000"
}]
}
}
```
### **add_address_book**
Add an entry to the address book.
Alias: *None*.
Inputs:
* *address* - string;
* *payment_id* - (optional) string, defaults to "0000000000000000000000000000000000000000000000000000000000000000";
* *description* - (optional) string, defaults to "";
Outputs:
* *index* - unsigned int; The index of the address book entry.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"add_address_book","params":{"address":"78P16M3XmFRGcWFCcsgt1WcTntA1jzcq31seQX1Eg92j8VQ99NPivmdKam4J5CKNAD7KuNWcq5xUPgoWczChzdba5WLwQ4j","description":"Third account"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"index": 1
}
}
```
### **delete_address_book**
Delete an entry from the address book.
Alias: *None*.
Inputs:
* *index* - unsigned int; The index of the address book entry.
Outputs: *None*.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"delete_address_book","params":{"index":1}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
}
}
```
### **refresh**
Refresh a wallet after openning.
Alias: *None*.
Inputs:
* *start_height* - unsigned int; (Optional) The block height from which to start refreshing.
Outputs:
* *blocks_fetched* - unsigned int; Number of new blocks scanned.
* *received_money* - boolean; States if transactions to the wallet have been found in the blocks.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"refresh","params":{"start_height":100000}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"blocks_fetched": 24,
"received_money": true
}
}
```
### **rescan_spent**
Rescan the blockchain for spent outputs.
Alias: *None*.
Inputs: *None*.
Outputs: *None*.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"rescan_spent"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
}
}
```
### **start_mining**
Start mining in the Monero daemon.
Alias: *None*.
Inputs:
* *threads_count* - unsigned int; Number of threads created for mining.
* *do_background_mining* - boolean; Allow to start the miner in @smart-mining mode.
* *ignore_battery* - boolean; Ignore battery status (for @smart-mining only)
Outputs: *None*.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"start_mining","params":{"threads_count":1,"do_background_mining":true,"ignore_battery":false}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
}
}
```
### **stop_mining**
Stop mining in the Monero daemon.
Alias: *None*.
Inputs: *None*.
Outputs: *None*.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"stop_mining"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
}
}
```
### **get_languages**
Get a list of available languages for your wallet's seed.
Alias: *None*.
Inputs: *None*.
Outputs:
* *languages* - array of string; List of available languages
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_languages"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"languages": ["Deutsch","English","Español","Français","Italiano","Nederlands","Português","русский язык","日本語","简体中文 (中国)","Esperanto","Lojban"]
}
}
```
### **create_wallet**
Create a new wallet. You need to have set the argument "--wallet-dir" when launching monero-wallet-rpc to make this work.
Alias: *None*.
Inputs:
* *filename* - string; Wallet file name.
* *password* - string; (Optional) password to protect the wallet.
* *language* - string; Language for your wallets' seed.
Outputs: *None*.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"create_wallet","params":{"filename":"mytestwallet","password":"mytestpassword","language":"English"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
}
}
```
### **open_wallet**
Open a wallet. You need to have set the argument "--wallet-dir" when launching monero-wallet-rpc to make this work.
Alias: *None*.
Inputs:
* *filename* - string; wallet name stored in --wallet-dir.
* *password* - string; (Optional) only needed if the wallet has a password defined.
Outputs: *None*.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"open_wallet","params":{"filename":"mytestwallet","password":"mytestpassword"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
}
}
```
### **close_wallet**
Close the currently opened wallet, after trying to save it.
Alias: *None*.
Inputs: *None*.
Outputs: *None*.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"close_wallet"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
}
}
```
### **change_wallet_password**
Change a wallet password.
Alias: *None*.
Inputs:
* *old_password* - string; (Optional) Current wallet password, if defined.
* *new_password* - string; (Optional) New wallet password, if not blank.
Outputs: *None*.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"change_wallet_password","params":{"old_password":"theCurrentSecretPassPhrase","new_password":"theNewSecretPassPhrase"}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
}
}
```
### **is_multisig**
Check if a wallet is a multisig one.
Alias: *None*.
Inputs: *None*.
Outputs:
* *multisig* - boolean; States if the wallet is multisig
* *ready* - boolean;
* *threshold* - unsigned int; Amount of signature needed to sign a transfer.
* *total* - unsigned int; Total amount of signature in the multisig wallet.
Example for a non-multisig wallet:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"is_multisig"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"multisig": false,
"ready": false,
"threshold": 0,
"total": 0
}
}
```
Example for a multisig wallet:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"is_multisig"}' -H 'Content-Type: application/json' {
"id": "0",
"jsonrpc": "2.0",
"result": {
"multisig": true,
"ready": true,
"threshold": 2,
"total": 2
}
}
```
### **prepare_multisig**
Prepare a wallet for multisig by generating a multisig string to share with peers.
Alias: *None*.
Inputs: *None*.
Outputs:
* *multisig_info* - string; Multisig string to share with peers to create the multisig wallet.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"prepare_multisig"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"multisig_info": "MultisigV1BFdxQ653cQHB8wsj9WJQd2VdnjxK89g5M94dKPBNw22reJnyJYKrz6rJeXdjFwJ3Mz6n4qNQLd6eqUZKLiNzJFi3UPNVcTjtkG2aeSys9sYkvYYKMZ7chCxvoEXVgm74KKUcUu4V8xveCBFadFuZs8shnxBWHbcwFr5AziLr2mE7KHJT"
}
}
```
### **make_multisig**
Make a wallet multisig by importing peers multisig string.
Alias: *None*.
Inputs:
* *multisig_info* - array of string; List of multisig string from peers.
* *threshold* - unsigned int; Amount of signatures needed to sign a transfer. Must be less or equal than the amount of signature in `multisig_info`.
* *password* - string; Wallet password
Outputs:
* *address* - string; multisig wallet address.
* *multisig_info* - string; Multisig string to share with peers to create the multisig wallet (extra step for N-1/N wallets).
Example for 2/2 Multisig Wallet:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"make_multisig","params":{"multisig_info":["MultisigV1K4tGGe8QirZdHgTYoBZMumSug97fdDyM3Z63M3ZY5VXvAdoZvx16HJzPCP4Rp2ABMKUqLD2a74ugMdBfrVpKt4BwD8qCL5aZLrsYWoHiA7JJwDESuhsC3eF8QC9UMvxLXEMsMVh16o98GnKRYz1HCKXrAEWfcrCHyz3bLW1Pdggyowop"],"threshold":2}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"address": "55SoZTKH7D39drxfgT62k8T4adVFjmDLUXnbzEKYf1MoYwnmTNKKaqGfxm4sqeKCHXQ5up7PVxrkoeRzXu83d8xYURouMod",
"multisig_info": ""
}
}
```
Example for 2/3 Multisig Wallet:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"make_multisig","params":{"multisig_info":["MultisigV1MTVm4DZAdJw1PyVutpSy8Q4WisZBCFRAaZY7hhQnMwr5AZ4swzThyaSiVVQM5FHj1JQi3zPKhQ4k81BZkPSEaFjwRJtbfqfJcVvCqRnmBVcWVxhnihX5s8fZWBCjKrzT3CS95spG4dzNzJSUcjheAkLzCpVmSzGtgwMhAS3Vuz9Pas24","MultisigV1TEx58ycKCd6ADCfxF8hALpcdSRAkhZTi1bu4Rs6FdRC98EdB1LY7TAkMxasM55khFgcxrSXivaSr5FCMyJGHmojm1eE4HpGWPeZKv6cgCTThRzC4u6bkkSoFQdbzWN92yn1XEjuP2XQrGHk81mG2LMeyB51MWKJAVF99Pg9mX2BpmYFj"],"threshold":2}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"address": "51sLpF8fWaK1111111111111111111111111111111111ABVbHNf1JFWJyFp5YZgZRQ44RiviJi1sPHgLVMbckRsDkTRgKS",
"multisig_info": "MultisigxV18jCaYAQQvzCMUJaAWMCaAbAoHpAD6WPmYDmLtBtazD654E8RWkLaGRf29fJ3stU471MELKxwufNYeigP7LoE4tn2Sscwn5g7PyCfcBc1V4ffRHY3Kxqq6VocSCUTncpVeUskaDKuTAWtdB9VTBGW7iG1cd7Zm1dYgur3CiemkGjRUAj9bL3xTEuyaKGYSDhtpFZFp99HQX57EawhiRHk3qq4hjWX"
}
}
```
### **export_multisig_info**
Export multisig info for other participants.
Alias: *None*.
Inputs: *None*.
Outputs:
* *info* - string; Multisig info in hex format for other participants.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"export_multisig_info"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"info": "4d6f6e65726f206d756c7469736967206578706f72740105cf6442b09b75f5eca9d846771fe1a879c9a97ab0553ffbcec64b1148eb7832b51e7898d7944c41cee000415c5a98f4f80dc0efdae379a98805bb6eacae743446f6f421cd03e129eb5b27d6e3b73eb6929201507c1ae706c1a9ecd26ac8601932415b0b6f49cbbfd712e47d01262c59980a8f9a8be776f2bf585f1477a6df63d6364614d941ecfdcb6e958a390eb9aa7c87f056673d73bc7c5f0ab1f74a682e902e48a3322c0413bb7f6fd67404f13fb8e313f70a0ce568c853206751a334ef490068d3c8ca0e"
}
}
```
### **import_multisig_info**
Import multisig info from other participants.
Alias: *None*.
Inputs:
* *info* - array of string; List of multisig info in hex format from other participants.
Outputs:
* *n_outputs* - unsigned int; Number of outputs signed with those multisig info.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"import_multisig_info","params":{"info":["...multisig_info..."]}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"n_outputs": 35
}
}
```
### **finalize_multisig**
Turn this wallet into a multisig wallet, extra step for N-1/N wallets.
Alias: *None*.
Inputs:
* *multisig_info* - array of string; List of multisig string from peers.
* *password* - string; Wallet password
Outputs:
* *address* - string; multisig wallet address.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"finalize_multisig","params":{"multisig_info":["MultisigxV1JNC6Ja2oBt5Sqea9LN2YEF7WYZCpHqr2EKvPG89Trf3X4E8RWkLaGRf29fJ3stU471MELKxwufNYeigP7LoE4tn2McPr4SbL9q15xNvZT5uwC9YRr7UwjXqSZHmTWN9PBuZEKVAQ4HPPyQciSCdNjgwsuFRBzrskMdMUwNMgKst1debYfm37i6PSzDoS2tk4kYTYj83kkAdR7kdshet1axQPd6HQ","MultisigxV1Unma7Ko4zdd8Ps3Af4oZwtj2JdWKzwNfP6s2G9ZvXhMoSscwn5g7PyCfcBc1V4ffRHY3Kxqq6VocSCUTncpVeUskMcPr4SbL9q15xNvZT5uwC9YRr7UwjXqSZHmTWN9PBuZE1LTpWxLoC3vPMSrqVVcjnmL9LYfdCZz3fECjNZbCEDq3PHDiUuY5jurQTcNoGhDTio5WM9xaAdim9YByiS5KyqF4"]}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"address": "5B9gZUTDuHTcGGuY3nL3t8K2tDnEHeRVHSBQgLZUTQxtFYVLnho5JJjWJyFp5YZgZRQ44RiviJi1sPHgLVMbckRsDqDx1gV"
}
}
```
### **sign_multisig**
Sign a transaction in multisig.
Alias: *None*.
Inputs:
* *tx_data_hex* - string; Multisig transaction in hex format, as returned by `transfer` under `multisig_txset`.
Outputs:
* *tx_data_hex* - string; Multisig transaction in hex format.
* *tx_hash_list* - array of string; List of transaction Hash.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"sign_multisig","params":{"tx_data_hex":"...multisig_txset..."}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"tx_data_hex": "...multisig_txset...",
"tx_hash_list": ["4996091b61c1be112c1097fd5e97d8ff8b28f0e5e62e1137a8c831bacf034f2d"]
}
}
```
### **submit_multisig**
Submit a signed multisig transaction.
Alias: *None*.
Inputs:
* *tx_data_hex* - string; Multisig transaction in hex format, as returned by `sign_multisig` under `tx_data_hex`.
Outputs:
* *tx_hash_list* - array of string; List of transaction Hash.
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"submit_multisig","params":{"tx_data_hex":"...tx_data_hex..."}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"tx_hash_list": ["4996091b61c1be112c1097fd5e97d8ff8b28f0e5e62e1137a8c831bacf034f2d"]
}
}
```
### **get_version**
Get RPC version Major & Minor integer-format, where Major is the first 16 bits and Minor the last 16 bits.
Alias: *None*.
Inputs: *None*.
Outputs:
* *version* - unsigned int; RPC version, formatted with `Major * 2^16 + Minor` (Major encoded over the first 16 bits, and Minor over the last 16 bits).
Example:
```
$ curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_version"}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"version": 65539
}
}
```
\ No newline at end of file