[00:00.660 --> 00:06.240] So I would like to introduce Francisco Cabanas, otherwise known as ArcticMine. He is on the [00:06.240 --> 00:11.280] Monero core team. He's going to be speaking with us about the economic impact of COVID-19 [00:11.280 --> 00:15.480] and transaction capacity and fees in Monero. So I'm going to go ahead and pass that on over to [00:15.480 --> 00:20.740] him. ArcticMine, go ahead and take it away. Thank you. Thank you for the great introduction. [00:21.020 --> 00:28.820] So the topic that I'm going to be speaking today is about drastic external impacts [00:28.820 --> 00:33.920] on the Monero network, high response, and what kind of impacts they would have. [00:34.160 --> 00:39.640] Now, the initial scenario that I'm looking at, we're going to have a scenario, [00:39.640 --> 00:45.400] and then we're looking at the aftermath, what happens. So you throw a disruption, aftermath, [00:45.400 --> 00:49.560] what happens if you don't change the protocol, have a proposal, implications of the proposal, [00:49.560 --> 00:57.920] and then some questions and discussion. So what actually started the scenario was an issue raised [00:57.920 --> 01:06.460] by user Yukoi HB, and actually a very important issue. And I'm going to quote what he said, [01:06.460 --> 01:11.080] and this is quoting straight from the GitHub issue. Imagine adoption humming along and the [01:11.080 --> 01:16.540] long-term median gets really high, say 100 times the current default penalty-free zone. [01:16.740 --> 01:23.200] Suddenly, catastrophe hits, and several major sources of transaction volume are taken offline. [01:23.200 --> 01:28.860] Short-term transaction volume collapses to five times the default penalty-free zone, [01:28.860 --> 01:35.000] and nominal fees are practically 20 times higher. Now, the scenario we're talking about is about [01:35.000 --> 01:44.720] 1,000 times of the transaction activity in Monero. This came up in February, just before the awareness [01:44.720 --> 01:52.780] of COVID-19. And then within a few days after the issue came, the start of the awareness of COVID-19, [01:52.780 --> 01:58.300] which is actually a perfect example for the issue. Pandemics was not referred in the particular [01:58.300 --> 02:05.520] issue, and I have a link below to GitHub for the research project issue, and I would suggest that [02:05.520 --> 02:10.180] there we could do a lot of also discussion on some of the technical solutions. [02:12.100 --> 02:18.720] Now, Monero has a long-term median, and it changes every... it's 100,000 blocks, [02:18.720 --> 02:24.660] so it changes up to 50,000 blocks, and that's around 69 days. It's about a couple of months [02:24.660 --> 02:32.780] and a week. And this is an important time frame to consider, because what's happening here is that [02:34.720 --> 02:39.740] at that point in time, it changes, and it's a scenario, and it has very significant impacts. [02:39.880 --> 02:46.020] And we're going to look at possible causes of an external disruption. Now, for example, [02:46.020 --> 02:50.680] one of the measures is a disruption of various Monero markets that believe in the issue. One [02:50.680 --> 02:55.560] of the issues that was mentioned was, for example, a closure of a very big [02:56.320 --> 03:05.420] DNN market, and what impact that would have on transactions. And then this category, I would say, [03:05.420 --> 03:12.480] is an impact that doesn't impact the traditional finance system. The second group that I'm [03:12.480 --> 03:18.440] including, which impacts on the international finance system, would be things like COVID-19, [03:18.440 --> 03:22.280] and the awareness that you have of the issue. The issue I should discuss, the possibility was [03:22.280 --> 03:27.060] of a limited nuclear war, and the kind of consequences of that, national disaster, [03:27.060 --> 03:32.760] major economic disruption. What we're talking about here is events, external events, [03:32.760 --> 03:39.800] that cause major economic disruption, and how that will impact the Monero network, [03:39.800 --> 03:47.220] and also, in particular, how will it impact the fee structure, and how we can respond to it, [03:47.220 --> 03:53.800] and some changes that are needed to do that. Now, the next slide is really interesting, [03:55.360 --> 04:03.540] because we are considering a very sizable series of scenarios. One thing I should mention in the [04:03.540 --> 04:10.960] previous slide, the numbers we're talking about will have a very high fee, sorry, a very high [04:10.960 --> 04:17.260] price on Monero. So there's no recovery, or a very long, slow recovery. So this is where [04:17.820 --> 04:24.020] you see the collapse in transaction rates, and it just sort of dies there, and nothing happens, [04:24.020 --> 04:27.840] and maybe a few years down the road starts to recover again. And the DNM market is a good [04:27.840 --> 04:34.620] example of that. And so in that case, you basically have, in that scenario, [04:35.240 --> 04:38.380] relatively little impact on the network, you do have the fee impact. [04:39.080 --> 04:43.040] The next one is a recovery within the long-term median, and that means that [04:43.040 --> 04:51.040] you drop, and then you come back up again within the 69-day time frame. And that means that the [04:51.040 --> 04:55.660] recovery level for transactions within the Monero network is really only five times, [04:55.660 --> 05:01.120] could be as high as five times. And then the third example is we start a long-term median, [05:01.120 --> 05:05.320] and it collapses completely, and then we are going back, we have to recover [05:05.320 --> 05:10.640] the full 20 times in the example, plus, say, an additional five times. [05:10.680 --> 05:17.700] The key to understand is this, an impact of the event on traditional finance. So if it impacts [05:17.700 --> 05:22.180] the banking system, if it impacts financial, can also have a significant impact on transaction [05:22.180 --> 05:28.420] demand, and this is going to show up in the recovery phase. So when we're trying to come out [05:28.420 --> 05:32.480] of this, all of a sudden everybody wants to use Monero because there's problems in the banking [05:32.480 --> 05:38.480] system. So not only do we have to deal how we get the median back up again to where we were, [05:38.480 --> 05:42.620] but now we have all this additional demand because the other guys are having problems. [05:45.270 --> 05:47.030] So let's look at the examples. [05:49.170 --> 05:55.510] Let's say that there's no impact on traditional finance. So in this example, [05:55.510 --> 05:59.990] this interruption of the Monero markets, the likely result is no recovery. [06:01.150 --> 06:07.450] So it's a long process. So basically, you have replacing markets come up, even a possible [06:07.450 --> 06:13.350] negative impact. You basically have a long recovery, and nothing particularly happens in [06:13.350 --> 06:19.910] this scenario that really requires a lot of impact on the protocol, except for the fee question. [06:22.010 --> 06:26.370] Let's look at the COVID-19 example. This is a great example of the external [06:27.150 --> 06:32.930] scenario. So what are we looking at here? Well, either it's going to recover right within the [06:35.150 --> 06:40.070] two months to 69 time frame, in which case, and then you get the demand, [06:40.070 --> 06:49.710] or maybe it's a bit delayed. And then you have the full collapse in the long-term medium, [06:49.710 --> 06:55.470] and this is critical. And then you have to make up not just 20 times the transaction, but maybe [06:55.470 --> 07:01.110] 100 times. So you really have a big upswing afterwards. You suddenly have to ramp up the [07:01.110 --> 07:06.110] whole network, not just because of the impact, but now because everybody else wants to use Monero [07:06.110 --> 07:10.290] because there's a problem somewhere else. And that's the key distinction when you're impacting [07:10.290 --> 07:19.770] traditional finance. So the other two examples, the limited nuclear war or the... do parallel [07:19.770 --> 07:25.470] this in a similar way, or can parallel it, as it will be, say, a very disruptive volcanic eruption, [07:25.470 --> 07:32.210] this kind of things, can actually have a similar impact economically, and the parameters are [07:32.210 --> 07:36.790] comparable. I will focus primarily on COVID-19 simply because we're living right through it. [07:36.790 --> 07:44.970] This is a perfect example of the type of scenario. So we step back for a moment and ask the question, [07:44.970 --> 07:51.390] what exactly did COVID-19 do to the Monero network? Well, what did it have... did the [07:51.390 --> 07:57.730] standard Monero stop functioning? Well, no. Did the blocks stop being mined? No, the miners shut down. [07:57.730 --> 08:03.170] No. Did the developers shut down? Did the functionality of the community shut down? [08:03.170 --> 08:07.870] To most extent, no. The only thing, basically, we're seeing a significant impact is the fact that [08:07.870 --> 08:12.510] we're delivering these stocks virtually. We did have to cancel Confranco in Berlin. [08:12.690 --> 08:20.610] So we had some impact, but relatively minor. The core components of the community, [08:21.010 --> 08:26.190] of the network, the clearance of transactions, all this happened, no problems. [08:26.870 --> 08:33.870] Now, compare that with the banking system. Bank hours were changed, bank branches were closed, [08:33.870 --> 08:38.470] lineups outside, people wearing masks, plexiglass screens on the tellers. [08:38.770 --> 08:45.730] When you look at the impact, they're way more significant. We take a look at payments. Well, [08:45.730 --> 08:51.190] the biggest one, actually, is that we've been in card payments, an increase from [08:51.770 --> 08:57.330] in card type and a drastic fall in chip and PIN. So there's been this movement in the type of [08:57.330 --> 09:03.070] credit card transaction. There's been some drop in cash. Part of the idea being is that certain [09:03.070 --> 09:09.550] types of payments are perceived to be propagating the COVID-19. And obviously, if you're sitting on [09:09.910 --> 09:14.910] a pin pad and inserting a card and fiddling with the terminal and touching all the absolute tips [09:14.910 --> 09:19.790] of your fingers, your chances of spreading the virus are much higher than if you just [09:20.310 --> 09:26.270] bring the card to the terminal and don't touch anything. And this is a so-called contactless [09:26.270 --> 09:31.310] card tap. The reality, however, is in a lot of card taps, there's still a lot of fiddling. [09:31.750 --> 09:35.270] And merchants expect you to touch buttons. And I have actually refused to do that. It's quite [09:35.270 --> 09:40.990] interesting. And so that's one element. Then there's cash, which is kind of in between, [09:40.990 --> 09:48.490] obviously better, worse than a totally contactless card tap, but far better than chip and PIN. [09:49.250 --> 09:54.110] And in this picture, you consider a cryptocurrency payment. Now cryptocurrency payment, [09:54.110 --> 09:57.930] in order to use it, you have to be contactless, because basically what you're doing is you're [09:57.930 --> 10:01.030] aligning QR codes. So you've got your phone, you're going to align the QR code, you're going [10:01.030 --> 10:05.770] to do it at a distance. It does not work if you touch it. So this is really interesting. [10:05.770 --> 10:09.870] If you want to pay with Monero, you can't propagate the virus. You have to go out of [10:09.870 --> 10:17.720] your way to do it. With the other payments, you can't. Well, the other ultimate best. Well, [10:17.720 --> 10:22.680] major unemployment, business failures. You walk around the city, all these businesses are [10:22.680 --> 10:27.200] closing. Massive increase in government debt. Governments have responded to the problem by [10:27.200 --> 10:34.040] going into debt and trying to mitigate the impacts. And a massive intervention by the [10:34.040 --> 10:41.160] central banks on increasing the money, the fiat money supply. This is mitigated. It's fine. It's [10:41.160 --> 10:47.540] mitigated to some degree, but it also has long-term implications. One major impact, obviously, is if [10:47.540 --> 10:52.080] you increase the number of unemployed people, you're going to disrupt car payments. And the [10:52.080 --> 10:55.440] reason you're going to do that is because people are going to suddenly lose their credit scores, [10:55.440 --> 10:58.700] and they're not going to be able to have credit cards, or they're going to be afraid that their [10:58.700 --> 11:03.880] debit account in the bank is going to be seized. So there's going to be a push towards cryptocurrencies [11:03.880 --> 11:09.360] just from this element. I don't even want to consider what could possibly happen if [11:09.360 --> 11:13.480] it's a major disruption of the banking system, and we still haven't got to that stage. [11:14.720 --> 11:20.760] Everything is kind of okay, maybe. The Federal Reserve and the European Central Bank, [11:20.760 --> 11:25.920] the Bank of England, the Bank of Canada, they're trying a very delicate job between hyperinflation [11:25.920 --> 11:31.260] on one side and collapse of financial institutions on the other. It's a delicate position. I honestly [11:31.260 --> 11:36.180] would not want to be in their shoes for what they're doing. It's a lot easier dealing with [11:36.180 --> 11:44.080] the Monero side of this. So one possible impact is a significant shift towards the use of [11:44.080 --> 11:50.120] cryptocurrency in payments. And this would be way greater in the original scenario, but could [11:50.120 --> 11:55.280] even occur in the current situation. So what you can see is that there's a demand on the Monero [11:55.280 --> 12:02.020] network, even as it is right now. And in many ways, this is a bit of a warning. And if something [12:02.020 --> 12:07.580] were to happen with the Federal Reserve and the banking system, something were to happen, [12:07.580 --> 12:12.200] even in a smaller country, we could suddenly face ourselves with significant demand on transaction. [12:13.180 --> 12:18.920] The story is not being ended on this. So we still have the possibility of the risk [12:19.360 --> 12:23.200] of having to deal. And that means at every level. Everything from helping newbies on how to [12:23.200 --> 12:28.740] set up their wallets, to making sure your notes are up to snuff, to cleaning, [12:29.300 --> 12:35.680] upgrading your internet connection. I mean, the reality is we could find ourselves having to roll [12:35.680 --> 12:40.360] up our sleeves at every level in the community. Just as the result is just because of these [12:40.360 --> 12:47.440] disruptions, there's suddenly a big demand on the network. So now let's take a look at what happens. [12:48.140 --> 12:52.240] No changes to the protocol. So we look at the protocol right now. First of all, in this scenario, [12:52.240 --> 12:58.520] and it's very important, we're doing a thousand times increase in the Monero transaction volume, [12:58.520 --> 13:05.120] because basically we are running right now about a tenth of the penalty free zone. So we're talking [13:05.120 --> 13:13.170] about basically 30 megabytes versus 30 kilobytes that we have today in transaction volume. [13:14.300 --> 13:19.100] One of the implications of this is if you look at the equation of exchange [13:19.800 --> 13:23.750] and you make some reasonable assumptions, and no change in velocity, [13:25.790 --> 13:33.670] and a constant, then we're talking about a potential price for Monero of around 100,000 [13:33.670 --> 13:38.650] US dollars. This sounds significant, but if you're going to increase the transaction [13:38.650 --> 13:46.650] capacity demand of the Monero network by a factor of a thousand, and it's fair to realize that [13:47.350 --> 13:52.750] assuming the velocity doesn't change and it hasn't come from somewhere, and the distribution [13:52.750 --> 13:59.990] doesn't change, so obviously the only thing you can move is the price. So now if you increase Q [13:59.990 --> 14:04.370] by a factor of a thousand, you've got a decreased P by a factor of a thousand, which is the inverse. [14:04.370 --> 14:09.010] So effectively what we say instead of $100, it's $100,000. Now there's variability. It could be [14:09.010 --> 14:14.630] $10,000, it could be a million, but there is definitely a factor here. And quite honestly, [14:14.630 --> 14:19.430] I mean, if a whole bunch of people are transacting the Monero network to that level, then there's [14:19.430 --> 14:23.990] also be a lot of investors are suddenly going to be interested in this cryptocurrency that's [14:23.990 --> 14:29.930] actually working and that you can actually use. To put it in another way, you have a practical [14:29.930 --> 14:35.930] use scenario in place. The thing to understand is the fee in current terms will not change [14:35.930 --> 14:43.090] significantly. So our fees would be roughly a bit higher, and this is mainly due to the fact [14:43.090 --> 14:49.130] that we still have the ten-fold increase until we get to the penalty-free zone, which has an impact [14:49.130 --> 14:55.190] on fees. And it's counterbalanced by things such as a drop in the emission-cum-to-tail emission. [14:55.510 --> 15:01.790] And we're going down to also some of the improvements such as CLSAG and so on. [15:02.330 --> 15:07.130] So that's kind of what... so we're talking about $0.04 USD for two-in-two-out transaction, [15:07.690 --> 15:11.570] even though the price has gone up by a factor of a thousand. That's one of the beauties of the [15:11.570 --> 15:18.230] Monero protocol. As you increase the block size, the fee for transaction goes down. So if you have [15:18.230 --> 15:22.310] this assumption, you have essentially a constant fee, close to a constant fee, in terms of [15:25.690 --> 15:30.490] a sort of fixed USD. By the way, I'm talking about USD as of today, so you sort of factor [15:30.490 --> 15:37.110] in any changes in the inflation rate. So what happens if you don't change the protocol? Well, [15:37.110 --> 15:41.550] okay, so the 20% increase in fee, this really goes from, say, $0.04 or $0.80, you'll see. [15:42.190 --> 15:47.970] And the interesting thing there is, the issue can be really disruptive if you have [15:48.830 --> 15:54.450] multi-signature transactions that are created ahead of broadcast. So for example, you create [15:54.530 --> 15:59.270] a transaction, you have multiple signatures, you engage in some business arrangements, [15:59.270 --> 16:03.610] and then like three weeks later or five weeks later or something, you want to [16:03.610 --> 16:08.090] broadcast that transaction, and now the fees have changed on you. And that was one of the [16:08.090 --> 16:11.370] main factors in the protocol question. I mean, you know, how do we deal with these situations? [16:11.370 --> 16:16.410] And that's the fee impact question. So there's a real need for minimum fee predictability for [16:16.490 --> 16:21.330] a given period of time. And as I said, the free impact applies to all three recovery scenarios. [16:23.270 --> 16:27.950] So the white economy, where you have first number one, no recovery, very slow recovery, [16:29.230 --> 16:32.570] the recovery is fine. I mean, there's no real stress on the protocol, [16:32.990 --> 16:38.210] but the fee issue remains. We're just dropping it and we're not really suddenly putting more [16:38.210 --> 16:43.430] demands on the network. Now, in the second case, it starts to get a bit more interesting, [16:43.430 --> 16:50.230] because what happens there is you suddenly have a five times increase in demand scenario. [16:52.090 --> 16:58.090] So you're pushing your protocol. So you can kind of manage it, but it's far from ideal. [16:58.090 --> 17:02.690] You're pushing the limits of the growth rate of the long-term median, depending on the rate. [17:02.970 --> 17:06.430] So that's a bit tight, and you still have the fee issue. [17:06.930 --> 17:10.410] It's kind of possible, not ideal, but manageable. [17:12.530 --> 17:19.670] But the part serious problem is this one. What happens with the third example? Now you drop [17:19.670 --> 17:27.530] the long-term median by a factor of 20. So you drop down, and now to recover back again, [17:28.090 --> 17:34.870] you have to go into this two to three year period just to get back to where you were, [17:34.870 --> 17:39.490] and then also to then allow for the addition. It's just too slow to recover. So you don't have [17:39.590 --> 17:45.330] a recovery protocol. You drop, you can think of it as a big bang attack in reverse, [17:45.330 --> 17:50.230] where you actually suddenly drop the transaction, and it has real consequences. [17:50.330 --> 17:55.910] And this is actually a real serious problem that was identified in this issue indirectly, [17:55.910 --> 18:02.330] but definitely very good. So what are we going to do in the proposal? Well, number one, [18:02.330 --> 18:08.070] we increase the growth of the long-term median of 1.2x to 2x. That alone will address these kind [18:08.070 --> 18:13.650] of recovery issues to a significant degree. It's about 30 times versus five times in a year. So [18:13.650 --> 18:17.530] there's a real increase in the rate of growth, and that's important. [18:18.310 --> 18:25.530] It gives you that flexibility, that ability. Now there is a 50 plus factor in there for searching, [18:25.530 --> 18:30.510] but that's okay. B, and this is the critical part, you limit the decay of the long-term median to [18:30.510 --> 18:37.310] half. So what we say is, at the end of that 20-time drop, we don't drop the whole thing all [18:37.310 --> 18:43.130] down to 24, we just drop it to four. And then we wait another 69 days and drop it to four again, [18:43.130 --> 18:52.030] and so on. And then the third proposal was to set the penalty-free zone to the maximum, sorry, [18:52.030 --> 18:59.990] minimum to the maximum of the current 300,000 bytes and a quarter of the long-term median. [18:59.990 --> 19:05.230] Now, I have seen discussion of proposals that go higher than that, and they're quite interesting. [19:05.450 --> 19:09.710] In fact, one of the proposals, I think, has a similar implication to that. [19:09.890 --> 19:12.450] This should be discussed and looked at, because they're quite interesting. [19:12.530 --> 19:17.030] But this proposal basically involves a quarter of the long-term median. [19:19.540 --> 19:24.740] The next thing we do is we change the median and fee-for-no-relay. This is more of an anti-spam [19:24.740 --> 19:34.140] measure. The thing to bear in mind here is that if you have a series of transactions that are not [19:34.140 --> 19:39.020] minable, you can literally launch a DDoS attack against the network. So basically what you do [19:39.020 --> 19:46.380] is you flood the network with a mass of transactions which are under the not-going-to-get [19:46.380 --> 19:51.360] mind. And this is one of the reasons why you have a minimum fee. So that's the danger there. There [19:51.360 --> 19:58.280] is a potential attack in that, and that's the reason why you do that. You basically want to [19:58.280 --> 20:04.080] set that relay fee for the node so that there's a really good chance the transaction gets mined. [20:04.080 --> 20:09.900] Now, obviously, if you're sitting at one-tenth of the penalty-free zone, which we are right now, [20:09.900 --> 20:19.740] well, a fee of 20% of the reference transaction is going to get mined. So the attacker has a big risk. [20:19.740 --> 20:25.620] Once you go above it, it starts to get dicey, and you could get scenarios where this could actually [20:25.620 --> 20:32.860] happen. I should point out these attacks have actually occurred on Bitcoin. And if you run a [20:32.860 --> 20:40.480] full Bitcoin node, which I do, with the port open, and you suddenly see this massive surge in [20:40.480 --> 20:44.860] bandwidth, well, wait a minute, Bitcoin protocol is running at capacity. So why is this happening? [20:44.860 --> 20:49.300] These massive transactions that are being transmitted and distributed by the nodes [20:49.300 --> 20:55.260] which are not being mined because the fees are too small. And this type of attack could be done [20:55.260 --> 21:01.540] in Bitcoin to actually push up the fees. But it's exactly a similar kind of problem. So you do have, [21:01.540 --> 21:05.760] and it really has an impact on the node. Suddenly your bandwidth could increase by a factor of 10 [21:05.760 --> 21:10.900] or something just as a result of these type of attacks. And I have seen, I've experienced it [21:10.900 --> 21:15.640] myself, I wash my bandwidth, I have unlimited bandwidth and it can get away. But still, [21:15.640 --> 21:21.760] I mean, this is not true. So that's one of the reasons for this type of protection. [21:23.380 --> 21:28.860] A few technical changes with respect to the wallet fees. One of the things that's not well [21:28.860 --> 21:35.980] known about the wallet fees in Monero is that there is an adjustment where we try to shift [21:35.980 --> 21:40.540] the median by 10 blocks. And the idea is to assume the worst possible scenario so that if you [21:40.540 --> 21:44.480] create a transaction, it doesn't change fast enough that you can't send it because the [21:47.280 --> 21:51.260] structure of the median has changed and the fees have gone up. And so this is one of the ideas. [21:52.180 --> 21:58.260] And basically we have a series of fee schedules in there where we would have each level of fee [21:59.940 --> 22:05.660] is protected against changing the median. So the principle here is you keep paying a higher fee, [22:05.660 --> 22:09.960] you get more blocks. If you go all the way, you get like 200,000 blocks of protection, [22:09.960 --> 22:17.160] essentially by paying a higher fee. And the concept is that, for example, you simply say, [22:17.160 --> 22:22.240] okay, if I want just to send my transaction right away within 10 minutes, okay, fine, I go with a [22:22.240 --> 22:27.660] normal fee, the lowest possible fee. And if on the other hand, I wanted to be good for at least [22:27.660 --> 22:33.580] the balance of the short-term median, sorry, long-term median, then I would pay the next one. [22:33.580 --> 22:38.100] I want more, you know, another 100,000 blocks and I keep going up the line. [22:39.340 --> 22:43.080] So the implications are fees are highly predictable. For example, a fee of four [22:43.080 --> 22:46.320] times will ensure the minimum fee is minimal until the drop in the long-term median. [22:47.280 --> 22:50.660] And then you can examine the long-term median and actually predict the worst-case scenario. [22:50.800 --> 22:55.420] Or you can choose a fee all the way. But in reality, there's no free lunch. I mean, [22:55.420 --> 23:00.560] the longer you want to protect this, the more fee you pay. And I should point out, [23:00.560 --> 23:08.300] even increasing this penalty-free zone to something as high as the long-term median, [23:08.300 --> 23:12.440] which I suspect is one of the ideas behind the proposals, will mitigate this even further. [23:12.440 --> 23:18.040] But you still have this principle that the longer you go, you want to go the higher the fee. So if [23:18.040 --> 23:23.420] you want your fee to be minable, like, say, three months down the road, you're going to pay, or four [23:23.420 --> 23:26.840] months down the road, you're going to pay a much higher fee than if you just want to create the [23:26.840 --> 23:34.350] transaction and just send it right to the network. This is the critical impact of the [23:34.350 --> 23:37.990] project. You remove this risk of a sudden collapse of the long-term median. And this is the biggest [23:37.990 --> 23:43.470] issue that I identified. And that is, what happens is, if you let it collapse, then bingo, [23:44.410 --> 23:47.870] you have this massive recovery. Because if you drop all the way down, it could take like two [23:47.870 --> 23:51.550] to three years to get up there. And all of a sudden, in a couple of months, it collapses. [23:51.890 --> 23:57.430] And this is why having this graduated decline in the long-term median is very critical. [23:57.430 --> 24:02.270] And it does allow... this is probably the most critical approach. You do not want that [24:02.270 --> 24:06.430] long-term median to suddenly drop all the way from the top to the bottom. You want it to [24:06.430 --> 24:13.430] go down in steps, the same way it grew up in steps. There's minimal action in the absence [24:13.430 --> 24:16.670] of a sudden drop in transaction. And of course, the reason for this is that the dynamic penalty [24:16.670 --> 24:25.490] fee, so essentially, doesn't even come into play. And another interesting thing is that [24:25.490 --> 24:32.170] you could actually increase the rate to look at transaction growth. And I have a link here, [24:32.170 --> 24:35.510] and this should work. I'm going to link it here, and I'm going to show you the site. [24:36.530 --> 24:44.010] And you should see... there we go. Okay, so if I go on the link here, and I'll see the [24:45.530 --> 24:52.810] site. And you should see the site here on the screen. And basically, if you look at transactions, [24:53.730 --> 25:06.350] you're going to see that there is a very significant trend on the screen here. And again, [25:06.350 --> 25:13.930] we will see what we're seeing in this scenario. So I will close this out right now. This is come up. [25:15.550 --> 25:20.790] Yes, it comes up here, and we will then go out again. [25:23.010 --> 25:28.410] Okay, and we will close these out. [25:30.960 --> 25:36.220] There, and we should see the proposal again. So again, if you click on the link, [25:36.220 --> 25:45.160] you will see the transaction rates. And this is actually a way to see what happens if you actually... [25:47.360 --> 25:52.720] you can actually look at the transactions, and you can see basically what the trends are. [25:52.720 --> 25:57.000] What you'll find is that some of the recent trends are very close to the maximum rate of the [25:57.960 --> 26:06.660] long-term median. Okay, so now we are going to look at some implications again. [26:07.000 --> 26:12.320] If we increase the minimum relay fee, this mitigates against flood XMR types of attacks. [26:12.320 --> 26:17.820] Now, I started a second here, and I would say that flood XMR is potentially the bigger threat [26:17.820 --> 26:23.660] than Big Bang, simply because it's a motivation. Now, also flood XMR is easiest to mitigate, [26:23.660 --> 26:28.060] because what you do is you simply increase the... if you increase the ring size, then you turn [26:28.060 --> 26:33.720] around and you increase the cost to the attacker, and essentially relative to the defense. And [26:33.720 --> 26:41.940] that's a factor of the attack. But we've got to bear in mind that this minimum relay fee also [26:41.940 --> 26:47.160] mitigates against these types of attacks. I've included a link to the proposal specification [26:47.160 --> 26:50.920] here. And again, you can go to the... and take a look at it there. [26:53.440 --> 26:55.980] And I've been looking for some questions and discussion. [26:56.780 --> 27:01.720] So I will turn it back to the moderator if there's any questions that I need to answer, [27:01.720 --> 27:02.800] or any discussion.