Author: OneKey Chinese, Source: Author Twitter @OneKeyCN
At the end of 2021, the Taproot upgrade took effect in block 709,632. At that time, people were immersed in the craze of Ethereum NFT, and no one knew that this would be the most "wealthy" upgrade of BTC.
Taproot and Segwit upgrades introduced new features to the BTC network, and also indirectly expanded the block data (equivalent to 1 MB to 4 MB), becoming the fuse for the BTC ecosystem outbreak from 2023 to date. The emergence of new assets such as Taproot Assets, Ordinals BRC-20, ARC-20, and Runes has also kept Taproot's transfer adoption rate basically at half or even above.
However, the introduction of new assets and new features is also accompanied by new security challenges.
The Bitcoin ecosystem has a different underlying model from the Ethereum ecosystem. At present, the scene of "many things need to be built" and "high threshold for understanding" in the new BTC asset ecosystem is believed to make many users excited - after all, this often means the opportunity to "get rich quickly".
However, this will also put forward new requirements for users' security operation awareness, otherwise it is easy to lose coins without knowing why. There have even been incidents such as the previous Atomic market's incorrect use of signature types leading to hacker attacks.
The following OneKey will explain in simple terms how to protect asset security and prevent phishing to the greatest extent in the BTC ecosystem with limited security infrastructure.
A brief analysis of the specific impact of Taproot upgrade
Before describing specific anti-phishing measures, we need to lay the groundwork for the impact of Taproot upgrade.
In addition to the previously mentioned indirect promotion of the prosperity of the BTC multi-asset ecosystem, there have actually been great changes in the underlying BTC transaction, mainly two: Schnorr signature and MAST technology. After these two are combined with PSBT (partial signature transaction), hackers have more room to play with phishing.
One is the Schnorr signature. Yes, this upgrade replaced the ECDSA signature in the white paper. The technical feature of this signature is that multiple signatures or public keys are aggregated into one. In the past, the work that required multiple signatures to confirm again and again now only needs to be verified once, which directly reduces the space occupied by the signature.
One is MAST technology. If the former is an aggregated signature, then MAST is used to "aggregate" multiple scripts (for scripts, you can understand it as Bitcoin's limited "smart contract"). At the same time, when submitting verification to unlock the spending, only one of the spending conditions needs to be verified. The space occupied by complex scripts with many conditions can be greatly reduced.
These two technologies have the greatest impact on privacy, and also imply security risks.
For transfer records, all UTXO transfers look the same after the upgrade. In Mempool, the transfer type is displayed as P2TR, and the addresses are all addresses of the same length starting with bc1p.
In the past, you could easily distinguish the difference between transfers to ordinary addresses (P2PKH / P2WPKH) and transfers to script addresses (P2SH / P2WSH).
Now before observing others spend a UTXO, you can't tell the difference between transfers to ordinary addresses and transfers to script addresses.
For scripts, miner verification only needs to expose one spending condition of the script, and other branch scripts are unknown to the outside world.
Five strategies to prevent phishing of new assets in the Bitcoin ecosystem
Obviously, the current security infrastructure of the asset ecosystem of the BTC layer is far less powerful than that of Ethereum, and there are many things that users need to understand and learn first.
At the same time, the principles of phishing are also different from those of Ethereum. Many phishing attacks may not be well understood by the entire market before they are discovered. For example, the *SIGNHASH_NONE signature security incident in the Atomic market, and the security reminders added by the Unisat/Xverse wallets were also added later.
(1) The first strategy: the old-fashioned basic skills of encryption security.
That is, pay attention to the security of offline storage of private keys, pay attention to whether the website is a trusted website, and pay attention to protecting the computer from Trojan viruses, etc.
However, in a FOMO market, users may want to "rush" into a new project before a consensus of trust has been formed. At this time, the following few strategies are particularly important.
(2) The second strategy: clarify input and output.
Ethereum has "blind signatures". That is to say, when signing, if the wallet does not parse, you can only see a mess of characters and cannot predict what will happen to the assets after signing. This also creates the risk of losing coins.
In Bitcoin, the input and output of a transaction must be clearly defined, as well as the corresponding transfer addresses of the input and output. (That is, "where it comes from, how much coins come in" and "where it goes, how much coins go out.")
When signing, regardless of whether PSBT is used, the changes that occur before and after the transaction will be clearly displayed in the wallet. Therefore, it is very important to check whether the input and output are in line with your intentions and expectations.
For example, if a hacker wants to take away all your Ordinals NFTs at once, the transaction input (INPUT) will show that all your NFTs have been put in. At the same time, the output (OUTPUT) will show that they have all gone to an unfamiliar address.
Take the example of using Unisat to place an order for Ordinals NFTs on MagicEden. When you place an order for one or more NFTs on the MagiEden market, the PSBT signature request that pops up will show that the transaction input (INPUT) is one or more of your NFTs, and the output will show how much Bitcoin you will receive once the transaction is successful.
(3) The third trick: Be careful with the signature type.
You can see the popular science of Bitcoin's current signature types here (https://btcstudy.org/2021/11/09/bitcoin-signature-types-sighash/).
The only signature types to pay attention to here are SIGHASH_NONE (0x02) and SIGHASH_NONE | SIGHASH_ANYONECANPAY (0x82). Both of these mean that you "only sign the input of the transaction, regardless of the output of the transaction."
For transaction inscription assets, the safe signature type should be SIGHASH_SINGLE | SIGHASH_ANYONECANPAY (0x83), which can construct a complete transaction through PSBT trustlessness. This is also the signature type used by mainstream inscription trading markets such as MagicEden and OKX.
Take the previous incorrect use of SIGHASH_NONE | SIGHASH_ANYONECANPAY (0x82) signature in the Atomic market as an example.
When you place an order for an Atom inscription asset, you do see the correct input and output when signing, that is, "the asset I placed the order for is specified in the input, and the output also has the money I can receive."
However, hackers can completely get this PSBT to modify the output, and the submitted transaction will also be packaged by the miners, and ultimately you will not receive the money for the order. In short, it is because the signature type used only signs the input part, which ultimately leads to "zero-yuan purchase".
Fortunately, the current mainstream BTC ecosystem wallets, such as Unisat and Xverse, already support highlighting reminders or prohibiting SIGHASH_NONE-type signature types. If you see a prompt for the relevant signature type, do not use this signature unless it is for a special purpose.
(4) The fourth mindset: Be careful when using scripts.
If a project or platform requires you to transfer assets to a script address, you must be extra careful. When signing, you will see that your assets have been transferred to an unfamiliar address in the output.
According to the previous content, you will know that after the Taproot upgrade, the script address and the user's private key address are the same.
If the thief tries to cheat with the private key address, the received assets can be transferred directly.
If it is a real script address. It depends on whether they have disclosed the entire content of the script address. If the incomplete content is disclosed, although the user can sign and transfer assets normally when using it, it is possible that one or more malicious UTXO unlocking conditions are hidden. It may suddenly "close the net" and transfer all UTXO assets one day in the future.
Even if they open source the entire script, the current wallets on the market do not have the function of verifying the integrity of the script MAST and the correspondence of the output address. Technically savvy users need to use the Taproot algorithm to confirm it. Or trust the project and team very much.
Fortunately, for current applications, transactions of various inscription assets do not require the use of complex scripts. PSBT (partial signature transaction) can be used to specify inputs and outputs.
However, in future BTC L2 operations, complex and multi-conditional Bitcoin scripts are likely to be involved. For example, Babylon @babylon_chain 's Bitcoin pledge script has relatively complex confiscation logic and unlocking logic.
If you want to use this native pledge method of Bitcoin script, it is particularly important to open source the script and verify the security and integrity, otherwise users need to absolutely trust the project party.
(5) The fifth mindset: Pay attention to security trends and take precautions.
Follow the top accounts in the security field to ensure that you can keep up with the latest phishing techniques and get warnings as soon as possible. Such as SlowMist's cosine @evilcos, Go Plus Security official @GoPlusSecurity, Scam Sniffer @realScamSniffer, and our OneKey official account @OneKeyCN.
Regarding taking precautions, we can transfer security experience from other places.
For example, in Ethereum, there is such a phishing method - that is, constructing addresses with similar beginnings and ends, causing users to mistakenly copy in historical records and lose assets. When constructing BTC signature transactions, it is also possible to step into the pit because of not clearly checking the output address.
In mainstream BTC ecosystem wallets such as Unisat / Xverse, the Taproot address is displayed as bc1px…e9wh0 (for example), and bc1p is the fixed beginning of the Taproot address.
This is equivalent to displaying only 6 letters for confirmation. Compared with the standard configuration of Ethereum wallets that have a common address address book function and basically display more than 10 digits, it is obviously not enough.
This means that hackers have a high possibility of generating matching addresses for customized phishing (although there are not many on Bitcoin at present).
So if you are more decisive and take precautions, you should check the address as complete as possible.
In short...
Study Bitcoin.
Study Bitcoin Security.
As Taproot introduces new assets and new scenarios to Bitcoin, we must also learn new forms of security threats, especially the evolving phishing techniques.
Especially with the current situation of imperfect ecological infrastructure, even misoperation and coin loss and burning occur from time to time, not to mention carefully planned phishing.
Catherine
Zoey
Bitcoinist
Beincrypto
cryptopotato
Cointelegraph