Hello everyone, this is Bo Min Lee from Constamp. I'm a security auditor.
And the topic today I'm going to talk about is double spending in BSV.
Is it possible?
Firstly, I will briefly explain what is Bitcoin SV, also called BSV.
And secondly, I will talk about is double spending possible.
What is double spending? And is double spending possible for BSV in its current condition?
Thirdly, I will talk about how to implement exactly, more details,
how to do the double spending in BSV, and what's the cost.
Finally, I will talk about another way to do double spending, specifically in BSV only.
First, what is BSV?
In 2017, we forked Bitcoin Cash.
And the goal of the BSV team is to stick to the great original vision of Bitcoin,
try to make it the cash for everyone.
I mean literally for everyone.
Everyone can use it as a cash.
But not only like cryptocurrency as a trading pair to the hedging or speculation.
BSV's goal is to be the cash for everyone.
So to achieve that, you need to be fast in reaching the settlement state.
Just like nowadays, what the cash is, right?
They have to achieve this by enabling certain characteristics and certain technical characteristics, right?
So the first one, I think the core concept of it is two.
First is to increase the block size.
Second one is to support the zero combination.
That's what they claimed.
So this is for BSV.
In this slide, I'm going to explain briefly what is double spending.
So first, in a normal trading scenario, there's a buyer and a seller, right?
And there's a BSV blockchain.
So all the balance changes depend on the transaction the buyer sent to the BSV blockchain.
We enable the transfer of Bitcoin SV, right?
And this is a trading scenario.
When a buyer wants to purchase a product from the seller,
first tell the seller that I'm going to purchase one good from you, okay?
And then send a transaction to BSV blockchain.
Let's call it transaction one or whatever.
Send one BSV to the seller.
This is what this transaction do.
And then the seller check that the transaction is okay, is valid,
and it's BSV balance of the seller's wallet plus one.
And then the seller is feel safe, good.
And then the seller will deliver the product to the buyer.
So this sounds great, right?
Seller earns money.
However, the next buyer ran away.
Suddenly, he did something, revert the original transaction.
We call that transaction one, right?
The transaction one was reverted.
And the seller will find out that the transaction one is reverted.
So then the BSV balance will minus one because it no longer exists.
Then seller cannot get back the product and the buyer has run away.
So this is what double spending is.
The seller lose money.
The buyer is a hacker.
So to explain how to do that in BSV, firstly, I will talk about what is POW insured.
Because this is related.
First, POW is the most commonly used algorithm for the public blockchain system nowadays.
It's a consensus algorithm that includes BSV.
BSV also use POW-based consensus algorithm.
And the concept of it, I'll just talk about the concept.
The concept of this is that probability of a miner a chance to execute any, to include any transaction that they select is proportional to the computational power that the miners owns.
This is the easiest way to understand this concept.
And then we have a website called crypto51.app.
It shows all the coins, all the famous coins, the symbol, the market gap, the algorithm they are using, and the hash rate it currently have.
Which means the total power, total hash power that they currently have on the network.
And the one hour attack cost, if you want to attack it, using the 51% attack.
Oh, I should explain what is the 51% attack cost here.
So the probability of a miner to include transaction, whatever he wants, is proportional to its mining power, right?
So 51% of hashing power means it has 51% of probability to be the miner that can include transactions.
To be the miner to change the ledger, right?
So 51% attack means an attacker having the hashing power for more than 51%.
So I can do something malicious.
Here is the hashing rate that is currently owned by that different network here, different blockchain.
So on the other hand, or on the other word, if you are a hacker and you have a hash rate more than 51%, for instance, for Bitcoin SV, you have more than 1,500 Pega hash rates and then you can do something malicious like double spending.
And this is a one hour attacker cost if you want to spend it on the internet.
I mean during the hash rate. So I'll talk about it later.
So then the following I'm going to explain is the core concept of double spending using this 51% attack.
What can really be done and what is the underlying mechanism of it?
So here I will take Bitcoin as an example.
The first step, let us look at this blockchain.
We have an original blockchain. It's a green one like 38, 39, 40, 41, 42, right?
And the first step, if you want to attack someone using the double spending attack, the first step for you to do is to fork your own blockchain, private blockchain.
You'll be a miner and have a hash power more than 51%, right?
So you fork your own private blockchain and you do not broadcast.
You don't broadcast and you concave, concave, blockchain longer and longer.
This is the first step.
And then the second step is to spend the Bitcoin only on the original blockchain.
Only on this one, like R40.
And then when you spend that Bitcoin, you are the buyer, right?
And the seller will perceive that they have obtained 100 Bitcoin and provide you with goods.
And then simultaneously in the blockchain that you currently manage, but not broadcasting, you just don't send that transaction.
You exclude that transaction from the blockchain that you are maintaining.
This is step two.
So step three, because you have the 51%, your hash power is more than 51%, so you are faster than the others.
You have higher probability to concave a longer blockchain than the others, than the original blockchain.
So you just exploit that.
You build a longer blockchain based on your power.
So now you are on block 42, but the others, the public blockchain, the consensus is just reaching the block 41.
This is the current status in step three.
And the step four, this is what you're actually hacking them.
You broadcast the private blockchain, the longer one, the longer blockchain that you are using.
You broadcast that to the network and the others, based on the consensus algorithm, they will accept the longer chain.
So when they see your blockchain, they will see, oh, maybe we should include this one and replace the original one.
And that's what will happen.
And then the private blockchain that you concave, that you build, become a new consensus blockchain.
And then the original blockchain, this part of the blockchain will be abandoned.
So this is what's happening.
And when this happens, the transaction you excluded will not be included in the new blockchain.
Hence, that transaction is reverted because it no longer exists.
And the poor seller will just find out that, oh, they lose 100 blockchain and they lose the product.
Oh my God.
This is what's happening.
So this is the concept of double spending in a DLW-based blockchain, taking Bitcoin as an example.
So to be more specific, how are we going to do that?
How can we do that?
Should we purchase many ASICs to purchase many machines and build an office to do that?
We don't.
Nowadays, we have NiceCash.
NiceCash is a place that allows people to peer-to-peer purchasing hash power from the others to rent them for a period of time.
And it's a marketplace of hash power.
So what you have to do using the NiceCash is to rent, is to pay, find your sellers and pay them with Bitcoin and rent hash power from it.
And what exactly you will have to do, if you want to carry out this kind of attack, you should first create a mining pool.
And you have to modify the pool's configuration, modify the node, the code of nodes to enable the functionalities, special functionalities,
because you don't want it to behave normally like an ordinary node.
You want the node to do something that you want it to do, right?
So you have to change the code, modify the code to excuse a predefined transaction from adding it to a block.
This is what you have to do.
And then you also have to enable it to temporarily stop broadcasting the fourth version of blockchain and temporarily hold it.
And then it can broadcast it and it's longer than the current blockchain or whatever you want it to broadcast.
So after you do this, you point all the hash power you purchased to the mining pool you built.
And then the nodes you purchased from NiceHash, they will behave as you expect.
You can guide them, you can have them do whatever you want.
So this is the user interface from NiceHash.
This is how you can purchase hash power from NiceHash.
You can see the European market is a US market.
And when you press on the hash power marketplace, you can see all the book of hash power.
And then you select the correct algorithm you want because these different machines may be running different algorithms.
So you have to choose the algorithm that you need and use Bitcoin to pay all the purchase.
This is what this marketplace only accepts.
You can determine the duration and the amount.
This is the order form.
You can determine the price, the limit price, the limit hash power, the amount you're going to pay for.
You can select your mining pool.
You can choose the duration and the amount of hashing power you want to purchase.
And then just place purchase.
So the introduction I was talking about is about the 15.1 attack, a normal attack.
This kind of attack can be carried out to most of different chains that use POW as a consensus algorithm like Ethereum and Classic.
Recently there's a big news.
If you are not familiar with it, you can try to look on it on the internet.
And that kind of attack can be used on most of the POW consensus algorithm.
But here I'm going to introduce the second type of double spending attack, which is especially just for the BS Bitcoin SV.
Before talking about that, I will have to talk about the more details about BSV.
But first, BSV users believe that there's no need to wait for confirmation for a Bitcoin SV transaction.
And why is that? Because they believe they can do the zero confirmation.
These claims about why zero confirmation is okay for BSV are all of these.
And most important thing, my point of view, is that they believe that the propagation of transaction is very fast.
Then the miner, they follow first seen safe road.
Namely, if a miner includes one transaction with this input, and then later it presents another transaction with the same input,
then the miner will consider that a false one.
And then they just accept the first one. It's seen.
So once they accept the transaction, they will not accept another one.
Trying to revert the first one or do something else. Malicious.
So this is the first seen safe road.
And then that is what I consider the core concept is that even if someone managed to stop a spend through a confirmation,
it can still be detected by connecting, by having the receiver or the seller in our trading example.
It's trivial. By connecting to several nodes and wait for five seconds and just try pulling the nodes
and let them know what transaction they have.
Is there any transaction that with the same input but different in spending?
If there is, they are conflicting to each other and we know that somebody is doing some malicious action.
So this is what their claims.
However, previously, there's a researcher, Razul, he did a demo to do this, what is so-called a zero confirmation double spend attack.
What he actually did is he used a mobile phone and spent his Bitcoin SV.
And then when he sent a transaction and he sent a transaction later, that revert the first one.
So if you want to emulate is that if a seller sees this kind of stuff, he may give his products out,
but with a reverted transaction, he will lose money.
So this is why it's so-called zero confirmation double spending.
And the core concept of it is to prevent nodes from propagating a transaction between the miners and the other miners.
So he connect to all the nodes of the network and send them the transaction simultaneously.
Whatever the number of the nodes are, just send them.
And using the ratio of the two types of transaction, using the ratio of the miners number to determine which transaction should be valid at the end of the day.
And in this scenario, it's the reverted one, right?
Just revert the first one.
And yeah, that's the core concept of doing that.
So there's a suggestion of CSW, one of the big supporters for BSV, about this.
About how to safely use BSV for everyone.
First, it's party claims.
I think it's more like not a technical side suggestion.
It's more like a business logic side suggestion on using BSV safely.
And I'll explain a simplified version of the suggestion in the next page.
So this is what he suggested.
It's to use Bitcoin SV, take it into a traditional trading workflow, and use it like that.
Instead of just sending out... instead of the example I gave you in the first few slides about the developer and trader, that workflow, he would consider that it's not safe.
He suggests that everyone use this workflow instead.
It's more like a traditional trading workflow.
So let's talk about it.
First, this kind of scenario first will let the merchant create a transaction template.
It's like an invoice.
You send the invoice to the customer first, and then have the customer sign the transaction and hand it to the merchant.
Then the merchant will post the miners to check that there's no transaction with the same input currently on the network.
No one knows about it.
Then the merchant can then broadcast it to multiple miners at the same time.
Broadcast the signed one, the signed transaction from the customer.
Broadcast it to multiple miners at the same time.
And after broadcasting it, the merchant will ask the miners to check if there's any conflicting transaction after that.
After two seconds, the merchant can hand over the product and he knows he's safe.
So what's the core concept?
The core concept of it is that the merchant decides when and how to send the transaction and detect any transaction with the same input before and after he sends that transaction to the mining miners.
So in this way, the sellers, the attacker will be hard for them to decide when to send their reverting transaction like the former example, the hacking example.
The core concept is that the merchant decides when and how to send the transaction.
And in that case, he can keep holding the miners to see if this buyer is trying to do anything malicious.
So at last, in regard to this zero confirmation double spending attack on BSV,
I would like to leave a last comment for this suggestion and for this attack and for this feature.
I think people should understand any merchant who supports the zero confirmation of BSV should also understand that
you should implement the tracking strategy suggested by CSW in that last page.
Because if you don't, it might be a potential target of an attack.
You should implement that tracking strategy.
So this is the reference.
And that's all for today.
Thank you everyone for listening.
Thanks for your time.
I'm open for questions.
So you have to trust all miners?
No, we don't have to trust all the miners.
Just like holding them, holding different ones.
It's hard for all the miners to cheat you at the same time, right?
So you just hold different miners.
And if any one of them is trustworthy, you know you have the good ground truth.
So is this attack happened before?
Yes.
The zero confirmation one happened before.
The researcher Razoo, he actually demoed his attack and put it on the internet.
There was a video.
You can see it.
Twice this week.
What Jay is talking about is for Ethereum Classic.
Twice a week.
It is a 51% attack.