 Okay, I have to clarify. I don't think I claim that we fixed transaction and reliability 100%. I think I said that we, in our hard fork, just as a bonus, some goodies, we threw in some things that fixed some longstanding problems. There's still more to do on that front, definitely, and there's a couple of great ideas on the board for fixing, making progress on fixing it without segwit. Okay, so I'm Tom Harding. I'm maintained between XT, which is one of those implementations that the Vinnie was talking about. Bitcoin XT is probably the embodiment of the maxim that if at first, second, third, and fourth, you don't succeed, keep trying to find a way to raise a block size limit, and it might eventually, you will eventually be rewarded. Today I'm going to discuss zero-conf transactions and what I'm determining, native-respend resistance, which is just the property that we're seeing and that we want to see more of, that Bitcoin Cash resists double-spends without needing a second-layer network or anything else. But how can we make that better and where exactly are we at right now? Thank you. So we have a rule called first scene. The first scene rule is simple. It means once a node has seen a transaction that spends a certain UTXO, it silently ignores any other unconfirmed transaction that spends that same coin. If nodes are honest, this strategy would completely solve the double-spend problem, but we simply ignore the double-spends with one small problem and that problem is timing. It's what, and this, it really gets to the very core of how Bitcoin functions as a consensus mechanism in those early first minutes. These are just some representations of first scene. I don't know if anyone even know what that thing on the left is. It's an egg being fertilized and an egg that gets fertilized instantly puts up a barrier. It doesn't let any other sperms come into it. That's how your nodes act. As soon as one transaction spends, it won't accept any others. And this is also, you know, I've seen my kids do that a lot. But what happens, given that we're dealing with finite speed of light and finite transmission speed, what happens if two spends are released into the network at exactly the same time? That is something to worry about. A tiny bit of history, because Satoshi did address this as sort of, oh, a thing we might want to think about in the future, and I put a link in there to it. He had a simple answer and a simple plan for maximizing zero-conf security. That doesn't mean making it as secure as confirmed transactions. For some reason, we weren't allowed for many years to ask how to maximize zero-conf security because we were told it'll never be as secure, so we have to break it completely. Luckily, we can now we're free to actually ask this question. But Satoshi's plan was that he said, well, when you see a new transaction, you receive money from someone. What you want to do is watch the network for a few seconds to make sure that it's not double spent. After a few seconds, it's going to be very likely that if a double spend comes after that, everyone will agree that it was not the first one. And it's a good plan, and it's one that you can quantitatively explore. One problem with his suggestion is even at that time, it relies on double spend relay, which doesn't exist, not on Bitcoin Core or on Bitcoin Cash. Hal Finney also went intriguingly a little further in a post about a year later, that where he talked about how you could have minor incentives to come after the fact and have minors incentivize each other to avoid mining an obvious double spend. I find that very, very interesting. Okay. So, first scene, this is a representation of first scene. What happens if two spends are released exactly the same time? If two transactions are released at exactly the same time, but in different places on the network, which one you saw first is random. And the network is going to act sort of like these streams of paint or the transactions being introduced at those points and then the paint spreads out and there's a pink zone and there's a yellow zone. And you're in one or the other. Part of the network will see what I call TX1 first and part will see TX2 first. Each node makes its own decision about which transactions should be kept and which ones should be silently dropped. The real network's not two dimensional like I showed here, but it may have dozens of connections to its peers but the proposition still holds. The network is partitioned into TX1 and TX2 believing factions. So, the question is whether the attacker, a double spender receives what he's paying for. He is one person that he's paying and there's the miner. So, the question is which part of the network are each of these two people in? There's two independent binary variables. The location of the person he's paying and the location of the miner. So, there's four things that can happen. Right here and do this. Okay, if they're both in the pink side, then that means both the miner, the person you're paying saw your first transaction and the miner also saw the first transaction and that's the one that pays the recipient. If both of them saw the double spend, then the recipient's not paid because he never sees a transaction that pays them. And the TX2 is also confirmed because the miner saw TX2. So, the guy just, TX2 pays himself, that's the double spend. TX1 is the one that pays the person who's supposed to get paid and TX2 is the miner. So, that's just a sort of a no op. And then it gets interesting. Skipping to the last one. The last one is the successful double spend, which is where the guy you're paying sees the thing that pays him but the miner sees the one that doesn't pay him and it ends up, you get your money back and because it's zero cost and someone handed you the goods right away, you got your value for the money. And the other one, this green situation is when you see the double spend and the miner sees, or sorry, the person that you're trying to pay sees the double spend, which he actually doesn't see it because he's not looking for it because it doesn't pay him, but that's the one his node sees. And you, and the miner mines transaction one, which means that the merchant actually does get paid but not until the block comes because he won't see that. What happens when a different transaction than the one that you saw previously as a node appears in a block, your node says, oh, okay, I guess that thing I had before was bogus. It tosses it out and keeps the one that got actually mined. So it's the, this suggests the attack is to simply, like a double spending wallet would, when you go to pay someone, you would click pay and then the wallet would send the payment but at the exact same time it would also send a different payment that pays himself and not the person that's waiting for the transaction somewhere else. And without optimizing any variables or anything else, there's a good chance, not a good chance, there's a chance that he will get that thing for free because the miner will see the other version. So this 25% is a best case scenario. Flaws and execution will reduce that probability. For example, if the attacker doesn't manage to transmit both transactions simultaneously and a number of other things, there's gonna be a lot more of one particular color in that diagram and it's gonna be more likely that things don't go wrong. But the question of how easy is this is something that's worth exploring, especially since we're, it's becoming, it's becoming kind of fashionable to say that ZeroConf works on Bitcoin Cash and it does work, however we should, one of the reasons it works is because I'm not sure how many people are trying to break it yet. So it's important that we keep on top of this as we go forward and we know some of the things we need to do to make it work better. So I tried an experiment. So in my experiment I transmitted simultaneous double spins to a pair of nodes in the network and then watch what happened from a single listening node and that's my merchant. So like I wanna see what the merchant saw and then I wanna see did he see the thing that finally got confirmed in a block. Well, so the ones that show in green are the ones where the miner confirmed the one that he saw that my listening node saw. The ones in orange are the ones that the miner confirmed the other one. So one thing I noticed was so every row here records a pair. It's a pair, there were two transactions represented on each row. So each row has a TX1, each row has a TX2. So wait a minute, first thing you might say is how did I even do this? Because my node's a node two and I should only see one because there's first scene rule. So good question. The reason is because one kind of nodes in the BCH network pays attention to the second scene transaction and relays it to other nodes. As Satoshi recommended, that's XT nodes. We don't keep the second scene transaction in the mempool or mine it, but we do relay it. The first one anyway. And so my injection points and the listening node were XT nodes. Okay, so all of the orange rows where a double spend got confirmed had a time difference. There's one of the things we measure the time difference at the node when he saw both transactions and how much time was there in between those two because that gets right back to the design of waiting for a certain amount of time. How long would we have to wait to avoid these double spends? And it actually turns out that all of the orange rows except for one were less than one second. They're say zero seconds on here. I don't have better resolution than that. And one of them was one second. So that's encouraging because it means that if your wallet, if the merchant's wallet could watch for double spends for even five seconds, it could be pretty confident that it wasn't going to have a double spend confirmed on that transaction. Okay, so I wanna mention, so that, I don't know if it's surprising or not that that attack can be successful. There are private solutions in place for large classes of transactions which improve on that situation. So BitPay has it, BlockCypher, these are the ones that I'm aware of. There's even others. So these protect more because the merchant will have their own, like BitPay I believe, has their own private monitoring network that relays double spends back through, not through the P2P network, but through their own private network to monitor for double spends and also just to check propagation. But that is probably not good enough because we need native protection for all BCH transactions. We should use a peer-to-peer network as the public double spend listening network for Bitcoin Cash. Oops, yeah, I'm running Windows. I knew it would come out. Okay. Oops, skipped ahead one. No, I didn't. So I just said we need native protection for all Bitcoin Cash transactions. That, there's two components to that. The one that seems, and the second one would build on the first. The second one is a future one. It's the thing I mentioned earlier about minor incentives. The first one is simply this relay feature. Wallet shows an alert when it sees a respend. Actually, probably what you do for the user interface would be, so today what happens, actually things, transactions show up pretty quickly when you pay somebody in their wallet. They see it pretty quickly. I know it seems fast, but it used to be a lot quicker. Three years ago it showed up in less than a second. Now it takes three or sometimes 10 or 20 seconds. This actually has to do with delays that were introduced by Core, which made it into all the cash clients to, for in the name of privacy, that actually delay the transmission. But, so you don't see the transaction at all for a certain amount of time. With this solution, what we could do is immediately relay the transaction as a recipient expects. So your recipient immediately sees it, but you'd probably show it in yellow or gray or something. I guess I'm not really a UX guy. And you would wait just like the confirmation timer, but much faster, and then it would say, okay, the five seconds has expired or whatever that time and the choice of that time is important. And then it would become, you should rely on this. So that way you can have both pieces of information. The fact that you saw the transaction and then the fact that it became reliable. And that's what it means. Absence of alert after two seconds greatly increases safety. Also, it's not realistic to think that every unconfirmed transaction can be protected from a respent forever if it's not being mined. So you have to have some time by which, it can be respent. So I just throw out two hours as a suggestion there. Okay, how am I doing on time? Okay, so oops. To make the network reliably alert user respends, we need to relay the first respend as alert. Recently the XT implementation has been upgraded, much improved by Dagger Johansson, and we plan to offer ports of that framework to other implementation. Also, Dagger has written an open source respend monitor web tool similar to the one, actually I think it was on Reddit this morning, that just details the observations of a node that's receiving double spends. So this is some code and that other site that's formatted with more detail on the transaction. Okay, so just a little bit about choosing T. If we model, make a statistical model of transaction propagation, we can predict how the entire network will behave. And what all that this is saying is that if we model a transaction as having a one second median, which is actually longer than what we were seeing on the network three years ago, then if two transactions are introduced with a five second delay at one time, then some remote median, what is the chance that if a remote node like the miner waits five seconds from after it sees the first one until it decides to mine it, what's the chance that they actually flipped around and the thing that he mines was actually a double spend. So it's actually a 10 second gap. And just for that case, I came up with the one second median. It's a 98% chance that he doesn't make a mistake with a 0.75 second median, which is what we actually were seeing. It's a 99.2% chance. This might need to be optimized even longer. So in this sense, when you look at this five seconds may not be enough because that's a 1% chance of a double spend working, you know, may not be acceptable. So that is why this kind of consideration, when we go into decide how, what should be the standard of how long to wait to be sure that your transaction, you're not gonna get double spent. It may be something longer than this. But the good news is we can learn from this. Right now it's still very opaque, only a tiny subset of the network forwards double spend. So if we can get more nodes doing it, we'll be able to gather more data on this before we make the rules any harder, more set in stone. And just briefly, once we go to the basic idea with minor deprecation would be that as before, minors don't include any re-spend in their block even if it was slightly later than, and they also would not, coming to the third one, they would include a transaction that had a double spend if the double spend was a long time after. How long after it's not known, but that's important because you can't have a situation where just by introducing a double spend, you make the minors not mine the original one because then you got your stuff for free. So that's like the crux of the trade-off. And what they would do, and there's different forms of this is the minors would not immediately build on a block that another minor produced that contained a double spend, an obvious double spend. So that's a way that minors could incentivize each other to follow a common set of rules. And it doesn't need to be a fork or it can be something that's self-healing similar to the Bitcoin Unlimited AD parameter. Okay. And just a few details. We've, I've learned about this from the first implementation of this which was done a couple of years ago. You'd want to probably have a reduced set of attributes of a transaction that you'd want to protect from double spends. You'd probably want it to be final. You'd probably want it to spend a limited number of inputs. That's an anti-DOS measure. You'd probably want the inputs to be confirmed mostly to simplify things. And it'd have to be highly standard. It's mostly covered with the other things. And also, it's important that you would replace a non-resistant transaction that spends a shared input because what you don't, another easy double spend attack is you send a non-standard transaction to the miner and he's got that transaction. He doesn't relay because it's not reliable. And then you use one of these normal transactions to pay your, to pay your merchant, but that's not the one that gets mine because already you gave the double spend to the miner. So the replacement is actually very important in order to have be a complete solution. Okay, I had one more slide which was to list other things, but I think I'll just, yeah. And if you survive that presentation, you're gonna do really well in Bitcoin Cash. All right, so we're ready for questions. Are there any questions that reflect the quality of the presentation you just heard? Great, great talk, Tom. Is it possible to relay a double spend but somehow modify the transaction? So there's enough information that my note can verify that it indeed is a double spend, but I couldn't actually include it in a block. I think it's possible to reduce the amount of information because not everything is signed in the original transaction, so you could do that. However, I'm not sure it meets your second criteria because I think you could still construct the other parts of it that weren't signed in such a way that it was, even if you even had to, that you could mine it. So the problem is a double spender doesn't, he only puts his signature on two things, the real transaction and the double spend. And the only real proof that he did it is his transaction that he signed. There's seen various ideas for a double spend proof, which would make bigger changes to the system and sometimes things that would happen in the authoring stage, but then you have the problem of who detects the proof and creates the proof, it'd be just random nodes or something, and then the question is how do they decide which one was first? They're gonna have to fall back on the same kind of timing-related judgment. So what I come to believe is that you have to let the nodes, all the whole network, participate and use their local clock as a resource in order to come to an emergent consensus, if you will, about which one was too long to be included. Good afternoon. We all know how convenient zero confirmation transactions are for merchants and consumers. What is the maximum advisable value for a transaction and for this type of transaction? And what's the best way to advise merchants of that value as well as our submerge that's more susceptible to these attacks versus others? Good question. I'm not sure I'm totally qualified to answer. I think the merchants have to decide that for themselves, but generally it should be much, the value should be much less than the cost to attack it. And well, this attack isn't very difficult. So, and it does also get into how the likely likelihood of this working, if we had a 1% chance of the wrong one getting mined, then you would want that for every dollar that you spent trying to attack it, you would want to not be able to gain a dollar. So 1% of $100, you wouldn't want it to be $100 if it cost a dollar to attack it. I'm kind of new to Bitcoin cash, so forgive me. You mentioned incentivizations from different points. I'm a little bit confused. Isn't the biggest incentive for miners to pick transactions, basically the mining fee? So I didn't hear you mentioning that. Like if I buy something for say $50 and I want to do a double spend, I might just spend $25 on a transaction fee just to get it for half price, whatever it is. Yeah, great question. Yeah, so the reason any of this works right now is because miners are being altruistic. They're doing what they do in support of the network. I did experiment with fees, one of the other variables. It didn't matter. I did zero difference, I did 10 satoshis difference, I did 50 satoshis different, or bits, not satoshis difference, and it didn't make a difference. There's also on that site, which I'll have, the urls are at the end of the presentation, which I guess will be made available somewhere, but also on that site, I have, let me go back to that slide. The transaction, the fee difference is the last, fee difference is here, and so we also have the amount, this last column is the amount of, that paid outputs in TX1 that weren't paid in TX2, so that's sort of the maximum loss of anybody who relied on TX1. So, what's the question again? Oh, right, right, right, so that is why, that is why I think it'd be a good idea to build minor incentives in there, because the nice thing about minor incentives is that, because it costs so much for a minor to lose a block, you know, $10,000 or whatever, a small chance of losing a block is enough, so only a mining minority would need to be committed to saying, look, we're not gonna build on your block if there's obvious double spends in it, in order to make the other miners say, okay, okay, we'll just keep doing that. So it's not even a majority, it's actually a minority, but it's not the end of the day, it is up to the miners as a group, and yeah, I'm not suggesting that the altruism is an ideal situation, and we should accept it, we should realize that the reason all these green ones are green is because, even if the fees were higher, they didn't mind the better one, they're not doing RBF, they don't have RBF, it's not in our software, and I guess they haven't added it. Two more max questions before we have to break for coffee. What do you think is the best way to incentivize providing network state information like possible that we spend? For instance, could a layer two network be used to pay instantly for that information? I have no idea how to address that question. I mean, should be more clear about that? Yeah, what were you asking? You mean a different currency, like how you have to pay to accelerate Bitcoin transactions with Bitcoin cash via VTC? Oh, so you're asking for someone who's running a node just to provide information, what would be a good way to incentivize, or would a layer two network be a good way to incentivize it? Well, I'm not too worried about it, because I mean, what incentive nodes have to forward transactions at all? I mean, if we add Respend Relay to the software, it doesn't really have any appreciable additional cost to what the nodes are doing today. So I don't know if I would agree that a separate incentive mechanism is needed for that. Forgive me, guys, we're gonna have to wrap it up because we gotta come back here after the coffee break. So with that, please give Tom a great hand.