diff --git a/docs/todo/hbs2-peer.txt b/docs/todo/hbs2-peer.txt
new file mode 100644
index 00000000..96f4f4b4
--- /dev/null
+++ b/docs/todo/hbs2-peer.txt
@@ -0,0 +1,37 @@
+TODO: ASAP-bloom-filter-of-blocks Каждый пир поддерживает фильтр Блума для
+блоков и раздаёт этот фильтр по протоколу.
+
+  Протокол подразумевает как отдачу всего фильтра целиком ( тут подходит
+  держать его в LWWRef)
+
+  Так и просто запросы к нему.
+
+  Запрос должен пролезать в UDP, таким образом, выглядит так, что это
+  список чисел с номерами бит, т.е в худшем случае (8 байт на число)
+  один запрос это проверка 128 блоков за раз. Поскольку CBOR у нас
+  кодирует числа с переменной длиной, можно ожидать, что в среднем
+  будет получше.
+
+  Это ускорит, возможно, на порядок поиск блоков, который тем хуже,
+  чем больше в системе пиров.
+
+  Открытые вопросы:
+
+  - Параметры фильтра Блума? Зашитые в систему, или зависящие от
+    пира (и тогда мы пересчитываем их)
+
+  - Надо ли качать фильтры целиком (кажется, что нет, но можно
+    запоминать/обновлять для каждого пира, и время от времени
+    чистить)
+
+  - Если параметры фильтра могут меняться для пира, как
+    согласовывать хэш функции? Если их зашивать и менять только
+    коэффициенты, то не слишком ли плохие будут хэш функции?
+
+  - Какие атаки может вызвать?
+
+  - Как эффективно хранить?
+
+
+
+