Как создать действительный адрес биткойна для уничтожения биткойнов?

(После этого вопроса .)

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

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

Как можно выбрать адрес для уничтожения биткойнов, чтобы каждый мог быть разумно уверен, что никто не узнает секретные ключи, чтобы тратить уничтоженные биткойны?

33 голоса | спросил billpg 3 42011vEurope/Moscow11bEurope/MoscowThu, 03 Nov 2011 00:34:22 +0400 2011, 00:34:22

6 ответов


29

Начать с недопустимого открытого ключа

Биткойн-адреса - это pubkeyhash (not pubkey) плюс информация о версии и контрольной сумме, закодированная в базе 58.

Bitcoin address = version + RIPEMD-160(SHA-256( Public Key )) + checksum

Шаги для преобразования открытого ключа в адрес можно найти здесь: https://en.bitcoin.it/wiki/Address

Поскольку адрес использует pubkeyhash, а не фактический pubkey, мы можем использовать это путем хеширования недопустимой паб-клавиши (такой, которая не может существовать) и, таким образом, создать допустимый адрес из недопустимой панели.

Итак, чтобы начать, мы обнаруживаем недопустимый открытый ключ. Все действующие открытые ключи начинаются с 0x04, если они не сжимаются, и 0x02 или 0x03, если они сжаты. Паблик, начинающийся с любого другого значения, не определен и, следовательно, не существует возможной подписи, которая может быть создана для удовлетворения этого ключевого требования. Поскольку для расходования монет требуется подписание транзакции с помощью правильного закрытого ключа, адрес, который не имеет известного закрытого ключа, является неприменимым. Используя открытый ключ, который, как известно, не имеет частного ключа, другие могут подтвердить, что никакого закрытого ключа не существует.

Действительный открытый ключ биткойна (не адрес):

  

04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f

Недействительный открытый ключ

  

0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Существуют и другие способы создания известного недопустимого открытого ключа. Ключи ECDSA должны быть ровно 65 байтов, если они не сжаты, или 33 байта, если они сжаты, поэтому ключ с другой длиной также будет недействителен. Для несжатых клавиш значение y должно быть правильно создано из значения x. Точка также должна лежать на кривой. Он также не может быть выше модуля кривой. Таким образом, существует множество способов создания явно недопустимых ключей, но лучше всего выбрать тот, который явно недействителен. Это, вероятно, самый простой явно недопустимый открытый ключ.

  

0x00

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

Важно то, что это не просто какой-то, вероятно, недопустимый ключ, это явно недопустимый ключ.

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

Произвести действительный (но непередаваемый) адрес из вашего недопустимого открытого ключа

Вы можете задаться вопросом, почему мы хотим, чтобы адрес был действительным. Все клиенты должны проверять адреса, данные пользователями, чтобы избежать случайной потери средств. Таким образом, недействительный адрес также неприменим, но большинство пользователей не смогут отправить деньги на адрес. Адрес P2PhH - это pubkeyhash с информацией о версии и контрольной сумме, закодированной в базе58.

Когда вы предоставляете адрес клиенту Bitcoin, он декодирует адрес обратно до «raw» pubkeyhash. Таким образом, создание действительного адреса означает начало с действующей паб-кнопкой. Это не проблема, потому что хэш чего-либо является допустимым хэшем. Клиенты не знают, что pubkey hashed для создания pubkeyhash, поскольку базовая папка не предоставляется, а функции хеширования - это один из способов.

Сеть Bitcoin только проверяет, что адрес находится в правильной форме, длине и имеет правильную контрольную сумму, когда «проверяет ее». Получение адреса из pubkey выходит за рамки этого вопроса, но есть утилиты, а ссылка выше предоставляет шаги. Получаемый pubkeyhash и закодированный адрес будут считаться действительными сетью и клиентом, но для этого требуется явно невозможный закрытый ключ, чтобы тратить средства, отправленные на этот адрес.

Теперь, используя только адрес (и декодированный pubkeyhash), пользователь не может проверить, что основной паб-ключ недействителен, поэтому вы должны опубликовать raw pubkey вместе с адресом. Пользователи могут воссоздать адрес, используя любой биткойн-клиент или инструмент, и будут предоставлять тот же адрес, который вы предоставляете. Теперь у пользователей есть надежный способ убедиться, что монеты действительно не поддаются проверке. Любые монеты, отправленные по адресу, никогда не могут быть потрачены и эффективно уничтожены.

Столкновение хешей

Технически это возможно, но маловероятно, чтобы более одного открытого ключа имел один и тот же адрес биткойна. Это называется хеш-столкновением. Если открытый ключ p1 и открытый ключ p2 оба хеша к одному и тому же адресу A, то приватные ключи для любого из этих открытых ключей могут тратить средства. Однако вероятность этого очень низкая. Если алгоритм хеширования RIPEMD не сломан, вероятность нахождения двух открытых ключей, которые генерируют один и тот же хеш(Адрес биткойна) равен 1 в 2 ^ 160, что намного превышает нашу вычислительную мощность для определения местоположения.

Несколько слов о том, почему вы должны использовать номер «Nothing Up My Sleeve»:

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

Если вы просто возьмете случайный недействительный ключ, например:

  

00000fdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f

Некоторые могут задаться вопросом, почему вы выбрали этот конкретный ключ. Страх в том, что вы выбираете этот ключ не случайно, а потому, что вы наткнулись на столкновение между этим ключом и действительным ключом. Невозможно доказать, что ключ случайен, поэтому страх всегда останется. Криптографические функции (например, RIPEMD или SHA-256) часто используют «ничего в моих значениях рукава», чтобы обеспечить безопасность, чтобы константа не была выбрана для включения криптографического дефекта или «бэкдора» в алгоритм. Например, SHA-256 использует константы для начальных значений сегментов блока. Технически это может быть любое случайное число, но это может привести к обеспокоенности тем, что «случайное» число фактически не является случайным. Таким образом, SHA-256 использует первые 32 бита фракционной части корня куба из первых 8 простых чисел. Это позволяет проверять, когда требуется псевдослучайное число. Очень маловероятно, что существует некоторое магическое свойство между дробной частью корня куба последовательных простых чисел, которая подрывает SHA-256.

http://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number

Обновление (03/31/2015)

Легче сделать это сейчас, используя вывод OP_RETURN (нулевые данные), и он не раздувает UTXO с выходами, которые не могут быть потрачены, но сеть не знает, что они не могут быть потрачены. Любые средства, отправленные на вывод, который содержит OP_RETURN, являются, по-видимому, непревзойденными, и сеть будет отключать вывод из UTXO. UTXO (неизрасходованный набор выходных данных tx) является критическим ресурсом, необходимым для проверки новых транзакций и блоков, поэтому уничтожение /сжигание монет с использованием UTXO является более ответственным использованием этого общего ресурса.

ответил DeathAndTaxes 3 42011vEurope/Moscow11bEurope/MoscowThu, 03 Nov 2011 00:52:55 +0400 2011, 00:52:55
8

Существует четыре основных способа, и все они работают:

  1. Придумайте адрес, который проходит основные проверки работоспособности, но внутренне недействителен. Вы можете точно знать, что ни один ключ не может соответствовать этому адресу.

  2. Поместите строки символов в адрес, который выходит за рамки того, что кто-то может генерировать в адресе суеты. Например, если в адресе Bitcoin есть «FourScoreAndSevenYearsAgo», это явно выходит за рамки возможности найти соответствующий закрытый ключ.

  3. Используйте открытый ключ, который, очевидно, составлен, например, тот, который состоит только из нулевых байтов или содержит все последовательные цифры Pi. Очевидно, что никто не может найти соответствующий закрытый ключ. (Чтобы это работало, вам нужно разгласить открытый ключ.)

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

ответил David Schwartz 3 42011vEurope/Moscow11bEurope/MoscowThu, 03 Nov 2011 02:55:43 +0400 2011, 02:55:43
4

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

1CounterpartyXXXXXXXXXXXXXXXUWLpVr <- используемый контрагентом

1ChancecoinXXXXXXXXXXXXXXXXXZELUFD <- используемый Chancecoin

Эти адреса характеризуются человекочитаемым идентификатором в начале, за которым следует большое количество X. Чтобы тратить средства на такой адрес, вам нужно сначала отменить хэш (невозможно), а затем найти закрытый ключ, который соответствует открытому ключу (также невозможно).

Обратите внимание, что последние шесть цифр этих адресов - контрольные суммы Base58Check. Это единственная сложная часть процесса: вам нужно найти более 4 миллиардов строк, пока не найдете действительную строку Base58Check. Это займет всего лишь мгновение. Вы можете легко сгенерировать эти адреса, используя adamkrellenstein /unspendable на GitHub.

Вдохновленный этот другой ответ StackExchange .

ответил paulkernfeld 7 FebruaryEurope/MoscowbSun, 07 Feb 2016 12:45:30 +0300000000pmSun, 07 Feb 2016 12:45:30 +030016 2016, 12:45:30
1

Способы, описанные в DeathAndTaxes, являются подходящими. Метод OP_RETURN, безусловно, лучший, если вы хотите придерживаться рекомендаций биткойна.

Тем не менее, я хотел бы представить альтернативный метод, в котором вы можете предусмотрительно сжечь монеты, а также включить достаточную информацию в адрес. Мы использовали этот метод в первых версиях OpenBazaar, и он называется " почти столкновение монеты ".

Стандарт де-факто для сжигания монеты в биткойне - это сценарий OP-RETURN. Этот скрипт имеет важное преимущество в том, что он способствует масштабируемости сети bitcoin, поскольку он позволяет всем узлам обрезать свой UTXO, когда обнаружено доказательство транзакций ожога. Механизм, используемый для достижения этого, прост: несмотря на то, что UTXO поддерживается для всех неизрасходованных регулярных транзакций, когда транзакция OP-RETURN принимается полным узлом, полный узел может полностью исключить эту транзакцию для UTXO, поскольку OP- Сценарий RETURN является доказательством того, что сумма остается неизменной и, следовательно, никакая будущая транзакция не может присоединить этот висячий вывод к его вводу; это, следовательно, постоянный висячий выходной край.

Сценарии OP-RETURN работают, если первым оператором скрипта биткойна является OP-RETURN, что указывает на немедленное исключение при выполнении скрипта, что делает невозможным проведение расходов. После первоначального оператора OP-RETURN остальные данные скрипта могут содержать информацию о том, почему монета была сожжена, так что разные приложения могут требовать различного сжигания, и поэтому возможна связь с учетной записью. Например, в случае OpenBazaar важно связать сгоревшую сумму с GUID OpenBazaar, который может быть включен как неисполняемый код после OP-RETURN. Тот факт, что этот код невыполним, следует из того, что он никогда не будет выполнен из-за более раннего исключения. Однако подход OP-RETURN не обладает определенными свойствами удобства использования, которые мы хотели бы сохранить в нашей реализации OpenBazaar. В частности, для простоты внедрения и использования, а также для разделения причин беспокойства мы решили, что OpenBazaar не нужно включать реализацию биткойн-кошелька. Вместо этого пользователь может использовать любой существующий кошелек, который они хотят. Следовательно, для совершения платежей, требуемых OpenBazaar, либо для покупок товаров, либо для транзакций ожога, пользователь должен будет использовать свой кошелек напрямую.

Сегодня кошельки не имеют возможности создавать сценарии OP-RETURN любым удобным для использования способом. Единственный способ создания транзакций ожога - это ручной выпуск пользовательских скриптовых команд, которые могут быть запутанными или невозможными для обычного пользователя без фона программирования. Кроме того, сценарий OP-RETURN должен быть связан с GUID OpenBazaar, что затрудняет включение этой способности в существующие кошельки. Хотя программное обеспечение кошелька может предложить API для этого, мы пока не знаем о таких реализациях.

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

Наша схема для записи основана на следующем криптографическом предположении: устойчивость к почти столкновению: вычислительно невозможно вычислить два значения хеширования x1, x2, такие как:

||H(x1)- H(x1)|| < ε

Если норма обозначает расстояние Хэмминга двух строк, а Îμ - малая константа, в нашем случае 1. Это предположение сильно поддерживается тем фактом, что хеш-функция криптографически защищена; если бы это уравнение не выполнялось, было бы найдено столкновение по модулю одного бита, что указывает на то, что хэш разбит почти на все его биты.

В этом предположении для H = RIPEMD160 наша схема просит, чтобы горелка приняла открытый ключ ECDSA, связанный с их идентификатором OpenBazaar, и превратил его в биткойн-адрес, следуя обычной схеме для 1-префиксных биткойн-адресов. Регулярные адреса биткойнов генерируются с помощью обычных ключей биткойнов ECDSA, как показано в стандартном алгоритме генерации адреса биткойна .

Чтобы сгенерировать адрес, который является непредвиденным, горелка начинается с открытого открытого ключа ECDSA OpenBazaar и применяет тот же процесс. Тем не менее, горелка возмущает первый SHA256 хэш на один бит, прежде чем подавать его на хэш RIPEMD160. В частности, они перевернули последний бит хеш-выхода. Остальная часть процесса следует тождественно. В заключение,горелка передает количество монеты, которую они хотят записать, на этот сгенерированный адрес. Теперь я проиллюстрирую свойства корректности, уникальности и безопасности для этой схемы.

Корректность . Чтобы проверить правильность ожога, третье лицо выполняет те же преобразования, что и горелка. Они начинаются с открытого ключа ECDSA узла OpenBazaar, чье доверие они хотят проверить и следовать процессу генерации адреса биткойна, применяя такое же возмущение, как и горелка после этапа SHA256. Приобретая конечный биткойн-адрес, верификатор затем проверяет блок-цепочку за деньги, которые были отправлены на этот адрес. Это завершает, что сжигание честной работы горелки будет правильно проверено честным верификатором. (Это существенное преимущество по сравнению с альтернативными схемами, которые не содержат почему-сгоревшую информацию, такую ​​как адреса без ввода-вывода.)

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

Безопасность . Чтобы эта схема была безопасной, мы должны доказать, что сгоревшие деньги фактически не могут быть потрачены кем-либо. В самом деле, если бы деньги были потрачены, то сберегатель должен был знать частный ключ, связанный с открытым ключом, который хэширует к возмущенному значению SHA256. Однако это позволило бы генерировать почти столкновение в RIPEMD160, поскольку открытый ключ, который можно использовать для расходования сгоревших денег и открытого ключа идентификатора OpenBazaar, будет представлять собой предварительные изображения хэшей, которые отличаются только на один бит. Из предположения о сопротивлении почти столкновению мы заключаем, что это вычислительно невозможно.

Метод столкновения с монетами с почти столкновением вводит проблемы масштабируемости для программного обеспечения биткойнов. Мы не были обеспокоены такими проблемами в OpenBazaar по двум причинам. Во-первых, мы почувствовали неудачу в биткойне в масштабе, учитывая, что массовое использование мотивированного сообщества нашим примитивным представляет собой проблему безопасности для самого биткойна, которая должна быть решена, не требуя от игроков вести себя справедливо для системы. Это проблема для биткойна, а не для OpenBazaar. Если биткойн восприимчив к атакам типа «отказ в обслуживании» с помощью таких средств, использование биткойна в качестве платежной системы должно быть пересмотрено.

Во-вторых, самое главное, потому что мы поддерживаем экосистему биткойнов и хотим предложить предложения по решению его проблем с масштабируемостью, их фактически можно устранить, если транзакции с подтверждением ожога сопровождаются предварительным изображением перед возмущением. Сопровождающее изображение является доказательством того, что деньги не поддаются проверке, подобно тому, как сценарии OP-RETURN являются доказательством несвободы. Поскольку эти предварительные изображения будут общедоступными в сети OpenBazaar, в случае, если OpenBazaar будет в значительной степени принят, полные узлы биткойнов могут использовать сеть OpenBazaar для обнаружения сокращаемых выходов UTXO, которые выполняют проверку на наличие ошибок при почти столкновении с платой за вызов -hash-скрипты. Несмотря на это, оптимизация платежной сети не вызывает беспокойства у ее финансово мотивированных пользователей, и ее технические детали реализации остаются открытой проблемой исследования.

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

ответил dionyziz 21 62015vEurope/Moscow11bEurope/MoscowSat, 21 Nov 2015 05:17:15 +0300 2015, 05:17:15
0

Альтернативой генерации адреса является использование действительного адреса, который, как известно, почти невозможно извлечь монеты из https: //blockchain.info/address/1BitcoinEaterAddressDontSendf59kuE .

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

ответил mca 26 Mayam14 2014, 08:42:59
0

Вы можете создать адрес vanitygen или vanitygen-plus и игнорировать закрытый https://en.bitcoin.it/wiki/Vanitygen

например.

$ ./vanitygen 1Love
Difficulty: 4476342
[48165 K/s][total 2080000][Prob 37.2%][50% in 21.2s]                           
Pattern: 1Love
Address: 1LoveRg5t2NCDLUZh6Q8ixv74M5YGVxXaN
Privkey: 5JLUmjZiirgziDmWmNprPsNx8DYwfecUNk1FQXmDPaoKB36fX1o

Просто используйте Address, не сохраняйте Privkey.

ответил Anomalous Awe 25 Jpm1000000pmSat, 25 Jan 2014 21:06:05 +040014 2014, 21:06:05

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132