Dominic is also a PG student at our lab and Mustafa will be here in a second, this will be soon. So, the workshop is scheduled in two parts. We have one part where we'll talk about cross-chain communication. The principle will also explain why cross-chain communication is where it's not possible without a trusted third party. And then we'll also have a technical deep dive into chain relay, specifically BGC relay. And then we've prepared a game. So essentially, if you have ganache installed on your laptop, if not, you should download it now. You will get a broken PDC relay implementation and you get to fix small parts of it. Or we'll have a game server which tests attacks against your relay and then we'll have a leaderboard. So, this workshop is based on a paper we recently released. So we wrote up a systematization of knowledge on cross-chain communication. So it's on e-print if you want to have a look at that. I won't be presenting everything because it's just way too much content. But yeah, if you're interested, that's where you should look. So, I mean, I guess we can all agree on why interoperability is necessary, but let me just repeat this again. Today there exist over 2,000 cryptocurrencies. And I think we can agree that most of them differ in design purpose, not only from functionality but also the different views of the community of how these things should be used. So, we kind of need a way to find a path to communicate between these different blockchains because it's very unlikely that there will be one chain to rule them up. Now, historically seen, cross-chain communication, the principles of cross-chain communication date back to communications across distributed databases. However, the main difference here is that in databases, specifically within a single data center, you don't expect bits and dean or adversarial behavior, right?  So, basically, non-blocking atomic commits is a way, or so basically, there's a problem and there's solutions for that. And the problem is that you want to make sure that your process that is running correctly does not fail and does not get stuck even if other processes crashed. Now, in distributed ledgers and blockchains specifically, the difference is that we actually expect participants to misbehave. We can have selfish miners, we can have people who try to double-spend and just attack your protocol because anyone can join the system. And this is basically the major difference between these two things. So, if we briefly talk about the main scenarios of cross-chain communication, if we talk about the main scenarios of cross-chain communication, I guess the one that everyone knows about is exchange of assets, right? Swapping coins against each other and also trying to transfer coins from one chain to the other, right? Making a payment to a merchant who maybe only accepts Ethereum and you're only in the different. Now, there we have atomic swaps. We also have the concept of cryptocurrency-backed assets. We'll talk about this in more detail later. Now, another very important scenario where cross-chain communication occurs is synchronization in sharded systems. Specifically, the idea of sharding is that you separate the state of a system and each sharder is responsible to maintain and secure the state of the subset of the state. Now, the problem is it only makes sense if you can actually communicate between the shards because otherwise you have a system of isolated shards and then it's already sharded. So, we'll talk about the differences in the different use cases and assumptions between sharding and cross-chain transfers a bit later. Now, what I think not many people know is that cross-chain communication was actually the first time implemented to use something else. Basically, it was used to introduce merge mining and that's basically a boot-shaping technique to launch new blockchains. And the idea there is that you have one parent chain and you allow miners to reuse the proof-of-work solutions from the parent chain, for example, Bitcoin, to create blocks and other blockchains like Namecoin. And essentially there, that means that Namecoin can use the security assumptions of Bitcoin, but it also becomes dependent because of Bitcoin bills, so does Namecoin because it uses the same proof-of-work. And finally, and we try to cover this bit more in the paper, there is this term of side-chains. Now, side-chains have seen many, many different definitions over the years and it's become an umbrella term for blockchain capability in general. And I guess the most famous, too, that we have seen is side-chains are an approach to extend functionality of one blockchain which becomes a parent chain and you have small blockchains on the side which are dependent on the security model of the parent chain. But there are other definitions and also quite famous ones specifically in academia which suggest that side-chains basically refer to one blockchain verifying the state of the other. Now, in the paper, we'll try to clarify this and we try not to use this term at all because it's very confusing in general. So, again, we'll talk about these two things in more detail today. Now, maybe a question to the audience. How many of you think that cross-chain communication is possible in a trustless matter? Okay, they've seen our tweet before, okay. So, the answer is no. And I'll try to explain why this is the case. But before being academics, you know, before we explain something, we always have to make a system. You know, to be sure that we cover all cases and that we understand what we're talking about. So, in cross-chain communication, we, for simplicity, assume that we have two different legends, right? In this case, Bitcoin and Ethereum. Now, we also have two parties or processes as distributed systems. We have Alice on Bitcoin and Bob on Ethereum. Now, let's assume we have two transactions, right? Transaction one, the blue one is owned by Alice, so only she can push it to the blockchain. And transaction two is owned by Bob. Now, transaction one is a Bitcoin transaction. It can only go into the Bitcoin blockchain. Transaction two is valid on Ethereum. It can only go into Ethereum. So far so clear, right? Very simple. Now, the idea of cross-chain communication is that Alice wants that Bob writes transaction two to Ethereum and Bob would like that Alice writes transaction one to Bitcoin. Now, this, and basically this also implies that Alice knows exactly how transactions it looks like and the other way around. Bob knows what he actually wants to have. Now, if what reduces to practice, you can imagine this being an exchange, right? Transaction two gives Ethereum to Alice. Transaction one gives Bitcoin to Bob, right? And let's keep this in mind for the rest of the discussion. Now, the goal of cross-chain communication is to synchronize these two processes, right? We want to make sure that Alice writes transaction one to Bitcoin, but Bob also writes transaction two to Ethereum. And we actually want to ensure that they both write at the same time, or at least atomically. Now, we have three properties for cross-chain communication in the paper. I will not bore you with theoretical definitions here. I'll just try to give the intuition what each of them means. So, effectiveness basically states that if everything is all right, if Alice and Bob are honest, and the transactions are as they expect, then cross-chain communication will proceed correctly, right? So, this basically allows the process to be executed. Now, atomicity reduces the set of potential behaviors to ensure that either Alice and Bob write transactions to the respective blockchains. So, either ticks one goes into Bitcoin and ticks two goes into Ethereum or none of them do, right? Because otherwise Alice or Bob could be at disadvantage and this would break our goal. And finally, timeliness basically ensures that at some point the protocol proceeds. At some point Bob or Alice will initiate the process and then the protocol starts working. Now, let's recall again, we're looking at an exchange. And essentially, cross-chain communication to Alice and Bob can be seen as a fair exchange of assets, specifically using our example to emphasize this. Right? Because they want to make sure that Bob receives coins on Ethereum and Bob receives coins on Bitcoin atomically. Otherwise, one of them will be cheap. Now, the thing is that fair exchange is impossible without our trusted third party. And this is a result dating back to 1999. If you have an e-cument at a look, it's written in this paper, it's actually fairly easy to follow and there's a really good explanation also about discussion about trusted third parties and what this actually means. Well, questions? What do you consider trusted? True. Let's get back to that. This is, I will talk about it in a second. Because using cash and more contracts, he's possible. No. And I'll try to explain in a second. Well, then the question is what do you consider trusted? The definition before. So, I'll explain in a second. You won't get to that point. But, yeah, HGLCs allow you to reduce trust in the third party, but you don't have a guarantee that you took that. The exchange will actually be atomic. We'll get to that in a second. So, again, we conjecture right now that it's impossible, right? And there's basically a proof sketch in the paper and I'll try to give an intuition here right now because, obviously, I don't think you should just trust me by me saying it. So, let's assume, again, we have a smart contract in a fear. And the smart contract allows us to do way more things than just HGLCs. So, it kind of supersedes actual contracts in this case. And using this smart contract, what we can actually do is we can enforce that Bob behaves correctly if Alice writes transaction tx1 to Bitcoin, right? Because we can require Bob to lock in some coins in the contract and the contract will then release these coins if Alice can show that she's sent Bitcoin to Bob on the Bitcoin side. So, this is actually a very weak model. Using HGLCs becomes more complicated. In fact, we'll cover this in a few slides later on. Now, if Alice now writes transaction 1 to Bitcoin, she wants to be sure that she receives the coins in Ethereum. So, what she has to do is she has to submit a proof or somehow inform the smart contract on the Ethereum side that she actually rolled the transaction into the Bitcoin side. And the problem is, within a single chain, yes, this smart contract could actually verify, right? If Alice were to write to Ethereum and took all the function of the smart contract, the contract would become aware that, yes, something has happened. But since these are separate ledgers, this contract by itself, also being a program which reacts to submit, but it has no other way to verify that something happened a bit except if someone tells them that it's happened. And this is actually where the intuition of the visibility comes in. Because the only way we can solve this problem is we can make an assumption that either all parties that we have a synchronous model, that means Alice is also online and that we know that there's a bound on the message delay. So, basically, in this case, Alice is online, she's honest to herself, obviously, and she's an incentive to claim the coins on the Ethereum side after saying the Bitcoin. So, she's the one who submits the proof. But the problem is, if we do not want to make this assumption in a synchronous model, and we went without Alice to crash, which is a typical assumption we have to make, the only other way we can achieve actual correct crossing communication is by having a trusted third party, which then takes the transaction one proof and submits it to the smart contract or, once you have a trusted third party, you might as well trust the third party who locks the coins on the Ethereum side. Questions? Like, moving between blockchains will allow to make these rules. And then, moving like a state route is done by some game which allows not to be just a trusted party by like some momentum protocol and like a protocol. So, there's a certain... I'm just trying to understand that it means trust us in this way. So, a trusted third party in the sense of distributed systems I mean, obviously you want it to behave honestly. You make this assumption.  It just incentivizes. It could be a fee like a protocol. Exactly. So, if you say this party was a lot collateral and will reimburse you, you may not face financial damage but the protocol still failed. Right? You're still the actual... So, trust it will be mean like a pure mathematical trust and not like an economically bound... So, I'm not saying you're mathematical. Let's put it that way. Trustless in game theory is a greyish definition. Right? I mean, essentially if you... And we have their protocols which ensure that you don't face financial damage. I mean, one thing is based on like... Sure. But in all these protocols you have some timeouts and some timebooks and some synchrony assumptions because if you don't have a synchrony assumption it breaks. Well, we'll come to that in a bit. I mean, we'll discuss atomic swap, cryptocurrency-backed assets and you'll see where the synchrony assumption comes in, actually. So, your argument in this example was that Alice would not be able to do the transaction and that's why you use third party? So, the thing is, in this model you must allow Alice to crash, right? You cannot assume... If we assume that Alice is on the plane... It's only at the amount of time within a hash-time lock-on rate in which she can... Well, we'll get to hash-time lock-on rate in a second and I'll actually explain on an example why it is still the problem. But essentially... The option problem? I mean... Not exactly. That's also a problem. But in hash-time lock-on rate contracts they only ensure that you cannot steal or misbehave within a certain period of time. But if you crash and the time it expires it still fits. There's a specific example on this. Why don't we let him get through all the variables? Okay, sorry. Question? Yeah, can you talk a little bit about how important it is for us to not rely on a synchrony assumption and why that's important and... I mean, the thing is, so... When we design protocols often we make the assumption that we have a synchronism network model because it's way easier to design these things, right? We assume that if I send a message at some point you will receive it. However, if we cannot make this assumption then I do not know... And if we assume that nodes can be malicious then I do not know if you're malicious or you just do not get the message. And there's a really famous FOP impossibility result by Nancy Lynch where the consensus is impossible in a system where you have at least one call to know if it's a synchrony. Because again, I send you the message but if I cannot make an assumption I don't know whether you received it or not I don't know, maybe you're malicious and you're just pretending not to know it or the network actually has a huge delay. Usually this synchrony is a network assumption and not a participant assumption. It sounds like here it's an assumption regarding Alice so I was just wondering... Okay, yeah, fair. Which one is it? I mean, it's both. Because you need Alice to be online because she needs to send the message. Sure, but you can usually ensure that somehow but if the network you don't have a synchrony assumption then it's hard. Yes, so the problem is within a single system you can try to ensure that Alice sends the message or something. That's the timeless assumption, right? At some point Alice will write the message but here we kind of have two separate systems so you have two separate networks. But I see the point so the definitions are more clear in the paper hopefully. It's not an easy thing to just explain by intuition but I hope this kind of makes sense to everyone. Are there any more questions on this? Okay, so if you have questions you will just have to trust them a lot. So yeah, we conjecture that it's a cruel one and then there's a discussion in the 1999 where it's an impossibility result on why this is the case and they try to give a similar explanation of why actually having a synchronist as a model is very similar to having a trusted partner, right? Because then Alice, if she has to be online and we must expect the message to be delivered on time it's the same thing as if we had a trusted third party. The trusted third party is online and it ensures that the message is delivered on time and it ensures that the protocol progresses. If we assume synchrony, Alice is her own third party or she trusts herself because she knows she'll be online and that's what she'll be delivering. So basically it's the same thing whether you assume a trusted third party or you assume a synchronized reception from theory perspective. Now obviously assuming a trusted third party the trusted third party would steal your coins and everything but for the correct execution of the protocol and again this is where the game-threatening perspective comes in if you can ensure that the trusted third party cannot fraud you financially it still is the same thing as a synchronized reception from disability assistance perspective. Now Mustafa will take over the classification of the protocol and then we'll move on to the examples. Okay, so I'm going to talk a little bit about different types of protocols that you could use to do cross-chain communication and this is based on a paper that we wrote a systemization of knowledge paper that compares different cross-chain communication programs. So obviously as Alex said there's different use cases for cross-chain protocols side-chain, sharding and so forth So the first classification that we have is we basically separate all cross-chain communication protocols into two broad categories. Okay, the first category fire up to get is basically when you basically post a message on chain and there is no recovery So what we mean by that is in some cases if you're trying to swap an asset and you want that swap to be atomic or you want that transaction to be atomic in the sense that if you're trying to move x to chain y but if x cannot successfully move to chain y there's two different ways of dealing with that The first way is try and forget where you basically post a message on chain x say chain x will now be moved to chain y and there's no recovery process behind that so there's no way this can fail If you say I want to check the chain x to chain y then there's no a board phase or recovery process behind that But here with two phase commit protocols there is a board or recovery phase in the case where a transaction fails So you might move object x to chain y but you might realize but when you move object x to chain y it might be the case that you might have to undo that because the overall transaction that this process is part of has failed and this is where the abort comes in and it will become more clear when you actually go through the actual protocols but this is a classification a second classification is local verification so when you actually do cross-chain communication who is responsible for verifying that communication for some protocols use local verification which is basically when only the participants who are involved in that cross-chain communication are responsible for verifying that cross-chain communication for example hglc-based atomic swaps so for example if Alice wants to send money to Bob if only Bob is responsible for verifying that that money has been sent on the other hand with global verification you don't just need the two participants or the participants of the cross-chain communication protocol to be involved in the verification you also need the entire consensus to be involved with that verification or you need to verify the consensus you need to verify some consensus level header or object and one example of this is atomic swaps with transaction-inclusion groups so the transaction-inclusion group which from Bitcoin for example the Ethereum chain has to receive a block header from the Bitcoin chain and the Ethereum chain has to verify the proof of work of that block header and so that's global verification because the Ethereum chain is verifying the consensus of the Bitcoin chain so the entire Ethereum chain is basically involved in some way of verifying the communication I find the security model there's different security models for cross-chain communication there's homogenous and heterogeneous heterogeneous let's start with heterogeneous because that's more simple than that and heterogeneous is basically when you have different chains that aren't really kind of connected or directly connected to each other for example let's say you want to communicate from Bitcoin to Ethereum or any of these chains this is considered heterogeneous because these chains are built differently and have different security assumptions so you might not be able to necessarily make assumptions about the security of interlaced chains I could just create my own blockchain and communicate with Bitcoin for example using a timing swap but people in Bitcoin can't make assumptions about the security of my chain now with the homogenous with the homogenous security model it's due to the uniform level of security for example sharding in a sharded system there's multiple chains but those chains are part of the same system and they use the same consensus protocol and they design to be connected to each other so you can make assumptions about the security of those chains and usually sharded systems are designed in such a way that if one chain fails then so does the other because those chains rely on the state of each other so you might be familiar with Cosmos for example or Polkadot Polkadot and Cosmos for example have a heterogeneous security model for example when Cosmos or Polkadot you can create your own zone or chain with your own consensus where for example if you have two pointer sharding or any kind of protocol it's because it's to be homogenous so when I go through different protocols we're not going to go into them to do my detail but we're going to give it to Alex to first start with atomic swaps so yeah also just one thing on this figure we won't have time to go into detail about all of them but one thing that you may notice is that local verification so when only two of the participants were involved in the exchange have to do the checks it's actually a agnostic of the blockchain it's an agnostic of the security model obviously you need to make sure that the locking mechanism is available but otherwise you don't care about any consensus level details and so on because again only us to verify so let's talk about cross-legion I hope I'll be able to answer your question why HLCs may not solve your problem so again in atomic swaps sorry sure so in atomic swaps using symmetric locks the idea is that both parties Alice and Bob use the same locking condition on both chains an example are hash locks right so what Alice creates she generates a secret and creates a spending condition on bitcoin for example which says if you can provide me with a secret you can take these coins and Bob does the same thing so usually they'll have a setup phase they'll exchange verification transactions and so on but then they both know the hash of the secret so Bob makes the same lock now in the next step if Alice wants to spend Bob's coins she has to reveal the secret and this again ensures that Bob has a secret and can also take Alice's coins now typically you also have time locks to prevent that if one of the parties crashes or if the exchange never starts that your funds are locked up indefinitely but this bears a problem and this is I hope basically this is why HLCs don't solve the problem or the cross-stream communication problem because what can happen is that Bob can crash Alice spends the coins from Ethereum reveals a secret but Bob never sees it because he's crashed and what happens then is Alice can wait until the time limit expires and take her coins back on the bitcoin side but that's why you choose the time locks like this it doesn't matter Bob crashes before he saw that Bob never even sees the secret he's just offline he posted the lock and he crashed well that secret is still there just have to find it everything is public Bob the guy who could spend these coins because this is not just the hash lock it's hash lock and the Bob signature on the bitcoins this can only be spent by Alice this can only be spent by Bob so that's how you choose to construct and if Bob crashes and he never sees the secret and he does not come online and if the time lock of this thing expires Alice can withdraw that's why you choose the time locks in a way like this so he has enough time to still do it it's not a contradiction you choose the time locks but if he's offline indefinitely he crashes well if he's offline indefinitely of course but then he can only participate on blockchain solutions let's take this offline but that's an impossibility you're going to agree what if Bob dies it's bad but it's still impossible without any forcing that he stays online that's a result I don't say that you should participate in the exchange if you think you may crash that's where you can use watch stars but still now what you can also do is you can try to say well what if Bob actually is online the whole time and he can actually go offline because he uses a smart contract and that's the same example as we show using the disability result if Bob locks his coin and says okay well if you can prove to this contract or anyone that you send bitcoin to my account on the bitcoin side you can take these coins and now the responsibility is on Alice because she is the one who has to push the coins to bitcoin send the coins on bitcoin and push the proof the problem is so Bob can go offline but what if Alice crashes so Alice sends the bitcoin and then she goes offline and of course Bob could say well okay I'm a nice guy I'll give you I'll send the proof myself or anyone else could do it so it's already an improvement because now anyone can push the proof and the contract will give you the coins but it's again if you think about it it's the same thing as with HDLCs and furthermore if this time up expires again Bob can take the coins out so if Alice crashes and she is offline or Bob is the guy who actually as it runs a denial service attack against Alice he can actually steal coins so another approach and this is basically a different approach is to use cryptocurrency back assets so instead of trying to circumvent this impossibility result each time we exchange what we can do is we can create a representation of bitcoin on Ethereum and we have a whole paper describing this concept a term to explain but I'll try to give a very very brief overview so what you do is you send coins to a vault which is collateralized and insured through the union and stadiums so you have the game threat to guarantee that if nothing goes wrong if something goes wrong you'll get reimbursed so you still have to mitigate exchange rates now Alice then submits approved to the contract that she locked up the coins and receives Bitcoin back tokens and she can use these tokens to now make native atomic swaps with a better guarantee than it would optimize more we sell the impossibility result of fair exchange also the free option problem but at least we don't have to synchronize clocks and everything else across two chains and we also don't have to trust that at this point in time there is no attack on bitcoin which prevents transaction being included so you do the slow setup then cost the setup phase at once and then you can trade these tokens and use them with smart contracts sorry what's the options problem? let's say you don't have that much time but it's a fairness problem that I can cancel the exchange and basically get a free option because I know what your offer is but you don't know what my offer is so now when I want to go back I burn these coins and then the vault has to release these coins to me otherwise it will get slashed I'm skipping over this because we're running out of time but there's a whole paper describing this concept and we also have some code online a vault is a smart contract or is it a zone? no so the vault this thing was constructed in a way that you need smart contracts only at one chain a vault can be a smart contract or a participant it could be a human on the bitcoin side it just needs smart contracts on the side where you issue the tokens can you sell the vault at the third party too? sorry? is that the vault a trusted party? it's a trusted party from a distributed assistance perspective yes but from a financial perspective it's insured with collateral so if it fails I can get back collateral from the Ethereum side so the construction is if the exchange rates don't crash completely I as a participant do not face financial damage can we just put licenses from user to that's a different thing the vault can go offline but then the contract if I'm online and I can go to the contract and say wait a second this guy went offline trying to accuse him I have to then say well he didn't do it or in our case if the vault does not submit the proof on time I'm automatically reimbursed but if you think about it the communication actually failed because nothing happened on the bitcoin side I didn't actually trigger a process on the bitcoin side I just got reimbursed on the Ethereum side so cross check communication failed but I still because a protocol is constructed I got a reimbursement on the one chain that I'm on so there's two different aspects to this you have to be careful to separate cool now back to Gustav and Charlie okay so I'm going to give you a brief overview of our cross shard communications so I'm going to rehash the atomic transaction problem so what is the atomic transaction problem it can also be called a train and resolve problem so this is first Alice wants to book a trip and she needs a hotel room and a train seat to get to the hotel and let's suppose that there's a travel agent contract on the chain and what that contract basically does it books a hotel room and a train seat at the same time just like when you go to Expedia you can book a package with your flight and hotel at the same time that the hotel room object or contract is in shard 1 and the train seat is in shard 2 so that means the travel agent contract will have to communicate with both shards to execute this transaction where Alice wants to book a hotel room and a train seat at the same time okay but the key thing here is that Alice wants to book both the hotel room and the train seat we don't want to end up in a situation where one of those transactions fails because if the train seat transaction fails then Alice has a hotel room but nowhere to get to it or if the hotel fails then she has a train seat but nowhere to stay so let's suppose this transaction happens she tries to make this transaction and tries to book the same hotel room one second earlier but Alice has already submitted this transaction one second later we can end up in a situation where Bob ends up with the hotel room and Alice has a train seat but she has failed to book the hotel room so her transaction was an atomic okay now the goal of cross shard communication is to have atomic transactions so that it should be that either Alice gets the both the hotel room and the train seat or nothing it's all or nothing we don't want a half complete transaction so there's two kind of board categories of doing cross shard communication the first one cross is basically retext based Vitalik made a first part of his material research he called it cross shard janking but it's actually basically retexted in the 70s the idea is very simple basically what you do is you issue a yank command for the hotel room and what that does is you remove that hotel room from that shard and that shard generates a receipt that this has happened that the hotel room has been removed from this shard and that receipt is simply a message in the block and the receipt itself can be proven using a mail book proof and then what Alice does is she sends that receipt and that chart 2 reads this receipt and re-creates this hotel room in that shard and so now the hotel room and the train seats are now in the same shard and so now there's no cross shard communication even needed the transaction can all happen in the same shard so now so what I just prescribed was a fire and forget protocol so this was here it's a fire and forget protocol there's no recovery phase there's no ward phase there's no failure mode here the only potential failure mode here is during the time that Alice can move this hotel room to this shard but might move these train seats to shard 1 so then she has to move the hotel room back to shard 1 but in terms of the actual protocol the protocol itself does not have a built-in support or recovery phase now the other mechanism for doing cross shard communication is called two phase commit and there'll be two at all over one on this diagram I'll explain it two phase commit is a very old protocol definitely it's old it was used in distributed systems design but it could also be applied to sharding it's called two phase commit because there's two phases so let's suppose you have shard 1 and shard 2 shard 1 manages the hotel shard 2 manages the train the user sends the transaction to both shards and then what the shards do is they check that the transaction is valid and they run a Byzantine folklore protocol just like basically what blockchain is to agree that the transaction on the ordering of the transaction or that the transaction has taken place and then they lock they lock these objects that means that once these objects are locked no other transaction can come along and try to use these objects because these objects these objects will be locked through this transaction so it's like this transaction is reserving reserving these objects it's just like when you're at an event for example and you try to book a ticket it says this ticket has been reserved for seven minutes or something like that if you don't book it within seven minutes then you will lose your ticket so you're basically reserving these objects for this transaction and once all of the shards have locked all of the objects necessary as needed for this transaction they basically communicate with each other tell them that yes these objects have been locked to this transaction and then they can execute this transaction and unlock the objects or specifically actually just destroy the objects depending on how depending on your transaction model if it's a UTXO model you will destroy the object because UTXOs only spend once if it's a contract model then it's basically unlocked and so that's basically the principle now what could happen is if another transaction I have a diagram for this but if another transaction this block comes along and tries to reserve the same hotel this locking will fail and then both of the objects will be unlocked but the transaction will be aborted the transaction won't be committed it will be aborted so now we're going to talk quickly about quash-chain verification I don't know about that just do that out quash-chain verification validation and this I think we'll go and demo that one actually how many people actually have a laptop here and can't participate in the coding department can you can you raise like just so we see okay cool that's like 10-15 minutes so yeah let's just go through this okay so quash-chain verification and validation when you do quash-chain transactions it means you validate the messages that you're receiving quash-chain are actually valid and verified now there's different levels of verification for blockchain and specifically with quash-chain quash-chain communication first level state verification like I don't mean verifying that the state is correct I mean just verifying what the state is or what the consensus thinks the state is for example checking that some block header sorry state is just proof of work it's not checking the state it's valid checking what does the consensus what state does the consensus agree on so it's just taking the proof of work so if you have a hack a local or a block header then this indeed involves checking that the block header has proof of work has consensus so does the state have consensus actually maybe that's number two sorry I might stop that number two is does the state have consensus so number one is just checking that the hash of block has consensus number two is checking if the consensus agrees on what the state is okay simply like clients so SPV verification so one you download a mobile wallet for bitcoin for example an android that mobile wallet is only downloading a small piece of the block for the block header and it's not actually checking what the state is it's just checking that the state has consensus and in the third level it's checking that the blocks are included in the state that are relevant to you so not necessarily every transaction so for example you might want to check that someone sends you a transaction so you would ask a node to give you a proof that that transaction has been included in the block simple metal proof and number four is state validity so just because you know that the state has consensus doesn't mean that the state is valid okay so it's very possible that this on this majority of miners or stakers could produce a block that is invalid or even like a single miner to do that actually not a dominant size majority so in the bitcoin or Ethereum for a block to be valid it's not it's common misconception actually if people think for a block to be valid it needs to have it all needs to have its consensus but that's not true not only does it need to have consensus the actual transactions in the block have to be correct as well so at this on this majority of consensus participants should not be able to insert balances transactions into the block that steal people's money so that's why it's also important to actually validate the state and not just trust the consensus and that's basically the purpose of full nodes if you run a full node you're verifying the entire block chain you're checking every single transaction you're not just simply trusting the consensus and the fifth level which we're talking about is data availability which is basically checking I guess that's kind of coupled with checking validity checking that if all the block data is actually available for verification and this can be actually done as alternative to stability instead of checking instead of checking that the state is correct yourself you just assume that the state is correct and rely on something called fraud proofs to tell that all people can generate if the state is incorrect so they can prove to you that the state is incorrect so normally block chains use a guilty and central proof and innocent model where you assume that every block is incorrect as you proof otherwise whereas fraud proofs use an innocent proof and guilty model but we're not going to be talking about data availability and the green stuff is basically what light clients and there's data clients do which will be relevant to their workshop and there's other verification techniques so as I said direct observation, you run a full node yourself to check the validity of the chain watchtower so you can ask someone to run a full node on your behalf as a full back if you fail and there's many ways to do this that does not require trusting a watchtower that's not going to go into detail but it's going to go in the arrow just to fully trust someone or there's verification games so what some people do is the computation happens off chain but if the execution is correct you can challenge the execution result on chain and there's an interactive game that is played to challenge the verification result and basically the test needs to make the end result to reduce the money ok so we'll do a really quick technical detail into chain relays which is relevant for the practical part and then since not everyone has a laptop I suggest we split the room so one room can do the coding example we'll also provide this alignment afterwards so we have to prep the server and everything we'll have a UI and you can play the game later on so we'll make it available and then in the other side we want to discuss so we can continue ok but let's do another 5 minutes because that's kind of relevant for even if you're not already spending the day so as mentioned chain relays are basically to be so they allow us to verify the state the state agreement and state pollution of another project now state can also be considered just partially to transactional data you just know well you can parse the data on a big transaction but you have no clue where it's actually included or even now the thing is with SPV clients and that's a kind of a problem because it's not really being defined in practice I mean we have a lot of formal frameworks for this now the backbone model but I have not really seen a lot of clear definitions of what an SPV client should be I mean basically everyone knows but then we don't really write it down but if we build an SPV client that's when we actually start to think about it so what do we need to verify and the first thing is we need to be aware of what they're just because otherwise since we know that Bitcoin difficulty is switched every 2060 blocks and if you're it's different but we need to make sure that our chain relay program knows what the difficulty is expected at this point in time otherwise I could submit blocks which are too easy next we have to verify that they perform that's clear we have to check that each block that we submit is an ancestor right because they want to make sure it's a chain then we also have to make sure we can detect forks right we need to know if we have two chains which one is the main chain which is the shorter and finally we also want to make sure that we can check transaction inclusion proofs because that's the actual thing that you want to achieve when you do an SPV client you want to know if the transaction existed working of course now in our game today we've simplified the implementation we've dropped the difficult adjustment verification and we've removed 4CAM otherwise the cold base becomes too cold so we assume that with constant difficulty and with no force it's a simple model and yeah we were the testnet so you won't be able to preface so a question that people often ask is well what happens in proof of state blocks right because it seems similar but then there's there's a subtle difference to this because instead of checking and tracking the proof of work difficulty adjustment you need to track the state distribution of the chain because you need to know who is allowed to sign any track in proof of work you know the guy who found the proof of work and that the proof of work match the target he's the one in proof of state we even have a comment here but you need to know are they the ones who are allowed to sign the track and then you check signatures which is usually way efficient and verifiable for work at least if you have to do it cross-chain and the rest basically stays the same now practical challenges that we face when implementing obviously we need to make sure that we have a cryptographic primitive there so we need to be able to verify the proof of work of the chain we're checking right so this works for Bitcoin on Ethereum but if you try to do the same thing you run into major problems it costs around 100 blocks of worth of Ethereum gas to verify a single life of block so that doesn't really work and then you almost make sure that your chain related is a life right it's a single SPV client deployed in the chain and if no one provides the data well then it's a good use of it and the problem is you know that it costs us money to submit the blocks to the chain related theory you might have to pay the gas costs so if you come along to the PDC relay and the last time we checked it was around 90,000 blocks by the big main chain so if I don't want to use the original chain related deployment it's already feasible so your best goal is to redeploy it agree with your parties that you have a new block that you're aware of and then you start submitting again or one day maybe we'll have more efficient life clients that use flight clients or super flow people pause we have a discussion in the paper and we point to the links I won't go into detail because so we actually we looked at the PDC that was deployed originally and what we see here is that there's kind of a discrepancy between the time that the PDC block was generated and where it arrived in the Ethereum blockchain chain related and if we take a closer look we see that a lot of blocks were delayed around 3,000 hours which is not really practical you'd expect 6 hours to be delayed or maybe 10 because we're waiting for confirmations but then someone should push it so the problem is incentives someone has to pay for this and what we also saw that only 2 addresses submitted more than 90% of the blocks so essentially this was consensus running the PDC but in practice if you have an application you need to make sure you split the fees among participants otherwise you may have incentive problems and if the channel is not up to date it's not useful and you run into the problem that you can't submit the proofs and yeah unfortunately it seems that so the original PDC implementation is not normal running there's implementations by SUMA so they have a nice library we've also done implementations so in theory you can have an exploit if you need to use it but the original one is unfortunately dead so yeah finally the cost factor so we need to pay for submitting the blocks and what we need to do is we need to pay for each block to be pushed to the PDC meaning the cost thing is the same for SPV clients except that if it's your phone you can then delete the blocks if you don't need them anymore and the costing model is different storage is not that expensive on your mobile phone if you have a contract storage so what you can do then is you can try to improve this using sublinear light plan techniques but this requires changes to the actual blockchain you're verifying so both light plan and super block new profiles which I would have described on this slide but we don't have time but they basically allow you to only submit a logarithmic amount of blocks instead of linear but yeah another maybe practical challenge is if we want to deploy this on many chains what we end up doing is we submit block headers from n chains that we're going to verify to n chains that we're verifying out so it doesn't seem a bit of a problem so in the long term we probably want to find out how we can reduce this and maybe share data across multiple chains so yeah we don't cover everything and being academics we just please read our paper for everything else we discuss locking techniques to achieve atomicity HLCs, ECDC locks and so on we also talk about the implications of privacy security and the network threat models so when you design blockchain cross-chain communication borrow quality these are the things you must consider so yeah and now to the practical part are you going to post these slides in here? we will release them at some point


So, now we consider a still more generic steady state problem. It is not a turbine, but a system which involves nearly every term that we thought of. Let me read out to you a steady flow system receives 60 kilogram per minute of gas at 2 bar 90 degree centigrade with negligible velocity and discharges it at a point 20 meters above the entrance section at a temperature of 300 degree centigrade with a velocity of 2200 meters per minute. During this process, 2 kilowatt of heat is supplied from external sources and the increase in enthalpy is 7.8 kilojoule per kg. Determine the power output. Now, this has all terms that we can think of. There is a Q dot, there is W dot S, there is delta H, there is delta kinetic energy and there is delta potential energy. Let us see how if we put each of these terms what we get? So, of course, this is a steady state problem. So, we start with our simple steady state first law equation. Before writing down the equation, let us just draw a diagram. It is no longer a turbine. I will draw an arbitrary shape here. This is the inlet section here i, this is the exit section e and this height difference has been given as 20 meters. There is a Q dot. The Q dot is given as 2 kilowatt. There is a W dot S which we are expected to find out and M dot has been given. This is 60 kilogram per minute which of course translates as just 1 kilogram per second. The problem has been invented to wake up the students because the units are in minutes. Typically, we would always work in seconds. Vi, it is mentioned is negligible. So, we will just put this as equal to 0. Ve, if you see, is equal to 2200 meters per minute. Again, this is non-standard. Let me convert it into standard units and this is what is expected. You just have to divide it by 60 and you will get meters per second. So, if we look at Ve squared by 2 minus Vi squared by 2, that would just be equal to Ve squared by 2 because Vi is negligible. This will turn out to be 36.667 squared by 2 and this would be just 672.2 joules per kg and that would be of course a reasonably small number. It is 0.672 kilojoule per kg and you would have noticed that Ve was even lesser than 50 meters per second. Hence, we do not expect this term to be big. What about GZe minus Zi? We have been given that this is 20 meters. 20 meters is a reasonably large number but GZe minus Zi would still be a reasonably small number. Let me just calculate it. This is 9.81 meter per second square multiplied by 20 meters. So, this would be 196.2 joule per kg. It is a very small number, 0.196 kilojoule per kg. He minus HI has been given. It is a reasonably large number. It is 7.8 kilojoule per kg. So, it is not as large as in turbines. It is a reasonably small number. It is not of the order of 100 or 200 or 900. Hence, the Ve squared by 2 term is at least comparable to this. You can say it is at least 10 percent of it and hence, we cannot neglect this. Of course, GZe minus Zi is much smaller but still compared to 7.8. It is not that negligible and hence, we consider it. Q dot of course, is of the same order as He minus HI. It is 2 kilojoule per second and if we divided by 1 kilochrom per second, you realize that it is of the same order. Let us just write down the first law now. So, we know all the quantities. This is a positive quantity. It is 2 kilowatt. This has to be found out. This is 1 kilogram per second. This He minus HI is 7.8 kilojoule per kg. Here, this is negligible but so, Ve squared by 2 minus Vi squared by 2 is nothing but Ve squared by 2 and we found that this is 0.672 kilojoule per kg and GZe by Zi, we found out was 0.196 kilojoule per kg. Luckily, we are just multiplying this by 1 here. So, W dot S, it will turn out is now, this entire thing kilogram per second multiplied by kilojoule per kg. So, this will turn out to be 7.8 kilowatt when you multiplied by m dot is 0.67 kilowatt, 0.196 kilowatt. So, we would end up with W dot S is 2 minus 7.8 minus 0.672 minus 0.196 and all the units you realize are in kilowatts. You will realize that this will turn out to be a negative quantity and to ensure that there is significant delta H increase in kinetic energy, increase in potential energy, you have to do both work input into the system and also input heat energy into the system. So, this will be a negative quantity which means work is done on the system and it will turn out hopefully as minus 6.668 kilowatt. So, this is a problem where we consider every term and we neglected none of the changes in potential and kinetic energies and that was reasonable since the terms were comparable. But typically in a turbine and compressor problems, you will realize that these terms will be negligible. Right now, that is it. Thank you.


So, our man, Mr. Tim Moyd, folks, is also going to be doing a workshop. This workshop is a week from today. And the first one that Tim did, Bottom Line, we were talking about how do you look at bottoms? Well, this next one here is the secret science of market tops. You're going to love it. Next Thursday, the 14th, so from 4 to 5.30, folks, it's only $149.00, Bottom Line, from over our website at TFN, we get the target dollar sale going on simultaneously. You're going to get a great workshop. You're going to really get to understand, number one, what to look for at bottoms and what to look for at tops. You know, neither Tim nor myself or anyone else, we're not saying it's a crystal ball, but you can see the consistency of what Tim does, folks, okay? It is pretty intense, okay? Because when we, you know, we were going on six or seven months right now, first he hit gold, then he Bottom Line hit the S&P, and now, you know, Bottom Line will see whether we're coming into a top or not. Tim Moyd, what's going on? All right, I got you some charts over your way. We'll take a look at them. You certainly do. Let's do that. Yeah. Yeah. It's a chart one. Yeah, just give me one second, Tim. We're on that webinar a week from today, so, but anyhow, this is kind of a teasing, I guess. Yeah, good. What to look for, but the first chart, you know, the bottom window is the SPY. Okay. The higher window is the VIX. VIX really is a great indicator, especially when you combine it with other things. And the top window is the SPX VIX ratio. Yes. I got a pink area, if you can see that July area, where the S&P are making higher highs in that ratio. Yep. It was making higher lows, and that's one of the reasons why we got out in July was because of that. Right. And I want to point out, we have something similar on a little bit smaller time frame. If you look way over to the right window, far right window there, you can kind of see it a lot better, but you can see the S&P in general kind of working higher, kind of making higher highs, higher lows, while that ratio, which is the top window, is actually making lower lows. Look at that, huh? Okay. You can see the VIX there. As the market goes up, you should have the VIX really trace opposite of the S&P and the S&P. Yes. Right. So, but when both of them are going up, that's usually a negative sign for the market. And so, that's what we have right now. How long can this last?  And we've been going up for, I don't know, close to two weeks now, maybe a week, a week and a half, whatever. So what I'm saying is this divergence, or both of them are going up at the same time, can last a while. So, you know, what good is that? You know?  Right. Yeah. They can just, you know, you're short and they keep kind of pushing higher. Yep. And, yeah, so you've got to really watch what's kind of going on, but you know there's a divergence there. So at the moment, you're not bullish. So can it go higher? Yeah, I can squeak up higher, but as long as those two, as long as the VIX or VIX keeps going up with the S&Ps, that divergence persists and at some point, you're going to turn down. So let's look at another ratio on page, on chart two. Okay. This one actually, one of the reasons why it got me short, back in July top, that ratio was, this is kind of the same thing here. You've got the S&Ps going up and you've got this, the middle window is a TLT, which is a bond market to the VVIX, which is VIX of the VIX. So when the VIX goes up or the VVX, VIX of the VIX goes up before the VIX goes up. So it anticipates, when that VVIX starts going up, it anticipates at some point, the VIX will start going up. So that's how that works. So it's a little bit quicker signal using the VVIX than the VIX. So anyhow, I did that. So normally, the TLT kind of really trades off, it's not an ideal world, but it does kind of trade off at the S&Ps when that tilt's going up, a lot of times, the mark's going down, and it's kind of a safe haven. So it's a good indicator to have, to try to figure out where that mark is going to reverse. If you remember, back in October 27th, we got long on the analysis. That was the day of the low we went long. And the reason why we went long is because this ratio was going straight up. Nice. And if you remember, folks, October 27th, that was a bad day in the marketplace. So I can see why Tim also did it, because there was some fear there, wasn't there? That's pretty cool. Stay right there, folks. Tim and I are coming right back. Welcome back, folks. Tim Boyd, Tom Mulbran. We do appreciate you growling proud of us. We have the Dow up 73, and the Aztec up 189, S&Ps up 34. We're talking about what I've managed to Tim more, and he's bringing us through these different things that he's looking at for market tops. Now what's going on, folks, is next Thursday, Tim's going to be doing a workshop. You can be in that workshop. It's only $149. Come over to our website at TFNN. You can see it right into featured content. It's going to be an hour and a half. These tools, folks, no one has these tools number one. You can have them all. You can go over the archive as many times as you want. You can put the formulas in, a spreadsheet, and you're off to the races. And you just have to do a little work when you do these every night, every night. That's the bottom line. But guess what? Do you want to make money or not make money? That's what it comes down to. So, Tim, we're looking at this chart number two. Chart two, actually, this is the close of yesterday. OK. And the middle window is that TLT to a VBIX ratio, and it's making higher highs, along with the S&P's making higher highs. Right. OK, that's bullish. Yes. OK, OK. So now, flip to chart three. OK. Now, this is today's. So, and this is updated today. That was yesterday. So we didn't close at a new high. We actually closed a little bit lower. So the divergence went away, or the bullish divergence went away today. So now, you're making a little bit lesser highs still. So you've got a divergence. You've got the TLT VIX ratio making a little bit lower highs as the S&P's still making higher highs. So that puts back on the negative divergence. I guess you might say. Yes. So now you've got the S&P X to VIX ratio divergence, which can go on for weeks. You've got this is a little bit shorter term, but you still have a divergence. So it still suggests, at some point, we're going into a high. So you're getting a little more information, right, that it's getting more dangerous up here, basically, right? Yeah. Yeah. If you look at last Friday's high, we had high volume. I don't have that volume short. We talked about it, I think, last Thursday. Yeah. I thought last Friday's high, maybe it was Tuesday. So last Friday's high, I bet there's a good chance we're going to test that, because we had high volume. Yeah, $29 million, right? Which we haven't touched yet, but we may touch it tomorrow. And these versions are still present, these bearish diverges still present, that potentially could end up with a cell signal. I'll have to wait and see. Don't know yet, but let's look at it. So that's the short-term trend. The short-term trend shows bearish divergence upward that way, no signal yet. But so let's look at the bear term. OK. This is going to be a great big top, and we're going to go down to zero on the SPs. No, we're not. And this is the reason why. On this chart, chart number four, the bottom window is the SPY. And the next window up is the SPX-PIX ratio. And the last time we were talking back in May, I thought that the market's going to hit higher. And the reason why I said that was because of this ratio. The ratio is making higher highs, where the SPYs was basically matching its previous highs. Well, the SPY-PIX ratio leads the S&Ps. So we have a kind of a semisteriors. Right now, we're testing the July highs or early July highs. And this ratio is making higher highs. Wow. So at some point, we could have minor pullbacks, just like we did back in April May. We see pullbacks there. Nothing real significant, but probably we need the arms to get up there. So you get these pullbacks. The arms goes up to 1 and 1 half twos. You get enough energy to probably rally through. So I'm thinking we're going to pull back to around 440. This ratio, our ratio is a bullish divergence. So that gives you confidence to buy on that decline. Right. Because the bigger trend is still up, according to this ratio. And it does a pretty good job picking out the lows, too. If you go back and look at the May, June low, which is that red box there, that ratio is going a little bit higher highs. I see it. Marcus is going through the floors. Look at that, folks. OK, if you're in your car, remember, this is Archive 2, folks, because that is. Look at that, man. It almost gets down on the bottom, but it didn't. Interesting, man. Yeah, and that was the low. OK, cool. That was the low. So the most, and actually, if you look at the top window there, too, normally the VIX will start going up before the market actually tops. Yes. And usually it gets above 17 when those tops come in. OK. And so we got, as I did this chart, we're at 13. And so even though we're kind of consolidating here, we may have a minor pullback just to probably scare everybody for a week or so. But then probably the Christmas rally will start and we'll rally to year end. But usually the VIX will go up and above 17, you're getting above 17, is when you have to really start watching the market. Even though the market may be going up, that VIX is up past 17. Chances are you're going to enter some pretty turbulent water where the market does. You know it's pretty wild, Tim, is that right now the VIX is just hanging out here. And it's been hanging really in the same place minus one day for like 10 trading days so far. Oscillating around the 13 mock. So it's pretty wild. Yeah, but on the bigger time frame, it looks fine.  Yep, absolutely. So you can't really see it on the bigger time frames, but the short term time frame is the VIX too. It's been going up, it was low as it looked like in the 11s. Now you're around the 13s. Going up, even though it's a minor divergence, you still probably get some short term reaction to it. OK. So you're looking. Now to go back to chart four again. OK. OK, I got it. Back there, yeah. See if you see that over the last couple of weeks how the VIX has kind of turned down? I do, I do. That ratio. So that's what we're looking at on a real small timeframe. The SP's keep making higher highs. Now, the ratio's going down. So you're probably going to get some sort of reaction here soon. You know, not months away, you know, days away. Let me ask you this. I don't think I've ever asked you this.  And this goes, folks, the first time I met Tim, I think is, well, you know, on the first time I met him, my person was 96. But I think I met him in like, I had him on 94. How did you come to the conclusion that you're going to start using some of these ratios looking at the marketplace? I just needed something more than what the trend was giving me. Yeah. And, you know, trend works great, you know, but you know, even that last low of October 27th, the 10-day trend never even got close to 1.2. OK, cool. OK. So, and these ratios actually helped me, you know, how did I come up with the ratio? I'm thinking, you know, I like the VIX. VIX has a lot of information. So I started messing with the SPX VIX ratio. Then I started, you know, the bond market has a lot to do with the stock market. Totally. So I started messing around with the TLT. Cool, OK. And just, you know, there's trial and error, and, you know, and just started screwing with it.  Yeah, pretty cool. Just stay right there, folks. Tim and I are coming right back. We have the Dow Industrial's up about 49. NASA's up 181. SP's up 31. Tim and I are coming right back, folks. Welcome back, folks. Tim O'Rourke with Tom O'Brand. We are talking with Tim. We are talking about these different types of ratios, folks, that Tim uses that he's going to be teaching at TFN next Thursday. So go to the front page of TFN and feature content. You can sign up right now, and you're going to be very happy you did. OK, Tim. All right. So we've got a chart four. So, you know, the bigger picture, because of the SPX VIX ratio making higher highs, where the SPs are still testing the previous July highs, is just, at some point, will make a higher highs, because the SPY VIX ratio leads the way. So let's go to chart five. OK. And this chart, you know, this is not really racist. This is a McCullin-Oscaraxi. The top window is a McCullin summation index. Yeah. And it works pretty good. All right, I kind of, you know, I do it with my trend.  You're going into a climatic low. And so that's all the blue lines across the chart there. When the summation index hits below minus 700. And October 27th, we were, I think, minus 813. So we hit climatic low in that vicinity. So, you know, my downside was pretty minimal.  Yeah, but, you know, 90% rally, in my opinion, was over. You know, so I had to worry about Monday or Tuesday, probably, if we're going to go down. Actually, not the rally, more downdraft, I mean, right? Yeah. Right, yeah, because you really got the downdraft already there, you know, that's. I looked at the summation, you know, it's minus 800. I mean, oh, well, can we go? Well, we can do a little work. Hey, Tim, what was the... 90% of the climb's done. Right, I know that the sun runs it now, but what was the father's name? Um, oh, yeah, Tom and... Tom, because, you know, he's the one that, he's the one... Tom is the sun. Oh, Tom's the sun, well, Sherman, right? Sherman, Sherman, right, Sherman. Well, Sherman's the one that gave me a number, you know. He didn't want to come on. I just realized this, man. I was calling people up, folks, okay? And I saw this thing, this immersion today, it says, like, what is this thing? He's the one that gave me a number. He says, no, I don't want to, you know, be on them. You know, just not that type of person. He's the one that gave me a number. And then I had Tom on, of course, after that, because Sherman only did it a few more years, and then Tom took it over. Isn't that crazy? Yeah, that's crazy. Matter of fact, they invited me out to California, and they were doing an investment club out there, and they had that investment club. I see. They were probably, oh, the people when I showed up, I was one of the, or actually him, and Sherman spoke, then I spoke, so there's just two of us, but they paved my way out there. Yeah. And I gave my, I was doing my tick, and you remember that tick thing I was doing? Oh, yeah.  I still love that tick thing, man. Yeah, yeah, yeah, it's, you know, you gotta find things that give you a panic. Right.  So, but yeah, it worked great. And as with Tim, I went presented out there and I met Sherman, met Tom and, and so. And folks who, what's cool. You can get back to this. Okay, guys. Yeah, they're both nice people. Yeah. So anyway, we got minus 800 on October 27th. That turned out to be the low. And so, how does summation thing work? Do you want a selling climax, and others reading below minus 700, then you want a buying climax, and that's a reading above plus 1,000, you know, like to happen within two months. Yeah. So October 27th was a low. That's one of my hit minus 800. As I did this today, we're at 461, approximately. So we got about, you know, 540 to go before we reached 1,000. And we like to have that happen around December 27th or before. Yes. Which is about what? Another two weeks away, three weeks away, whatever. Right. So now if we do get that, now that adds quite a bit of oomph to the bigger trend. Oh yeah. We have two of them, pretty much in a row. We had one coming in, you know, first of the year, that was October, then actually January, we had, you had October, you had the selling climax blow 700, then you had the buying climax in January. So that's actually about three months. Not ideal. And now you get another one, you know, that climax October 27th.  I see. Because when you get these signals, if you go back and look, this chart goes back to 2007. Right. You know, sometimes those signals last years. Right. You know, you got one, you know, the COVID crash, which is a March of 2020. Yes. You know, the market went straight up for what, two years? Exactly. Exactly. So, you know, that would blow well, so don't know if it'll happen, but if it does happen, you know, you can't really be bearish. So, so I know, we'll see, but the bigger trend at the moment is still up. Right. So I don't see a big top here forming, even though there's quite a bit bearish talk out there. So. Oh, there's plenty of bearish talk out here. This is what's actually so cool, folks. Okay, because, you know, the euphoria is not out here. And so that's pretty intense, man. And we're right next to highs. That's what's really weird, Tim. Do you know what I mean? When you think about it. And I guess this has been a year and a half that, you know, we went down and, you know, unless you're doing this every day, I don't think people realize how close we are to the highs, actually. Yeah. Yeah, we'll ruffle close to highs if you know what you did.  And that, you know, ideally you want that trend to go up right through the ceiling. Right. And to get some panic going, and you know, that builds energy for the next rally. Yeah. So we can put through the gold market real quick. Absolutely. Good. Everyone wants to hear that, that's for sure. Okay, so I get the weekly gold shot up, with the weekly XAU gold ratio, and then the weekly XAU, cool, okay. All right, this chart goes back to 2013. And what it is, just the honest eye of that ratio. And every time you get it below 30, in other words, that's when gold stocks relation to gold is going down a lot faster than gold's going down. Yes. When that ratio is getting killed, gold stocks are actually getting killed. Right. And that's when the opportunity rises. So you're trying to pick out the worst top possibly ratio to find, and when the RSI gets below 30, that's usually a good, oh, which we did have two signals back in 2022. One in July and one in September, because the RSI hit below 30, went up a little bit, and hit below 30 again, so it kind of gave a double signal. And it is a good signal also for at least, near me at term tops, when this ratio gets above 70. And we had that happen back in, looks like about, I don't know, March of 2022, got above 70 in July, September got below 30. So anyhow, my point is to the next chart. Okay. And in order to ask you, when we left off on Tuesday, and as soon as we come back, we'll talk about this. You know, when we were looking at the GDX on the monthly, you were talking about the aspect of getting above the middle Bollinger band, right? Yeah, yeah. And it looks to me like the monthly actually is there right now. Stay right there, folks. We're coming right back. Welcome back, folks. Tim Oetomo, Brian. We are talking gold now. Okay, Tim, go ahead. Chart number seven, quick look at that. Okay. It's a monthly XAU gold ratio. And I use these castings on this because it just works. Okay. This chart goes back to like 1984. So it shows all the signals going back to 1984. And the last thing we got was August of 2022. And this signals are really pretty good for the bigger timeframe. And it's kind of gone up, kind of going sideways here, but most of these signals, when they get, the flow of the castings is below minus 10, which it did back in August of 2022. And it turns out, most of the time, those are multi-year rallies. So I'm thinking the August of last year was the bottom. I see, yep. So I'm thinking the market is actually in a bull trend right now since August of 2022. So flip to chart eight real quick. Okay, I'm there. So now we're into a real small timeframe. And I got a minute to talk about it, but you know, the head and shoulder bottom formed the top window of the GDX. Yes. I thought the October low was probably the head. Had a right shoulder. The neckline was around 30. We had a sign of strength through the neckline. And the bottom window is the 18-day average up-down volume. The next window up is the 18-day average advanced decline. As long as both those two indicators remain above 10, they are one's plus 16, the other's plus 20, then that probably 30 area GDX will hold. And just to give you an idea, folks, okay? You know, at that sign of strength, we went up with 41 million shares. And Tim, we've only done 14 million today as we're coming back into it. 41 million to 14. Pretty wild. Well, listen, man, you have a great weekend, a safe weekend. We look forward to speaking the next Tuesday, Tim. All right, thank you. Okay, stay right there. This is a fast hour, man. Have a great one, have a safe one, folks.


Sylvester Stallone right now is pissing a B.I.T.C.H. about him not owning Rocky or being part of the rights if I'm not mistaken for the new Creed film. So Michael B. Jordan is directing it but he's pissed off that he has no hand in it. But if you listen to what Sylvester Stallone's been saying for a while he's been saying he this is um Michael B. Jordan's thing now his character is saying he's going to step out of it but I guess he had to change your heart and now he's back. Okay so long story short he has no rights to this film he's pissing a B.I.T.C.H. so he has no rights. If it was me and I was Sylvester Stallone and being a smart man that I am I would have went ahead and renegotiated my contract around Rocky II or III coolant III three pop off big I would renegotiate my contract and definitely have somehow gotten rights to the Rocky franchise hands down. Yeah but this is what broadens me about a lot of these actors whether in any type entertainment business when things don't go their way then they blame the company. Yeah it's like dude you're Sylvester Stallone. Yeah you should at the peak of your thing you got to get him for everything is worth you get what I'm trying to say. Yeah I understand like in the from the you know the onset he had like a hundred dollars to his name when he did the first Rocky yes they had him over a barrel. He sold his dog. Yeah I think he was sleeping out of his car. So that I agree I would have did the same thing. But by the third movie like you're saying I mean he's already a millionaire at this point that the franchise is huge he has he has negotiation you know. Let's not even include the whole point he was still doing like Rambo and all that. Oh yeah so he was like a mega star. Big star he was one of the biggest stars. Bro that's like the rock right now wanting to piece the franchise of anything he can do if he's killing give give him what he wants. So I think the rock is the rock's making all the moves that these older 80s actors did not think to make. That's what I'm saying you know so what I'm thinking of what I'm saying basically is that Sylvester Stallone F.E.C.K. himself and now he's pointing the finger. You feel I'm trying to say so it's like dude it is what it is. Yeah it's like I don't really care so much about the crocodile tears coming from Stallone. I love the guy he's made some fantastic movies. Let's move on. But the whole point to he's trying to dog creed three which I don't like.  So it's not but did you say it's not because of Michael B. Jordan. No it's not really because the producer on this thing is the same guy that's been you know making money off of this dude for a century and he's also making the Ivan Drago spin-off movie. I heard about that. Yeah yeah I heard about that.  But another thing to that too though Sylvester Stallone once again he said that yo he'll work on Creed 4 as long as this producer guy is not in it. So it's like dude like do you want to be down or you don't want to be down like which one is it here. Like you felt I'm saying. He just see even in Creed 2. Creed 2 was trash. He felt like I didn't think it was trash but I definitely thought it was a step down from Creed. Creed 1 was really good. And I think it was a step down not because I'm like will be Jordan he was putting in the work but Stallone it was like sleeping through all of his scenes. He was dragging. He was definitely especially in that final fight I was expecting him to be like Mickey and be like knock him out but he was back kind of like yeah good job. I'm gonna be funny though Sylvester Stallone did give a good reference for people who watch boxing. He was like he read the script for Creed 3 and when he was reading he was like okay so where do I fit in in here. He said basically he uh compared it to I'm just gonna carry the spit bucket.  He's just yeah he's carried a spit bucket. Unsung hero. Yeah basically so he's like I was carrying the spit. I thought that was funny. Do you think they killed him?  I think he's dead yeah. You think Creed goes to like Adonis goes to like his grave?  Yeah he's off the grid.  Yeah I agree with you. I agree even though don't do that. He's back at his restaurant. He's doing good things.  Like I think this is one segment where he's just not gonna be a part of it. Yeah but he said he'll come back for Creed 4 but like I said man make up your mind bro which one are you gonna do? God I should point out that we are in like folding chairs right now it's just a bad scenario. We got to get some better chairs in here. Well we got to get a better setup. Once again this reminds me of if I was kidnapping somebody and I was holding my gun Yeah well yeah. Why don't we try to make it comfortable? That's cool.


We want to best have the freedom. Others, all the others said we have not acknowledged up until now in the creative category. Do we want to invite on stage Manchester five minutes to go. Let's go! Let's go! We need to have freedom in Manchester. Needless to say, for a while I saw the leaders of the United Nations from the United Nations. We want to best have the freedom to invite on stage and cross the table.


The stream connectivity surveys began in 2007, after looking at the Penobscot River Restoration Project, we realized that a whole lot of habitat was upstream of the main stem dams. And that connectivity was a problem. So fish as well as all life within stream really needs a lot more movement up and down along the channel. It's critical that the processes that move material up and downstream can continue unabated without constrictions, without barriers that hold back sediment, and allow free movement. Working with partners at the Main Forest Service and the Natural Resources Conservation Service, U.S. Fish and Wildlife Service, we started conducting surveys around the watersheds. This is an exciting collaborative project with multiple stakeholders. The stream crossings on Plum Creek land have varied in their history and in their quality going back decades. Through this collaborative project with TNC and others, we are able to inventory our stream crossings, and then through data analysis, we can zero in and filter on those particular stream crossings that have some issue, whether it's a barrier issue for fish, and then decide collaboratively on a plan going forward.  And what they do is they come up to that crossing to basically do surveying of the structure. So they're measuring what the length and width of the structure are. They're measuring the depth of the water and the width of the stream so they can get a better determination of whether the structure is actually constricting the stream. Maine Audubon has been leading a collaborative effort over the last four years called Stream Smart, which is designed to help people understand why it's important to replace these poorly functioning culverts and bridges. We've been doing trainings with road construction crews and engineers and landowners all across the state. By reviewing and inventorying stream crossings across our land, we can pick out those stream crossings that need attention and then use this new technology such as cement blocks and different types of material. What used to be at this site were two smaller undersized culverts that would hydrologically pass the water, but once again it doesn't help that ecological function. We decided to span the whole creek with this arch culvert. Basically half of a culvert that the whole bottom's cut out and then to stabilize the roadbed and the sediment around it we've added those bigger boulders of the riprap. So to improve the ecological functions at crossings we're trying to go to structures like this that maintain the natural bottom and are big enough to try to span the whole width of the creek. For the past four years there's been a very concentrated effort with crews that have been trained up and worked throughout an extended field season that's been funded by the Nature Conservancy with Maine Audubon. There are probably 35 large landowners that own most of the state of Maine and it makes sense to conduct outreach to each of those landowners where we can work in terms of collecting data, sharing information on the road base and help point to priority places for restoration.