Check bitcoin public key

Check bitcoin public key

Generate Bitcoin Private Keys and check them against blockstreams liquid api. I’ve tried blockcypher and blockexplorer.com but run into issues with limits that I’m FAAARRR to lazy to work around with a round robin of profile switches or setup a full archival node of my own to fire against. Feel free to fund my

Stupid Python3 Script that Generates random private keys and checks them in realtime. call this poor mans Mining for BTC — same chances as solo but you could find an address w/ money in it 🤑 This is for entertainment only and is designed to demonstrate how IMPOSSIBLE it is to realistically get a collision and take control of someone else’s coin. Credits to @Shlomi for the inspiration.

BIG OL DISCLAIMER: I cannot emphasize this enough — this is for DEMONSTRATION and ENTERTAINMENT purposes . you will have much better success finding employment, buying bitcoin and holding it than to have this little goofy script find a populated private key with a balance. though if you happen to find a populated address you may as well call the pressess and let em know you beat the odds with that extreme luck.

1. Clone this script — download it or in the terminal use git clone https://github.com/Frankenmint/PKGenerator_Checker/
2. Let’s install some dependencies! pip install ecdsa hashlib base58 requests cfscrape
3. Navigate to the directory: cd PKGenerator_Checker
4. Run it! python PkMaker.py

• What’s Going on?: A random 32 byte Number is generated and encoded into Hex — Basially a number between 1 and 2^256 OR if counting in decimal form: 115792089237316195423570985008687907853269984665640564039457584007913129639936. Then, that key is hashed a few times into a public address according to these standard rules and is fired off to blockexplorer.com using their API. The script then prints the balance to the console window.
• I threw this together while following along this video series and reccomend YOU instead watch through the tutorials for your own benefit and to better grasp what happens at the protocol level for Bitcoin

* I had to use cfscraper to get around the issue of cloudflare on the v2 version of the script which uses bitcoinlist.io this version will scan an entire page at a time of keys..though idk if the underlying site is to be trusted (ie they just tell you the funds are zero and sweep the funds into their own wallet first)

TODO: I believe the richlist is down right now but someone offerred a different page which I’ll look intoat some point.

Источник

Check bitcoin public key

Private Keys Generator Checker

Generate Bitcoin Private Keys and check them against blockchain.com API

This is a fork and update of the original PKGenerator_Checker

Stupid Python Script that Generates random private keys and checks them in realtime against blockchain.com API.

To better understand what are the odds of finding a valid address with balance:

«Even if you were to generate one address for each grain of sand on Earth every second, and do it for as long as old the galaxy is

13.21 billion years, you’d still be nowhere near likely to have found even a single duplicate.»

This fork updates includes:

• Use blockchain.com API to check wallets balance instead of using blockcypher which limits the number of request you can make per hours/minute.
• If the script has ever to find a wallet with any balance will save the address and private key along with the balance in a .txt file.

1. Clone this script — download it or in the terminal use git clone https://github.com/monzanifabio/pkgen-checker.git
2. Let’s install some dependencies!
   pip install ecdsa hashlib base58 requests cfscrape
3. Navigate to the directory: cd pkgen-checker
4. Run it! python pkgen.py

If you don’t want to setup all the dependencies manually you can always run pip install -r requirements.txt

If launching the script returns an error regarding some missing dependencies you might want to use pip install —upgrade to fix those.

Источник

Bitcoin Address Utility

Enjoyed the article? Share:

Bitcoin Address Utility is an open-source program that allows a user to do various useful functions with Bitcoin addresses, such as convert them between various formats, encrypt and decrypt them, and print them as paper wallets. This program was started by Casascius and is available for downloading on GitHub at https://github.com/casascius/Bitcoin-Address-Utility. It is written in C# and is based on Microsoft’s .NET / Visual Studio toolchain.

Bitcoin Address Utility runs natively for Windows, and also runs on Linux and Mac OS X using Mono.

The binary can be downloaded from my website at https://casascius.com/btcaddress-alpha.zip (this file also includes the source code from which it was built).

• A calculator that lets you convert between private and public keys, hex and base58, bitcoin and altcoin addresses, etc.
• Bulk Bitcoin address generator;
• Paper wallet printer;
• Decrypter for encrypted private keys;
• Self-escrow utility;
• Intermediate code generator (used for creating encrypted paper wallets);
• Physical bitcoin insert printer (the small round private key paper found in Casascius Coins).

Contents

Address utility screen [ edit ]

The Address Utility screen offers the following functions:

• Create new Bitcoin addresses with corresponding minikey and standard private key formats
• Copy Bitcoin addresses and private keys to the clipboard as QR code images
• Convert minikeys to WIF/hexadecimal private key formats
• Create private keys from text strings via SHA-256 hash («brainwallet»)
• Convert between hexadecimal and WIF private key formats
• Decrypt/encrypt private keys per BIP 0038
• Calculate public key from private key
• Calculate compressed/uncompressed equivalents for public keys
• Confirm that public keys are valid (i.e. that they represent a valid EC curve point)
• Calculate Hash160 from public key
• Calculate Bitcoin address
• Convert between equivalent addresses for Testnet/other altcoins.
• View balance on block explorers

Base58Check Calculator screen [ edit ]

The Base58Check calculator screen allows quick conversions between the Base58Check encoding commonly used in Bitcoin-related objects and the encoded hexadecimal equivalent. This screen is especially useful for discovering what hexadecimal prefix is required to create Base58Check strings with a specific prefix, or for seeing what is encoded in non-standard Base58 strings generated by service providers.

The 32-bit checksum is verified on all Base58 entries, and «invalid» is displayed in the hex box if the checksum is incorrect. However, verification of the checksum can be skipped simply by appending a question mark to the end of the Base58 string. Once the hexadecimal equivalent is known, simply making an insignificant change to the hex box (such as adding a space to the end) will result in the correct checksum being recomputed and displayed.

If «invalid» is still shown after adding a question mark to the Base58 string, it probably contains invalid characters such as 0, O, I, or l.

Key Combiner screen [ edit ]

The Key Combiner screen allows elliptic-curve arithmetic on Bitcoin public and private keys. Specifically, multiplication can be used for creating two-factor Bitcoin addresses, and addition can be used for secure vanity address generation.

The two boxes accept either a public or private key in any recognized format (hexadecimal, WIF, minikey, etc.).

Multiplying or adding two private keys yields a new private key, as well as its corresponding public key and Bitcoin address.

Multiplying or adding a private key and public key yields a combined public key and Bitcoin address, but no private key. When the public key input is replaced by the matching private key, then calculating the resulting private key becomes possible.

Источник

How do I get an ECDSA public key from just a Bitcoin signature? … SEC1 4.1.6 key recovery for curves over (mod p)-fields

Update: Partial solution available on Git

Please note that the message to be verified must have Bitcoin Signed Message:\n as a prefix. Source1 Source2

There is something wrong in the C# implementation that I can probably correct from this Python implementation

It seems to have a problem with actually coming up with the correct Base 58 address.

I have the following message, signature, and Base58 address below. I intend to extract the key from the signature, hash that key, and compare the Base58 hashes.

My problem is: How do I extract the key from the signature? (Edit I found the c++ code at the bottom of this post, need it in Bouncy Castle / or C#)

Base58 Bitcoin address «hash»

Since the Base58 Bitcoin address is just a hash, I can’t use it for validation of a Bitcoin message. However, it is possible to extract the public key from a signature.

Edit: I’m emphasizing that I’m deriving the Public key from the signature itself, and not from the Base58 public key hash. If I want to (and I actually do want to) I should be able to convert these public key bits into the Base58 hash. I don’t need assistance in doing this, I just need help in extracting the public key bits and verifying the signature.

Question

In the Signature above, what format is this signature in? PKCS10? (Answer: no, it’s proprietary as described here)

how do I extract the public key in Bouncy Castle?

What is the correct way to verify the signature? (assume that I already know how to convert the Public Key bits into a hash that equals the Bitcoin hash above)

Prior research

This link describes how to use ECDSA curves, and the following code will allow me to convert a public key into a BC object, but I’m unsure on how to get the point Q from the signature.

In the sample below Q is the hard coded value

Additional research:

THIS is the Bitcoin source that verifies a message.

After decoding the Base64 of the signature, the RecoverCompact(hash of message, signature) is called. I’m not a C++ programmer so I’m assuming I need to figure out how key.Recover works. That or key.GetPubKey

This is the C++ code that I think I need in C#, ideally in bouncy castle. but I’ll take anything that works.

Custom signature format in Bitcoin

This answer says there are 4 possible public keys that can produce a signature, and this is encoded in the newer signatures.

2 Answers 2

After referencing BitcoinJ, it appears some of these code samples are missing proper preparation of the message, double-SHA256 hashing, and possible compressed encoding of the recovered public point that is input to the address calculation.

The following code should only need BouncyCastle (probably you’ll need recent version from github, not sure). It borrows a few things from BitcoinJ, and does just does enough to get small examples working, see inline comments for message size restrictions.

It only calculates up to the RIPEMD-160 hash, and I used http://gobittest.appspot.com/Address to check the final address that results (unfortunately that website doesn’t seem to support entering a compressed encoding for the public key).

Sample output for the initial data in the question:

If we plug the RIPEMD-160 value into the address checker, it returns

as given in the question.

I’m afraid there are some problems with your sample data. First of all your sample Q is 61 bytes long, but Bitcoin public keys (using secp256k1 curve) should be 65 bytes in their uncompressed form. The Q you supplied does not verify the message correctly, but the Q I have calculated does seem to verify it.

I wrote code that calculates the correct public key for string «StackOverflow test 123» and verifies it using ECDsaSigner. However, the hash for this public key is 1HRDe7G7tn925iNxQaeD7R2ZkZiKowN8NW instead of 1Kb76YK9a4mhrif766m321AMocNvzeQxqV .

Can you please verify that your data is correct and maybe give the exact hash of the message string so that we could try to debug, an incorrect hash can mess things up quite bad. The code I have used is following:

EDIT I see this is still not commented on or accepted, so I wrote a full test that generates a private key and a public key, then generates a valid signature using the private key. After that it recovers the public key from the signature and hash and uses that public key to verify the signature of the message. Please see below, if there are still some questions please let me know.

Источник

Blockchain на Go. Часть 5: Адреса

Вступление

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

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

Биткоин-адрес

Вот пример Bitcoin-адреса: 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa. Это самый первый Bitcoin-адрес, который якобы принадлежит Сатоши Накамото. Bitcoin-адреса находятся в открытом доступе. Если вы захотите отправить кому-то монеты, вам нужно знать адрес получателя. Но адреса (несмотря на уникальность) не являются идентификатором вас, как владельца «кошелька». Фактически, такие адреса являются открытым ключом. В Bitcoin ваша личность — это пара (или пары) закрытых и открытых ключей, хранящихся на вашем компьютере (или в каком-либо другом месте, к которому у вас есть доступ). Для создания таких ключей используются криптографические алгоритмы, которые гарантируют, что никто другой не сможет получить доступ к вашим монетам без физического доступа к вашим ключам. Давайте рассмотрим, что же это за алгоритмы.

Криптосистема с открытым ключом

Алгоритмы криптосистем с открытым ключом используют пары ключей: открытые и закрытые. Открытые ключи можно сообщить кому угодно. Закрытые ключи, напротив, не должны раскрываться никому: никто, кроме владельца, не должен иметь к ним доступа, поскольку это личные ключи, которые служат идентификатором владельца. Ваше лицо — это ваши закрытые ключи (в мире криптовалюты, конечно).

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

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

Если вы когда-нибудь использовали Bitcoin кошелек в виде приложения, вероятно, для вас была создана мнемоническая фраза. Такие фразы используются вместо закрытых ключей и могут быть использованы для их генерации. Этот механизм реализован в BIP-039.

Итак, теперь мы знаем, что идентифицирует пользователей в Bitcoin. Но как Bitcoin проверяет владельца выхода транзакции (и монеты, которые там хранятся)?

Электронная цифровая подпись

В математике и криптографии существует концепция электронной цифровой подписи — алгоритмы, которые гарантируют:

1. что данные не были изменены при передаче от отправителя к получателю;
2. что данные были созданы определенным отправителем;
3. что отправитель не может отрицать то, что именно он отправил эти данные.

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

Чтобы подписать данные, нам понадобится следующее:

1. данные для подписи;
2. закрытый ключ.

Алгоритм создает подпись, которая хранится во входах транзакции. Чтобы проверить подпись, необходимо следующее:

1. данные, которые были подписаны;
2. подпись;
3. открытый ключ.

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

Цифровые подписи не шифруются, а данные получить из нее невозможно. Это похоже на хеширование: вы преобразуете данные при помощи алгоритма и получаете их уникальное представление. Разница между хешем и подписью — это пары ключей, которые позволяют произвести проверку последней.
Но такие пары ключей также можно использовать и для шифрования данных: для шифрования используется закрытый ключ, а для расшифровки — открытый. Однако же Bitcoin не использует алгоритмы шифрования.

Каждый вход транзакции в Bitcoin подписывается тем, кто создал эту транзакцию. Каждая транзакция в Bitcoin должна быть проверена перед тем, как поместить ее в блок. Верификация означает (помимо других процедур):

1. Проверку того, что входы имеют достаточные права на использование выходов из предыдущих транзакций.
2. Проверку правильности подписи транзакции.

Схематически, процесс подписи и проверки данных выглядит так:

Давайте рассмотрим полный жизненный цикл транзакции:

1. В самом начале содержится блок генезиса с coinbase транзакцией. В транзакциях coinbase нет реальных входов, поэтому подпись не требуется. Вывод транзакции содержит хешированный открытый ключ (используются алгоритмы RIPEMD16(SHA256(PubKey)) ).
2. Когда кто-то отправляет монеты, создается транзакция. Входы транзакции будут ссылаться на выходы из предыдущих транзакций. Каждый вход будет хранить открытый ключ (не хешированный) и подпись всей транзакции.
3. Другие узлы в сети Bitcoin, которые получат транзакцию, тоже проверят ее. Помимо прочего, здесь происходит сопоставление хеша открытого ключа на входе транзакции с хешом соответствующего выхода, (это гарантирует, что отправитель тратит только принадлежащие ему монеты); подпись правильная (это гарантирует, что транзакция создана реальным владельцем монет).
4. Когда узел готов к майнингу нового блока, он поместит транзакцию в блок и начнет добывать ее.
5. Когда блок добыт, каждый другой узел в сети получает сообщение о том, что блок добыли и добавляет его в цепь.
6. После того, как блок добавлен в цепь, транзакция завершена, теперь на ее выходы можно ссылаться в новых транзакциях.

Эллиптическая криптография

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

Bitcoin использует эллиптические кривые для генерации секретных ключей. Эллиптические кривые — это сложная математическая концепция, которую мы не будем здесь подробно объяснять (если интересно, можете почитать об этом здесь ПРЕДУПРЕЖДЕНИЕ: очень много математики!). Кривая, используемая Bitcoin, может случайным образом выбирать число между 0 и 2²⁵⁶ (что составляет приблизительно 10⁷⁷, на заметку, атомов в видимой вселенной где-то между 10⁷⁸ и 10⁸²). Такой предел означает, что почти невозможно сгенерировать один и тот же закрытый ключ дважды.

Кроме того, Bitcoin использует (и мы будем) алгоритм ECDSA для подписи транзакций.

Base58

Теперь давайте вернемся к вышеупомянутому адресу 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa. Теперь мы знаем, что это общепринятое для человека представление открытого ключа. И если мы его декодируем, он будет выглядеть примерно так (как последовательность байтов, записанных в шестнадцатеричной системе):

Bitcoin использует алгоритм Base58 для преобразования открытых ключей в читаемый человеком формат. Алгоритм очень похож на известный Base64, но он использует более короткий алфавит: некоторые буквы были удалены из алфавита, чтобы избежать гомографические атаки. В связи с этим, в этом алфавите отсутствуют следующие символы: 0 (ноль), О (заглавная буква «о»), I (заглавная «i»), l (строчная «L») а также знаки «+» и «/».

Примерно так выглядит процесс получения адреса из открытого ключа:

Следуя этой схеме, ключ, который мы привели выше, разделен на три части:

Хорошо, теперь, когда мы собрали все воедино, пришло время писать код! Я надеюсь, что сейчас все, что было непонятным прояснится.

Реализация адресов

Начнем со структуры кошелька Wallet

Кошелек — не что иное, как пара ключей. Нам также понадобится тип Wallets , чтобы хранить коллекцию кошельков, сохранять их в файл и выгружать их из него. В конструкторе Wallet создается новая пара ключей. Функция newKeyPair проста, здесь мы используем ECDSA. Затем создается закрытый ключ с использованием кривой, и открытый ключ генерируется при помощи закрытого ключа. Одно замечание: в алгоритмах на основе эллиптической кривой открытые ключи являются точками на кривой. Таким образом, открытый ключ представляет собой комбинацию координат X, Y. В Bitcoin эти координаты объединяются и образуют открытый ключ.

Теперь, создадим функцию генерации адреса:

Разберем по шагам преобразование открытого ключа в адрес Base58:

1. Возьмем открытый ключ и запишем его дважды с помощью алгоритмов хеширования RIPEMD160 (SHA256 (PubKey)) .
2. Подготовим версию.
3. Вычислим контрольную сумму путем хеширования результата из шага 2 и SHA256 (SHA256 (payload)) . Контрольная сумма — это первые четыре байта полученного хеша.
4. Добавим контрольную сумму в комбинацию version+PubKeyHash .
5. Зашифруем комбинацию version+PubKeyHash+checksum при помощи Base58.

В результате вы получите настоящий адрес Bitcoin, вы можете даже проверить его баланс на blockchain.info. Но я больше чем уверен, что на счету этого адреса ничего не будет. Вот почему выбор правильного алгоритма шифрования с открытым ключом настолько важен: учитывая, что закрытые ключи являются случайными числами, вероятность генерации одного и того же числа должна быть как можно меньше. В идеале он не должен повторятся вообще.

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

Теперь нам нужно изменить входы и выходы для использования адресов:

Обратите внимание, что мы больше не используем поля ScriptPubKey и ScriptSig , вместо этого ScriptSig разделяется на поля Signature и PubKey , а ScriptPubKey переименован в PubKeyHash . Мы будем реализовывать те же функции блокировки/разблокировки выходов и логику подписей входов, как в Bitcoin, но реализуем мы это при помощи методов.

Метод UsesKey проверяет, что вход использует определенный ключ для разблокировки выхода. Обратите внимание, что входы хранят нехешированные открытые ключи, а функция принимает хешированный. IsLockedWithKey проверяет, был ли использован хеш-ключ открытого ключа для блокировки выхода. Это дополнительная функция для UsesKey , и они обе используются в FindUnspentTransactions для построения соединений между транзакциями.

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

Теперь давайте проверим, что все работает правильно:

Отлично! Пришла пора реализовать подписи транзакций.

Реализация подписей

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

У нас есть все для реализации подписей к транзакциям, кроме одного: данных для подписи. Какую часть транзакции мы должны подписывать? Или же необходимо подписывать сделку в целом? Выбор данных для подписи очень важен. Дело в том, что данные, которые должны быть подписаны, должны содержать информацию, которая идентифицирует данные уникальным образом. Например, нет смысла подписывать только выходные значения, потому что такая подпись не будет учитывать отправителя и получателя.

Учитывая, что транзакции разблокируют предыдущие выходы, перераспределяют их значения и блокируют новые выходы, должны быть подписаны следующие данные:

1. Хеши открытых ключей хранящиеся в разблокированных выходах. Это идентифицирует «отправителя» транзакции.
2. Хеши открытых ключей хранящиеся в новых, заблокированных, выходах. Это идентифицирует «получателя» транзакции.
3. Значения новых выходов.

В Bitcoin логика блокировки/разблокировки хранится в скриптах, которые хранятся в ScriptSig и ScriptPubKey полей входов и выходов соответственно. Поскольку Bitcoin допускает разные типы таких скриптов, он подписывает все содержимое ScriptPubKey .

В связи с этим в Bitcoin происходит подпись не транзакции, а ее обработанной копии со входами, содержащими ScriptPubKey указанного выхода

Здесь описан подробный процесс обработки копии транзакции. Скорее всего, он устарел, но мне не удалось найти более надежный источник информации.

Все это выглядит достаточно сложным, давайте начнем писать код. А начнем мы с метода Sign :

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

Давайте внимательнее рассмотрим этот метод:

Coinbase транзакции не подписаны, так как в них нет реальных выходов

Мы подписываем обработанную копию, а не всю транзакцию:

Копия будет включать все входы и выходы, а TXInput.Signature и TXInput.PubKey будут равны nil.

Затем пройдемся по каждому входу в копии:

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

Метод Hash сериализует транзакцию и хеширует ее с помощью алгоритма SHA-256. Результатом являются данные готовые для подписи. После получения хеша мы должны сбросить поле PubKey , чтобы не было влияния на наши дальнейшие итерации.

Мы подписываем txCopy.ID при помощи privKey . Подпись ECDSA представляет собой пару чисел, которые мы объединяем и сохраняем в поле входа Signature .

Рассмотрим функцию верификации:

Метод довольно простой. Для начала получим копию транзакции, как в прошлом методе:

Затем нам понадобится кривая, которая используется для генерации пар ключей:

Затем пройдемся по всем входам и проверим, что они подписаны:

Эта часть идентична той, что используется в методе Sign, так как во время проверки нам нужны те же самые данные, что мы и подписывали

Здесь мы распаковываем значения, хранящиеся в TXInput.Signature и TXInput.PubKey , так как сигнатура представляет собой пару чисел, а открытый ключ — это пара координат. Мы конкатенировали их раньше для хранения, и теперь нам нужно их распаковать для использования в функциях crypto/ecdsa .

Теперь мы создаем ecdsa.PublicKey , используя открытый ключ, который мы берем из входа, и выполняем ecdsa.Verify , передавая подпись, из входа. Если все входы проверены, мы возвращаем true; если хотя бы один вход не прошел проверку, возвращаем false.

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

FindTransaction находит транзакцию по идентификатору (для этого требуется итерация по всем блокам в цепи); SignTransaction берет одну транзакцию, находит транзакции, на которые она ссылается, и подписывает ее; VerifyTransaction просто проверяет транзакцию.

Теперь нам нужно подписать и проверить транзакции. Подписывать мы будем в методе NewUTXOTransaction :

Проверка транзакции происходит до того, как она будет добавлена в блок:

Вот и все! Давайте проверим все еще раз:

У нас даже ничего не сломалось, удивительно!

Давайте закомментируем вызов bc.SignTransaction (& tx, wallet.PrivateKey) в NewUTXOTransaction , для гарантии того, что неподписанные транзакции нельзя будет майнить:

Заключение

Мы реализовали почти все ключевые особенности Bitcoin и это потрясающе. А в следующей части мы наконец-таки завершим реализацию транзакций.

Источник