Биткойн в 2021 году

Предлагаем вашему вниманию размышления 1-го из криптоэнтузиастов под псевдонимом AJ. Повествование идет от первого лица, чтоб не искажать смысл написанного создателем. Не забудьте в конце статьи поделиться своим воззрением в комментах.

Сначала прошедшего года я написал статью, в какой рассуждал о собственных общих ценностях по Биткойну, и я как и раньше полностью доволен таковым подходом – средство сбережения как база определённо оправдало себя!

В прошедшем году мы следили, как почти все начали держать биткойны, и, думаю, эта тенденция продолжится – что положительный символ, но, если следовать прошлогодней логике, это также значит, что следует уделять больше внимания и предстоящим стадиям принятия: к примеру, если удвоится число людей, держащих биткойны, то необходимо также удвоить число тех, кто без помощи других хранит свою криптовалюту, кто проводит транзакции в сети Lightning и т. д. Другими словами в эталоне таковой рост самостоятельного хранения и транзакций второго уровня должен быть больше того, что мы ждали при постоянном принятии Биткойна.

Тем не наименее я не уверен, что в этом году буду настроен на рост биткойна; быстрее я ожидаю объединение. Посмотрите, какой была стоимость BTC сначала крайних пары лет: $450 в 2016 г., $1000 в 2017 г., $13 000 в 2018 г., $3700 в 2019 г., $8000 в 2020 г., и прямо до $55 000 в 2021 г. Был ли в 2016-18 гг. восьмикратный рост обеспечения и надёжности, который бы соответствовал росту цены с января 2016 г. по январь 2019 г. в 8 раз? Может быть, да. Был ли восьмикратный рост обеспечения и надёжности в 2019-20 гг., который бы соответствовал росту цены ещё в 8 раз? Может быть. Но что, если кто-то задумывается о достижении цены $200 000 либо $300 000 в не далеком будущем, – не требуется ли для этого рост обеспечения и надёжности ещё в 8 раз? Откуда он возьмётся? И эти коэффициенты множатся: если вы желаете $280 тыс. в декабре 2021 г., то это рост надёжности не в 3*8 = 24 раза, в 8 в кубе = 512 раз за 6 лет (2016-22 гг.)! Ваши оценки могут варьироваться, но я не думаю, что Биткойн уже в 500 раз надёжнее, чем 5 годов назад.

Потому, вроде бы я ни был воодушевлён в связи с Taproot и способностями, которые он открывает (PTLC и в предстоящем eltoo в сети Lightning, «сценарии без сценариев» и discreet log-контракты, подтверждение резервов, сохраняющее конфиденциальность, дешёвые мультиподписи – может быть, перечень не нескончаемый, но как минимум весьма длиннющий), пожалуй, я сейчас ещё больше, чем годом ранее, придерживаюсь представления, что важнее работать над тем, что крепит имеющийся фундамент, чем над прекрасными новенькими мыслями, которые его меняют.

Уже есть ряд направлений, где подход Биткойна к сохранности и надёжности за крайние пару лет улучшился с технической точки зрения: больше людей занимаются рецензированием (к примеру, через клуб рецензирования запросов на включение конфигураций либо программку стажировки Chaincode), непрерывное интеграционное тестирование сделалось наиболее глубочайшим и различным (как благодаря тому, что сделалось может быть больше интеграций через GitHub, так и из-за того, что Travis стал так ненадёжным, чтоб вынудить находить остальные подходы), фаззинг-тестирование существенно стало лучше и сделалось несколько обширнее употребляться, и, на мой взор, статический анализ кодовой базы незначительно усовершенствовался. Также был ряд улучшений эталонов кода (к примеру, внедрение неопасных указателей, инстракций блокировки, класса span заместо сырых указателей). Я не проводил анализ, но это то, что мне дает подсказку память и интуиция.

: Unsplash

Что касается надёжности, на мой взор, короткосрочные ценности последующие:

  • Модуляризация – к примеру, чтоб можно было лучше поделить процессы, чтоб понизить опасности для сохранности, и лучше применять фаззинг, чтоб отловить баги в пограничных вариантах. Уже ведётся работа над тем, чтоб поделить графический интерфейс юзера и кошелёк на отдельные процессы, но пока этого нет в обычной сборке. Если интерфейс P2P-сети также будет отдельным действием, это быть может ещё одним преимуществом. Хотя это симпатичная цель, думаю, до LibConsensus ещё далековато – P2P, управление пулом памяти и правила валидации на данный момент довольно тесновато переплетены, – но можно сделать шаги к данной для нас цели, которые сами по для себя будут улучшениями.
  • P2P-сеть – это тривиальный метод штурмовать Биткойн, так как, по определению, доступ имеет любой. Тут есть несколько уровней: пассивный мониторинг P2P-сети может дозволить нарушить ожидания юзеров насчёт конфиденциальности, тогда как активная изоляция юзеров в независящие сети может повредить фундаментальные предпосылки Биткойна (нереально продлить самую длинноватую цепочку, если недозволено контактировать с теми, у кого она есть). Есть также целый ряд промежных заморочек меж этими крайностями, которые, к примеру, могут нарушить предпосылки систем второго уровня, таковых как Lightning. Посторонние (потенциально централизованные) кандидатуры как запасные копии P2P-сети также могут предоставить ценную поддержку – нечто вроде Blockstream Satellite, передачи блоков по любительскому радио либо передачи заголовков блоков через DNS может поправить расколы в P2P-сети, которые сам P2P-уровень не может автоматом убрать. Либо же улучшения эффективности, такие как Erlay либо подключение лишь для передачи блоков, сделают вероятным наиболее высочайшее свойство связи, что усложнит атаки.
  • Непрерывная интеграция, статический анализ, воспроизводимые сборки – за крайний год, похоже, платформа Travis перевоплотился из временами имеющей раздражающие препядствия в фактически непригодную для проектов с открытым кодом. Непрерывная интеграция – принципиальная часть разработки и рецензирования; её нарушение значительно усложняет и то, и другое. То, что мы имеем на данный момент, кажется очень хорошим, но оно ещё ново и пока недостаточно испытано временем, так что, пожалуй, пригодится год на доработки. Думаю, требуют совершенствования и остальные нюансы, связанные с непрерывной интеграцией, к примеру автоматическое тестирование первичного скачки блоков (похоже, данные на bitcoinperf устарели на несколько месяцев). Статический анализ служит похожей цели, и хотя почти все уже включено в непрерывную интеграцию через линтеры и функции компиляторов, думаю, тут вероятна ещё доборная нужная автоматизация. В конце концов, постоянно ценно уделить внимание «крайней мили», чтоб убедиться, что люди употребляют ПО, которое тестируют создатели, и, кажется, работа с NixOS подаёт надежды в этом плане.
  • Валидация третьими сторонами – в крайнее время возник ряд инструментов для постороннего мониторинга: разные веб-сайты, отслеживающие комиссии и размер пула памяти; ForkMonitor, ищущий тупиковые блоки (и двойное расходование); либо, с натяжкой, анализ поведения кошельков и поддержки SegWit от Optech.
  • Мне бы хотелось привести в перечне ценностей формальную верификацию на консенсусном уровне, но, думаю, тут ещё нужно много доработок, и, возможно, поначалу будет нужно рефакторинг, чтоб воплотить это в LibConsensus, а потом необходимо будет выделить это в отдельный процесс, для которого лишь тогда можно будет найти формальную спецификацию, что, в свою очередь, даст то, на базе что можно проводить формальную верификацию. Полагаю, лучше достигнуть этого за ближний цикл либо два.

    : AgnorMark

    Меня не волнует майнинг – когда-нибудь может показаться риск, что субсидии блока очень низкие и доход с комиссий недостаточен, но это не произойдёт, пока стоимость умножается резвее, чем происходят за ранее запланированные халвинги. Определённо есть опасности централизации, будь то в производстве ASIC, владении/контроле над оборудованием либо на уровне пулов, но мне кажется, что ситуация не усугубляется и это не наибольшая конкретная угроза. Может быть, я ошибаюсь; тогда, надеюсь, те, кто так считает, работают над предотвращением заморочек, а не пользуются ими.

    Есть также остальные уровни надёжности и сохранности, кроме просто поддержания работы сети, если разглядеть вопросец «как предупредить утрату/хищение моих монет?» обширнее. Фишинг и потенциальные физические атаки в итоге утечки данных кошелька Ledger – это обыкновенные примеры такового рода заморочек, но взломы/сбои бирж совершенно, вредное ПО, подменяющее адреса, так что ваши средства идут злодеям заместо подходящего получателя, и утрата доступа к ключам – это также повод для беспокойства. Думаю, дескрипторы, Miniscript и мультиподписи Taproot станут неплохим шагом к тому, чтоб предупредить утрату ключей, а прогресс с BIP322 (подписание сообщений по адресу Биткойна) может посодействовать избежать атак с заменой адреса.

    В определённом смысле технические решения – это всё, на что можно возлагать, если вы держите средства без помощи других, но когда задействован банк/кастодиан, полезным также быть может (не плохое) регулирование: требования хранить клиентские данные под защитой либо уничтожать, аудит третьими сторонами, чтоб удостовериться, что вправду используются заявленные рациональные процедуры, и т. д. Если кастодианы хранят средства на Taproot-адресах, то быть может целенаправлено применять подтверждения платежеспособности с нулевым разглашением (с сохранением конфиденциальности), из-за что будет труднее создавать компании-однодневки либо иными методами похищать средства клиентов.

    Разумеется, что там, где это может быть, подобные эталоны должны внедряться средством аудируемого открытого кода, заместо того чтоб добиваться огромных средств на реализацию от каждой компании. Но также стоит пошевелить мозгами о том, могут ли такового рода нормативы принять вид отраслевых эталонов («мы придерживаемся отраслевых эталонов, тогда как соперник X – нет») заместо неотклонимого правительственного регулирования – посреди остального, вызывает сомнения, имеют ли правительственные регуляторы подходящий опыт, чтоб избрать рациональные практики, которых должны придерживаться криптовалютные системы. Хотя, может быть, это обязано быть нечто направленное на «права потребителей», а не на «ветвь» как таковую, чтоб это не было только вектором для регуляторного захвата.

    Я считаю, что проделан хороший прогресс в стабилизации разработки Биткойна: в 2015-17 гг. люди всерьёз думали о том, чтоб поменять разрабов Биткойна, – создатели противились резвому повышению размера блоков, потому естественным решением казалось поменять их теми, кто этому не противится. Если разглядывать Биткойн как экспериментальный технологический стартап, направленный на платежи, то, может быть, это хорошая мысль; но если разглядывать его как средство сбережения, то это страшно: заменив профессионалов, поэтому что они считают, что ваш план ошибочен, вы не получите надёжную систему, а без надёжной системы не будет неплохого средства сбережения. Но, хотя в Твиттере временами всплывает недовольство, это по большенному счёту уже в прошедшем, и на данный момент, судя по всему, намного огромную поддержку имеет финансирование разрабов и наблюдается существенно наиболее мощный консенсус в отношении того, какие конкретно разработки должны вестись (хотя, может быть, это только поэтому, что несогласные перебежали в остальные проекты и новейшие разногласия ещё не успели показаться).

    Тем не наименее, хотя, может быть, это полностью близко к улучшению в 64 раза, которое бы поддерживало нынешнюю стоимость, я считаю, что необходимо ещё намного больше, чтоб поддержать непрерывный рост принятия.

    : Unsplash

    Я в особенности оптимистично настроен в отношении пока ещё не анонсированного подхода, который изучит Инициатива по цифровым валютам Массачусетского технологического института (МТИ). Если я верно понимаю, планируется предоставлять долгосрочное финансирование маленький команде старших разрабов и исследователей, которые должны фокусироваться на поддержании стабильности и сохранности Биткойна – другими словами на аудите кода, разработке инструментов для поиска и предотвращения багов и проведении мотивированных исследовательских работ, чтоб опережать взломщиков в гонке вооружений в области сохранности. Я не уверен, будет ли это реализовано и пройдёт ли проверку временем, но если да, то это должны будут воспроизвести и остальные группы, чтоб избежать лишней централизации, но, думаю, это перспективный подход для предстоящего улучшения сохранности и надёжности ещё в 8 раз, а может, и не только лишь.

    Я также общался с Джереми Рубином, у которого есть достойные внимания идеи о финансировании для Judica. Снова же, если я верно понимаю, сущность предложения в том, чтоб попробовать соединить благотворительную/покровительственную модель, финансирующую почти все разработки с открытым кодом в Биткойне, с подходом ангельского инвестирования, что может принести больше средств на исходном шаге благодаря близкой к реальности способности получить в конечном итоге выгодный бизнес и, как следует, окупить исходные вложения.

    Мне это кажется намного наиболее принципиальным, но я считаю, что нужно продолжать изучить вероятные идеи, чтоб избежать централизации разработки: другими словами если мы будем просто расширять то, что имеем на данный момент, то в конечном итоге может оказаться только несколько компаний (либо людей), чьи ежеквартальные итоги зависят от финансирования разработки и которые, как следует, несут огромную часть бремени, тогда как остальная экономика в некий степени паразитирует на их, тогда и кто-то увидит возможность получить контроль над разработкой и решит купить их все. Мягеньким примером подобного может служить приобретение CentOS компанией Red Hat (через оборотный наём-поглощение, как, пожалуй, это можно именовать) и недавнешнее изменение стратегии CentOS, сокращающее её конкурентнсть с продуктом Red Hat – RHEL.

    (Есть также много увлекательных тестов с финансированием в сфере децентрализованных денег/Эфириума совершенно, но пока что я не думаю, что они содействуют текущему финансированию разработок по надёжности и сохранности, о котором я тут говорю.)

    Пожалуй, есть три «атаки», которые меня в текущее время тревожат, и они все соединены с вышеперечисленными совершенствованиями.

    1-ая из их связана с тем, что «модуляризация», о которой говорилось ранее, предполагает много манипуляций с кодом, причём так, чтоб не поменять какое-либо поведение. Но так как меняемый код непростой, можно просто поменять поведение случаем, потенциально создав обидные баги либо даже уязвимости. А так как рецензенты не ждут конфигураций поведения, эти препядствия быть может трудно выявить. Пожалуй, это припоминает препядствия с беспилотными авто либо контрольным досмотром – огромную часть времени всё отлично, потому трудно гарантировать сохранение полной внимательности, чтоб совладать с теми редчайшими вариантами, когда что-то пойдёт не так. И хотя есть много автоматических проверок, которые выявляют разные классы ошибок, они всё же далековато не безупречны. Мне кажется, что тут есть серьёзные опасности как случайных багов, так и преднамеренных уязвимостей, вставленных злодеями, которые могут некое время выдавать себя за контрибьюторов Биткойна. Но даже невзирая на эти опасности, модуляризация всё равно кажется стоящей целью, так что вопросец в том, как идеальнее всего эти опасности минимизировать. К огорчению, кроме того, что уже делается, я не понимаю, как этого можно достигнуть. Я пробовал применять вопросец «вправду ли это изменение является преимуществом?», чтоб ограничить скорость конфигурации кода, но пока не достигнул результата.

    Ещё один возможный вектор атаки – это рецензирование кода. Это принципиальная часть поддержания правильности и сохранности Биткойна, которая не очень отлично масштабируется. Этому есть несколько обстоятельств: самая обычная из их – это то, что один человек может за денек вычитать ограниченный объём кода, но ещё один фактор – это то, что хоть какой патч может иметь неприметные последствия, которые появляются лишь при содействии с остальным кодом, который не изменяется, и весьма трудно знать обо всех возможных неочевидных взаимодействиях в базе кода, и даже если они известны, может потребоваться время, чтоб осознать, к чему они могут привести. Таковым образом, больше конфигураций – это одна неувязка, но разделение рецензирования меж огромным числом людей – иная: это понижает возможность, что патч с неприметным багом будет проверен тем, кто способен осознать, что таковой неприметный баг совершенно существует. Буквально так же стремительная и действенная разработка – это не постоянно преимущество: это уменьшает время, доступное для того, чтоб осознать, что есть неувязка, до того как конфигурации будут внесены и люди сосредоточатся на чём-то другом. Модуляризация, по последней мере, тут помогает: она значительно понижает возможность взаимодействий с совсем иными частями проекта, но, естественно, не исключает её вполне. Непрерывная интеграция также помогает, автоматизируя рецензирование классов возможных заморочек. Думаю, мы уже хорошо справляемся в этом плане с консенсусным кодом: есть много рецензий, и всё продвигается неторопливо. Но остальные направления вызывают у меня беспокойство. К примеру, я весьма опешил, увидев, что запрос на включение конфигураций №20624 был предложен в пятницу и принят в пн (да ещё и в предрождественский период). Такие конфигурации просто могут внести неприметные баги, которые могут серьёзно сказаться на P2P-взаимодействии, и я не думаю, что же все-таки это такое принципиальное улучшение, которое оправдывало бы подход «поначалу включи, а рецензируй позднее».

    Крайнее, что меня волнует, – это риск того, что злоумышленники могут испытать наименее тривиальные методы «увольнения разрабов», чем случались ранее. В конце концов, если можно поменять всех, кто мог бы быть против того, что ты хочешь сделать, то не надо включать что-то исподтишка и возлагать, что никто не увидит этого при рецензировании, можно просто смело это сделать, и даже если не избавишься от всех, кто мог бы оказывать для тебя сопротивление, то, по последней мере, снизишь возможность, что твой патч будет основательно проверен теми, кто остается. Есть различные варианты, как это можно провернуть. К примеру, можно отыскать метод, как сделать внесение правок довольно противным, чтоб люди просто сами ушли: неизменные споры по второстепенным вопросцам, замедление прогресса, чтоб казалось, что это просто пустая растрата времени, и личные нападки в СМИ (либо соцсетях). Ещё один метод – сделать из человека изгоя, чтоб никто не желал иметь с ним дела. Либо же вероятны судебные иски (ср. с  мыслями Анджелы Уолч о фидуциарных обязанностях для разрабов) либо наиболее прямые пробы применить насилие.

    : Unsplash

    Не думаю, что на это есть прямой ответ – даже если всё перечисленное выше потерпит беду, всё равно можно вынудить людей уйти, предложив им много средств и какую-то другую увлекательную работу, к примеру. Пожалуй, наилучшая защита носит наиболее культурный нрав: наличие большенный группы контрибьюторов с мощной поддержкой общих целей (таковых как децентрализация, надёжность, фиксированное предложение, защита пользовательских средств, невозможность отмены транзакций), причём довольно различной, чтоб они все не были уязвимы к схожим атакам.

    Один из рисков финансирования большей части разработки одним и этим же методом в том, что это содействует конформизму заместо контраста. Явное правило спонсирования – «не кусай руку, которая тебя кормит». К примеру, в соглашении о грантах разрабам от BitMEX сказано: «Не решать действий, которые могут нанести вред репутации грантодателя». И я не желаю это критиковать: это естественное следствие сути гранта. Но если все, кто работает над Биткойном, будут конкретно мотивированы придерживаться этого правила, то что будет, если пригодится сказать о ненадлежащем поведении?

    Естественно, может быть, тут уже всё в порядке, поэтому что есть довольно разрабов, которые могут тихо уйти с работы либо которые уже так финансово независимы, чтоб ни перед кем не отчитываться?

    Но мне кажется тревожным звоночком то, что Лючок Дашир не получил один из таковых грантов, – я понимаю, что он подавал заявку на несколько, и он владеет всеми необходимыми свойствами: он длительный контрибьютор, он сыграл не последнюю роль в вербовании внимания к дилеммам BIP16, в реализации SegWit, в предотвращении катастроф, которые могли появиться из-за активации софт-форка SegWit юзерами (UASF), и в работе над активацией Taproot, и он один из числа тех, кто отлично умеет отыскивать малозаметные взаимодействия, создающие опасности багов и уязвимостей, о которых я давал информацию выше. С иной стороны, он известен своими чудаковатыми мыслями, с ним быть может трудно работать и, может быть, его ожидания нереалистичны. И что все-таки это даёт в сумме? Может быть, он представляет прецедент как раз таковой атаки на Биткойн. А может, ему просто не везёт. Либо же ему просто необходимо лучше себя разрекламировать либо поменять отношение на наиболее подходящее для бизнеса – и, думаю, как раз такое отношение нужно, если хочешь решить делему без помощи других, заместо того чтоб полагаться на чью-то помощь.

    Но… если мы все так будем созодать, то не столкнёмся ли мы с той же неувязкой «конформизма» и не делает ли это всех в той либо другой степени уязвимыми к атаке перевоплощения в «изгоя», когда кто-то может вас стимулировать, пока вы не отреагируете очень остро на что-то в целом безопасное, потом обвинит вас в том, что с вами трудно работать, и будет повторять этот процесс, пока за вами не закрепится таковая репутация и никто не захотит иметь с вами дело?

    Хотя мне определённо нравится работать с теми, с кем я отлично лажу, я не уверен, что разрабам необходимо работать только с теми, кого они находят приятными, в особенности если стоимость этого – возможность что-то упустить при рецензировании либо риск сотворения некоего подобия уязвимой монокультуры. С иной стороны, я склонен считать терпение добродетелью, и, как следует, те, кто испытывает моё терпение, делают мне услугу, буквально так же как школьные экзамены, – они демонстрируют твой уровень и то, над чем для тебя стоит работать, – потому, может быть, я очень терпим к раздражающим людям. И я также упоминал перевоплощение работы над Биткойном в противное занятие как один из возможных векторов атаки, так что не понимаю, существует ли обычный ответ. Может быть, стоит продвигать страничку спонсоров Лючка на GitHub?

    Вроде бы то ни было, подведу результат

    Невзирая на высказанную выше идея, что Taproot не основной ценность в этом году и что необходимо больше сосредоточиться на надёжности, чем на росте, я считаю, что большая доступность мультиподписей в кошельках, чтоб понизить возможность утраты пользовательских средств, – это хорошая мысль, и для меня это всё же на первом месте. На втором, пожалуй, пробы сделать код для P2P и пула памяти наиболее гибким, инкапсулированным и подходящим для тестирования, хотя я не уверен, как смягчить возникающий при всем этом риск очень резвого конфигурации кода. Не думаю, что я буду уделять много внимания непрерывной интеграции/тестированию/статическому анализу, но всё же я считаю, что это принципиально, потому постараюсь больше заниматься рецензированием, чтоб посодействовать с продвижением в этом направлении.

    В остальном хотелось бы узреть животрепещущие и подходящие для тестирования патчи ANYPREVOUT. Так как это открывает путь для eltoo, что улучшает надёжность каналов Lightning, это будет хорошее достижение в плане сохранности (и я считаю, что в целом конкретно этого недостаёт Lightning, а как следует, это также отлично согласуется с целью роста Lightning таковыми же темпами, как Биткойн). Но, пожалуй, ценность этого не таковой высочайший, как улучшение надёжности базисного уровня Биткойна.

    Есть также много остальных увлекательных аспектов технического направления, но я считаю, что в этом году следует сосредоточиться на нескольких главных элементах и не поддаваться чрезмерному возбуждению, так что неплохой мыслью будет придерживаться в качестве фундамента того, что описано выше.

    Не считая того, я надеюсь, что смогу и далее поддерживать инициативы остальных по финансированию разработок – будь то принципиальных либо тех, которые уже работают.

    Если вы по некий причине читаете это, чтоб отыскать советы касаемо того, что для вас созодать, а не чтоб выяснить мои мысли, то вот, что мне приходит на мозг:

    • Средства: задумайтесь насчёт того, чтоб (в восходящем порядке валютных сумм) поддержать либо нанять Лючка Дашира либо остальных разрабов Биткойна (либо, если для вас это по силам, самому что-то сделать), поддержать Инициативу по цифровым валютам МТИ либо профинансировать/сделать что-то независящее, но не наименее не плохое, чем инициатива МТИ либо Chaincode. Для банков, которых затронуло письмо Управления контролёра валютного воззвания США о платежах, неплохой мыслью будут серьёзные инвестиции в разработку Lightning.
    • Код Биткойна: помогите сделать лучше внутренний тестовый охват, статический анализ и/либо воспроизводимость сборок; организуйте и поддерживайте наружное тестирование; рецензируйте код и отыскиваете баги в запросах на включение конфигураций, до этого чем они будут одобрены. И есть ещё миллион увлекательных опций, над которыми можно работать.
    • Lightning: поработайте с PTLC (используя Taproot в Signet либо на базе ECDSA), ANYPREVOUT/eltoo, над улучшением предотвращения мусора и совершенно над реализацией и совершенствованием всего, что уже есть в перечне текущих задач для Lightning.
    • Остальные проекты: проводите больше тестирования в Signet совершенно, протестируйте интеграцию Taproot в Signet (в особенности что касается опций сохранности, таковых как мультиподписи), мониторьте активность в блокчейне и пуле памяти на предмет странностей, чтоб посодействовать очень стремительно найти и предупредить потенциальные атаки.

    В конце концов, если вдруг не разумеется, это только мои мысли о ценностях сейчас, и это не значит, что над остальным не стоит работать.

    Вы постоянно сможете поблагодарить переводчика за проделанную работу: BTC: 3ECjCH5tPoyDCqHGCXfiiiLZQ3tVGzCSxB ETH: 0xf45a9988c71363b717E48645A412D1eDa0342e7E

    Author: Anonim