BRC20 tokens are a non-fungible asset on the Bitcoin network. The tokens are embedded into a Satoshi using Ordinal Theory. The ordinals protocol can assign more information on top of a satoshi called an inscription. The Satoshis each have an ID, which is ordered by how they were mined on the Bitcoin network.
The Ord data is stored in a Taproot script-path spend script. The Ord is the reference of a particular Satoshi. The Inscription is the information about the token itself, which can be an image, text, or anything else. Commonly, the metadata is stored in the witness data of the transaction. It should be noted that the Bitcoin itself hasn't changed - just how people are viewing said Bitcoin.
BRC20 has three operations: deploy, mint (create) and transfer. The inscribed operations are not executable actions. They leverage the OP_RETURN OPCODE in a bitcoin transaction that is not spendable then add arbitrary data to the end of the script, called an Inscription which contains a JSON payload to specify what is happening.
The
transfer requires
two transactions:
- Inscribe the JSON-style content into a satoshi marked with a unique sequence number. This is sent to yourself.
- Execute the actual transfer by sending the previous inscription to the receiver.
The BRC20 token balance structure has three values: available balance, transferrable balance and overall balance. Available balance is what a user can freely spend. Transferrable balance is a token that has been inscribed in a token transfer but hasn't been sent to the user yet. The overall balance is just the sum of these two.
I don't fully understand how this system works tbh. Here are a two articles:
one and
two.
The attack targets the transferable balance field. When a token transfer is initiated via an inscription, the tokens move from available to transferrable, waiting for pending transactions to be confirmed. First, an attacker sends a bunch of false transfers from the target to the user. When doing this, they make the first tx with the inscription update happen but make the second one have a very low fee to guarantee it will not happen for a long time.
By doing this, the system is locked up. The requests for usage appear to require sequential transactions. So, if there's a transfer happening to you then you are unable to perform any actions. By intentionally getting the transactions stuck for long periods of time, it locks your targets wallet as well. They ran this locally then on a popular wallet used on Binance. I personally think that testing a live system like this without notifying the party first is completely unethical.
I'm still confused on how the tracking of BRC20 tokens works. None-the-less, this was an interesting vulnerability that abused multiple parts of how Bitcoin and BRC20 function, which is cool. This was a systemic issue on Bitcoin which is pretty crazy. Overall, I wish more context was provided on token tracking but an interesting vuln!