Welcome back to part two of this very special episode of crypto scam with another guest to continue
our discussion of the scalability and the promises of Ethereum, uh, with us for the
rest of this episode is going to be the famous Jameson Lopp and his uncanny beard, uh, who
is now a systems engineer at Casa, a new startup in the space. Uh, formally he was the systems
engineer at, uh, BitGo. And thank you very much for joining me on this episode, Jameson.
Pleasure to be here for the first time. Yeah, you're right. This is the first time I'm interviewing
you and, um, we haven't seen each other lately. I haven't attended too many, uh, Bitcoin developer
events, uh, but your name did come up this past weekend as I was purchasing my, uh, new
toy in the world of hardware and you were instrumental to them in order to actually
stress test, uh, the crypto key stack. So you want to do a quick shout out to them and
a word on what I'm holding? Yeah, I bought a bunch of the hardware metal, uh, storage
devices out there and put them through the ringer, everything from like 2000 degree heat
for a prolonged period of time to, uh, crushing with like 10 ton hydraulic press and the crypto
key stack held up the best to all of those things and, and even more environmental hazards
like hydrochloric acid, rusting, all kinds of stuff. So if you're going to go, uh, with
the metal, uh, that's probably one of the best ones to do. Yeah, no, that's great. Now
this is not a hardware wallet. This is simply a way you can preserve your private key in
a non-destructible way a lot better than writing it down on a piece of paper. Uh, so there
you go. We got a little plug in there. So is that what you currently do mostly physical
stress testing or you mostly focus on technical stress test? Uh, that was a kind of unique
thing for me. I've never tried anything like that before, but I've read a number of reviews
and a few stress tests of, of these metal devices and I just felt like they didn't take
it to the extreme that it really needed. So, um, I think that, you know, I arguably, uh,
put these into conditions that the normal user is not going to experience, but, uh,
you know, we, we like to think adversarially in this space. Cool. So real quick, tell us
about CASA where, um, are you, I'm assuming you are one of the co-founders of CASA as
well. Yeah. Early, early employee, uh, you could call me a partner, I suppose. Um, and
uh, yeah, tell us, um, what, what, what your company does or the company that you are associated
with does, uh, what your exact role is and what is your general role in the Bitcoin ecosystem?
So at CASA, I'm doing similar stuff to what I was doing at Bitco, which is really, uh,
helping build the infrastructure and think about all the backend systems that we need.
Um, and then just thinking about security from another different perspectives of how
can we facilitate these crypto finance transactions while minimizing the trust required. You know,
obviously users are going to be dealing with us and our, our software that we're providing
and there will be some trust, but we want to minimize that as much as possible while
still helping the user be sovereign in what they're doing. And specifically when we're,
we're targeting like user sovereignty, we want to be a non-custodial solution. We want
the user to finally realize the promise of being your own bank in Bitcoin. And we're
doing that by offering very user-friendly mobile app, but that is backed by the security
that you get from hardware key management devices like Ledger, Trezor, KeepKey, what
have you. So while you'll be using a mobile app to actually manage, uh, your wallet, see
your balance, uh, you know, facilitate creating the transactions, the actual private keys
themselves are going to be stored on geographically separated hardware key management devices.
So it's really like a fault product where we're trying to make your wallet robust, not
only against hackers, but against physical attackers and all types of other loss that
can happen, uh, even due to like user negligence. So that's kind of one of the things that we're
going for is lowering the barrier to entry, lowering the learning curve that's required
to be your own bank. Gotcha. Thanks a lot for that background. And is it fair to call
you, I'd say a Bitcoin Core contributor? Uh, from a technical standpoint, I mean, I've
got three or four, um, you know, pull requests that were just trivial changes, usually stuff
that I ran into while I was working on my own fork of Bitcoin Core, which is the Satoshi
fork. So, um, you know, don't have any major functionality that I've contributed there,
but, uh, I am on the list of the, like, you know, 570, uh, people who have a code that's
in the core repository. Right. And from my point of view, it's hard for me to get, you
know, I want core developers, you know, the, our, our top 20 engineers, I, I, I'm not really
here to interview them. I want them working. Like I need them to keep my Bitcoin safe and
decentralized. And, uh, uh, and I know you are very well respected in the space. And
I recently heard you on the noted podcast talking about your adventure in setting up
your Ethereum node. And I wanted to dive a little bit deeper into that specific conversation.
So earlier in this episode, I talked with stop and decrypt who is somewhat anonymous
in the space. Uh, and I, not many people know much about him other than he writes, uh, pretty
detailed research articles. And lately he is, or not lately, but over the summer he
wrote several criticizing the scaler, the technological scalability of Ethereum. Now
as I brought stop and decrypt for this interview, I found out that he's not actually, uh, a
developer. Uh, he's more of a researcher. So I wanted to bring you on and just for a
more developer perspective, because my developer days are long behind me. I did have a degree
in financial engineering. I used to look at code. I used to write amazing VBA code in
the back of Excel. I'm telling you, my VBA skills were not ones to mess with, but that's
as far as I really wanted to go. Started learning some Python and then realized, you know, coding
is not what I really want to do. Um, so I'm actually gonna pull up screen share and we'll
jump right into, uh, the full topic. So, uh, the first article that he wrote, it was titled
the Ethereum blockchain size has exceeded one terabyte. And yes, it's an issue. This was
written back in May, uh, back at the end of May, we are now about to go into September.
So it's been a good, what, four months? Uh, it's been a good four months since then. And
it was a pretty lengthy and detailed article. I love the picture of, uh, Vitalik holding
up that sign, uh, that everyone has been using. I think it's coming up there eventually. These
are long articles guys. I read all of them. Uh, and, uh, it, it takes some time. So what
are, um, what do you think about that? Uh, and how did, like from a general point of
view, um, how is the Ethereum blockchain getting so many transactions and where do you think
it's going? And then we'll pick at the details of that. Yeah. So, um, the, the one terabyte
number is for a, what they call an archival node. Uh, within Ethereum, there's, there's more
classes of node types and security models than, uh, you're going to find in Bitcoin.
And, uh, that was the type though, that, uh, I was running when we were operating infrastructure
at Bitco is this archival node. And basically that means that if you are, uh, starting off
your node and this requires using non-default parameters, by the way, the default is using
a much more lightweight and, uh, lower security model. Um, but if you do decide to do a full
validating archival node where you start off from the Genesis block and you download every
transaction that's ever happened and actually perform the calculations that do the state
changes to the Ethereum state, then if you're lucky, you know, maybe a week or so later,
if you're running decent hardware, you will catch up and you'll get to the current tip
of the blockchain. Now you're only going to be able to do that if you're running pretty
high end solid state disks that have a lot of disk throughput simply because the, uh,
the calculations that are required involve reading and writing a lot of data from the
disk. And if you get to the very end, then you'll end up with, you know, over a terabyte
of data. And that's because it's storing all of the different states that have ever occurred
in Ethereum. There are, you know, other options for you to prune those away. And I think if
you end up doing pruning, then you'll probably end up with somewhere around 50 gigabytes
of disk usage, but you'll still have had to do all of the reads and writes, which is what
makes that initial sync incredibly slow. And like, you can't even do an initial sync from
the Genesis block on Ethereum if you're using spinning disk hard drives, for example. You
also can't do it if you're using a virtual private server that, that has a pretty low
IOPS or, you know, disk IO set to it. So the nodes that we were running at Bicco were fairly
expensive to use because this disk IO on virtualized servers is incredibly expensive. But I have
done some tests on the opposite end where I bought one of those like brand spanking
new M.2 NVMe drives that's like a RAM drive. And I was able to do a full sync and validation
of the Ethereum blockchain earlier in the spring, I think in a couple of hours. And
that was with like a $2,500 computer that I built myself. So suffice to say that there
is a lot more disk IO required to churn through the entire Ethereum blockchain in comparison
to Bitcoin. And the way that they get around this is that on pretty much all of the Ethereum
clients that I'm aware of, they will default to doing something called either warp, warp
syncing or fast syncing, where they're basically going out and they're getting a snapshot from
usually like 30,000 blocks or so ago, I forget how many weeks or months that is. And then
they will just start syncing and validating from that point in time. So, you know, you
could call this the like ask a friend model of, you know, gives me the state from a while
ago, and then I will assume that the proof of work that that chain is following is been
valid up to that point, you know, that there's no invalid states before that. And we'll just
go forward from there. And that's, you know, somewhat similar to like a Bitcoin SPV type
of mode, though, where you do start doing more validation, you just you don't do it
from the very beginning. So it's it's weird. It's kind of a hybrid security model. And
then, you know, what we're going to get into, I think, talking later is about the even crazier
changes that are going to happen to Ethereum security model when we start talking about
stuff like sharded proof of stake. Yeah, we're about to get into that. I'm just a little
more curious on the costs, right? Yeah. And also, you said you did it in the spring. I
think Ethereum has gotten a lot of transactions into their blockchain since the spring because
now we're going into the fall. What would your expectation be on costs, time costs,
machine costs? You know, just general, let's say on January 1st, let's say going into 2019.
What would you say would be a reasonable price cost and time cost to download, you know,
the full big boy Ethereum blockchain from Genesis block? Yeah, from from, you know,
I don't keep us as close a track as I used to since I'm not operating these type of Ethereum
nodes on a day to day basis anymore. But from what I have been seeing, it seems like the
Ethereum blockchain has been basically maxed out for most of the year while on Bitcoin,
of course, as the price declined, the activity dropped off a lot and very few blocks have
been full on Bitcoin. But at the very least, if you're going to want to build your own
machine that is running this, you're probably going to want to spend close to $1,000 because
you're going to want to get, you know, really high end solid state drive and fairly high
end CPU to be able to churn through that. And this is of course, assuming that you want
to do the non default full validation of the entire history, it gets a lot more expensive
if you're doing this in an enterprise environment, like running virtual private servers. Those
costs are going to easily run into, you know, hundreds of dollars per month if you want
to have sufficient disk IO to keep up with the blockchain. And what we find is that the
releases of these new Ethereum clients tend to come out with performance improvements.
And that's mainly because I think there's a lot of pressure on the Ethereum developers
because the enterprises are just running into issues where their nodes are falling out of
sync, lagging behind, and it's resulting in operational headaches for exchanges and
DApp makers and really anyone who needs to be providing services that are up to date
with the current state of the Ethereum blockchain.
Gotcha. But all of those costs you have just described, actually let me drop the screen
share. So all of those costs that you just described, they're hardware costs. What about
bandwidth and internet speed costs? Like what minimum bandwidth do you need to download
this thing, you know, in less than six months historically and what bandwidth speed you
need to be paying for in order to keep up with their 12 second blocks, I believe?
Yeah. Well, the bandwidth isn't as bad because, you know, the block size on Ethereum I think
equates to about 20 kilobytes. Now, of course, their block times are more like 15 seconds,
but it's not so much the bandwidth of like downloading and uploading as it is the much
more intensive disk operations where you're having to read and write data from arbitrary
points on the disk. Every time a transaction comes in, you know, that could be requiring
you to read data from a really long time ago. And that's why using spinning disks is just
a non-starter because they take like 10 milliseconds to go even find a point on the hard drive,
whereas solid state is a lot faster in terms of latency.
Gotcha. So what does this, like, how does this work for every single ICO that has launched
on Ethereum? And how many of these ICO companies do you think are running their full Ethereum
nodes, processing their own transactions, or are they relying on some centralized entity
to do it for them?
I would suspect that very few of them are running, you know, fully validating nodes.
It's just, you know, it's a lot more, it's costly in terms of money and time and operational
expenses. But even beyond that, it's just, it's not the default. And really what you
find in software in general is that defaults are very sticky. So even if they are running
their own node, they're probably just downloading parity or death or whatever and running it
with the defaults. And so that's doing fast and warp syncing and skipping over the vast
majority of validation.
All right. So before we move on to the next article specific to sharding and POS, like,
let's just say on a scale of one to 10, how would you rate Bitcoin? Bitcoin is decentralized.
How would you rate that on a scale of one to 10? And then the same question to Ethereum,
how would you rate the Ethereum's decentralization on a scale of one to 10?
I actually, I hate trying to simplify it in such terms because when we talk about centralization
and decentralization, there's so many different ways you can measure it. So many different
vectors now. And when I do it, it's, you know, it's going to be mainly from technical standpoint
of like, what is the network of nodes look like? And, you know, from that standpoint,
I think that there are a lot more fully validating nodes on the Bitcoin network. So it's thus
much more decentralized than on Ethereum where the Ethereum node account, if we're looking
at like fully validating nodes is much, much smaller. And I think it's going to continue
to decrease simply because the cost of running them will continue to increase.
Right. And that is actually my biggest, I try to look forward and that is my biggest
thing. I never felt the need to run my own Bitcoin node until the whole user activated
soft fork kind of blew up in our faces because no one expected the miners not to go along
with something that everyone thought they should have been happy with. So the user activated
soft fork experiment created a lot more node holders and I think made the system a little
more decentralized. And I think that going into the future, Bitcoin is being built out,
the technology of Bitcoin is being built out as a way to encourage more people to run their
own validating nodes. And everything I've seen so far in Ethereum is discouraging your
ability to create your own node, decentralize the system and process your own transactions.
Would you agree with that generalization? Well, yes, because it's a lot more difficult.
It's a lot more challenging to build a system that is, you know, efficient at the base layer.
Whereas there are a number of tendencies that push various people and developers and companies
within these ecosystems to want to centralize different aspects of it because centralization
is tantalizingly easy because you can get such greater performance gains by centralizing
different aspects of the system. Gotcha. All right. So let's jump over to how Ethereum
plans to scale. And Ethereum has two things on their roadmap and everyone is debating
which one should happen first. And of course, they're going to meet in the middle and try
to do both of them at the same time, which is probably going to create an even bigger
disaster. So one of them is, of course, moving to a proof of stake system. And the other
one is moving over to sharding. So I don't know which one would you rather start with.
If we start with sharding, please define sharding for us.
Yeah, from reading over stuff, they seem to want to tie them together because I think
it will be simpler for them to do that, kind of like do one big transition all at once
rather than try to figure out how to do multiple different transitions.
All right. This is what the Bitcoin core developers attempted to do with segregated witness and
ran into a bit of a problem. And if those pieces were going to be done one at a time,
maybe one of them would have created the big problem. So in hindsight, it's hard to say
if that was the right way to do it or not. But now it's hindsight. And I think the way
it was done was absolutely it needed to be done.
Yeah. Yeah. So sharding in general technical terms is a fairly old concept. I actually
first experienced sharding 10 years ago when I was working on a web application that was
on the LAMP stack. So Linux, Apache, MySQL, PHP. And we had a MySQL database and the
company grew to the point that it just wasn't possible for that single server with that
single MySQL database to continue to be able to process the load of our increasing number
of customers. So what did we do? We sharded it. And by sharding, basically that meant
that we created a bunch of new machines that had their own MySQL databases. And then there
were just little pointers in a master database. And whenever a customer started doing stuff
with our web app, we would say, okay, this user has been assigned to this shard. So just
send them over and do all the regular database operations, but do it on this one machine
rather than on a single huge instance. And so it's a fairly straightforward way of doing
quote unquote horizontal scaling, where you can just buy more machines, you throw more
machines at the problem. That ends up being a lot more cost efficient than vertical scaling,
which means you still have like one machine or a few machines and you just buy increasingly
more powerful ones, but they become exponentially more expensive to do so. Now in a decentralized
environment, this still makes sense from a performance standpoint, because you're basically
spreading out the load more widely across a larger number of machines. But the trick,
the kind of downside is how do you do this without changing the security model of the
system? Because we currently in Bitcoin have a single blockchain, and if you're running
a full node, then you're downloading all the data, validating it yourself. And it gives
you this amazing security model people often refer to as trustless, where the only real
security assumption is that you at one point in time have connected to one other honest
node on the network. Even if you're connected to 100 nodes and 99 of them are lying to you,
then that one honest node will get the data to you that you will be able to authoritatively
say yourself, this is the correct data and everyone else is lying to you. But if you're
on a network where you're only downloading 1% of the data, then the other 99% could potentially
be lying to you by omission. You're just never receiving the data. So it becomes a lot trickier
to retain a strong security model in a system where you're not looking at all the data yourself.
Well, that's very informative, but that's the security and the omission of data perspective.
So stop and decrypt specifically makes the point that sharding can actually centralize
your system. I don't know if you had a chance to deep dive into this article, but what are
your general thoughts on just centralization in general because of sharding?
Yeah. And I've spent a number of hours reading through as much of the technical documentation
around proof of stake and sharding that are currently available in Ethereum. And I remember
when you were first asking me about this about a month ago, I said, I'm really not comfortable
talking about it because I don't understand it very well. And since then I've spent a
fair amount of time, probably at least six hours so far reading through the various blog
posts and FAQs, both on F3 search and Vitalik's blog and Twitter and whatnot.
Yeah. I'm sorry about that, James. I didn't mean to kill some of your brain cells. I really
need them to continue programming Bitcoin.
No, no, this is good. I mean, you know, learning is always good. But what I would say is that
at least, you know, six or so hours into it so far, I'm not sure that anyone really
understands the proof of stake and sharding in Ethereum because I don't think it's done.
And the reason why I say that is you actually go to the FAQ for sharding on F3 search website.
And there is a note near the bottom that says, you know, this is only about 70% done. And
then it lists a lot of things that have not yet been fully finalized. And that includes
a fair amount of the game theory around like how they're going to penalize bad actors or
even find bad actors in the system. And so suffice to say that within Ethereum moving
to this proof of stake model, they're implementing a ton of new game theory. That's not necessarily
bad. I mean, you could make an argument that Lightning Network is implementing a ton of
new game theory. But they're also introducing just an enormous level of complexity at the
base layer. And there are things and there's a lot of unanswered questions of, you know,
how are you going to have good guarantees mainly or what I'm worried about is the cross
shard communication of like how do you guarantee or at least have some sort of probabilistic
guarantee that transactions and data that occur on one shard correctly make it over
to another shard. And they're trying to do that by using a lot of like pseudo random
sampling from the validator set to say, okay, you know, each shard has 150 validators and
they're randomly assigned. So it's hard to gain the system. But there's still, I think,
deeper level issues in how they're going to do the actual load balancing of the data across
the shards. And so there's a number of things that could go wrong. Like if the activity
on one shard got really out of whack, really high, and another shard was really low, you
can start running into throughput issues. And the reason why this is the case is that
you should basically think of each of these shards as being the same as what the current
Ethereum blockchain is like. So we can expect that they will be able to do, at a best case,
maybe 15 transactions per second. So what happens when one shard starts trying to do
100 transactions per second, and then some other neighbors that are only doing one or
two transactions per second are trying to communicate with it. So it's just an issue
of increasing levels of complexity by orders of magnitude. And of course, the fact that
this is something that has been researched for, I think, four or so years now. And if
you look at Vitalik's recent tweet storm that was 70-something tweets long, he went through
the whole history of it. And it's pretty clear that this is still a work in progress. They're
still trying to figure out the optimal scenario. And it's not clear whether or not there is
an optimal scenario. And it's even less clear what all the tradeoffs are going to be. But
it is certainly clear that if you are running a fully validating node on Ethereum right
now, it is going to become exponentially more expensive to be what I'm seeing referred to
as a top-level node, because the top-level node would have to validate not only what
is the current Ethereum blockchain, but then the beacon chain and all of the shard chains,
which I'm also seeing conflicting information about, but it seems like they're currently
targeting 1,024 shards. So 1,024 instances of the Ethereum virtual machine potentially
doing 15 transactions per second. So say throughput max is out around 15,000 transactions per
second. You're going to need a CraigWrite-level node, a $20,000-something-odd node in order
to be able to validate all of that stuff yourself. And I think almost nobody is going to be doing
that.
Well, we both know CraigWrite might do it. But no, but it's really funny that you mention
that because I finally met CraigWrite for the first time. This was recently, probably
a couple of months ago when I was in London. I was visiting London. Some of the guys put
together a dinner because I was in town. They invited CraigWrite for fun and he said yes.
And as funny as that conversation went, I was sitting next to him all throughout the
dinner of like 10, 15 people at the table. Him and I agreed on everything except what
is Bitcoin. We can sit there across the table from each other and talk shit about Ethereum
all day. He hates this thing as much as I do, or many other Bitcoin maximalists do.
So there is some commonality even with, if you ever do end up sitting at a table with
CraigWrite and you want to find some commonality, start talking about some of these altcoins
and it can be a pretty enjoyable conversation to say the least. I know people are still
mad at me for saying this, but it was fun. While listening to him talk about how bad
Ethereum is, it was actually pretty interesting. The other thing I was going to say is, I remember
I was actually at the very first scaling event in Montreal. I believe it was in 2015. If
you were there, I don't believe you were a speaker.
That was the only one I didn't make it to. My memory is pretty good, but I don't remember
meeting you there. That's when Vlad Zanfier introduced sharding for the first time and
spoke about it publicly on stage. That was 2015. I still remember that. I remember all
the discussions that took place after that. Let's change gears slightly and stick with
the proof of stake mechanism. You're not an economist and there will be an Ethereum part
four. This is an Ethereum part three, guys. In part one, we talked about the regulatory
problem of Ethereum with it being a security, the way it was financed. In part two, Johnny
Dilley and I discussed the concept of smart contracts and why smart contracts don't really
need to be decentralized because that doesn't make any sense. There's no censorship in
your contracts. It's just maybe the money that you need to pay for those contracts.
This is focused on the technology. I will bring up the proof of stake conversation in
my fourth episode, which is going to focus on economics, hopefully with an actual economist,
why proof of stake is more of either a communist system or more of you just get free Ethereum
for holding Ethereum system. From a technological perspective, what do you think about proof
of stake versus proof of work? I find it hard to apprehend how people are taking proof of
stake seriously. The technological innovation of Satoshi Nakamoto's blockchain was proof
of work. That is the innovation. Proof of stake, it's been done forever. Where is the
technological innovation of proof of stake? Right. A lot of people, of course, get upset
about proof of work because they consider it to be a waste of energy. They consider
it to be harmful to the environment. You can come up with all kinds of metrics to make
an argument that from an energy efficiency standpoint, Bitcoin is less efficient than
any number of other financial systems. But the thing about proof of stake that is appealing
to people is that they can be running their system basically without requiring any sort
of inputs, externalities, I guess, if you will. They have their fully self-enclosed
ecosystem that nobody else can screw with. The downside is that you run into a number
of problems of incentive. Of course, I always end up going back to Andrew Polstra's proof
of stake versus proof of work paper from years ago in which he was making arguments that
long-range attacks are the primary problem that you run into within a proof of stake
system. Actually, Vitalik himself has referenced this on a number of occasions. He called it
the nobility problem. This basically means if you ever have a point in time where someone
controls an inordinate proportion of the value of the system, they can always in the future,
even if they sell off all the value that they have, they can always do a long-range attack
that starts from that point in time and rolls forward. This was actually a way that a number
of the early naive proof of stake systems worked or were attacked is that someone would
just go back in the blockchain weeks or months after they had already sold off all their
coins and then said, okay, I'm creating a new chain from this point in time when I held
a lot of money. You can basically rewrite history at no cost because your CPU can be
generating these blocks, probably hundreds of blocks per second because there's no real
proof of work required. What ends up happening is that you start creating this sort of Rube
Goldberg machine to deal with all of the new edge cases that come from nefarious things
that a proof of stake attacker could do. Actually, if you look at Vitalik's tweet storm that
I was talking about, he concedes that they ended up abandoning trying to solve the long-range
attack problem and they rather they just introduced a new security assumption, which is that we
will just make it so that no client will ever accept blocks that are more than 20 or 30,000
blocks old. We have an implicit type of checkpoint there. Maybe that's good enough. It's really
hard to argue about this because you can't really know whether it's good enough until
it gets attacked and it fails. Really what you find if you're looking at the current
cutting edge state of proof of stake research is that they're trying to figure out how to
do the best slashing conditions, which is a fancy term for saying penalization conditions,
and trying to figure out how to only penalize the bad actors without penalizing good actors
who accidentally went offline for a while and stopped doing their job. You start going
down this rabbit hole that gets insane and that's why they've been still doing this research
and pivoting for the past three or four years now. Maybe it is a solvable problem, but as
far as I and most of the other people I talk to can tell, it still has not been fully solved.
But kudos to Vitalik and Vlad and all the other team for keeping at it. Maybe they will
finally solve it and we'll be able to make all the tree-huggers happy and everybody can
switch to a proof of stake system and we don't require any more electrical generation to
go on. But of course, plenty of counter arguments to that. I would say Bitcoin actually incentivizes
people to find cleaner, more efficient forms of power generation.
Yeah, that's always been the argument that I have been trying to use. Bitcoin will drive
the innovation in not only energy generation and energy consumption, but also thermodynamics
and let's say cooling of your heated equipment. There could be so much innovation there that
I'm really looking forward to. So this is the paper that I have on the screen right
now that you're referring to from Andrew Bolstricht, right?
That's the one.
Right, so I'll throw that in the video description. I don't know if I'm going to go out searching
for their Twitter war, but please, I encourage you to go and do that. So because of all of
these concerns, and it sounds like they're still researching this thing, does that explain
this amazing Google search of Ethereum delays the difficulty bomb? And once again, continuously,
because I thought that Ethereum was supposed to be on a proof of stake system a year ago,
and what was going to force them to get there was this difficulty bomb rendering their mining
useless, and they continue to delay it. Any thoughts on this? Have you heard anything?
What's the latest news? Is it going to be like the debt ceiling that gets us delayed?
Exactly. It's like, what's the point in even having a debt ceiling or a difficulty bomb?
We all know that you're not going to let your network commit suicide because you did not
reach a technical achievement in the time that you thought was going to happen. I'm not going
to criticize them for saying that they should have gotten it done by now. When you're doing
stuff that nobody's ever done before, it's really hard to come up with timeframes. I
think it's weird that they keep putting this difficulty bomb back in. Why not just take
it out so that you can admit that we don't know how long it's going to take to get to
where we're going? I don't know. It's kind of a weird aspect of Ethereum. They've already
set the precedent that whenever they get close to the difficulty bomb, it's going to get
taken out. At this point, it's hard to say when they're going to be willing to do a full
transition to proof of stake. The story keeps changing on an annual basis. I would be surprised
if we're sitting here a year from now and they have completed the transition, but maybe
a year from now it will be in sight and it will be scheduled.
I still have a conceptual difficulty believing that they can ever go to proof of stake. Ethereum,
even though it's down 90% or whatever, Ethereum is still like $100 to $200. I believe they're
mining three Ethereum every 12 to 15 seconds, whatever their blocks are. How do you just
show up and tell a giant mining facility that's invested millions of dollars to just point
their hardware somewhere else? I think a few things could happen. We very
easily could end up with another Ethereum classic situation or maybe Ethereum classic
becomes much greater and a lot of the proof of work transitions over there. Also, there's
I think quite a few other altcoins that can be GPU mined and they might be able to soak
up a lot of that demand. There was actually I think a meeting very recently in which it
seemed like there was pretty strong consensus to decrease the mining reward in Ethereum.
We may see a decrease there, another economic disincentive for proof of work miners to stick
with Ethereum. I've always said for probably a couple of
years now, I envision another Ethereum. We already have ETC. ETH will stay with Vitalik
because wherever he goes, he's trademarked for ETH and I envision an ETW, Ethereum work
where the miners are going to try and convince all of the current ICOs to stay on the Ethereum
proof of work chain. I think it will be a little challenging to get your ICOs to convert
to another blockchain like an Ethereum classic, like an EOS, like a Tezos or a Waves or all
of them. Lately, I've been saying these ICOs that become platforms for other ICOs, like
all the ones I just named, they're going to be totally fungible and your company's unlicensed
security in the form of your ICO can just transition from one to the other to the other
with all of them slowly becoming technologically unstable over time until some centralized
solution shows up or at this point, I think Ethereum would almost be better served as
a centralized scalable solution to run all of these ICO smart contracts because none
of these ICO smart contracts are actually decentralized. They're centralized by the
company creating the ICO. Wouldn't it make better business sense for Ethereum to centralize
their product and offer their services for a fee of moving all of this stuff around,
like all of these securities around? Maybe. I mean, so there's of course the Ethereum
Enterprise Alliance could potentially create their own network for that. Really, it seems
to me like stuff like EOS, which is even more centralized but has much greater capacity
for throughput, could pick up a lot of this ICO slack. But kind of a counterpoint though
for the incentives is that if a lot of these ICOs are holding a lot of value in Ether,
then they could be incentivized to switch to a proof of stake system and basically Ethereum
would become secured by the ICOs themselves. Yeah, no, that is an interesting thought to
consider and it's also great that you said EOS is more centralized with a lot more throughput
and that makes sense because decentralization comes at a cost. It comes at a security cost
and it comes at scalability cost. You have to weigh those costs and Bitcoin isn't willing
to budge on decentralization side of the equation and which is why the focus is on the lightning
network and scaling your transactions as a second layer protocol, as long as that second
layer protocol can be just as decentralized, probably even more fungible and anonymous
and have a lot more transaction throughput and then it's a done deal. Bitcoin can actually
scale. Well, maybe it all just comes down to marketing. Yeah, no, that is interesting.
Alright, any final general thoughts? I mean, you remember the DAO. I mean, I'll give the
floor to you as far as the technology and the competency of the Ethereum. I know developers
don't like to talk bad about other developers. I once asked Eric Lombroso on a live interview
the following question. I didn't want to put him on the spot. I said, are there any altcoin
developers that you truly respect? And he avoided the question. I think I meant it specifically
in the case of Bcash, but I'm not going to go there. But is there anything else you want
to talk about from the DAO hack, from the Parity Wallet hack, from the MyEtherWallet
hack, to anything else you think that why do people continue to trust the technology
underlying Ethereum with these grand hopes that just aren't deliverable?
Yeah, well, it's just a very different mindset. And as I look out across this diverse ecosystem
of different networks, I also see a diversity of different perspectives and ideologies.
And in general, I think it's fair to say that Ethereum is a much more social network, social
ideology. And that's why Vitalik and a lot of the other developers are willing to make
certain trade-offs with regard to consensus, where they're turning it into more of a social
consensus of saying, we're going to have a bunch of fairly well-known actors that are
going to be putting skin in the game, and then we're just going to try to figure out
how to help coordinate these actors. And that's a stark contrast to a Bitcoin-style ideology
where it's more like, you know what, we have the protocol, and everyone is either going
to follow the protocol or they're going to fork off, and you get burned if you don't
stay in consensus with everyone else. So I think that a lot of these things are valid,
and it's hard to make technical arguments about them that necessarily convince people
who have that other perspective. And I just take a very long-term view on it of these
things are going to get attacked, and the ones that survive were good enough, and the
ones that die were obviously not good enough. And time is going to have the ultimate say
in which of these perspectives is workable.
All right. And one more question I forgot to ask earlier. As you read over the two articles
by Stop and Decrypt, was there anything there you disagreed with? Was there anything there
you felt was inaccurate?
Well, you know, I first read it when he first published it, and I didn't know whether or
not it was accurate, but then I went back recently and read a lot of the technical FAQs
and stuff from Ethereum developers, and I would say that my perspective is about the
same as his, that ultimately this new type of system creates a much smaller number of
players who are able to actually validate the whole system, and it results in the regular
end user having to trust the system a lot more. And also, you know, the main point that
I think he was making is that, unlike in Bitcoin, if you're running one of these nodes in Ethereum,
especially once it gets sharded, you can't reject anything that goes wrong. You just
have to go along with what you're told. And so once again, it comes down to these very
different perspectives, I guess, in how the network should operate and how the developers
extend them over time.
And I'll let you go on this one. As a long time Bitcoiner, as a developer within the
blockchain space, would you advise, would you ever build anything on top of or combined
with Ethereum or advise anyone that it's actually a good idea?
Something that you want to scale out, you know, to be a mainstream application. Now,
if you actually look at one of CASA's recent blog posts, we are going to add Ethereum support,
and that's because we have wealthy clients who will pay us to add Ethereum support. But
we are actually in a conundrum because I spent over a year at BitGo working on Ethereum wallets
and Ethereum infrastructure, and it was a nightmare for a number of reasons. And I wrote
a very lengthy blog post about that. And I really want to avoid trying to do multisig
and a smart contract again, because like some of the stuff that you were mentioning, there's
no real guarantees. There's very poor auditability and correctness proofs, anything like that.
And so if we're going to be doing multisig and Ethereum, we want to have some sort of
assurance that if there is a bug in the smart contract we're using, that the entire network
is going to fork to fix it. Otherwise, what guarantees do we have? We don't want to end
up in another parity situation.
All right. Jameson, thank you very much for coming on on this third episode of Ethereum's
crypto scam, where we delve deep into the technology and the scalability of Ethereum.
My pleasure.
Thank you.
All right, guys, if you really like the show, there will be more to come. I am bringing
back crypto scam slowly. This Ethereum series really got me stuck. I tried completing the
technology of Ethereum is unsustainable over a year and a half ago, and I had a big problem
getting the right guests. Those guests have finally arrived. And hopefully the show will
flow going forward. Of course, you can check out all of my other podcasts on the ToneBase
YouTube channel and the ToneBase audio podcast stream. See you all on the next episode of
Crypto Scam.