diff --git a/docs/papers/hbs2-git-doc-0.24.1.tex b/docs/papers/hbs2-git-doc-0.24.1.tex
index d8d1088e..c85e70ac 100644
--- a/docs/papers/hbs2-git-doc-0.24.1.tex
+++ b/docs/papers/hbs2-git-doc-0.24.1.tex
@@ -129,24 +129,23 @@ broadcast сообщений, DNS бутстрапа и списка извес
 прочее, $git~push$ происходит в \term{references}{ссылку}, которая поддерживается всеми пирами,
 которые согласны поддерживать эту ссылку.
 
-Узел hbs2-peer может постить \term{transaction}{транзакции} обновления ссылок и получать их, а также
-получать журнал транзакций в виде дерева Меркла.
+Узел hbs2-peer может отправлять и получать транзакции обновления ссылок, а также получать журнал
+транзакций как дерево Меркла.
 
 Как было сказано выше, hbs2-git использует механизм \term{references}{ссылок} для своей работы.
 
-Ссылка представляет собой некий идентификатор, как правило, ассоциированный с публичным ключом
-шифрования. Технически это может быть что угодно, что может быть хэшировано, но это что-то
-должно быть идентифицировано с тем, кто эту ссылку обновляет, а так же, по возможности должно быть
-уникально в рамках вселенной.
+Ссылка --- это идентификатор, часто связанный с публичным ключом шифрования, который может быть
+любым хешируемым объектом. Она должна однозначно ассоциироваться с обновляющим её пользователем и
+быть уникальной.
 
-Одним из способов добиться подобной уникальности --- является использование пары публичный
-ключ/приватный ключ и публичного ключа в качестве уникального идентификатора.
+Одним из способов добиться уникальности является использование пары публичный
+ключ/приватный ключ и публичного ключа в качестве идентификатора.
 
-Владелец приватного ключа очень заинтересован в том, что бы его приватный ключ был уникален и
-известен только ему и он изо всех сил старается эту уникальность поддерживать, в частности,
-использует качественный генератор случайных чисел и никому свой приватный ключ не сообщает.
+Владелец приватного ключа заинтересован в том, что бы его приватный ключ был уникален и известен
+только ему и он изо всех сил старается эту уникальность поддерживать, в частности, использует
+качественный генератор случайных чисел и никому свой приватный ключ не сообщает.
 
-Так же мы предполагаем, что подобрать секретный ключ по известному публичному ключу --- очень
+Мы предполагаем, что подобрать секретный ключ по известному публичному ключу --- очень
 сложная задача.
 
 Ссылки могут быть разных типов.  Конкретно, hbs2-git использует ссылки двух видов:
@@ -154,13 +153,13 @@ broadcast сообщений, DNS бутстрапа и списка извес
 \begin{description}
   \item[LWWRef] В терминах CRDT это Last~Write~Wins~Register, где некое значение
     ассоциировано с монотонно возрастающим счётчиком, и все участники (пиры) принимают
-    то значение, у которого этот счётчик больше. Так же: lwwref, lww-cсылка.
+    то значение, у которого этот счётчик больше. См: lwwref, lww-cсылка.
 
-  \item[RefLog] В терминах CRDT это G-Set или же Grow~Only~Set транзакций, так же множество
+  \item[RefLog] В терминах CRDT это G-Set или же Grow~Only~Set транзакций, где множество
     транзакций представлено деревом Меркла. Транзакции (в рамках RefLog) упорядочены строго
     по их хэшам. Содержимое транзакций может быть произвольно и определяется клиентским приложением.
     Наличие порядка, таким образом, приводит к тому, что всё множество может быть адресовано
-    неким хэшем (дерева Меркла) и хэш этот одинаков для одинакового набора транзакций. Так же:
+    неким хэшем (дерева Меркла) и хэш этот одинаков для одинакового набора транзакций. Также:
     рефлог.
 \end{description}
 
@@ -756,7 +755,7 @@ bdfb845c343eb1da14fe1969219c303c1397980e refs/heads/master
 
  $seed$ содержится в блоке значения ссылки $L_1$.
 
- $PK_2$ также содержится в блоке значения ссылки $L_1$.
+ $PK_2$ аналогично, содержится в блоке значения ссылки $L_1$.
 
  Таким образом, все имеют доступ к публичному ключу рефлога $PK_2$ и могут проверять подпись автора
  для даннго рефлога, и только автор имеет доступ к  приватному ключу $SK_2$ и имеет возможность