Можем ли мы создать UTXO, который можно потратить только через доказательство работы?

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

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

Без OP_CAT и с арифметикой, ограниченной 4-х байтными входами, правильно ли я понимаю, что вышеизложенное было бы невозможно? Или есть обходной путь?

Вы можете добавить возврат операции в свой tx с первыми 200 битами закрытого ключа. Плательщику придется перемалывать последние 56 бит, пока он не найдет правильный закрытый ключ для подписи. Комбинируйте с мультиподписью или настройкой Шнорра, чтобы настроить таргетинг на одного получателя!
@pinhead спасибо! Это умный способ сделать это. Действительно, для раскрытия ключа потребуется доказательство работы. Однако в этом случае каждый гарантированно в конечном итоге получит по существу один и тот же «одноразовый номер» (то есть всего лишь полный закрытый ключ), так что не сможет ли майнер основной цепи просто украсть награду? Или, другими словами, можете ли вы уточнить, что вы имеете в виду, говоря об использовании, например, мультиподписи, чтобы она предназначалась для одного получателя? А именно, кто бы ни выполнял работу, но также и таким образом, чтобы первоначальному UTXO не нужно было знать, кто является набором потенциальных работников. Имеет ли это смысл?
Хм, это тяжело. Майнеры могут украсть все, что не подписано. Я думал, что вы можете отправить мультиподпись 2 из 2, где один ключ является известным получателем, а другой ключ должен быть взломан (этим получателем). Майнер не сможет украсть это.
Еще раз большое спасибо за ваш ответ. Это очень полезно. Таким образом, проблема с этой конструкцией (предложенный вами метод 2 из 2) заключается в том, что мне нужно заранее знать ключ получателя, а это не то, что я хочу. Есть ли способ связать серию этих типов транзакций вместе, чтобы добиться этого?
Каково применение этого? Мне любопытно узнать, чего вы пытаетесь достичь
привет @chytrik, спасибо за интерес. Есть пара приложений, о которых я могу думать. Хотя основной вопрос, который меня больше всего интересует, ускользает от моего другого вопроса здесь bitcoin.stackexchange.com/questions/91069/… заголовок блока сайдчейна исключительно с доказательством работы (в отличие от федеративного). Таким образом, вопрос здесь является просто сокращенной формой этого вопроса.

Ответы (1)

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

  • набор определенных получателей, которые могут потратить, если они выполнят PoW: у вас может быть транзакция, которая может быть потрачена, если кто-то предоставит: значение, хэш которого меньше указанной суммы (которая определяет сложность) И подпись, которая описывает набор разрешенных сущности (потенциально любая мультиподпись).
  • любой, кто выполняет доказательство работы, может тратить (И вы можете тратить без PoW): это сложнее, поскольку простой PoW на основе хэша не будет работать, майнер может просто изменить адрес назначения расходной транзакции на адрес, находящийся под его контролем. Вам нужно доказать, что вы знаете секрет (результат PoW), фактически не включая его в tx, чтобы майнеры не могли получить деньги без повторения PoW: это то, что делают цифровые подписи. Как было предложено в комментариях, вы можете создать utxo, который можно потратить, подписавшись с определенным закрытым ключом, известным только вам, и который содержит его часть подop_return. Таким образом, нужно попробовать любой закрытый ключ из набора разрешенных, пока он не сможет создать действительную подпись. Это не приводит к утечке самого закрытого ключа, поэтому майнер не может подписать один и тот же tx с другим адресом назначения.
  • любой, кто выполняет доказательство работы, может тратить (И вы НЕ можете тратить без PoW): я думал об этом некоторое время и не могу найти простой конструкции для этого, это может быть сложно даже с более сильными возможностями сценариев, чем у биткойна. Мое лучшее предположение состоит в том, что у вас есть доказуемо случайный открытый ключ (например, с использованием VDF в одноразовом номере последнего блока), и каждый должен использовать закрытый ключ, чтобы потратить его. Я вижу две основные проблемы: майнеры могут иметь некоторое преимущество в выборе одноразовых номеров, чтобы повлиять на случайность PK, и сложно настроить сложность, вам нужна настраиваемая схема подписи, которая имеет желаемый уровень безопасности, и это нетривиально с биткойн-скриптом.

Это НЕ полный список, это только первые идеи, которые пришли мне в голову. Особенно второй случай, который кажется мне наиболее вероятным, может быть сконструирован несколькими различными способами: например, вы также можете опубликовать хэш закрытого ключа в ( op_returnтак что закрытый ключ не должен быть включен в транзакцию). ), и вы бы превратили его в PoW на основе хэша, поскольку хеширование намного быстрее, чем подпись.

спасибо за Ваш ответ. Для первого пункта вы упоминаете сравнение, если хэш меньше определенного значения. Однако хэш представляет собой 256-битное число, а числовые операции сравнения в биткойн-скрипте ограничены 32 битами. Так я не уверен, что этот вариант вообще будет работать? Однако из ваших сценариев третий — это тот, который я пытаюсь реализовать: любой выполняет работу, И я не могу тратить деньги, не выполняя работу. Пока я в тупике.
Я вообразил, что желательный случай — третий. Совсем не простая задача. Вы меня не подготовили к вопросу числового сравнения, но за счет написания безумно запутанного сценария, я думаю, вы можете обойти это. Если у вас достаточно 32 битов безопасности, вы можете просто взять последние 4 байта хеша и сравнить их с целью. В противном случае вы можете взять последние два блока по 4 байта и объединить две проверки.
Это интересный подход (хотя, как вы предложили, похоже, что сценарий может оказаться довольно раздутым/запутанным). Однако я думаю, что «взять последние 4 байта хэша» это может сломаться. Помещение 32 байтов (хеш) в стек представляется возможным. Однако вытягивать по 4 байта за раз и сравнивать их кажется невозможным, если я не ошибаюсь? Еще раз спасибо за ваши мысли по этому поводу.
Я определенно не эксперт по биткойн-скриптам, но при беглом взгляде это кажется невозможным, я не думаю, что смогу помочь дальше. Это может стать проще с чем-то вроде сценария без скриптов, но я действительно слишком мало знаю об этом.
Да, с грядущими (возможными) обновлениями что-то подобное может стать возможным. А пока я тоже не уверен. Спасибо за ваши мысли об этом!
Чтобы построить доказательство работы таким образом, чтобы оно также было защищено от атак майнеров, вы все равно можете сделать то, что было предложено в первом комментарии. Вы можете добавить к обычному tx вывод, содержащий часть закрытого ключа. Таким образом, нужно перебрать оставшиеся биты, чтобы получить действительную подпись, и майнеры не имеют значительного преимущества. В этом случае создатель точно знает закрытый ключ, и никак иначе. Почему вы не рассматриваете это направление?
Извините за опоздание. Основная причина, по которой это направление менее интересно для меня, заключается именно в том, что создатель будет знать закрытый ключ. Так что это не будет «честной конкуренцией» между теми, кто пытается завершить работу.
Если вы поместите частичные закрытые ключи в OP_RETURN, что мешает мне «троллить» всех, отправляя аналогичные транзакции с неправильными частичными закрытыми ключами? «Хахаха, вы, ребята, сделали 2 ^ 56 зря! Лохи!»
Может быть, может быть хэш с оплатой за скрипт, в котором требование решить сложность требовало майнинга на самом последнем произведенном блоке. Вы можете попросить конкурирующих майнеров хешировать самый последний блок и получить одноразовый номер, который создает уровень сложности обмена, необходимый для траты вознаграждения. Таким образом, после каждого нового блока мог быть только один победитель, сложность можно было регулировать для каждого блока, и никто не мог «подделать» доказательство работы, отвечающее этим требованиям. Если кто-то предоставит копию последнего блока с добавленным дополнительным одноразовым номером, соответствующий сложности конкурса, верните true.
Чтобы уточнить, использование целого блока биткойнов нереалистично (если вы не хэшируете сжатую версию?), но должно быть достаточно доказательства Меркла данных из блока (что в основном представляет собой своего рода сжатую контрольную сумму). Хотя размер этих данных может усложнить решение доли, которую необходимо учитывать.