WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:20.820 --> 00:00:23.160 Live from Prague, this is Bitcoin. 00:00:23.880 --> 00:00:24.360 Explained. 00:00:24.620 --> 00:00:24.980 Hey, Sjors. 00:00:25.280 --> 00:00:25.600 Hello. 00:00:25.940 --> 00:00:27.980 Sjors, we have a distinguished guest today. 00:00:28.220 --> 00:00:28.680 We do. 00:00:29.380 --> 00:00:32.920 Jan, welcome to the show. Jan Čapek. Is that how I pronounce it? 00:00:33.280 --> 00:00:36.420 We actually say Čapek, but you did a pretty good job. 00:00:37.260 --> 00:00:37.740 Čapek. 00:00:37.880 --> 00:00:43.020 I think that's exactly what I said, Jan. So you work with Braiins? and we're 00:00:43.020 --> 00:00:46.940 gonna talk about Stratum V2 yeah we have two mics which is gonna be awkward 00:00:46.940 --> 00:00:50.400 sometimes you maybe hear someone talking in the background I'll just give the mic 00:00:50.400 --> 00:00:53.020 to you and then you can sort of introduce yourself how about that 00:00:53.960 --> 00:00:58.740 Hi guys. My name is Jan Čapek. I work for Braiins. I'm a co-founder of Braiins 00:00:58.740 --> 00:01:04.380 company. We started back in 2013 by basically making the first Bitcoin mining 00:01:04.380 --> 00:01:09.880 pool, a professional project. And since then our Bitcoin adventure started back 00:01:09.880 --> 00:01:14.600 in the day in 2018, we came up with the idea of extending our product line with 00:01:14.860 --> 00:01:19.240 mining firmware. So we implemented support for Antminers S9 and we call that 00:01:19.240 --> 00:01:23.860 project at that time Braiins OS. Then we had, it was like fully open sourced. By 00:01:23.860 --> 00:01:28.420 the time you could have all the data sheets for S9, the source code and 00:01:28.420 --> 00:01:32.710 everything, even from the manufacturers. So we kind of continue in that, in that 00:01:32.710 --> 00:01:37.390 line. Then we came up with a commercial extension called Braiins OS plus, which 00:01:37.390 --> 00:01:41.650 provides some additional features like optimized chip tuning of individual hash 00:01:41.650 --> 00:01:47.170 boards. And here we are 2023 and we're like slowly walking towards having our own 00:01:47.170 --> 00:01:52.210 mining hardware. We have now a control board coming in June and in Q3, we will 00:01:52.210 --> 00:01:56.330 have a PSU. So we're like approaching this product line from all the different 00:01:56.330 --> 00:01:59.670 aspects. And at some point there should be Braiins miner available. 00:02:00.100 --> 00:02:04.020 Yeah, and you gave a talk during Pizza Day Prague, which will hopefully one day 00:02:04.020 --> 00:02:08.480 be on YouTube. That is super interesting about this control board and all sorts 00:02:08.480 --> 00:02:09.380 of problems with that. 00:02:09.740 --> 00:02:14.260 Right. I gave a little overview of the issues that I see in the mining industry. 00:02:14.460 --> 00:02:19.260 And generally, the note was about the fact that people kind of take Bitcoin 00:02:19.260 --> 00:02:23.240 mining for granted. Not too many people actually look into it, except for the 00:02:23.240 --> 00:02:28.050 miners themselves. that is a great source of revenue for them but general Bitcoin 00:02:28.050 --> 00:02:32.190 users think like oh we have Bitcoin miners here but when you look at the details 00:02:32.190 --> 00:02:36.110 there are some centralization issues coming mostly from the fact that there's 00:02:36.110 --> 00:02:42.060 just a few players in the game mostly from China that basically keep the whole 00:02:42.060 --> 00:02:47.560 market for themselves. And it's a very motivating and incentivizing fact for us 00:02:47.560 --> 00:02:49.160 to actually enter the business as Braiins. 00:02:49.740 --> 00:02:53.820 Yeah. But I think today we'll be mostly focused on the software side of this 00:02:53.820 --> 00:02:55.700 story and not so much in the hardware side. 00:02:56.530 --> 00:02:58.850 First though, Jan, do you ever listen to our podcast? 00:02:59.290 --> 00:03:00.530 I think I did once. 00:03:00.870 --> 00:03:03.530 So you know what everyone's favorite part of the podcast is, yeah? 00:03:04.800 --> 00:03:06.020 Which one is that? Tell me. 00:03:07.200 --> 00:03:09.120 Sjors, do we have the boostagrams on the road? 00:03:09.930 --> 00:03:11.590 Yeah yeah we have them yeah 00:03:11.590 --> 00:03:12.370 Do you know the jingle? 00:03:12.370 --> 00:03:14.260 I don't sorry. 00:03:14.800 --> 00:03:20.780 I'll I'll do the jingle then Sjors stacks sats. Sjors stacks sats. Sjors 00:03:20.780 --> 00:03:22.060 stacks sats. 00:03:22.060 --> 00:03:27.360 Well, well, well. So we got a couple this time on the last episode about the 00:03:27.360 --> 00:03:32.580 witness discount. One is from fake for 10,000 sats, he says Sjors stacks sats and 00:03:32.580 --> 00:03:36.430 stays humble. Apparently. Then we have one from 00:03:36.430 --> 00:03:41.810 shadowycodermark, 9,400 sats saying, Van Wirdum, Sjorsnado. So he likes the old 00:03:41.810 --> 00:03:42.630 name of the podcast. 00:03:43.950 --> 00:03:46.930 Then somebody said that he thought I was an opera singer. 00:03:47.370 --> 00:03:48.670 No, that must be me, Sjors. 00:03:49.630 --> 00:03:50.610 That's possible. 00:03:50.610 --> 00:03:51.110 For sure. 00:03:51.530 --> 00:03:55.250 Somebody even asked a question, which I answered. So I won't repeat the question 00:03:55.250 --> 00:03:59.220 here. But sometimes I will answer boosts. Well, that's about it. 00:03:59.900 --> 00:04:05.610 Sjors stacks sats. Back to the episode. Okay, Stratum V2. Jan, 00:04:08.050 --> 00:04:12.650 first of all, okay, first, what is actually Stratum? What is Stratum V1? Let's start there. 00:04:13.810 --> 00:04:19.290 Stratum V1 didn't have the attribute of being V1 until we invented the V2 00:04:19.290 --> 00:04:24.870 so it's been known publicly until V2 as Stratum mining protocol so 00:04:24.870 --> 00:04:29.150 essentially it's a protocol between the Bitcoin mining machines and the pools so 00:04:29.150 --> 00:04:34.290 that pools can distribute jobs to the miners in a scalable way so it has some 00:04:34.290 --> 00:04:38.850 mechanisms to adjust difficulty of these mining jobs for the machines in case of 00:04:38.850 --> 00:04:43.890 huge farms connecting to the pools so that these pools can handle such loads so 00:04:43.890 --> 00:04:48.930 this was the the biggest added value compared to getblocktemplate back in the day 00:04:48.930 --> 00:04:53.610 where this was the old way of mining basically directly against the Bitcoin node 00:04:53.610 --> 00:04:59.090 to allow like scalable approach and even more than that you could have 00:04:59.090 --> 00:05:03.510 aggregate you could have aggregated the full hash rate on the mining farm through 00:05:03.510 --> 00:05:07.510 proxy and there would be then just a few connections going to the pool acting as 00:05:07.510 --> 00:05:11.980 if it was one gigantic miner Unfortunately the protocol so so fortunately we had 00:05:11.980 --> 00:05:12.500 the protocol 00:05:12.500 --> 00:05:17.480 I wanted to interrupt you a little bit to maybe zoom in a little bit or recap how 00:05:17.480 --> 00:05:22.480 mining works period because not all the listeners will know that so well the 00:05:22.480 --> 00:05:26.160 short story is in order to create a new block you need to find a nonce which is a 00:05:26.160 --> 00:05:29.840 random number or pseudo doesn't matter it doesn't have to be random but you have 00:05:29.840 --> 00:05:34.680 to find a number such that if you add it to the header of the of the Bitcoin of a 00:05:34.680 --> 00:05:40.220 block, if you then hash the header, you get a bunch of zeros at the start. 00:05:40.440 --> 00:05:44.360 That is the challenge you're trying to find. And then the difficulty adjustment 00:05:44.360 --> 00:05:49.160 based, to put it simply, the difficulty adjustment means that if blocks are found 00:05:49.160 --> 00:05:53.240 too quickly, then you have to add another zero or not really another zero, but 00:05:53.240 --> 00:05:57.360 basically it just becomes more difficult because in order to have more zeros at 00:05:57.360 --> 00:06:00.780 the start of a number, you have to do more random guesses. So you have to try 00:06:00.780 --> 00:06:06.590 more nonces. And then initially miners would just be the CPU of a computer, the 00:06:06.590 --> 00:06:12.470 one CPU, one vote idea. And as more CPUs started mining, 00:06:12.830 --> 00:06:16.570 they would have to add more zeros. But then somebody figured out how to do it on 00:06:16.570 --> 00:06:22.240 a GPU, a graphical computer, graphical processing card. And then I think a little 00:06:22.240 --> 00:06:27.760 bit later, well, and then later on, you got these dedicated chips basically. But, 00:06:27.940 --> 00:06:33.610 and that brings, I think it brings us to the problem of pooling, where you have 00:06:33.610 --> 00:06:37.830 multiple, where it's no longer a good idea to try and mine yourself because 00:06:37.830 --> 00:06:41.430 you'll find a block once every 2,000 years or something. 00:06:41.570 --> 00:06:42.430 Depends on your hash rate. 00:06:42.710 --> 00:06:46.510 Right. And so then you want to join with other people and distribute the work. 00:06:47.430 --> 00:06:53.310 And the reward. And the reward. and then well this is where we get into 00:06:53.310 --> 00:06:58.150 what getblocktemplate is maybe and what what problems started to be caused when 00:06:58.150 --> 00:06:59.030 you're trying to share the work. 00:06:59.030 --> 00:07:04.130 Well it was invented here in Prague pooled mining is that right? yeah don't hear 00:07:04.130 --> 00:07:06.130 me in the background Sjors, it's just a quick question. 00:07:06.130 --> 00:07:06.670 It's fine. 00:07:06.670 --> 00:07:07.870 Sorry, listeners. 00:07:07.870 --> 00:07:13.070 Yes it has been invented here in Prague the the concept of pooled mining we're 00:07:13.070 --> 00:07:16.910 basically the first Bitcoin mining pool in the world the concept has been 00:07:16.910 --> 00:07:20.720 discussed for a long time on BitcoinTalk so There have been more people 00:07:20.720 --> 00:07:26.380 interested in these things, but I would say the quality changer or the shift, the 00:07:26.380 --> 00:07:31.020 major shift was actually with introducing the Stratum protocol by Slush back in the day. 00:07:31.180 --> 00:07:33.980 So initially pools did not use Stratum at all? 00:07:34.200 --> 00:07:38.320 They were using the getblocktemplate and there were, I think there was one more 00:07:38.320 --> 00:07:38.820 mechanism. 00:07:39.140 --> 00:07:43.950 But getblocktemplate just... Well, it's an RPC call to Bitcoin Core and it gives 00:07:43.950 --> 00:07:48.110 you a block and then you can add, it basically puts all the transactions in there 00:07:48.110 --> 00:07:51.730 and you can add your own coinbase transaction that sends it to yourself. Right? 00:07:51.890 --> 00:07:54.750 That's what the thing does. But then how do you use that in a pool? 00:07:55.210 --> 00:08:00.170 Well, the pool was providing a little bit of abstraction about this, but it was 00:08:00.170 --> 00:08:05.530 not meant for thousands of machines connecting to it because there was no way to 00:08:05.530 --> 00:08:09.830 adjust the difficulty for it. You would be either getting spammed by all the 00:08:09.830 --> 00:08:15.350 shares from the machines or you would never see a share. And then the problem was 00:08:15.350 --> 00:08:19.150 that it was difficult to measure it. And then when you had to distribute the... 00:08:19.500 --> 00:08:24.580 the reward and there were issues associated with that. So conceptually, it was 00:08:24.580 --> 00:08:26.840 something that just did not scale at all. 00:08:27.020 --> 00:08:30.500 So the concept of shares was invented first, right? Because the idea of a share 00:08:30.500 --> 00:08:34.960 is that you try to produce a block, but instead of the actual difficulty, you 00:08:34.960 --> 00:08:39.060 take an easier difficulty. So you say like, okay, the block has difficulty 1000, 00:08:39.060 --> 00:08:43.300 I'm just picking a number. If you can produce a block with difficulty 10, we 00:08:43.300 --> 00:08:48.350 count that as 1% of effort. And somehow we track. And that's how you prove that 00:08:48.350 --> 00:08:51.310 you're actually putting in the effort. So you're sending all these blocks at 1% 00:08:51.310 --> 00:08:53.270 of the actual difficulty. 00:08:53.410 --> 00:08:58.130 And it's even more advanced in a way that, for example, pools specifically choose 00:08:58.130 --> 00:09:02.490 how often they want to see a share, like just statistically. So, for example, our 00:09:02.490 --> 00:09:07.530 pool is configured so that it gives difficult enough jobs to its miners so that 00:09:07.530 --> 00:09:10.430 they produce a result, let's say, every five seconds. 00:09:10.840 --> 00:09:15.100 So instead of saying, I want a certain percentage, you're saying, I want to see a 00:09:15.100 --> 00:09:18.180 share every five seconds and I'll make it easier for you if you can. 00:09:18.400 --> 00:09:22.620 This is correct. And this share that you submit has the value of the difficulty 00:09:22.620 --> 00:09:27.220 that I give you. So for example, if it's a weak miner given a difficulty one, 00:09:27.240 --> 00:09:32.660 because it's some USB stick, for example, those old Block Erupters, they were 00:09:32.660 --> 00:09:38.600 able to mine like difficulty one share in like 20 seconds, right? Which is far 00:09:38.600 --> 00:09:42.700 behind the expected performance. So you would see big variations in the hashrate. 00:09:42.800 --> 00:09:46.840 But these devices are no longer relevant. But to compare it, so these devices 00:09:46.840 --> 00:09:50.340 would be given, for example, difficulty one, and they would barely produce a 00:09:50.340 --> 00:09:54.060 share every 20 seconds. So they would get this one point in our accounting, 00:09:54.340 --> 00:09:59.960 whereas some ASIC has difficulty 8,000. So every share that they generate is 00:09:59.960 --> 00:10:04.740 8,000 points for them. So once the block is found, then you see the ratio of 00:10:04.740 --> 00:10:06.300 contribution to finding the block. 00:10:08.200 --> 00:10:11.740 So that was the problem that Stratum solved, is that you could not give every 00:10:11.740 --> 00:10:15.120 device its own target, essentially, its own difficulty target. 00:10:15.280 --> 00:10:20.140 Yes, this is exactly the added value that now it actually scales because the pool 00:10:20.140 --> 00:10:25.020 can protect itself from being basically DDoSed by the machines. 00:10:25.400 --> 00:10:29.020 And the DDoS risk is, I guess, but I mean, the pool could have just set the 00:10:29.020 --> 00:10:33.640 difficulty more high, but then the problem would be that the smaller miners can't 00:10:33.640 --> 00:10:37.310 participate anymore, right? So it's a trade-off between... making it accessible 00:10:37.310 --> 00:10:43.270 for anybody with a reasonable machine, but also not getting so many shares that 00:10:43.270 --> 00:10:46.860 the server gets overloaded. from the from the very fast machines right. 00:10:46.860 --> 00:10:51.860 And there was another aspect as well because it was essentially like request 00:10:51.860 --> 00:10:57.480 response based like HTTP kind of protocol originally so it was not that the 00:10:57.480 --> 00:11:01.240 miners were keeping a permanent TCP connections but the servers were also 00:11:01.240 --> 00:11:06.120 harassed by by by the miners like connecting disconnecting all the time just to 00:11:06.120 --> 00:11:10.320 get the job and to some of the result so so the the protocol itself the 00:11:10.320 --> 00:11:15.600 getblocktemplate stuff was not really meant for like scale mining it was just 00:11:15.600 --> 00:11:20.340 suitable for like your home own home setup let's say when back in the day when 00:11:20.340 --> 00:11:24.700 you didn't mind using pools but you were basically solo mining everybody at the 00:11:24.700 --> 00:11:30.000 beginning of Bitcoin history was pretty much solo mining on their CPUs then maybe 00:11:30.000 --> 00:11:35.560 GPUs and then at some point it became infeasible to to mine on your own and the 00:11:35.560 --> 00:11:38.840 reason being the probability of finding the block is still the same but what is 00:11:38.840 --> 00:11:44.440 stepping in is the variance because what some people don't know, it's good to 00:11:44.440 --> 00:11:49.560 repeat it, is that you mine… Bitcoin in blocks and they have the fixed value. You 00:11:49.560 --> 00:11:53.720 cannot mine one Bitcoin. The subsidy in the block is given by the protocol plus 00:11:53.720 --> 00:11:57.160 the transaction fees. Technically, I don't even know if you can set it to like 00:11:57.160 --> 00:12:01.980 one and see what would happen because it's below. So I don't want to refer to the source code. 00:12:02.020 --> 00:12:05.120 It would be possible, but it would be stupid. 00:12:05.300 --> 00:12:10.060 But generally, you mine it in blocks and that means that I cannot with a mining 00:12:10.060 --> 00:12:13.680 machine that's less performant, mine just a fraction and be happy with it. The 00:12:13.680 --> 00:12:17.960 only way to mine the fraction is to join the pool. with with all the computing 00:12:17.960 --> 00:12:22.160 resources and proportionally receive the reward based on the on the mined blocks 00:12:22.160 --> 00:12:28.160 of such a huge computing cluster and typically back in the day the the 00:12:28.160 --> 00:12:33.560 hashing power was rising really steeply every month and it became 00:12:33.560 --> 00:12:37.380 unfeasible for these solo miners so they were gathering in the pools and we were 00:12:37.380 --> 00:12:40.060 so we were one of the first we were the first Bitcoin mining pool 00:12:40.100 --> 00:12:44.580 and so let me see what did the name Stratum come from? 00:12:46.650 --> 00:12:52.450 Honestly, I don't know. I know the history that Electrum Wallet actually has some 00:12:52.450 --> 00:12:57.750 protocol, and I think the name was coming from there. But I'm not the original 00:12:57.750 --> 00:13:00.170 author of the Stratum V1 protocol. 00:13:01.320 --> 00:13:06.200 Okay, I think so far we discussed the concept of mining and how it works with 00:13:06.200 --> 00:13:09.660 shares and how Stratum sort of plays into that, but that doesn't cover all of 00:13:09.660 --> 00:13:14.700 Stratum, right? We haven't broken down everything that Stratum is or does, I think. 00:13:15.270 --> 00:13:19.310 I think the two things you mentioned so far is that it's able to give different 00:13:19.310 --> 00:13:23.190 difficulties to different machines and that it communicates with something a 00:13:23.190 --> 00:13:25.410 little bit more efficient than HTTP requests. 00:13:25.830 --> 00:13:29.970 Right. So this was the quality shift, but still there were some deficiencies in 00:13:29.970 --> 00:13:34.450 this protocol. So we have to realize that we're dealing here with like money 00:13:34.450 --> 00:13:39.750 printing or money generating machines. So even back in 2013, it was quite 00:13:39.750 --> 00:13:43.790 valuable not to make too many programming errors and lose the Bitcoin. For 00:13:43.790 --> 00:13:48.690 example, by mining to an invalid coinbase address or generating invalid shares 00:13:48.690 --> 00:13:54.410 because of one bit being flipped or reverse byte ordering or anything. So 00:13:54.410 --> 00:13:59.810 back in the day, it was actually a wise approach by Slush to 00:13:59.810 --> 00:14:05.650 come up with a protocol that would be easy to use and easy to debug. But 00:14:05.650 --> 00:14:11.630 here we are back in 21st century, where 2023, where the protocol 00:14:11.630 --> 00:14:17.410 still exists, but has like these tiny flaws in a way that it's not efficient 00:14:17.410 --> 00:14:21.490 because it's text-based. It was easy to develop with such protocol. You could 00:14:21.490 --> 00:14:26.050 technically telnet to your mining server and just talk to it and pretending 00:14:26.050 --> 00:14:30.170 you're a miner and you can easily verify that it's generating the proper jobs. 00:14:30.650 --> 00:14:34.950 Second part is that there have never been like an official central go-to place 00:14:34.950 --> 00:14:40.550 with a specification. Bits and pieces are on the Bitcoin Wiki. Some version of 00:14:40.550 --> 00:14:44.530 the protocol is published on our website, for example. And there are other 00:14:44.530 --> 00:14:50.120 sources of truth, let's say. That would be the least important problem. 00:14:50.300 --> 00:14:54.640 The major problem is that throughout the time, there were different flavors and 00:14:54.640 --> 00:15:00.100 dialects actually implemented, sourcing from the fact that even the manufacturers 00:15:00.100 --> 00:15:05.520 of the mining machines, eventually with the rise of ASICs, they were not able to 00:15:05.520 --> 00:15:11.110 go to one single place and implement the protocol correctly. Back in the day, I 00:15:11.110 --> 00:15:16.350 remember like regularly on regular basis in 2013, 2014, really tweaking the 00:15:16.350 --> 00:15:21.950 mining servers so that they're able to talk to these Stratum compatible ASICs 00:15:21.950 --> 00:15:25.650 because this was the time when new ASICs were being introduced to the market. And 00:15:25.650 --> 00:15:29.690 every now and then you would have some exotic version of the firmware that would 00:15:29.690 --> 00:15:33.530 not comply. And that's actually also the time when I was thinking like we should 00:15:33.530 --> 00:15:39.290 be providing also the firmware to eliminate this degree of freedom and potential 00:15:39.290 --> 00:15:43.690 issues. Because bad things could have been happening. Like if the machine is not, 00:15:43.890 --> 00:15:49.450 for example, rolling the timestamp properly, or if it's not doing something else, 00:15:49.530 --> 00:15:53.450 or if it's producing invalid shares, then somebody was actually wasting energy, 00:15:53.550 --> 00:15:57.890 right? Because these jobs cannot be acknowledged as valid or these shares. So 00:15:57.890 --> 00:16:02.170 this was one deficiency, not having like a central standard for it. 00:16:03.560 --> 00:16:08.740 The fact being text-based means quite a bit of inefficiency. A lot of text 00:16:08.740 --> 00:16:13.340 strings that represent different messages like mining.submit or mining.subscribe. 00:16:13.640 --> 00:16:18.510 mining.submit is probably the most... frequently cited piece of text on the 00:16:18.510 --> 00:16:23.110 internet in my view because it's like terabytes and terabytes of these strings 00:16:23.110 --> 00:16:24.910 being sent like every second. 00:16:25.090 --> 00:16:28.410 So mining.submit means like I'm here by sending a share. 00:16:28.650 --> 00:16:32.350 Yeah, it's me and mining.submit a bunch of stuff. That's not necessary. You can 00:16:32.350 --> 00:16:35.110 have one constant or use of standard protocol for this. 00:16:35.290 --> 00:16:36.890 Why is this a problem specifically? 00:16:37.270 --> 00:16:37.950 Wasting bandwidth. 00:16:40.270 --> 00:16:45.190 So there are use cases where you want to be a bit bandwidth savvy. And it's not 00:16:45.190 --> 00:16:50.030 just about the bandwidth, but it takes additional time that eventually at the end 00:16:50.030 --> 00:16:53.490 of the day, what that can mean is that your share is going to be considered 00:16:53.490 --> 00:16:57.990 invalid just in case you'll be racing against a block that has been just found in 00:16:57.990 --> 00:17:03.190 the network. So every little piece of inefficiency counts towards 00:17:03.190 --> 00:17:06.430 you not mining as efficiently as you could. 00:17:06.550 --> 00:17:11.230 Yeah, there's 600 seconds per block on average. yeah if you're wasting one second 00:17:11.230 --> 00:17:16.550 you're wasting one six hundredth of your revenue pretty much so seconds matter 00:17:16.550 --> 00:17:18.030 milliseconds matter 00:17:18.030 --> 00:17:21.290 yeah and one thing you haven't mentioned oh by the way just to make this clear 00:17:21.290 --> 00:17:26.000 it's always good to sort of break it down to the basics Stratum the people 00:17:26.000 --> 00:17:30.080 running Stratum so it's the mining pool it has a server and then you mentioned 00:17:30.080 --> 00:17:34.120 the actual miners or sometimes called hashers they have it on their machines and 00:17:34.120 --> 00:17:37.700 these machines talk with the servers so they are using Stratum and what you 00:17:37.700 --> 00:17:41.940 mentioned is that because it's not even strictly standardized sometimes they 00:17:41.940 --> 00:17:44.760 don't really communicate well that's what you're saying right that's one of the 00:17:44.760 --> 00:17:45.500 problems that 00:17:45.500 --> 00:17:49.480 that's that was that was one of the problems back in the day nowadays I don't 00:17:49.480 --> 00:17:54.580 remember a single issue because I mean Once the protocols got stabilized, 00:17:55.060 --> 00:17:59.400 I would say like everybody's kind of scared of touching it. So the manufacturers 00:17:59.400 --> 00:18:04.520 don't make any changes in the CGMiner code base for this. And the pools already 00:18:04.520 --> 00:18:08.600 have implemented all these hacks for all the different flavors of the firmware. 00:18:08.820 --> 00:18:13.240 So not too many issues arise now, but really back in the day, it wasn't a month 00:18:13.240 --> 00:18:16.540 where we would have to deal with some farm, like not being able to submit shares 00:18:16.540 --> 00:18:19.020 or something like this to accommodate for this. 00:18:19.160 --> 00:18:24.120 You mentioned CGMiner. from what I remember that's the mining software that was 00:18:24.120 --> 00:18:29.840 used on GPUs or even on CPUs and it was just shoved into ASICs and adjusted to 00:18:29.840 --> 00:18:31.400 live inside an ASIC right 00:18:31.400 --> 00:18:36.620 maybe a description of like that residing in an ASIC is not very precise but yes 00:18:36.620 --> 00:18:42.310 so this was the This was and is still the mining software being used by 00:18:42.310 --> 00:18:45.910 most of the manufacturers. This is the software that they actually violate the 00:18:45.910 --> 00:18:46.690 GPL on. 00:18:46.850 --> 00:18:48.750 I was going to say, because wasn't that open source? 00:18:48.970 --> 00:18:50.530 It is open source. 00:18:50.550 --> 00:18:56.550 Back in the day with Antminers S9s, Bitmain was still publishing the sources for CGMiners. 00:18:50.570 --> 00:18:51.190 Or GPL even. 00:18:56.670 --> 00:19:00.750 So technically you could have put together your own firmware with like all the 00:19:00.750 --> 00:19:04.370 different bits and pieces, but it required quite a bit of skills. So it was not 00:19:04.370 --> 00:19:09.870 like... Git clone and just run some build. Because there are a few 00:19:09.870 --> 00:19:13.130 components to the firmware. It's not just the software because you have to think 00:19:13.130 --> 00:19:18.170 of the ASIC as a full computer. So it has a control board with a CPU that's 00:19:18.170 --> 00:19:21.850 driving these ASICs. There's an additional component between the ASICs, but I'm 00:19:21.850 --> 00:19:26.650 getting into too many details here. So it's a complex system. You can think of it 00:19:26.650 --> 00:19:30.450 as a full operating system image with a dedicated software for mining that is 00:19:30.450 --> 00:19:36.400 called CGMiner. Back in the day in 2019, we started developing our own for 00:19:36.400 --> 00:19:40.140 various reasons. One primary reason was that we wanted to be independent of the 00:19:40.140 --> 00:19:44.800 original CGMiner code base. We wanted to do in a modern programming language, 00:19:44.960 --> 00:19:49.640 which C is no longer considered to be the modern programming language. And last 00:19:49.640 --> 00:19:54.510 but not least... We wanted to have some kind of like business advantage or edge 00:19:54.510 --> 00:19:58.950 towards compared to our competition. So having something that has been fully 00:19:58.950 --> 00:20:04.090 built in-house from scratch, not violating any licenses, that's sort of where we 00:20:04.090 --> 00:20:04.730 were headed with that. 00:20:05.920 --> 00:20:10.520 Okay. And also, so to take a small step back again, we just mentioned that the 00:20:10.520 --> 00:20:13.720 mining pool is running Stratum and then the machines are running Stratum and 00:20:13.720 --> 00:20:14.760 they're talking with each other. 00:20:16.320 --> 00:20:20.460 Before we get lost in the details, so who does what exactly? I think Sjors kind 00:20:20.460 --> 00:20:24.040 of explained this. Basically, the server does everything. The server constructs 00:20:24.040 --> 00:20:28.420 the entire block, includes all the transactions, creates everything, except for 00:20:28.420 --> 00:20:32.980 the nonce. So the whole thing is then sent to the machine, and the machine is 00:20:32.980 --> 00:20:35.700 just trying different nonces until it finds a [unclear] block. Is that right? 00:20:35.940 --> 00:20:40.920 This is exactly how it works. A little bit more complicated fact is that there's 00:20:40.920 --> 00:20:43.900 not just the nonce, but there are additional fields in the block header that 00:20:43.900 --> 00:20:48.980 nowadays... Thanks to Stratum V1 extension to support ASICBoost. We don't want to 00:20:48.980 --> 00:20:52.840 get into the ASICBoost topic here. But it's an additional feature to make the 00:20:52.840 --> 00:20:57.180 machines run more efficiently. So they're iterating more fields in the block 00:20:57.180 --> 00:20:58.160 header than just the nonce. 00:20:58.200 --> 00:21:02.500 Yeah, to just quickly explain what the problem is here. If you have a CPU and the 00:21:02.500 --> 00:21:05.060 nonce field is, I think it was eight bytes or something. 00:21:05.300 --> 00:21:06.020 It's four bytes. 00:21:06.180 --> 00:21:10.300 It's four bytes. So four bytes is not a lot of combinations. And so if you're 00:21:10.300 --> 00:21:14.160 really fast, you can make more combinations. And then there's no point in trying 00:21:14.160 --> 00:21:17.400 the same combinations again because you've already tried those. So you have to 00:21:17.400 --> 00:21:20.570 change something else about the block. And one thing that changes every second is 00:21:20.570 --> 00:21:24.510 the timestamp but you're still going to be too fast and so you want to change 00:21:24.510 --> 00:21:29.310 some other fields in the header and even in the coinbase transaction in order to 00:21:29.310 --> 00:21:31.950 keep up in order to try enough variation essentially. 00:21:31.950 --> 00:21:37.290 Okay I'm gonna pull us back from the weeds again So one of the problems that we 00:21:37.290 --> 00:21:41.630 haven't mentioned yet, you mentioned a couple of problems in efficiency and 00:21:41.630 --> 00:21:45.910 non-standard protocol. One of the big problems, one of the ones that people are 00:21:45.910 --> 00:21:51.450 talking about a lot, is potential censorship. So because the mining pool is doing 00:21:51.450 --> 00:21:55.590 all the transaction selection, that means that the mining pool can potentially 00:21:55.590 --> 00:21:59.990 make sure that some transactions don't make it into the block, right? 00:22:01.160 --> 00:22:05.680 That is correct. So if you want to talk about the new protocol, we tried 00:22:05.680 --> 00:22:11.000 addressing it by protocol or sub-protocol extension that we call job negotiation. 00:22:11.300 --> 00:22:17.000 And essentially what that means is that the miner is able to generate his own 00:22:17.000 --> 00:22:21.920 block template and he only negotiates in an asynchronous way. So essentially he 00:22:21.920 --> 00:22:25.740 generates a template and starts mining on it right away. And in the meantime, he 00:22:25.740 --> 00:22:29.540 can negotiate with the pool if the pool considers this template valid. Because 00:22:29.540 --> 00:22:35.450 let's say... a rogue miner who would try to attack the pool would generate 00:22:35.450 --> 00:22:40.490 a block template that would mine the coinbase into his own pocket. But obviously 00:22:40.490 --> 00:22:44.550 from the pool perspective, this is not a fair game. So even though he would be 00:22:44.550 --> 00:22:47.950 submitting the shares, eventually it would be reflected in the pool accounting as 00:22:47.950 --> 00:22:53.870 invalid by the time such template is created. But there is another reason, not 00:22:53.870 --> 00:22:58.010 just because of pool censorship. If we find out that some pools are doing 00:22:58.010 --> 00:23:01.990 censorship, you always have the option because there's more than just one or two 00:23:01.990 --> 00:23:06.130 pools in the world. You can switch over to another pool that would not be doing 00:23:06.130 --> 00:23:11.710 these. immoral things let's say but the protocol is trying to get ready for 00:23:11.710 --> 00:23:16.830 future in case we would have some kinds of regulations stepping in basically 00:23:16.830 --> 00:23:22.710 forcing the legal entities behind the pools who are running the pool services to 00:23:22.710 --> 00:23:27.770 not select the transactions like let's say it would become illegal it would be it 00:23:27.770 --> 00:23:32.810 would require like additional certification or whatever regulations knowing the 00:23:32.810 --> 00:23:37.470 customers whatever And in that case, the pool would say we're just providing a 00:23:37.470 --> 00:23:42.110 data service and leaving the responsibility, even like the legal responsibility, 00:23:42.330 --> 00:23:45.830 up to the miners. It would be their choice. If they want to mine with this 00:23:45.830 --> 00:23:49.850 particular pool, they have to choose their own transactions. And we would just do 00:23:49.850 --> 00:23:55.830 the validation that the block itself is valid, but not giving them the full 00:23:55.830 --> 00:23:58.510 templates. So this is sort of like getting ready for the future. 00:23:59.450 --> 00:24:01.730 So I hear there are some tokens involved here. 00:24:03.450 --> 00:24:07.270 But I'll explain it, I guess. So the idea is that when you propose a template to 00:24:07.270 --> 00:24:12.350 the pool and they approve it, then you get a token that basically proves that 00:24:12.350 --> 00:24:15.350 they approved your template. And my understanding is the point there is that 00:24:15.350 --> 00:24:19.240 eventually you're going to get paid for the shares you submitted. And so the only 00:24:19.240 --> 00:24:23.480 way the pool can enforce that you don't create a block that they don't like is by 00:24:23.480 --> 00:24:28.960 not paying your shares and vice versa. If your thing was approved, then you 00:24:28.960 --> 00:24:32.740 should be getting paid for that. So then if they're somehow not paying you out, 00:24:32.880 --> 00:24:35.560 even though they approved your share, you have a little signed message saying, 00:24:35.620 --> 00:24:40.120 hey, the pool approved this template and they didn't pay me. So you can make some 00:24:40.120 --> 00:24:40.820 noise about it. 00:24:41.580 --> 00:24:44.360 So you can prove it to other miners and they will leave the pool. That's the idea? 00:24:45.650 --> 00:24:51.410 That's also the case. I mean, like the actual business scenario or the 00:24:51.410 --> 00:24:57.410 full process is not prescribed by the protocol. The actual policy is to 00:24:57.410 --> 00:25:00.910 be set between the miner or terms and conditions or business terms and conditions 00:25:00.910 --> 00:25:04.130 are to be specified between the miner and the pool. 00:25:04.720 --> 00:25:05.160 Right. 00:25:05.300 --> 00:25:08.860 So this is one way you could use it, but the protocol doesn't care how you use it. 00:25:08.860 --> 00:25:13.260 No, not really. There's more complicated stuff associated with that. And that 00:25:13.260 --> 00:25:17.220 relates to the fact like how you want to do the accounting. Because let's say you 00:25:17.220 --> 00:25:22.200 would be a miner who would be in favor of empty blocks as an extreme example. But 00:25:22.200 --> 00:25:27.170 that's probably the one that's really on the left side. But this can happen. Such 00:25:27.170 --> 00:25:32.990 a miner, if it's a major player on the pool, is essentially lowering the rewards 00:25:32.990 --> 00:25:38.470 for everybody else because the rewards are split in a proportional way. 00:25:38.650 --> 00:25:44.210 So there is no reason for somebody in the game to systematically 00:25:44.210 --> 00:25:48.690 lower the rewards for anybody else unless he has some special incentives. So that 00:25:48.690 --> 00:25:52.650 means the pool has to reflect this in their accounting and also depreciate the 00:25:52.650 --> 00:25:56.670 value of the shares that you're submitting because you're... for whatever reason 00:25:56.670 --> 00:26:00.530 you have a motivation you have you're submitting something that eventually ends 00:26:00.530 --> 00:26:05.510 to or leads to a block that would be less valuable than your your neighboring 00:26:05.510 --> 00:26:07.070 miners with uh... 00:26:07.070 --> 00:26:10.390 so if somebody submits a template that has very few transactions in this… 00:26:10.390 --> 00:26:12.650 [unclear] zero as as a good example. 00:26:12.650 --> 00:26:16.050 Yeah so you don't necessarily have to reject it you just say well okay, that's 00:26:16.050 --> 00:26:17.530 fine but your shares are gonna be worth less. 00:26:17.530 --> 00:26:21.730 Now, not worth less but less. that's gonna be worth less yeah 00:26:23.400 --> 00:26:27.800 Okay, so we've been jumping a little bit between V1 and V2, which is fine, but I 00:26:27.800 --> 00:26:32.420 do want to clarify. So yeah, the difference was that miners used to construct the 00:26:32.420 --> 00:26:36.940 whole block with all transactions. No, sorry, the pools did. And then the miners, 00:26:37.120 --> 00:26:41.720 the hashers, the machines just made an answer. And then with V2, now the machines 00:26:41.720 --> 00:26:43.860 can do that. But it's optional, right? 00:26:43.860 --> 00:26:49.300 It's an optional feature of the protocol to be implemented by the pools. And on 00:26:49.300 --> 00:26:52.500 the miner side, it requires running additional piece of infrastructure as well. 00:26:52.850 --> 00:26:56.790 Right. Was this the main motivation for creating V2? 00:26:57.390 --> 00:27:02.310 The main motivation for creating V2, from my perspective or from our perspective 00:27:02.310 --> 00:27:06.390 as Braiins, was that we want to solve our own problem. And the problem was that 00:27:06.390 --> 00:27:11.150 we developed the mining firmware back in the day. And when we wanted to have the 00:27:11.150 --> 00:27:16.110 commercial extension, our business model was that we were collecting part of the 00:27:16.110 --> 00:27:21.920 hash rate in form of a fee, right? Like 2.5% was the fee. But there was no secure 00:27:21.920 --> 00:27:26.920 way how to ship this hashrate to our endpoints. So we looked at the current 00:27:26.920 --> 00:27:30.840 protocol and we're like, this is not usable. Even if you build TLS on top of it 00:27:30.840 --> 00:27:34.220 or whatever, it just doesn't make sense. It doesn't have standard and anything. 00:27:34.380 --> 00:27:39.240 So we just sat down and came up with a draft of a protocol that would address 00:27:39.240 --> 00:27:43.720 these three aspects, not speaking of the job negotiation, because that was not 00:27:43.720 --> 00:27:46.380 the use case that we really shoot it for primarily. 00:27:46.820 --> 00:27:49.520 So job negotiations is what we just discussed? 00:27:49.710 --> 00:27:54.190 Yes, this is what we just discussed. But we wanted to address the security of the 00:27:54.190 --> 00:27:58.570 protocol. So no more plain text. Everything has to be encrypted and signed. 00:27:58.790 --> 00:28:02.370 So there's two aspects to being plain text, right? Writing everything out loud 00:28:02.370 --> 00:28:06.570