Внедряем оплату BTC куда угодно (Python)
Предыстория
Полгода назад взялся за один проект с возможностью оплаты биткойном. Так как проект делали на языке python, то и оплату хотелось реализовать на нем же. Сразу же взялся анализировать готовые решения, доступные библиотеки и Rest API Blockchain.com. С апи блокчейна я моментально обломался, так как их токен для использования апи довольно не просто получить.
Затем решил юзать различные библиотеки (block-io, bitcoinlib, blockchain и др.) После пару ночей попыток реализовать нормальную оплату, остановился на bitcoinlib, так как она более менее стабильно работала, и я спокойно переводил с одного кошелька на другой. Беда наступила когда появились первые 100 пользователей и вся оплата внезапно рухнула. Возможно я криво написал или что-то не так понял с работой библиотеки, но любые попытки восстановить работу оплаты были безуспешны, только если обнулять бдшку, но и так неизвестно сколько бы она продержалась.
В итоге решили оставить без BTC оплаты. Я опечалился и не связывался с оплатой биткойном полгода.
К чему я пришел
На днях я все-таки решил добить этот вопрос для себя, надеюсь кому-то еще пригодятся мои наработки.
Пример seed фразы:
vivid area able second bicycle advance demand alpha flip stable drift route
Чтобы сгенерировать фразу будем использовать библиотеку bipwallet. Чтобы ее установить воспользуемся командой pip install bipwallet.
Если мы хотим получить напрямую доступ к биткойн кошельку, то, зная фразу, можем сразу восставновить кошелек в blockhain.com:
Следующим шагом мы будем преобразовывать нашу seed фразу до получения нужного адреса кошелька биткойна.
Чтобы во всем не запутаться и знать какие данные мы должны получить, я использовал сайт https://iancoleman.io/bip39/
Генерация дочернего адреса кошелька для каждого пользователя:
Чтобы получить наш нулевой адрес Биткойн кошелька на основе seed фразы (12VeK1eRgPHRUikNLXq3Nuz99gS2S46QMD), нам нужно пройти всю цепочку преобразований. Методом проб и ошибок мне все-таки удалось получить адрес кошелька следующим кодом:
Данная функция возвращает адрес кошелька и wif в зависимости номера. Максимальное число с которым удалось получить адрес это 999999999.
Это все значит, что имея только одну seed фразу мы можем создать 1 млрд дочерних адресов. Каждому пользователю при регистрации мы будем выдавать новый адрес, через который он сможет оплачивать по BTC. Появляется ограничение на 1 млрд пользователей, но нам никто не запрещает использовать несколько seed фраз или генерировать каждому юзеру новую фразу, но тогда каждая оплата будет кидаться не в общий ваш кошелек, а по разным.
Проверка баланса и транзакции:
Теперь когда у каждого пользователя свой личный адрес биткойн кошелька, нужно проверить баланс этого адреса. Для этого мы будем обращаться к сайту Blockchain.com дабы получить нужную информацию.
Вот таким простым кодом мы можем получить всю информацию по балансу и транзакциях пользователя. Дальше все зависит от логики самого приложения.
Транзакции
На данном этапе мы дали каждому пользователю свой адрес кошелька и знаем все транзакции с данным адресом, но этого недостаточно. Нам нужно чтобы мы могли отправить его же деньги обратно. Для этого воспользуемся библотекой bit. Чтобы ее установить воспользуемся командой pip install bit.
В итоге мы получили вот такую транзакцию:
Выглядит красиво, но что с этим делать?
Можно зайти на сайт https://www.blockchain.com/btc/pushtx
и вручную отправить эту транзакцию.
Также можем декодировать эту транзакцию и проверить все ли верно мы указали https://www.blockchain.com/btc/decode-tx
Но нам нужно это автоматизировать, поэтому напишем несколько строк:
Выполним пост запрос, если получаем ответ: Transaction Submitted. Это значит, что через несколько секунд транзакция появится в сети и деньги спишутся с пользователя.
Применение
Ну чтож, написав всего несколько десятков строк, мы можем генерировать для каждого пользователя свой адрес кошелка, проверять его баланс, переводить биткойны с одного кошелька на любой другой.
Для демонстрации работы BTC оплаты, я напишу простенького телеграм бота, который будет выполнять роль клиента Blockchain.com, то есть вы сможете хранить в нем свои биткойны и от туда же переводить другим людям. Ссылка на исходники бота будут в конце.
Задеплоил на heroku, так что надеюсь не будет падать)
Функционал бота
Регистрация пользователя
В качестве БД я использовал sqlite3 и создал одну таблицу пользователей:
При нажатии start мы регистрируем пользователя, генерируем для него адрес биткойн кошелька, wif и добавляем данные в БД:
Проверка баланса
Получить BTC
Для создания qr-кода я использовал библиотеку qrcode и на вход передал ранее сгенерированный адрес биткойн кошелька из БД.
Отправить BTC
Проверим через сайт, что транзакция отправилась:
Исходники и как запустить
Скачать исходники бота можно тут github.com/Lil-hack/blockchain-client
Склонировав репозиторий, устанавливаем необходимые пакеты:
Некоторые библиотеки у меня не заработали на windows, так что лучше сразу запускать на linux.
В файле main.py заменяем ваш токен телеграм бота:
В файле btc_core.py заменяем на вашу seed фразу:
И запускаем бота командой: python main.py
Работает на python 3.7.0 и выше. Бот написан за один вечер, так что просьба строго не судить ^^
Итого
Как оказалось, все довольно не сложно, и в несколько десятков строк можно добавить оплату BTC в любой python проект. Я не профи в криптографии, так что скорее всего многие моменты упустил, но надеюсь кому-то эта статья будет полезна.
Русские Блоги
Понимание BIP32, BIP44, BIP39, участвующих в разработке HD-кошельков
Концепция цифрового кошелька
Кошелек используется для хранения денег. В блокчейне наши цифровые активы будут соответствовать адресу учетной записи. Только ключ (закрытый ключ) учетной записи может использовать актив (подписать транзакцию потребителя с помощью закрытого ключа).
Связь между закрытым ключом и адресом следующая:
(Фото из мастерства биткойнов)
В одном предложении оно сводится к следующему:Закрытый ключ генерирует открытый ключ по эллиптической кривой, а открытый ключ генерирует адрес с помощью хэш-функции. Оба процесса являются однонаправленными.
Поэтому на самом деле цифровой кошелек фактически является инструментом для управления закрытыми ключами (генерация, хранение, подпись). Обратите внимание, что кошелек не сохраняет активы, а активы находятся в цепочке.
Как создать аккаунт
Например, вы можете бросить монету 256 раз, использовать бумагу и ручку для записи лицевой и оборотной сторон и преобразовать ее в 0 и 1. Случайно полученное 256-битное двоичное число можно использовать как закрытый ключ кошелька.
С точки зрения программирования, это обычно происходит путем взятия длинной строки случайных байтов из криптографически безопасного случайного источника (не рекомендуется писать случайное число самостоятельно) и использования алгоритма хеширования SHA256 для работы с ним. Может легко произвести 256-битное число.
Фактический процесс должен сравнить, меньше ли он n-1 (n = 1,158 * 10 ^ 77, чуть меньше 2 ^ 256), у нас есть подходящий закрытый ключ. В противном случае мы повторяем это с другим случайным числом. Полученный таким образом закрытый ключ может дополнительно генерировать открытый ключ и адрес в соответствии с вышеуказанным способом.
BIP32
Кошелек также является контейнером закрытых ключей.В соответствии с описанным выше методом мы можем сгенерировать набор закрытых ключей (у человека также есть много требований к учетной записи, которые могут лучше защитить конфиденциальность), и каждый закрытый ключ необходимо создать резервную копию.
Так обстоит дело с самыми ранними биткойн-кошельками с прозвищем «Просто куча ключей (куча закрытых ключей)».
Чтобы решить эту проблему, естьBIP32 предложение: Согласно случайному начальному числу, получите n закрытых ключей посредством иерархической детерминированной деривации. Таким образом, при сохранении необходимо сохранить только одно начальное число и получить частный ключ, как показано на рисунке:
(Картинка от Master Bitcoin) Клавиша Sun на картинке выше может использоваться для совершения транзакций.
Давайте проанализируем процесс иерархической деривации. Первым шагом является получение мастер-ключа: 
Корневое начальное число вводится в алгоритм HMAC-SHA512 для получения секретного ключа (по секретному ключу или открытому ключу) и основной цепочки, которую можно использовать для создания мастер-секретного ключа (m) и кода мастер-цепочки (кода мастер-цепочки) на этом этапе. Код плюс порядковый номер будут использоваться в качестве входных данных алгоритма HMAC-SHA512 для продолжения получения секретного ключа и кода цепочки следующего уровня, как показано ниже:
Следовательно, добавление индекса (горизонтальное расширение) и переход на следующий уровень (глубокое расширение) через подраздел может привести к созданию закрытого ключа в течение неопределенного времени.
Обратите внимание, что этот процесс деривации определен (один и тот же вход, всегда один и тот же выход) также является однонаправленным, дочерний ключ не может получить родственный ключ того же уровня и не может вывести родительский ключ. Если код дочерней цепочки отсутствует, ключ внука не может быть получен. Теперь у нас есть понимание иерархического происхождения.
Ключевой путь и BIP44
BIP44 согласовал стандартное значение для этого пути (и расширенную поддержку нескольких валют). BIP0044 определяет структуру, содержащую 5 предопределенных уровней дерева:
m / purpose’ / coin’ / account’ / change / address_index
m фиксировано, цель также фиксирована, значение равно 44 (или 0x8000002C)
Coin type
Это представляет валюту, 0 представляет Биткойн, 1 представляет цепочку тестирования Биткойн, и 60 представляет Эфириум
Полный адрес списка валют:https://github.com/satoshilabs/slips/blob/master/slip-0044.md
Account
представляет индекс счета этой монеты, начиная с 0
Change
Константа 0 используется для внешних цепочек, а константа 1 используется для внутренних цепочек (также называемых меняющимися адресами). Внешние ссылки используются для адресов, видимых за пределами кошелька (например, для приема платежей). Внутренняя цепочка используется для адресов, которые не видны за пределами кошелька и используются для возврата изменений транзакции. (Так обычно используйте 0)
address_index
Это индекс адресов. Начиная с 0 он представляет количество сгенерированных адресов. Официально рекомендуется, чтобы address_index для каждой учетной записи не превышал 20
По словамОбсуждение предложения EIP85Кошелек Ethereum также следует стандарту BIP44, и путь определения m/44’/60’/a’/0/n
a представляет номер счета, n является адресом, сгенерированным nth, 60 находится вПредложение SLIP44Кодировка Ethereum идентифицирована в. Поэтому, если мы хотим разработать кошелек Ethereum, нам также нужно понять предложения биткойн-кошелька BIP32 и BIP39.
BIP39
Предложение BIP32 позволяет нам сохранять начальное число случайных чисел (обычно представленное шестнадцатеричным числом), а не набор ключей, что на самом деле более удобно, но более неудобно для пользователей (например, холодное резервное копирование), которое появляетсяBIP39, Он использует мнемонический метод для генерации начального числа, так что пользователям нужно запомнить только 12 (или 24) слов, последовательность слов с помощью функций PBKDF2 и HMAC-SHA512 для создания случайного начального числа в качестве начального числа BIP32.
Вы можете просто сделать сравнение, следующее более удобно для резервного копирования:
Использование мнемонических слов в качестве начальных значений на самом деле состоит из двух частей: создание мнемонических слов и создание мнемонических слов случайных начальных чисел. Давайте проанализируем этот процесс.
Генерировать мнемонические слова
Процесс генерации мнемонических слов таков: сначала сгенерируйте 128-битное случайное число, а затем добавьте 4 цифры к проверке случайного числа, чтобы получить 132-битное число, а затем разделите его на 11 бит, чтобы 12 двоичных чисел, затем используйте каждое число для проверкиBIP39 определенный список словИтак, вы получите 12 мнемонических слов, процесс выглядит следующим образом:
(Картинка приходит из сети)
Ниже приведен фрагмент кода, который использует bip39 для генерации мнемонических слов:
Мнемоническое словообразование
Функция растяжения ключа требует двух параметров: мнемоника и соль. Соль может увеличить сложность взлома грубой силой. Соль состоит из константной строки «мнемоника» и необязательного пароля. Обратите внимание, что если вы используете разные пароли, функция растяжения будет генерировать другое начальное число при использовании той же мнемоники. Этот процесс показан ниже:
(Картинка приходит из сети)
Тот же код для выражения:
Адрес контрольной суммыEIP-55Форма адреса, определенная в случае, когда требуется использование заглавных букв.
Пароль может использоваться в качестве дополнительного фактора безопасности для защиты начального числа. Даже если украдена резервная копия мнемоники, безопасность кошелька может быть гарантирована (также требуется, чтобы пароль имел достаточную сложность и длину), но, с другой стороны, если мы забудем пароль, Тогда мы не сможем восстановить наши цифровые активы.
резюме
В настоящее время на рынке кошельки Ethereum и Bitcoin в основном соответствуют этим стандартам.
Bip32 root key что это
«One Seed to rule them all, One Key to find them, One Path to bring them all, And in cryptography bind them.»
It is not possible to maintain one single (mnemonic) seed backup for all keychains used across various wallets because there are a variety of incompatible standards. Sharing of seeds across multiple wallets is not desirable for security reasons. Physical storage of multiple seeds is difficult depending on the security and redundancy required.
As HD keychains are essentially derived from initial entropy, this proposal provides a way to derive entropy from the keychain which can be fed into whatever method a wallet uses to derive the initial mnemonic seed or root key.
The key words «MUST», «MUST NOT», «REQUIRED», «SHALL», «SHALL NOT», «SHOULD», «SHOULD NOT», «RECOMMENDED», «MAY», and «OPTIONAL» in this document are to be interpreted as described in RFC 2119.
The terminology related to keychains used in the wild varies widely, for example `seed` has various different meanings. In this document we define the terms
Most wallets implement BIP32 which defines how a BIP32 root key can be used to derive keychains. As a consequence, a backup of just the BIP32 root key is sufficient to include all keys derived from it. BIP32 does not have a human friendly serialization of the BIP32 root key (or BIP32 extended keys in general) which makes paper backups or manually restoring the key more error-prone. BIP39 was designed to solve this problem but rather than serialize the BIP32 root key, it takes some entropy, encoded to a «seed mnemonic», which is then hashed to derive the BIP39 seed which can be turned into the BIP32 root key. Saving the BIP39 mnemonic is enough to reconstruct the entire BIP32 keychain, but a BIP32 root key cannot be reversed back to the BIP39 mnemonic.
Most wallets implement BIP39, so on initialization or restoration, the user must interact with a BIP39 mnemonic. Most wallets do not support BIP32 extended private keys, so each wallet must either share the same BIP39 mnemonic, or have a separate BIP39 mnemonic entirely. Neither scenarios are particularly satisfactory for security reasons. For example, some wallets may be inherently less secure like hot wallets on smartphones, Join Market servers, or Lightning Network nodes. Having multiple seeds is far from desirable, especially for those who rely on split key or redundancy backups in different geological locations. Adding is necessarily difficult and may result in users being more lazy with subsequent keys, resulting in compromised security or loss of keys.
There is added complication with wallets that implement other standards, or no standards at all. Bitcoin Core wallet uses a WIF as the hdseed, and yet other wallets like Electrum use different mnemonic schemes to derive the BIP32 root key. Other cryptocurrencies like Monero also use an entirely different mnemonic scheme.
Ultimately, all of the mnemonic/seed schemes start with some «initial entropy» to derive a mnemonic/seed, and then process the mnemonic into a BIP32 key, or private key. We can use BIP32 itself to derive the «initial entropy» to then recreate the same mnemonic or seed according to the specific application standard of the target wallet. We can use a BIP44-like categorization to ensure uniform derivation according to the target application type.
We assume a single BIP32 master root key. This specification is not concerned with how this was derived (e.g. directly or via a mnemonic scheme such as BIP39).
The HMAC-SHA512 function is specified in RFC 4231.
BIP85-DRNG-SHAKE256 is a deterministic random number generator for cryptographic functions that require deterministic outputs, but where the input to that function requires more than the 64 bytes provided by BIP85’s HMAC output. BIP85-DRNG-SHAKE256 uses BIP85 to seed a SHAKE256 stream (from the SHA-3 standard). The input must be exactly 64 bytes long (from the BIP85 HMAC output).
RSA key generation is an example of a function that requires orders of magnitude more than 64 bytes of random input. Further, it is not possible to precalculate the amount of random input required until the function has completed.
The Application number defines how entropy will be used post processing. Some basic examples follow:
Derivation path uses the format m/83696968’/
Application number: 39′
Truncate trailing (least significant) bytes of the entropy to the number of bits required to map to the relevant word length: 128 bits for 12 words, 256 bits for 24 words.
The derivation path format is: m/83696968’/39’/
| Wordlist | Code |
|---|---|
| English | 0′ |
| Japanese | 1′ |
| Korean | 2′ |
| Spanish | 3′ |
| Chinese (Simplified) | 4′ |
| Chinese (Traditional) | 5′ |
| French | 6′ |
| Italian | 7′ |
| Czech | 8′ |
| Words | Entropy | Code |
|---|---|---|
| 12 words | 128 bits | 12′ |
| 18 words | 192 bits | 18′ |
| 24 words | 256 bits | 24′ |
BIP39 English 12 word mnemonic seed
128 bits of entropy as input to BIP39 to derive 12 word mnemonic
BIP39 English 18 word mnemonic seed
196 bits of entropy as input to BIP39 to derive 18 word mnemonic
Derives 24 word BIP39 mnemonic seed
256 bits of entropy as input to BIP39 to derive 24 word mnemonic
Application number: 2′
Uses 256 bits[1] of entropy as the secret exponent to derive a private key and encode as a compressed WIF which will be used as the hdseed for Bitcoin Core wallets.
Path format is m/83696968’/2’/
Application number: 32′
Taking 64 bytes of the HMAC digest, the first 32 bytes are the chain code, and second 32 bytes[1] are the private key for BIP32 XPRV value. Child number, depth, and parent fingerprint are forced to zero.
Path format is m/83696968’/32’/
Application number: 128169′
The derivation path format is: m/83696968’/128169’/
Application number: 828365′
The derivation path format is: m/83696968’/828365’/
The RSA key generator should use BIP85-DRNG as the input RNG function.
Keys allocated for RSA-GPG purposes use the following scheme:
Note on timestamps:
The resulting RSA key can be used to create a GPG key where the creation date MUST be fixed to unix Epoch timestamp 1231006505 (the Bitcoin genesis block time ‘2009-01-03 18:05:05’ UTC) because the key fingerprint is affected by the creation date (Epoch timestamp 0 was not chosen because of legacy behavior in GNUPG implementations for older keys). Additionally, when importing sub-keys under a key in GNUPG, the system time must be frozen to the same timestamp before importing (e.g. by use of faketime ).
Note on GPG key capabilities on smartcard/hardware devices:
GPG capable smart-cards SHOULD be be loaded as follows: The encryption slot SHOULD be loaded with the ENCRYPTION capable key; the authentication slot SHOULD be loaded with the AUTHENTICATION capable key. The signature capable slot SHOULD be loaded with the SIGNATURE capable key.
However, depending on available slots on the smart-card, and preferred policy, the CERTIFY capable key MAY be flagged with CERTIFY and SIGNATURE capabilities and loaded into the SIGNATURE capable slot (for example where the smart-card has only three slots and the CERTIFY capability is required on the same card). In this case, the SIGNATURE capable sub-key would be disregarded because the CERTIFY capable key serves a dual purpose.
This specification is not backwards compatible with any other existing specification.
This specification relies on BIP32 but is agnostic to how the BIP32 root key is derived. As such, this standard is able to derive wallets with initialization schemes like BIP39 or Electrum wallet style mnemonics.
The reason for running the derived key through HMAC-SHA512 and truncating the result as necessary is to prevent leakage of the parent tree should the derived key (k) be compromized. While the specification requires the use of hardended key derivation which would prevent this, we cannot enforce hardened derivation, so this method ensures the derived entropy is hardened. Also, from a semantic point of view, since the purpose is to derive entropy and not a private key, we are required to transform the child key. This is done out of an abundance of caution, in order to ward off unwanted side effects should k be used for a dual purpose, including as a nonce hash(k), where undesirable and unforeseen interactions could occur.
Many thanks to Peter Gray and Christopher Allen for their input, and to Peter for suggesting extra application use cases.
[1] There is a very small chance that you’ll make an invalid key that is zero or bigger than the order of the curve. If this occurs, software should hard fail (forcing users to iterate to the next index).
This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.
