{% assign version = '1.1.1' | split: '.' %}
{% include disclaimer.html translated="true" version=page.version %}
## Вступление

В настоящем руководстве описана *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.