text
Editor's note: This article is from Ambi Lab, author: Ambi Lab, and is published with authorization.
Bitcoin addresses have addresses starting with 1 and addresses starting with 3. Is there any difference between the two?
Under what circumstances will the bitcoins on the address be locked up?
Who Exactly Has Control of Bitcoin, You? Or your wallet?
If you're using a Bitcoin wallet and can't answer the three questions above, then this article is for you.
When the SECBIT laboratory audited the source code of the digital wallet, it found that a bitcoin wallet open source library called pywallet contained a serious flaw. If you transfer to the OmniLayer receiving address generated by pywallet, the assets will be permanently lost.
According to zer0to0ne, a blockchain technology expert at the SECBIT laboratory, the OmniLayer protocol allows the issuance of custom assets (such as USDT) on the Bitcoin blockchain. The essence of OmniLayer asset transactions is bitcoin transactions. There are many code bases for bitcoin transactions, and pywallet is one of them. It can conveniently construct Bitcoin transactions conforming to the OmniLayer format. At present, pywallet has been applied in some digital wallet software.
However, when the open source library pywallet generated the OmniLayer wallet address, it mistakenly reversed the prefix of the address, and several assets were locked in the invalid address!
The following is a screenshot of pywallet-related error codes:https://github.com/ranaroussi/pywallet/commit/eb784ea4dd62fe2a50e1352e7d24438fc66a4ac0#diff-ca3a8be6f2ab4be3bfd69a49f5f4122a
File address:
Jump in the queue and popularize science: There are three most common address types on the Bitcoin network: ordinary public key addresses (1-address), script hash addresses (3-address) and isolated witness addresses (bc1-address). prefix to distinguish. Among them, the prefix of 1-address is 0x00, and the prefix of 3-address is 0x05.
• 1-Address: This is the most common Bitcoin address, usually used for ordinary transfers and payments. 1-The address is actually the encoding of the public key Hash. After verifying the signature of the 1-address, the payment can be unlocked.
• 3-Address: This address is the script hash address. This type of address actually corresponds to the code of a Bitcoin script Hash.
• bc1-address: bech32-encoded address, used for segregated witness transactions.
The open source library pywallet reverses the address prefixes, incorrectly setting 1-addresses to 3-addresses. Therefore, the assets originally intended to be transferred to the 1-address will be mistakenly transferred to the 3-address. When the account holder uses the 1-address verification method, that is, the private key signature to withdraw assets, the blockchain network uses 3-address execution scripts to perform verification, resulting in users being unable to withdraw assets normally!
Please use the pywallet open source library with caution! !
Fact: Bitcoin has never really implemented the function of transferring money
This is beyond the expectations of many people, because the implementation of Bitcoin is based on the UTXO model, which is different from the account model we intuitively understand. zer0to0ne explained that, in fact, Bitcoin has never really implemented the transfer function in the usual sense. Satoshi Nakamoto only designed a series of Bitcoin script operators and Bitcoin script executors for Bitcoin, and the so-called transfer process is actually simulated by a Bitcoin script locking and unlocking process. This is different from the ledger concept (or account model) in daily life.
For ease of understanding, we can compare asset transactions on the Bitcoin blockchain to locking assets in a safe, and only the person holding the key to the safe (that is, the payee) can take out the assets in the safe for transactions. For example, if Alice wants to pay Bob an asset, Alice locks the asset in a safe, and only Bob has the key to the safe, that is, only Bob can take out the asset. If Bob wants to take out the asset, Bob must spend the asset at the same time (that is, lock it into another safe). Before Bob takes out the assets, the assets do not really belong to Bob. Imagine that if Bob loses the key, then it will no longer be possible to withdraw the asset. In other words, when the asset is still kept in the safe, it neither belongs to Alice nor fully belongs to Bob. Of course, Alice can also put assets in a safe that anyone can open, which is also called an Anyone-Can-Spend transaction.
Because of the different receiving addresses on the Bitcoin blockchain, there are different types of safes. Different types of safes require different types of keys to open. The payer customizes a safe for the payee, puts the assets in the safe and locks it, and then throws the safe in a public place. There are two ways to open the safe:
• If the payee is a 1-address, we call the safe a 1-type safe. The corresponding key must be the private key corresponding to the designated receiving address. The process of unlocking the safe is to verify the 1-address public key and the digital signature corresponding to the public key. This is also the verification process we usually understand for transferring money to an ordinary account address.
• If the payee is a 3-address, we call it a 3-type safe. The unlock key must be an executable Bitcoin script. The process of unlocking the safe is: the Hash value of the Bitcoin script corresponds to the 3-address, and the Bitcoin script executor returns successfully after running the script. That is to say, only those who have the original script and can execute it successfully can extract the assets in this safe.
Back to the question in this section: Why is it said that Bitcoin has never realized the transfer function in the true sense. The answer is simple, because the concept of accounts does not exist in the Bitcoin system, and transfers between accounts are out of the question. It is also unknown how many safes a person can open in the future.
Through the above explanation, we can see that when the pywallet open source library mistakenly recognizes a 1-address as a 3-address, it is like transforming the original 1-type safe into a 3-type safe, and the account holder still holds 1 - to unlock the key of the safe, then naturally the safe cannot be opened. So can the OmniLayer digital assets that were mistakenly locked by zer0to0ne be recovered?
Is there a possibility to use the 1-address key to open the 3-safe?
zer0to0ne then explained to us the ins and outs of two important concepts, P2PKH (Pay to Public Key Hash) and P2SH (Pay to Script Hash). These two nouns represent two different types of Bitcoin transactions.
The following is a wonderful technical detail analysis of zer0to0ne
P2PKH - the great invention of Satoshi Nakamoto
Base58(0x00 +
Pay to Public Key Hash, as the name suggests, is to put Bitcoin into a safe, and the keyhole is the public key Hash (Public Key Hash). The most common 1-address we see is essentially an encoding of Public Key Hash. 1- The address generation process is also very simple. The public key is calculated through Hash160 to obtain the Public Key Hash, the prefix 0x00 is added to the head of the Public Key Hash, the checksum is added to the end of the Hash, and the Bitcoin at the beginning of 1 is obtained through Base58 address.
Let's take a look at the safe construction process of the P2PKH transaction type. Alice sends Bitcoin to Bob as an example:
OP_DUP
OP_HASH160
Payer Alice needs to set a locking script when constructing the safe:
OP_EQUALVERIFY
OP_CHECKSIG
(Public Key Hash contained in Bob's receiving address)
Note: We can understand this step as Alice customizing a safe for Bob, putting bitcoins in the safe and locking it with Bob's public key PubKey Hash. Now no one can open this lock except Bob who holds the private key.
When Bob needs to spend the bitcoins that Alice gave him, he needs to provide the necessary parameters: transaction signature + public key (technical jargon: scriptSig) to open the safe, so that the lock script returns True after execution. This step is usually done automatically by the wallet.
Let's take a look at how the Bitcoin node verifies the legitimacy of scriptSig.
(Image from Mastering Bitcoin)
, the Bitcoin script executor starts from the PUSH data. The PUSH operation will read the first byte to obtain the length information of the data to be pushed into the stack, and then continue to execute the Bitcoin script until the execution is completed to check the execution result.
, Executing CHECKSIG will verify the correctness of the digital signature, ensuring that the signer has the private key corresponding to the address.
No one can forge the digital signature except the person who holds the private key. So far, a Bitcoin P2PKH transaction has been safely completed.
Explain again: When Bob wants to spend the bitcoins Alice gave him, Bob can only open the safe left by Alice with the correct key, and put the money into a newly constructed safe for Bob.
At this time, some smart readers will notice a detail: if Bob takes out the key, any miner on the blockchain can see the shape of the key before opening the safe, and theoretically they can copy it immediately A key to open and spend Alice's safe to Bob (commonly known as Front-running attack). Is it really possible to do this? Obviously Satoshi Nakamoto has considered this issue, the transaction signature in this key is the complete signature of the transaction initiated by Bob. Assume that Bob wants to put the bitcoins in the safe constructed by Alice into a new safe (for Charlie). At this time, the key presented by Bob contains Charlie’s public key Hash. Although the miner can copy Bob’s key, the key The key information of the next new safe has been hidden, so miners cannot use this duplicate key to complete other actions (the digital signature cannot be embezzled).
P2SH - a major innovation in the post-Satoshi era
Satoshi Nakamoto designed such a powerful script system, it seems too wasteful to only use it to construct transfer transactions. Let us try to construct some special locking scripts with other instructions and use other methods to unlock them.
OP_HASH160
OP_EQUAL
For example, we can construct a script that uses Hash pre-image to unlock transactions:
When this condition is met, the script can be successfully unlocked.
We continue with the example of a safe and give this type of safe the name 3-type safe. Now Alice's bitcoin to Bob is locked in a safe protected by the above Hash160, let's call it a hash lock.
This lock still requires the correct shape to open, but the security is much weaker. The lack of a digital signature mechanism causes the key information hidden by the key to not change with Bob's new safe. Any miner can copy the exact same key the moment Bob shows the key, rush to open the safe (Front-running) left by Alice to Bob, and transfer the coins to another person, Eve, so the coins that originally belonged to Bob Bitcoins would be looted.
Although this script is very insecure, it has two very magical functions:
1. The output of the transaction structure is short enough, which means that the space occupied by the UTXO cache maintained by the Bitcoin node will be greatly reduced
2. The Pre-image is always referenced as an input when the transaction is spent, and will not appear on the output side of the transaction. UTXO remains streamlined, and the burden of handling fees can be passed on to the receiver.
Since the output script described has many benefits, is there a way we can make this transaction safe? This requires talking about what is P2SH.
Bitcoin Core developer Gavin Adresen proposed a technique called Pay to Script Hash (P2SH).