🖥 Интервью с Полидом: Кроличья нора Заветов

Интервью с Полидом: Кроличья нора Заветов

Попали ли вы в «кроличью нору» заветов?

Интервьюер: Хуа, писатель-фрилансер, независимый исследователь. Х: @AmelieHua

Опрашиваемый: Поли, специалист по системам управления, обслуживает несколько распределенных систем управления (РСУ) и работал с другими пятью девятью системами (время безотказной работы 99,999%). Х: @Polyd_

Заветы — старая, но свежая тема. Еще в 2013 году разработчики начали обсуждать эту тему, и в последние годы было предложено множество BIP, направленных на реализацию ковенантов, что вызвало интенсивные дебаты и сделало эту тему одной из самых горячих.

Ковенанты заслуживают серьезного обсуждения из-за их мощных возможностей. Считается, что они открывают новые возможности для программирования Биткойна и позволяют использовать смарт-контракты. Для Биткойна это, несомненно, палка о двух концах. В этой статье мы рассмотрим, что такое ковенанты, как они работают, их надежная функциональность и их значение для Биткойна. При обсуждении деталей в этой статье в качестве примера часто используется CTV, но CTV — не единственный метод реализации заветов.

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

1.

Хуа:

Прежде чем обсуждать ковенанты, возможно, потребуется прояснить два вопроса, связанных с Биткойном, что может помочь нам лучше понять ковенанты.

Мы знаем, что Биткойн использует язык сценариев, и известно, что языки сценариев поддерживают реализацию смарт-контрактов. Однако на самом деле смарт-контракты не были реализованы в основной цепочке Биткойн. Это неизбежно создает ощущение, что реализация смарт-контрактов в Биткойне сталкивается с некоторыми непреодолимыми препятствиями, и это кажется невозможным в сети Биткойн.

Однако многие люди могут не знать, что, хотя Биткойн можно запрограммировать с использованием языка сценариев, набор кодов операций крайне ограничен. Этот ограниченный набор кодов операций ограничивает возможности программирования Биткойна, а это означает, что, хотя язык сценариев может реализовывать смарт-контракты, у программистов нет достаточных «инструментов» для реализации смарт-контрактов.

Поли:

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

На протяжении многих лет это создавало множество проблем, поскольку люди пытались обойти эти ограничения. У нас также произошел семантический сдвиг в термине «смарт-контракт», который означает одну конкретную вещь, когда вы должны рассматривать сеть Lightning как создание множества смарт-контрактов, сформированных многими людьми. Эти мультиподписи с хэшлоками и таймлоками являются не только смарт-контрактами, но и имеют временные соглашения.

Проблема в том, что, как вы уже упоминали ранее, поскольку у Биткойна есть только простые коды операций для выполнения только основ, если вы попытаетесь масштабироваться за пределы двух человек в смарт-контракте, вы можете получить либо сильное раздувание внутрицепочного следа, либо то, что вы хотите сделать, может оказаться невозможным. Это строгое ограничение исходит из нескольких мест. Я думаю, что самое большое из них заключается в том, что когда в 2010 году произошла ошибка инфляции, Сатоши отключил целый список кодов операций более высокого порядка, включая OP_CAT, который позволил бы нам создавать более динамичные смарт-контракты посредством транзакций. самоанализ.

С тех пор BCH преодолела это ограничение в своем собственном скрипте, показав, что скрипт не так слаб, как все предполагают, просто Биткойн всегда был медленнее из-за его децентрализации, а координация практически невозможна, за исключением длительных периодов времени. Мы также почти не затронули Taproot и Tapscript, которые облегчат многие проблемы, связанные с занимаемым пространством, и позволяют использовать новые варианты поведения, такие как BitVM, путем объединения контракта в подпись, и вы раскрываете его только при необходимости.

Хуа:

Почему существуют строгие ограничения на коды операций? Можете ли вы использовать OP_CAT в качестве примера, чтобы помочь нам понять этот момент?

Поли:

Итак, OP_CAT обманчиво прост: он берет две строки и складывает их вместе. Первоначально он был отключен, потому что у него были проблемы с ресурсами, и его можно было использовать для сбоя узлов, но я не уверен, что это полная история, поскольку Сатоши установил ограничение стека в 520 байт и отключил OP_CAT в том же коммите, поэтому их может быть больше. к этому, чем простое истощение ресурсов.

Но просто чтобы дать краткий список того, что может выполнять OP_CAT: соглашения CTV/TXHASH, проверка доказательств SPV, защита от двойного расходования для TX 0-conf, 64-битная арифметика, хранилища, квантово-устойчивые подписи. Этот список можно продолжить: только OP_CAT может эмулировать транзакции в стиле CTV[CheckTemplateVerify] и TXHASH. Единственная проблема заключается в том, что он крайне неэффективен в том, как он выполняет эти действия, которые могли бы быть возможны, но это может просто сделать эти транзакции нежелательными, за исключением пользователей масштаба, таких как хранители.

2.

Хуа:

Давайте поговорим об еще одном «ограничении» Биткойна. Биткойн поддерживает только «верификацию» как форму вычислений и не может выполнять вычисления общего назначения.

Мы также знаем, что, например, смарт-контракты на Ethereum содержат правила перехода состояний. Он завершает переход состояния посредством вычислений, обеспечивая функциональность смарт-контрактов. Для сравнения, Биткойн не может выполнять вычисления общего назначения, то есть он не может самостоятельно осуществлять переходы между состояниями посредством вычислений.

Верно ли мое понимание?

Поли:

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

На самом деле я не такой уж большой поклонник того, как работает Ethereum. Из-за того, что это является вычислительным по своей природе со встроенной проверкой, если я попытаюсь совершить сделку, мое окно может сдвинуться, и я могу «не суметь торговать», но транзакция для попытки торговать все еще была действительна, поэтому я все равно заплатил за комиссии, которые потратили мои деньги на то, что я хотел бы считать неудачной транзакцией, и потратили впустую блоковое пространство для кого-то другого. Еще один странный аспект — оракулы в Эфириуме. Оракулы должны платить газ, чтобы обновить цены своих оракулов, тогда как в биткойнских DLC оракул ослеплен и просто предоставляет подпись и не может быть «закреплен» из-за изменения комиссий, а также не может ориентироваться на конкретные контракты.

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

3.

Хуа:

Давайте теперь начнем обсуждать заветы. Что такое заветы?

Поли:

Ковенанты обычно относятся к ограничениям на передачу монет. Слово «завет», кажется, несет в себе некую коннотацию, поэтому оно помогает демистифицировать его и объяснить как простые запирающие механизмы, которые можно разместить только на вашей *собственной* монете.

У нас уже есть два соглашения внутри Биткойна, и они поддерживают сеть Lightning Network: CSV [CheckSequenceVerify] и CLTV [CheckLockTemplateVerify]. Некоторые просто называют эти коды операций «примитивами смарт-контрактов», поскольку они представляют собой простые временные блокировки, но их также можно классифицировать как временные соглашения.

CTV [CheckTemplateVerify] — это предлагаемое обновление Биткойна, включенное в BIP 119. Оно отличается от CSV и CLTV. Вы можете думать о CTV как о «блокировке TXID [Transaction ID]» или «блокировке UTXO», только эти TXID могут быть сделан из этого замка. Для CTV мы называем эту блокировку TXID «Соглашениями о равенстве», поскольку результирующие транзакции должны быть равны исходным транзакциям, которые были зафиксированы. Его также называют соглашением об отсрочке обязательств, поскольку вы можете видеть, что ваш UTXO был принят на себя, но еще не размещен в цепочке.

Наиболее известной альтернативой является SH_APO [Любой предыдущий выход или AnyPrevOut], который фокусируется на обеспечении обязательства по выплате, одновременно позволяя методу внесения быть гибким. Обсуждаются также несколько других: OP_CCV [также известный как MATT], OP_EXPIRE, TXHASH и TEMPLATE KEY.

Хуа:

Когда вы упоминаете, что «ковенанты обычно относятся к ограничениям на то, как можно передавать монеты», могу ли я понимать это так: Ковенанты — это метод определения того, как могут быть использованы средства, или, другими словами, это способ ограничения того, где средства могут быть использованы. потраченный.

Поли:

Да, он фактически предусматривает распределение UTXO определенным образом: как только вы примете на себя обязательство, вы не сможете забрать его обратно, теперь он привязан к консенсусу, и только его новый владелец может решить, как потратить свои средства.

Когда UTXO создается в цепочке, мы инстинктивно предполагаем, что этот UTXO хранится на одном закрытом ключе. Но если это был UTXO, связанный с CTV, то когда UTXO будет потрачен, вы увидите дополнительный 32-байтовый хэш в паре с новой транзакцией, которая представляет скрытое состояние, которое было внутри исходного UTXO.

Хуа:

Вы несколько раз упомянули «блокировку TXID/блокировку UTXO». Могу ли я понять это так: чтобы понять, как CTV реализует свою функциональность, нам нужно понять, что такое блокировка TXID и как она работает. Блокировка TXID — это ключевой механизм.

Поли:

Да, это создает прочную основу для построения дальнейших схем. TXID определяется содержимым tx. И если вы можете добавлять входные данные в tx, вы можете манипулировать TXID. CTV позволяет заблокировать количество входов и выходов. Таким образом мы гарантируем, что обязательства CTV не заслуживают доверия. Если бы TXID был податливым, вы потенциально могли бы украсть чьи-то средства. Если у вас есть механизм блокировки TXID, вы объединяете его с другими механизмами блокировки, такими как временные блокировки, для создания еще более эффективных смарт-контрактов.

4.

Хуа:

Как вы думаете, почему заветы — это кроличья нора?

Поли:

Я называю ковенанты кроличьей норой, потому что с помощью простых ограничений на транзакции, таких как блокировка по времени или блокировка TXID, можно сделать очень многое. Нам удалось построить всю сеть Lightning с помощью простых временных блокировок, и хотя она не идеальна, это единственная существующая по-настоящему децентрализованная сеть L2. Мне не нравится, как он постепенно смещается в сторону кастодиального контроля, но именно поэтому я и начал рыться в этой кроличьей норе: чтобы сделать наши смарт-контракты более мощными. Мы называем блокировку TXID шаблоном. С Taproot мы получили возможность агрегировать подписи. Благодаря шаблонам и CTV мы получаем возможность агрегирования транзакций.

CTV служит заменой предварительно подписанного оракула транзакций, что устраняет требования к доверию и интерактивности, необходимые для создания более сложных смарт-контрактов, необходимых для таких вещей, как хранилища и платежные пулы. Хранилища и пулы платежей, которые вы можете создать с помощью CTV, сегодня технически возможны, но в настоящее время они исключены из-за доверия или интерактивности, необходимых для их работы. Более того, с помощью CTV мы можем создавать фабрики каналов, дополнительные решения уровня 2, такие как Ark, Timeout-Trees, Stakechains или Surfchains, а также решения JIT Fidelity Bond, такие как PathCoin.

Вероятно, моя любимая функция — это неинтерактивные каналы [NIC], которые мы также называем холодными каналами. Основная идея состоит в том, чтобы взять обычный канал Lightning и просто поместить его в шаблон CTV. Что отличает его от обычного канала Lightning, так это то, что ни одной из сторон на самом деле не нужно было находиться в сети для создания этого канала. Поэтому, если мне нужен канал с другим человеком, мне не нужно, чтобы он был в сети, чтобы создать его, мне даже не нужно говорить им, что я это сделал, пока я не буду готов потратить на него деньги! Это позволяет использовать возможность холодного хранения на молнии, поскольку мне не нужна сторожевая вышка или узел для защиты моих средств в любых каналах, которые еще не активны. Сторонние координаторы также могут установить сетевые карты для двух человек, что обеспечивает большую гибкость в возможностях.

В нынешнем виде CTV не позволит вам создавать ончейн DEX, но я не уверен, что это так уж плохо, поскольку люди в настоящее время пытаются построить оффчейн DEX, используя Lightning Network, как это происходит сегодня. . Я думаю, что это связано с дискуссией «Верификация против вычислений»: сколько вы действительно хотите в сети, а сколько вам нужно для проверки в сети. Единственное, что меня беспокоит в отношении сетевых DEX, помимо чрезмерных обновлений в сети, приводящих к более высоким комиссиям, — это MEV. Мы уже заметили некоторую MEV от транзакций DEX BCH, и по мере взросления рынка ситуация обязательно ухудшится.

Хуа:

Можете ли вы привести пример, который поможет нам понять, как работает CTV?

Поли:

Допустим, я ожидаю получить 5 BTC, и на данный момент единственное, что я могу сделать, это получить платеж и проверить его в сети. С помощью CTV я могу взять на себя обязательства по будущим адресам или людям и свести их к простому публичному ключу, который я даю своему плательщику, чтобы он заплатил мне. Они не знают подробностей этого, поэтому это остается конфиденциальным для всех, кроме меня. Как только я смогу подтвердить, что мне заплатили, все действия, которые я предпринял с использованием шаблона CTV, также вступили в силу.

Таким образом, если бы я решил создать канал с Бобом, как только Алиса заплатит мне, канал с Бобом теперь будет зафиксирован, хотя канала с Бобом нигде не видно в цепочке, он доступен только через мой шаблон и транзакцию. который создала Алиса. Это известно только мне, пока я не поделюсь подробностями канала с Бобом. Как только я поделюсь подробностями с Бобом, мы сможем использовать канал в обычном режиме. Когда мы совместно закрываем канал, вместо того, чтобы размещать в цепочке детали открытого канала, мы просто помещаем в цепочку закрывающий канал. Это позволяет нам выполнять сквозные транзакции, сокращая общее количество транзакций, которые должны быть в цепочке, как минимум вдвое для решений уровня 2.

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

5.

Хуа:

Как вы упоминали ранее, мы можем вводить различные коды операций для реализации заветов.

Поли:

Поэтому, если мы вновь введем OP_CAT, я думаю, это позволит реализовать практически все возможные типы соглашений, поскольку вы сможете имитировать любую форму самоанализа для TXHASH. Более ограниченным методом было бы введение кодов операций, представляющих желаемое явное поведение, как в случае с CTV, CSFS или CheckSeperateSignature. CTV — это возможность делать отложенные выводы. CSFS — это возможность делать отложенные подписи, чтобы вы могли отложить сам платеж. Они звучат одинаково и на самом деле хорошо работают вместе как строительные блоки, обеспечивающие LN-симметрию, но обязательства выполняются на разных уровнях.

TXHASH и TEMPLATE KEY позволяют осуществлять самоанализ и служат одной и той же цели, но TEMPLATE KEY использует однобайтовый режим, а TXHASH использует многобайтовые флаги. Это открывает гораздо более мощные возможности внутри скриптов и смарт-контрактов, но многие обеспокоены возможными побочными эффектами. TXHASH и TEMPLATE KEY — это скорее CTVv2, который сделает CTV более мощным и выразительным.

Хуа:

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

Поли:

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

Многие разработчики следят только за Lightning и за его развитием. Они склонны отдавать предпочтение таким кодам операций, как SH_APO, поскольку он обеспечивает LN-симметрию. Многие разработчики, которым не особенно нравится Lightning из-за его ограничений, таких как ограничения входящей ликвидности или требования быть онлайн, они склонны отдавать предпочтение таким кодам операций, как OP_CAT, TXHASH, как более выразительным решениям масштабирования. Разработчики, которые предпочитают CTV, более нейтральны и смотрят на него с системной точки зрения. Оно не обязательно делает что-то идеально, но значительно расширяет возможности каждого делать то, что он предпочитает, каким бы оно ни было, не создавая при этом рисков, которые могут возникнуть. не может быть измерен, поскольку не предполагает самоанализа.

6.

Хуа:

Прежде чем обсуждать ковенанты, мы говорили о проблемах, связанных с кодами операций в языке сценариев, и о проблеме ограниченных вычислений, приводящих к переходу состояний. Мы уже знаем взаимосвязь между ковенантами и опкодами. Теперь давайте углубимся в проблему перехода состояний. Я не уверен, что рассматривать ковенанты с точки зрения «перехода государства» правильно, но эта перспектива меня действительно очаровывает.

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

Поли:

Завет – это шаблонная оболочка или «государство». Внутри него вам нужно будет создать временные блокировки и другие функции, чтобы обеспечить желаемую функциональность, которая вам нужна, будь то хранилище, канал молнии или какое-либо другое решение уровня 2.

Таким образом, CTV позволяет создавать состояние, но вам необходимо динамически перестраивать состояние при каждом переходе, чтобы поддерживать его в гомеостазе, мы называем это метарекурсивным. В то время как что-то вроде SH_APO позволяет вам создавать состояние, а затем периодически обновлять его, делая его рекурсивным. CTV также может создать цепочку транзакций, которая позволит вам «пройти через это состояние».

Хорошим примером для размышления является Ark, это гигантский смарт-контракт, почти как гигантский монетный союз, и тот, кто запускает протокол, создает новое состояние [или раунды, как его называют] каждые несколько секунд, чтобы участники могли платить другим по мере необходимости. Как только оператор Ark будет готов, он отправит транзакцию в мемпул, чтобы зафиксировать текущее состояние в цепочке. Эти заполнители в цепочке можно рассматривать как «переходные состояния». Оператору приходится постоянно пересчитывать новые состояния, чтобы представить их участникам Ark, и то, что отправляется в цепочку, является проверкой этого состояния.

Хуа:

Можем ли мы понять это так: Ковенанты реализуют форму смарт-контракта, основанную на проверке, а не на вычислениях?

Поли:

Да. Определенно. Этот смарт-контракт просто сравнивает транзакцию с соответствующим хешем sha256. Проверка скорости блока фактически увеличится, поскольку нет никаких операций подписи.

Хуа:

Одним из направлений развития блокчейнов является модульность, включая вычисления вне цепочки. Тем не менее, похоже, что Биткойн естественным образом создан для вычислений вне цепочки, отставая, но фактически лидируя. Что вы думаете?

Поли:

Время — плоский круг. Удивительно, но кажется, что мы прошли полный круг к тому, чего хотят от блокчейна. Похоже, что у Биткойна все еще есть некоторые проблемы с модульностью и размером. Мне бы хотелось, чтобы у нас были лучшие сайдчейны, которые не были бы просто решениями с несколькими подписями и использовали бы настоящие криптографические средства для защиты своих средств и позволяли бы односторонние выходы. Я думаю, что это поможет расширить границы модульности Биткойна. Taproot позволил проводить еще больше вычислений вне цепочки с помощью таких вещей, как BitVM, что позволило бы нам вычислять практически все, что угодно, вне цепочки. Но, к сожалению, он не может эмулировать такие вещи внутри Биткойна, как CTV, так что, похоже, нам еще есть куда двигаться вперед.

7.

Хуа:

Какие возможности могут быть достигнуты путем объединения соглашений с другими кодами операций, такими как DLC?

Поли:

Таким образом, у DLC есть несколько проблем, которые можно было бы решить с помощью соглашений, таких как повышение гибкости параметров DLC за счет создания множества ценовых точек [если мы делаем ставку на цену чего-то, например, Биткойна]. Другая причина заключается в том, что аппаратные кошельки [HWW] не могут взаимодействовать со многими DLC, а раунды подписания DLC и попытки сделать это с HWW приводят к тому, что открытие DLC занимает несколько минут. С помощью CTV эту задержку входа в DLC можно сократить до секунд.

8.

Хуа:

Есть ли еще какие-то моменты, которые вы хотели бы представить читателям?

Поли:

Мы рассмотрели множество концепций. Мы коснулись того, как его можно использовать для смягчения чрезмерного спроса на блоковое пространство и потенциальных DDoS-атак. Мы обсуждали, как люди могут сэкономить место, создав неинтерактивные каналы. Я думаю, что еще один хороший вопрос для обсуждения — это «проблема выхода L2». Если нам удалось вывести всех из уровня L1 и переместить их на большой уровень L2, в настоящее время не существует хорошего способа ускорить вывод людей из этого уровня L2. Мы могли бы думать об этом L2 как о Lightning [мы называем потенциальный массовый исход Lightning «проблемой громового стада»] или о Coinbase, Binance или Liquid как о L2. Есть люди, которые претендуют на Биткойн, но их единственный способ получить это требование — это отправить транзакцию, чтобы разместить ее в цепочке. На Coinbase миллионы людей, я понятия не имею, как вывести их оттуда и на Биткойн каким-либо упорядоченным образом в сегодняшних условиях. Попытка вывести людей из биржи приведет к задержке в мемпуле на 6 месяцев. CTV может это исправить.

Создайте ковчег или дерево тайм-аутов с помощью CTV. Биржа могла бы даже предлагать эту услугу напрямую. Каждый мог быть выгружен из исходного «общего UTXO», который находился в соответствии с консенсусом Coinbase, и помещен в «общий UTXO» с консенсусом по своему выбору, будь то простой пул или большое дерево тайм-аутов. Вот тут уж совсем мозг морщится, это было чистое преобразование L2<>L2. Не было никакого промежуточного шага, требующего от меня сначала спуститься на уровень L1. И я могу продолжать повторять этот процесс бесконечно, используя любой слой по своему выбору. Нет необходимости возвращаться на базовый уровень, если меня не заставили туда, например, из-за отказа от сотрудничества с моим каналом или, возможно, удаления из моего хранилища. Ошибка Ark и Timeout-Tree заключается в том, что у них есть требования к переносу средств: вам придется перемещать свои средства каждые несколько недель или месяцев, иначе вы потеряете свои средства. Это не идеальное решение для долгосрочных фондов, но отлично работает для любых краткосрочных холдингов и более крупных рынков.

Я хотел бы предоставить полный список всех концепций, которые были разработаны с использованием CTV и его способности просто агрегировать предварительно подписанные транзакции: неинтерактивные каналы, деревья тайм-аутов, Ark, даркпулы, платежные пулы, платежные каналы, шаровая молния, Контроль перегрузки, Dpool's, сжатие, замена деревьев, PathCoin, Stakechains, Surfchains. Но не думайте об этом как о независимых шаблонах: если есть функция одного, которую вы хотите включить в другой, вы можете создать свой собственный шаблон, чтобы попытаться найти желаемое поведение.

Использованная литература:

Заветы Оуэна 101 https://x.com/OwenKemeys/status/1741575353716326835 Заветы Оуэна 102 https://x.com/OwenKemeys/status/1744181234417140076 Демо-версия CTV Оуэна https://x.com/OwenKemeys/status/1752138051105493274 Букварь Далласа https://x.com/dallasirushing/status/1740443095689318566 Пакетирование каналов Lightning требует соглашений https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022006.html Деревья таймаута https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-September/021941.html Арк https://www.arkpill.me/ Даркпулы https://gist.github.com/moonsettler/6a214f5d01148ea204e9131b86a35382 PathCoin https://github.com/AdamISZ/pathcoin-poc

Заветы Оуэна 101 https://x.com/OwenKemeys/status/1741575353716326835

Заветы Оуэна 102 https://x.com/OwenKemeys/status/1744181234417140076

Демо-версия CTV Оуэна https://x.com/OwenKemeys/status/1752138051105493274

Букварь Далласа https://x.com/dallasirushing/status/1740443095689318566

Пакетирование каналов Lightning требует соглашений https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022006.html

Деревья таймаута https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-September/021941.html

Арк https://www.arkpill.me/

Даркпулы https://gist.github.com/moonsettler/6a214f5d01148ea204e9131b86a35382

PathCoin https://github.com/AdamISZ/pathcoin-poc

Это гостевой пост Эмли Хуа. Выраженные мнения являются исключительно их собственными и не обязательно отражают точку зрения BTC Inc или Bitcoin Magazine.