WEBVTT 00:00.000 --> 00:05.520 Hello everyone, this is Bo Min Lee from Constamp. 00:05.520 --> 00:07.260 I'm a security auditor. 00:07.840 --> 00:13.400 And the topic today I'm going to talk about is double spending in BSV. 00:13.400 --> 00:15.200 Is it possible? 00:16.860 --> 00:24.820 Firstly, I will briefly explain what is Bitcoin SV, also called BSV. 00:24.820 --> 00:29.540 And secondly, I will talk about is double spending possible. 00:29.540 --> 00:31.440 What is double spending? 00:31.440 --> 00:36.440 And is double spending possible for BSV in its current condition? 00:36.840 --> 00:47.980 Thirdly, I will talk about how to implement exactly, more details, how to do the double spending in BSV, and what's the cost. 00:49.500 --> 00:59.520 Finally, I will talk about another way to do double spending, specifically in BSV only. 01:00.520 --> 01:03.860 First, what is BSV? 01:04.160 --> 01:11.820 In 2017, we forked Bitcoin Cash. 01:12.360 --> 01:27.100 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. 01:27.840 --> 01:29.420 I mean literally for everyone. 01:29.420 --> 01:31.220 Everyone can use it as a cash. 01:31.220 --> 01:42.300 But not only like cryptocurrency as a trading pair to the hedging or speculation. 01:43.260 --> 01:45.760 BSV's goal is to be the cash for everyone. 01:45.760 --> 01:50.940 So to achieve that, you need to be fast in reaching the settlement state. 01:50.940 --> 01:55.120 Just like nowadays, what the cash is, right? 01:55.500 --> 02:09.920 They have to achieve this by enabling certain characteristics and certain technical characteristics, right? 02:09.920 --> 02:13.820 So the first one, I think the core concept of it is two. 02:13.820 --> 02:16.600 First is to increase the block size. 02:16.600 --> 02:20.100 Second one is to support the zero combination. 02:20.100 --> 02:22.520 That's what they claimed. 02:23.600 --> 02:25.380 So this is for BSV. 02:26.700 --> 02:31.340 In this slide, I'm going to explain briefly what is double spending. 02:32.200 --> 02:39.620 So first, in a normal trading scenario, there's a buyer and a seller, right? 02:39.620 --> 02:41.900 And there's a BSV blockchain. 02:41.900 --> 02:52.140 So all the balance changes depend on the transaction the buyer sent to the BSV blockchain. 02:52.140 --> 02:58.080 We enable the transfer of Bitcoin SV, right? 02:58.080 --> 03:00.740 And this is a trading scenario. 03:00.740 --> 03:10.300 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? 03:10.300 --> 03:14.320 And then send a transaction to BSV blockchain. 03:14.520 --> 03:17.640 Let's call it transaction one or whatever. 03:17.640 --> 03:20.320 Send one BSV to the seller. 03:20.320 --> 03:23.160 This is what this transaction do. 03:23.160 --> 03:32.400 And then the seller check that the transaction is okay, is valid, and it's BSV balance of the seller's wallet plus one. 03:32.400 --> 03:36.940 And then the seller is feel safe, good. 03:36.940 --> 03:40.740 And then the seller will deliver the product to the buyer. 03:41.040 --> 03:43.460 So this sounds great, right? 03:43.600 --> 03:45.200 Seller earns money. 03:45.340 --> 03:48.460 However, the next buyer ran away. 03:48.460 --> 03:55.400 Suddenly, he did something, revert the original transaction. 03:55.400 --> 03:57.500 We call that transaction one, right? 03:57.500 --> 03:59.480 The transaction one was reverted. 03:59.720 --> 04:04.820 And the seller will find out that the transaction one is reverted. 04:04.820 --> 04:11.000 So then the BSV balance will minus one because it no longer exists. 04:11.380 --> 04:16.680 Then seller cannot get back the product and the buyer has run away. 04:16.680 --> 04:20.560 So this is what double spending is. 04:20.560 --> 04:22.300 The seller lose money. 04:22.640 --> 04:24.140 The buyer is a hacker. 04:25.140 --> 04:34.000 So to explain how to do that in BSV, firstly, I will talk about what is POW insured. 04:34.000 --> 04:36.620 Because this is related. 04:36.940 --> 04:44.640 First, POW is the most commonly used algorithm for the public blockchain system nowadays. 04:44.640 --> 04:48.920 It's a consensus algorithm that includes BSV. 04:48.920 --> 04:53.560 BSV also use POW-based consensus algorithm. 04:53.560 --> 04:56.220 And the concept of it, I'll just talk about the concept. 04:56.220 --> 05:13.360 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. 05:13.360 --> 05:18.680 This is the easiest way to understand this concept. 05:19.660 --> 05:24.460 And then we have a website called crypto51.app. 05:24.560 --> 05:34.580 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. 05:34.580 --> 05:40.400 Which means the total power, total hash power that they currently have on the network. 05:40.700 --> 05:48.400 And the one hour attack cost, if you want to attack it, using the 51% attack. 05:48.400 --> 05:51.940 Oh, I should explain what is the 51% attack cost here. 05:51.940 --> 06:06.080 So the probability of a miner to include transaction, whatever he wants, is proportional to its mining power, right? 06:06.080 --> 06:20.960 So 51% of hashing power means it has 51% of probability to be the miner that can include transactions. 06:20.960 --> 06:26.340 To be the miner to change the ledger, right? 06:26.340 --> 06:40.420 So 51% attack means an attacker having the hashing power for more than 51%. 06:40.420 --> 06:43.360 So I can do something malicious. 06:43.680 --> 06:52.480 Here is the hashing rate that is currently owned by that different network here, different blockchain. 06:52.480 --> 07:21.200 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. 07:21.840 --> 07:27.360 And this is a one hour attacker cost if you want to spend it on the internet. 07:27.360 --> 07:28.760 I mean during the hash rate. 07:28.760 --> 07:30.400 So I'll talk about it later. 07:31.620 --> 07:41.720 So then the following I'm going to explain is the core concept of double spending using this 51% attack. 07:41.740 --> 07:48.180 What can really be done and what is the underlying mechanism of it? 07:48.180 --> 07:51.080 So here I will take Bitcoin as an example. 07:51.080 --> 07:56.660 The first step, let us look at this blockchain. 07:56.660 --> 07:58.060 We have an original blockchain. 07:58.060 --> 08:04.940 It's a green one like 38, 39, 40, 41, 42, right? 08:04.940 --> 08:17.720 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. 08:17.720 --> 08:27.980 You'll be a miner and have a hash power more than 51%, right? 08:27.980 --> 08:31.820 So you fork your own private blockchain and you do not broadcast. 08:31.820 --> 08:36.880 You don't broadcast and you concave, concave, blockchain longer and longer. 08:36.880 --> 08:38.460 This is the first step. 08:38.900 --> 08:45.840 And then the second step is to spend the Bitcoin only on the original blockchain. 08:45.840 --> 08:49.080 Only on this one, like R40. 08:49.080 --> 08:55.080 And then when you spend that Bitcoin, you are the buyer, right? 08:55.080 --> 09:06.280 And the seller will perceive that they have obtained 100 Bitcoin and provide you with goods. 09:06.280 --> 09:17.560 And then simultaneously in the blockchain that you currently manage, but not broadcasting, you just don't send that transaction. 09:17.880 --> 09:23.420 You exclude that transaction from the blockchain that you are maintaining. 09:24.640 --> 09:26.420 This is step two. 09:27.920 --> 09:36.320 So step three, because you have the 51%, your hash power is more than 51%, so you are faster than the others. 09:36.320 --> 09:46.380 You have higher probability to concave a longer blockchain than the others, than the original blockchain. 09:46.560 --> 09:49.960 So you just exploit that. 09:49.960 --> 09:53.360 You build a longer blockchain based on your power. 09:53.360 --> 10:03.500 So now you are on block 42, but the others, the public blockchain, the consensus is just reaching the block 41. 10:03.500 --> 10:06.720 This is the current status in step three. 10:06.940 --> 10:13.320 And the step four, this is what you're actually hacking them. 10:13.860 --> 10:18.520 You broadcast the private blockchain, the longer one, the longer blockchain that you are using. 10:18.520 --> 10:25.660 You broadcast that to the network and the others, based on the consensus algorithm, they will accept the longer chain. 10:25.660 --> 10:32.100 So when they see your blockchain, they will see, oh, maybe we should include this one and replace the original one. 10:32.500 --> 10:34.820 And that's what will happen. 10:37.870 --> 10:45.690 And then the private blockchain that you concave, that you build, become a new consensus blockchain. 10:45.690 --> 10:53.510 And then the original blockchain, this part of the blockchain will be abandoned. 10:53.610 --> 10:54.850 So this is what's happening. 10:54.850 --> 11:01.910 And when this happens, the transaction you excluded will not be included in the new blockchain. 11:02.590 --> 11:07.690 Hence, that transaction is reverted because it no longer exists. 11:07.690 --> 11:16.790 And the poor seller will just find out that, oh, they lose 100 blockchain and they lose the product. 11:16.790 --> 11:17.950 Oh my God. 11:17.950 --> 11:19.650 This is what's happening. 11:20.870 --> 11:34.630 So this is the concept of double spending in a DLW-based blockchain, taking Bitcoin as an example. 11:34.630 --> 11:38.210 So to be more specific, how are we going to do that? 11:38.210 --> 11:39.810 How can we do that? 11:39.990 --> 11:58.110 Should we purchase many ASICs to purchase many machines and build an office to do that? 11:58.890 --> 12:00.410 We don't. 12:00.810 --> 12:03.250 Nowadays, we have NiceCash. 12:03.250 --> 12:16.130 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. 12:16.130 --> 12:21.590 And it's a marketplace of hash power. 12:21.590 --> 12:37.850 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. 12:38.190 --> 12:46.870 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. 12:46.870 --> 13:02.530 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. 13:02.530 --> 13:06.850 You want the node to do something that you want it to do, right? 13:06.850 --> 13:15.410 So you have to change the code, modify the code to excuse a predefined transaction from adding it to a block. 13:15.410 --> 13:17.490 This is what you have to do. 13:17.490 --> 13:29.450 And then you also have to enable it to temporarily stop broadcasting the fourth version of blockchain and temporarily hold it. 13:29.810 --> 13:41.450 And then it can broadcast it and it's longer than the current blockchain or whatever you want it to broadcast. 13:41.450 --> 13:49.490 So after you do this, you point all the hash power you purchased to the mining pool you built. 13:49.490 --> 13:57.230 And then the nodes you purchased from NiceHash, they will behave as you expect. 13:57.230 --> 14:01.270 You can guide them, you can have them do whatever you want. 14:02.590 --> 14:07.070 So this is the user interface from NiceHash. 14:07.070 --> 14:13.350 This is how you can purchase hash power from NiceHash. 14:13.350 --> 14:17.310 You can see the European market is a US market. 14:17.310 --> 14:28.390 And when you press on the hash power marketplace, you can see all the book of hash power. 14:28.390 --> 14:39.830 And then you select the correct algorithm you want because these different machines may be running different algorithms. 14:39.830 --> 14:48.230 So you have to choose the algorithm that you need and use Bitcoin to pay all the purchase. 14:48.230 --> 14:51.730 This is what this marketplace only accepts. 14:51.930 --> 14:54.670 You can determine the duration and the amount. 14:55.330 --> 14:57.310 This is the order form. 14:57.310 --> 15:06.290 You can determine the price, the limit price, the limit hash power, the amount you're going to pay for. 15:06.550 --> 15:08.570 You can select your mining pool. 15:08.570 --> 15:22.140 You can choose the duration and the amount of hashing power you want to purchase. 15:22.140 --> 15:24.000 And then just place purchase. 15:30.730 --> 15:37.730 So the introduction I was talking about is about the 15.1 attack, a normal attack. 15:37.730 --> 15:52.610 This kind of attack can be carried out to most of different chains that use POW as a consensus algorithm like Ethereum and Classic. 15:52.610 --> 15:54.870 Recently there's a big news. 15:55.250 --> 15:59.730 If you are not familiar with it, you can try to look on it on the internet. 16:00.490 --> 16:07.070 And that kind of attack can be used on most of the POW consensus algorithm. 16:07.070 --> 16:16.910 But here I'm going to introduce the second type of double spending attack, which is especially just for the BS Bitcoin SV. 16:17.930 --> 16:25.730 Before talking about that, I will have to talk about the more details about BSV. 16:25.730 --> 16:36.290 But first, BSV users believe that there's no need to wait for confirmation for a Bitcoin SV transaction. 16:36.410 --> 16:37.830 And why is that? 16:37.830 --> 16:45.650 Because they believe they can do the zero confirmation. 16:46.410 --> 16:53.610 These claims about why zero confirmation is okay for BSV are all of these. 16:53.670 --> 17:01.970 And most important thing, my point of view, is that they believe that the propagation of transaction is very fast. 17:03.370 --> 17:08.210 Then the miner, they follow first seen safe road. 17:08.210 --> 17:28.770 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. 17:28.770 --> 17:31.070 And then they just accept the first one. 17:31.070 --> 17:32.190 It's seen. 17:32.190 --> 17:36.830 So once they accept the transaction, they will not accept another one. 17:36.830 --> 17:40.610 Trying to revert the first one or do something else. 17:40.610 --> 17:41.550 Malicious. 17:41.650 --> 17:44.190 So this is the first seen safe road. 17:44.190 --> 18:08.830 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. 18:08.830 --> 18:09.810 It's trivial. 18:09.810 --> 18:18.230 By connecting to several nodes and wait for five seconds and just try pulling the nodes and let them know what transaction they have. 18:18.290 --> 18:26.910 Is there any transaction that with the same input but different in spending? 18:26.930 --> 18:36.170 If there is, they are conflicting to each other and we know that somebody is doing some malicious action. 18:36.710 --> 18:39.830 So this is what their claims. 18:41.890 --> 18:59.410 However, previously, there's a researcher, Razul, he did a demo to do this, what is so-called a zero confirmation double spend attack. 18:59.450 --> 19:09.390 What he actually did is he used a mobile phone and spent his Bitcoin SV. 19:09.390 --> 19:18.850 And then when he sent a transaction and he sent a transaction later, that revert the first one. 19:19.070 --> 19:33.330 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. 19:34.210 --> 19:37.410 So this is why it's so-called zero confirmation double spending. 19:37.410 --> 19:45.730 And the core concept of it is to prevent nodes from propagating a transaction between the miners and the other miners. 19:45.750 --> 19:51.370 So he connect to all the nodes of the network and send them the transaction simultaneously. 19:51.630 --> 19:56.450 Whatever the number of the nodes are, just send them. 19:56.450 --> 20:11.050 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. 20:11.730 --> 20:14.730 And in this scenario, it's the reverted one, right? 20:14.730 --> 20:16.830 Just revert the first one. 20:17.050 --> 20:20.490 And yeah, that's the core concept of doing that. 20:20.490 --> 20:29.530 So there's a suggestion of CSW, one of the big supporters for BSV, about this. 20:29.530 --> 20:32.650 About how to safely use BSV for everyone. 20:33.030 --> 20:37.790 First, it's party claims. 20:38.050 --> 20:43.390 I think it's more like not a technical side suggestion. 20:43.390 --> 20:48.890 It's more like a business logic side suggestion on using BSV safely. 20:48.890 --> 20:53.630 And I'll explain a simplified version of the suggestion in the next page. 20:53.670 --> 20:57.710 So this is what he suggested. 20:57.710 --> 21:05.410 It's to use Bitcoin SV, take it into a traditional trading workflow, and use it like that. 21:05.410 --> 21:20.670 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. 21:21.370 --> 21:25.430 He suggests that everyone use this workflow instead. 21:25.430 --> 21:27.670 It's more like a traditional trading workflow. 21:27.670 --> 21:30.310 So let's talk about it. 21:30.310 --> 21:36.930 First, this kind of scenario first will let the merchant create a transaction template. 21:36.930 --> 21:38.270 It's like an invoice. 21:38.270 --> 21:45.530 You send the invoice to the customer first, and then have the customer sign the transaction and hand it to the merchant. 21:46.290 --> 21:54.510 Then the merchant will post the miners to check that there's no transaction with the same input currently on the network. 21:54.570 --> 21:56.690 No one knows about it. 21:56.690 --> 22:03.430 Then the merchant can then broadcast it to multiple miners at the same time. 22:03.430 --> 22:06.990 Broadcast the signed one, the signed transaction from the customer. 22:06.990 --> 22:10.450 Broadcast it to multiple miners at the same time. 22:10.450 --> 22:24.430 And after broadcasting it, the merchant will ask the miners to check if there's any conflicting transaction after that. 22:24.430 --> 22:32.170 After two seconds, the merchant can hand over the product and he knows he's safe. 22:32.930 --> 22:34.370 So what's the core concept? 22:34.370 --> 22:52.350 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. 22:52.350 --> 23:06.550 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. 23:06.550 --> 23:11.650 The core concept is that the merchant decides when and how to send the transaction. 23:11.930 --> 23:21.290 And in that case, he can keep holding the miners to see if this buyer is trying to do anything malicious. 23:22.770 --> 23:36.130 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. 23:36.130 --> 23:50.570 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. 23:50.570 --> 23:56.170 Because if you don't, it might be a potential target of an attack. 23:56.170 --> 23:59.170 You should implement that tracking strategy. 24:00.490 --> 24:03.010 So this is the reference. 24:03.150 --> 24:05.330 And that's all for today. 24:05.350 --> 24:06.750 Thank you everyone for listening. 24:06.750 --> 24:08.010 Thanks for your time. 24:08.010 --> 24:09.990 I'm open for questions. 25:03.610 --> 25:06.330 So you have to trust all miners? 25:06.330 --> 25:10.270 No, we don't have to trust all the miners. 25:10.310 --> 25:15.550 Just like holding them, holding different ones. 25:15.550 --> 25:22.130 It's hard for all the miners to cheat you at the same time, right? 25:22.130 --> 25:23.970 So you just hold different miners. 25:23.970 --> 25:32.370 And if any one of them is trustworthy, you know you have the good ground truth. 25:37.200 --> 25:41.790 So is this attack happened before? 25:41.990 --> 25:42.780 Yes. 25:43.030 --> 25:47.290 The zero confirmation one happened before. 25:48.010 --> 25:57.550 The researcher Razoo, he actually demoed his attack and put it on the internet. 25:57.550 --> 25:58.640 There was a video. 25:59.010 --> 26:00.710 You can see it. 26:03.150 --> 26:04.470 Twice this week. 26:04.470 --> 26:09.270 What Jay is talking about is for Ethereum Classic. 26:09.270 --> 26:10.390 Twice a week. 26:10.390 --> 26:12.700 It is a 51% attack.