Scaling bitcoin transcript request
It's interesting also that, people who do not upgrade, get access to scale. People who upgrade, leave empty space in the base block which could be used by people who haven't upgraded. So this does support quite well an incremental scaling that builds up over time as people opt-in and the new space left by people opting-in is used by new users coming in or existing users who haven't upgraded their wallets, creating new transactions. Hopefully new users will of course be using segregated witness compatible wallets, though We were talking about the orphan problem and how that is significant for mining.
There is an interesting technical solution to this, to convert a latency bottleneck into a bandwidth bottleneck. The physical network has excess bandwidth, the transport mechanisms between miners and pulls. Full nodes that are not mining are not entirely sensitive to how quickly they receive blocks. They don't need to receive in 3 seconds, 10 seconds would probably be fine.
The idea of weak blocks is that we could push the network harder by using up the excess bandwidth currently going unused. Assuming this happens next, the weak blocks and IBLT goes live, then we would be in a position to make use of the excess bandwidth without worrying about the current orphan rate problems. We could increase the use of hte extra bandwidth, perhaps with a hard-fork planned ahead, it could potentially be done with a soft-fork but I think a hard-fork would be more likely.
Another potential upgrade would be a kind of flexible size, a block size that could grow over time automatically , maybe reacting to demand in some way, and that's what the flexcap outline proposal kind of does.
It's possible that this would happen next or a simpler block size change would happen next. This should deliver another 2x scale increase. We can see with these three changes we get to the scale that was talked about in the requirements section of this presentation at the beginning. Then we can talk about the layer 2 or Lightning and so, that can happen in parallel, it's not waiting or deferring, there are different people on different teams developing Lightning today. I think there are 4 or 5 companies working on this.
Most of it is open-source where you can contribute as well, with mailing lists and source code posted. So basically the existing segregated witness testnet is now being used by people working on lightning, because it provides everything they need, once it goes live, there will be no network features missing that would prevent Lightning. So that's an exciting progress. In terms of Lightning, the estimates are, they vary it depends on how the usage pattern works out, but there are estimates that are maybe to 10, times more transactions than on-chain transactions.
It's important to point out that Lightning transactions are real native Bitcoin transactions zero-conf zero confirmations but with an initial transaction that gets committed into the blockchain. They could be posted to the on-chain but there's a caching mechanism that collapses them so that they don't all need to be sent to the chain.
This is a write coalescing disk cache or something. What could we do with this huge amount of scale? We might see new types of use cases, like micropayments, or low-value payments, bringing in new users and use cases. For example, sending a small amount of bitcoin with an email or some people have talked about using this to pay a website a small amount of money per page view and that would maybe provide them a better source of revenue and less frustration than ad blocking, and something like Lightning might be able to provide this.
Another interesting property of Lightning is that it provides instant and secure final confirmation of transactions. One of the problems that people have with Bitcoin payments is that technically you should wait until the first or second confirmation, which is about 10 minutes for the first confirmation.
This is far too slow for retail payments. There's a chance of "accepting" a payment and then not getting paid. Lightning can provide a secure and instant confirmation which is great for that retail problem as well.
Thank you for your comprehensive and interesting presentation about Bitcoin scaling issues. I see the audience lotta of important and people from Czech and Slovic bitcoin community. I think these people can wait for question to you, any questions? I have question of course. Thank you Adam for coming. Your presentation was quite technical. My question is completely untechnical from the social part. You were involved in bitcoin from the very beginning, maybe one of the first people to interact with Satoshi Nakamoto.
But I heard that you really started to think about bitcoin in when you bought your first bitcoin for real? How could this happen? I guess I am happy to think about the technical protocols. Other people are more practical and are eager to try software out.
At the time, Hal Finney was the first people to try out Bitcoin and write a report about how it works. I was content to read the report and think "that's very cool". Also for some reason it seemed to me it was uncertain whether this would bootstrap. I was kind of taking a wait and see approach. Different people saw potential earlier or later, some tried it out and kept some coins, yeah that's how that happened.
This is contrary to how people think, that people who were in the beginning saw that bitcoin would previal and rise. For example, for me, I was really switching to bitcoin really fast but this is only because I didn't see the past where a lot of trials failed. My name is Maria. I am relatively new to this topic. I wanted to make two questions. I read before that bitcoins can be stolen.
What if someone sends you virus over internet? Is that even possible? The second question is, let's say with money, with paper, with this system that we have, people make illegal ways to make money.
Like money laundry and so on and so on. Is there a legal way to make bitcoins? Right, the theft problem. Bitcoin is interesting but irreversible transactions means that it's relatively unforgiving. It stresses computer security. For an average Windows machine, it could be dangerous to store private keys.
At least if you lost it you would know that you had a virus and that you should reinstall the machine or something. For higher security applications, people should be using hardware wallets like the trezor or smartphones where they don't install much software on, even smartphones can have security vulnerabilities.
You can also potentially use trustless vaults, there's a multisignature mechanism where you can work with a provider that helps you retain security. Your second question was regarding illegal uses of bitcoin. It has some privacy, but it's not great privacy. All of the transactions can be followed on the network.
The entire ledger is public data. There was a presentation recently by one of the internal investigation team members who were investigating the corrupt law enforcement agents, they were able to trace the transactions and figured out how much BTC they took and determined it was indeed them.
In many ways, bitcoin is more traceable than other forms of payment. Physical paper cash is more attractive these days for illegal behavior. There's far more volume in physical paper cash too-- way more crime and greymarket transactions go on in the world than the entire market value of bitcoin by a big magnitude. If people want to focus on reducing crime, there's other areas to focus on that are much more productive to focus on. I have a question about hashcash.
Have you thought about this idea of for combatting the asymmetric problems like DDoS attacks. Very easy to send traffic to a website but difficult to consume. I think the hashcash problem is very nice. I implemented this in an anti-DDoS proxy. It seems like the idea is frozen. I am wondering if you have any new thoughts on this or new developments. There were some attempts to use hashcash for DDoS. There was somebody using it to deter click fraud where people are receiving money per advertising click.
They would cause people to mine hashcash on the CPU and only count the click if it actually happened. There's a wordpress plugin that does something similar to deter abusive blog spam, which is trying to artificially increase search engine rankings by pasting links everywhere.
Another idea was a more dynamic, I think there was an internet draft by some people at Cisco some years ago where they proposed that you would connect to a web server and if the web server was underload, it would request some work, and if it was under more load it would request more work.
If the web server would have crashed anyway, some people could get through this way, but only the people with the plugin or the person with the most powerful hardware would get to use the service. This was such that people would be able to get some level of service rather than nobody.
I forgot the name of the primary author of this proposal. I don't know if it was ever used. The other things it was used for was anti-spam, so spamassasin actually respects hashcash postage stamps.
The microsoft mail suite, like outlook and exchange and hotmail, have their own hashcash with a different format. It's not compatible with hashcash. They implemented that as an anti-spam mechanism in that ecosystem, I think it's called postmark, they released it as an open specification so that anyone can implement it in theory although I think Microsoft was the only one to implement it. The other problem with hashcash is that people make ASICs.
I figured that if this was massively successful that spammers would make hardware to overcome this limitation. I was thinking that if hashcash would become widely adopted, that individuals should have ASICs too to keep the playing field level.
Yeah that could help. That's a related topic for bitcoin. Some people wonder about if in the very long-term we should consider, with a lot of notice like 3 years notice, to change the hash function in some way. Or changing it, I think there are some coins or proposals to change the hash function every 6 months.
And maybe that would prevent or deter ASICs, but I think it wouldn't ultimately solve the problem because it's a universal rule of software that hardware wins. People would look at the catalog of hash functions, look at the common properties, and make things that accelerate them, or make optimized FPGAs, or make GPUs that are optimized for that purpose, without the graphics IO and whatstuff.
Ultimately, specialized hardware always wins, especially if the problem is dynamic, because the space of techniques and functions has to be specified upfront. The other problem is that it makes it harder to make ASICs. Also, it's part of the social contract that changing the PoW hash function is controversial. It's possible to not just change the hash function, but the problem itself.
If you have a web server giving you a javascript PoW problem, if you solve it, and if an attacker can create an ASIC that can solve all the problems, it's profit anyway. I think the general fast problem solver for proof-of-work is something like a GPU or there's a company making CPUs sort of like a high core count, a very simple RISC count like cores in a chip. Those kinds of things are maybe, maybe they are single-threaded performance is weak, but they have a much higher execution throughput than a conventional CPU.
ASICs are, with mining, mining is fault-tolerant, if you make a general purpose CPU you need some huge number of 9s of reliability. You can get those kind of CPUs and push it to the limit and then use it for general purpose execution with a JIT compiler for whatever the web server is sending you. You can still get pretty decent advantage over a conventional user. It's very difficult to get a, it doesn't take a strong advantage to break things.
It doesn't take much for a miner to win all of the mining output or all of it. It is challenging to make a fair algorithm. It pushes the hardware design in a different direction which is more complicated.
For us it's both latency and bandwidth. Because of the great firewall of china. I could imagine a scenario where you build a block on the other end, but you are still missing the transactions stuck in China. What are your thoughts on this? Perhaps the solution is to get rid of China so that they don't have the majority, but that's hard to do. So you have a node in China? That's the right thing to do. That's not China's problem. People misunderstand this sometime.
But you said you were concerned about bandwidth? Well there are some separate things to do about bandwidth. There are a number of proposals to compress blocks. The IBLT part is for compressing asymptotically by a factor of 2 that all the transactions go against the network and then again in a block but with IBLT you basically send the transactions only once then you send a compact list of which transactions, like "these are the transactions I am using" which could fit in a handful of TCP packets.
This is what you see with the relay network. It conveys how to construct the block with a single TCP packet most of the time. There's a high bandwidth saving. There's not much more bandwidth saving you could do. You must receive the transaction. Transactions exist and there's a compression limit beyond which you cannot compress them further. Other things which could be done for people trying to run nodes in constrained bandwidth situations is to turn off relaying.
You could be a leech on the p2p network where you just receive transactions and not relay them. It's not giving back to the network, but perhaps it's better for people with high bandwidth to provide the relay function to the network instead. I think it's important that blocks be constructed, sometimes when people talk about bandwidth constraints in China or something, they all say well okay but they can just rent a server in Singapore or somtehing with high bandwidth and low cost and relatively close and that will solve the problem, but it's another form of centralization.
What makes bitcoin have its properties like policy neutrality and permissionless is that there are too many jurisdictions involved to impose policy. Because of the many jurisdictions, there might be one thing blocked in Singapore but not blocked in China.
If they are not constructing their own local blocks, we lose that diversity of policy. It's interesting to know that you have gone to the step of obtaining a node in China. That's interesting, I don't think many people have done that:.
The relay network is doing some really odd things with routing. Sometimes and I guess this is why you have nodes, you are probably doing the same thing. You would think maybe we should route over the internet and it will go through the shortest route. But in the relay network, BlueMatt has rented VPS in very strange places that can achieve a very short route faster than you could achieve over the public internet because the routes are otherwise too ridiculous. I have a question about the hard-fork which happened in the beginning of the year.
I am wondering about your take on this. What do you think about this hard-fork by Bitcoin Classic team? Do you think it will happen again? How do you prevent this? So it brings another question more philosophical like, is decentralization attainable?
When you take something like the linux kernel, it's open-source software and everyone can add new features, but you still have one guy managing Linux. Is it a mistake to not have one person deciding? I'll talk about the second question first. The counterargument has been that if you're applying it to yourself and imagine that you have decisionmaking power about what features go into Bitcoin, I would feel scared to be in that position because over time powerful forces such as governments that would like to change the properties.
You can see a preview of this in the Ripple company, where the government asked them to make changes to the protocol which were not popular with the users. They were in central control so the government asked them to make those changes. We have to achieve neutrality and keep primary the features that users value in Bitcoin.
Having developers in different countries working for different companies and having strong independence, is maybe a more robust way to keep the system independent and retain the properties that Bitcoin users prefer.
We're looking at a snapshot in time wondering what will happen in the future as companies and governments might want to influence Bitcoin protocol design. I think that if too many properties are lost, Bitcoin will lose its value.
Bitcoin companies at the moment should find it in their own interest to retain the existing Bitcoin features even if governments maybe bully them. Your other question about hard-forks, I think it's a question about tradeoffs. There are different ways to do upgrades. They have advantages and disadvantages. It's possible for different ecosystem companies to have different views because maybe they specialize in a different area of business. A miner might prefer one feature, a payment processor might like another, and a user might like neither.
What you are seeing is that some people have different preferences. In some sense it ties back to "what are bitcoin's differentiating properties? Not necessarily everyone agrees on Bitcoin's desirability. If you make different assumptions about what's important, you can end up with different conclusions. I think that one of the debates is how fast can you do a hard-fork. On my slide, I put the simple hard-fork which is like bip which I think you are referring to, and in my view, and I think quite a lot of the developers believe that there is a tradeoff where the faster you do it the more risky it would be.
If you do it tomorrow it would be a disaster, in a month it might be a rush to see everyone upgrade and there are risks for people who haven't upgraded, and it requires a lot of coordination which the bitcoin network and ecosystem hasn't tried to do before, like how do I call up this person, how do I reach this node, how do I know who is running a node, there are even bitcoin services running that are economically active but the nodes are running with old software.
There was a story about a mining pool still running that had a few petahashes and was mining invalid blocks for a few months. There were miners pointing at the pool but the miners weren't checking if they were receiving shares.
It's hard to do strict planning. In a top-down managed network, there are reporting responsibilities and who to contact and the people they contact will cooperate and collaborate to achieve that.
But in bitcoin, it's a peer-to-peer network so it's difficult sometimes to reach or identify people. In many ways this is a feature of bitcoin that some components of it will be possible without identity. It's good that miners can be permissionless and not necessarily identified, because this makes it harder to apply policy requests to the miner. This at the same time also makes it difficult to contact the miner if they are mining invalid blocks or if we want them to upgrade or something.
It's a tradeoff, it's a grey area, it depends on how optimistic you are, it depends on how important immediate higher scale is to you.
Maybe some other users wont want to take the same risks you would prefer to take. I think it's a question of different users and types of ecosystem companies having slightly conflicting views and preferences. We'll see how it plays out. Ultimately, for the network to upgrade and scale, it needs people to work together, it needs backwards compatibility, upgrade mechanisms will not work if people don't work together.
It's up to the ecosystem and the users really. At the end of the day, developers are writing software and if nobody runs their software then that kind of shows that the decision is the users' to make, they can choose what software to run.
As I mentioned briefly, the economic nodes control the consensus rules, the miners have to follow the economic views of the running software on the network. There's no hard and fast answer but I am hopeful that Bitcoin will scale. That's a lot of centralization. For sidechains, you have to be on the same sidechain or else you have the doubling of transactions as described earlier. Inside a payment channel, you just need the same relationship.
So what we propose is a payment channel between many parties in a multi-hop hub and spoke model, like internet routing. This uses minimally trusted intermedaries. They can't take your coins. It does not involve a third-party custodian. This does require a small malleability soft-fork. We kind of need to fix malleability anyway. If we fix malleability, we can do this. We were looking around to see who came up with payment channels.
There's some stuff in I don't know who came up with the idea and we may never know. Anyway, it's an old idea, well old for bitcoin. Payment channels require multisig. It allows two entities to send transactions to each other rapidly without hitting the blockchain each time.
I am going to go through the basics of setting up a two-party unidirectional payment channel. Alice can only send money to Bob through this. So what she does is she gets a refund transaction. There's a multisig address that Alice and Bob both have control over. Alice wants to send 1 BTC to it. Before she does so, she gets Bob's refund signature.
So at worst, Alice loses access to her funds for 30 days. Bob creates this timelock refund transaction.
Alice can either sign it herself, or it can wait half-signed. Alice keeps this on her hard drive because she knows that at the end of the month she can get her money back.
Once she has this, she knows it's safe and she sends bitcoin to the multisig address because she knows worst case she can get it back. Once it's in the multisig address, she can commit to payments to Bob. Alice can sign this and then hand the transaction to Bob. She can give 0. She will sign this transaction. It's not valid because Bob has not signed it yet. Alice cannot push this to the blockchain because miners would ignore it.
She can give this to Bob out-of-band. Bob can treat this as a payment. Bob can sign this at any time, and then broadcast it to the network, and in doing so close out the channel.
Instead though, Bob will wait. He knows that the channel is going to be open for the rest of the month. The next time that Alice pays, she gives 0. He sees that this is better for himself, so he will broadcast this transaction instead of the earlier one.
At some point, Alice might request the channel to be closed out and Bob could cooperate, or if Bob is a jerk he could wait until the end of the month to sign a transaction. If Bob waits too long, Alice gets all of her money back. So Bob is motivated to sign this at some point before the end of the month the locktime expiry. The network only sees the multisig transaction with two outputs.
So during that month period, she can send as many small microtransactions to Bob as she wants. You can change the direction of channels after you create it. Setup the refund transaction, fund the multisig address. When Alice spends to Bob, she adds a locktime nlocktime. So now Bob wants to pay Alice back for whatever reason, Bob says I am going to pay Alice now from the money that you were paying me.
He can provably commit to a payment to Alice by overriding this transaction. He sets a lower locktime on the transaction.
So this is a race between when people make a transaction published to the blockchain. You can't do this a million times. You only have so many times you can use a shorter locktime.
Changing the direction requires bringing the expiry closer to the present. They can both sign a new thing with no locktime if they cooperate. Okay, so then I will transition briefly to 3-party payments. I will show the motivation and Joseph will talk about how it works. Let's say that Bob is a big company or they are some kind of payment processor like Bitpay or something that people use a lot. Alice has a channel open.
Carol has a channel open. Everyone has a connection to Bob, and Alice wants to send to Carol, and this is the future where sending a bitcoin transaction is expensive. It would be nice to send to Bob who can then send it to Carol instead of using an expensive bitcoin transaction.
So Alice can send to Bob and hten Bob can send to Carol. This is a micropayment network. But there's some trust issues here. Bob might just take the bitcoin that Alice sent. And Carol could claim that she never got the coins, and there's no real way to verify whether Bob took the money. So this doesn't really work.
It might work if you trust Bob but we're trying to minimize trust. So Joseph is going to talk about how to actually do this. Yeah that model works pretty well. You can use 2-of-3 multisig to help mitigate the problems. It would be nice to do this in a trustless way. You can create a hashlock contract. A hash function is a undirectional cryptographic method whereby you take some input and you get some output that cannot be reversed. What you do is you take some random data R and you convert it through hash or whatever and you use that as a key and you need the lock which is the random data R in order to unlock the funds encumbered.
And there's a paper from called pay-to-contract and essentially if Alice has the data R which produces H, she can say I have paid you the money. She does that by the receiver writing some signed message effectively a contract that says if Alice knows R which produces H then at that point Alice has paid me 0.
And you might ask yourself, why not just check on the blockchain? Because everything we're discussing here is off-blockchain. So you need some way to prove that funds have been sent.
So essentially this right here is what Carol produces. She has some random data R. And she runs it through some hash function like hash to produce H. She gives H to Alice. Now Alice knows H but doesn't know R. And Carol knows both. Alice uses a payment channel payment to Bob but this is encumbered and can only be released if Bob can produce R.
Let's assume this work; if it doesn't work then bitcoin has some problems. Bob does the same with Carol. What happens is that Carol has a payment from Bob that is encumbered. Carol can only use these funds if she gives R to Bob or broadcasts it to the blockchain. Carol might tell Bob R because she wants her money. Bob and Carol can broadcast the channel on to the blockchain, or they could agree to novate "I know you know R, I know you can put the funds on the blockchain, let's not do that because it's expensive, let's do it in the channel".
If Bob is uncooperative then Carol can broadcast it on the blockchain. But assume Bob is nice. Now that he knows R, he can get the 1 bitcent from Alice.
So Bob was acting as an intermediary, and it wasn't a substantial risk. He can always pull funds from Alice and give them to Carol. But the problem is that if Carol refuses to disclose R she could hold up funds in the channel. Alice and Bob's channel has already hit the blockchain. Bob could be out of the money. Also, Bob has to be sort of wealthy. Alice can't receive any more funds because she's sort of full. If everyone gives money to Bob, you kind of want Bob to send money out, to create channels outside; if Bob sends money to Alice then that has a channel that can be spent so the system sort of works.
The availability of funds that Bob has, has some implications for fees. Bob just needs to be really rich on a single hub-and-spoke model. Say that Bob is rich. How do you mitigate the problem? You can do third-party multisig where the Alice and Bob payout is using a third-party escrow service. That could work fairly well today. You could also trust that Bob would be honest and send the money and not encumber everything. But what we really need is a trustless model.
Corruptible custodians are undesirable. You want to make sure Bob is unable to steal funds. Complex chained transactions in bitcoin don't really work because with malleability you can create hostage scenarios where if funds are locked in 2-of-2 multisig then the refund transactions are not spendable because the other transactions were mutated.
So this creates a hostage scenario and one attack here involves the time value of money where one party might be able to tolerate a longer locktime in order to intimidate the other party Kimberly was able to estimate that of that finite chunk of bitcoins - remember, there will only ever be 21 million of them - there is a painful amount locked away forever.
And on one hand, it shows the most obvious problem with a ruthlessly decentralized money system. If you lose your private key, you lose your bitcoins.
In a centralized system, if you had a sack of U. We did a whole episode about this. On the other hand, all of this last bitcoin illustrates something, like, paradoxical, almost, about Bitcoin.
We think of it as this ephemeral thing that can just disappear. But it's there forever, and no one's making new bitcoin. There's only going to be 21 million estimated bitcoin in the history of the stuff. And all of this lost bitcoin is reminder that this is digital, yes.
And you could lose it easily, yes. But it is truly a scarce digital resource - whatever that means. The other thing to note, Kim says, is that the vast majority of these lost coins were lost in the early years of bitcoin, when the coins were essentially worthless.
People going forward probably won't be losing at such a high rate. Probably most of the losing has already happened. Because who cares about letting a penny fall through the couch cushions? Even if bitcoin goes back down to pennies, I think people will be more careful about their keys. So we can see what - how much bitcoin is in this wallet. Oh, our baby is crying. He and his wife, Jaquie ph , are sitting next to his computer.
Syl's got his digital wallet. He's got his private key. And for the first time in nearly a decade, he is able to open up his virtual bitcoin vault. What is dawning on Syl is that his bitcoin vault is empty. Not only is it empty. He can check the history, and he can see that this is clearly the wrong account. He must have, like, set up a second account, a test account.
A friend must have transferred him a little bitcoin, and then Syl transferred it right back. Laughter I don't know what to do now. Well, this is where we're at right now. This is Kimberly and Jonathan from Chainalysis again.
I got on the phone with them, and we called Syl Turner. Now, we should say here that the Chainalysis company does not want you to call them about your lost bitcoin. But they are very smart, and they're very kind.
And they agreed to hear poor Syl Turner's story and see if there was anything that can be done. So he tells them the whole story, how he's been back into his attic, and there is not another hard drive.
There's not another private key. But he knows there is another account with bitcoins in it. Well, it's a real shame to hear that it wasn't the right hard drive. Unfortunately, what we need to find the needle in the haystack is even, like, a little bit of a key. What Jonathan is saying is that bitcoin private keys are designed to be unguessable, even by the most powerful computers that we have right now.
But if Syl happened to write down part of his key at some point, there are companies that will use that information to help Syl break into his own account. They'll charge him a fee or ask for some of his bitcoins. But you have to have some piece of your private key.
And at this point - and probably forever - Syl does not. This is going to be, like, my deathbed regret.
Like, I should've backed up that wallet. Have you lost something that you need help finding? Let us know about it. Or we're on Facebook, Twitter and Instagram.
Today's show was produced by Nick Fountain. Our senior producer is Alex Goldmark. And our editor is Bryant Urstadt. Special thanks this week to Tasnim Shamma for this amazing audio of Syl Turner's hard drive booting up.
And also an apology this week to Jonathan Levin and all of Britain, really, for my terrible accent. If you are looking for something to listen to right now, we have a new show. Today's show is about the underrated numbers in today's jobs report - the numbers you don't hear so much about that tell us a lot about what's going on in the job market.
You can find it wherever you find your podcasts. Visit our website terms of use and permissions pages at www. NPR transcripts are created on a rush deadline by Verb8tm, Inc. This text may not be in its final form and may be updated or revised in the future.
Accuracy and availability may vary. Accessibility links Skip to main content Keyboard shortcuts for audio player. Bitcoin Losers The Bitcoin market has gone crazy. And it's revealing something strange. A lot of people can't find their Bitcoins. We go looking for lost billions. January 5, 6: Facebook Twitter Flipboard Email.
Testing, three, two, one. So I called my friend Tasnim Shamma There's knocking on the door right now, so - hey, come on in. Nice to meet you. Nice to meet you as well. You want me to just go straight up to the attic? Yeah, I mean, I guess so. It's kind of what we're here for, right? We'll go up to the attic now. All right, so - yeah. Are you in the attic? Yeah, we are in the attic.
Luckily it's not super hot. I'm a little nervous, too. I can't believe this is happening. Actually, one of my old roommates Of all kinds of stuff that Syl probably should have thrown away. So let's dig in. I mean, there's a lot of empty boxes, too. Do you want me to stay on the line with you while you clean out your whole attic? Oh, I stepped on something. Syl Turner still digging through his attic in Georgia.
All right, so I think it's one of these computers. He's pretty sure that is not the right hard drive, so he pries open a second computer. I really did not expect to see hard drives in here, to be honest.
What did you think had happened?