hpr-knowledge-base/hpr_transcripts/hpr2949.txt

Episode: 2949
Title: HPR2949: Grin and Beam: The 2 major mimblewimble blockchains
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2949/hpr2949.mp3
Transcribed: 2025-10-24 13:46:28

---

This is HPR episode 2949 for Thursday, 21st of November 2019.
Today's show is entitled Grim and Beam.
The two major Mimble Wimble blockchains.
It is hosted by Mike, and it's about 23 minutes long and carries an explicit flag.
The summary is Grim and Beam are two Mimble Wimble implementations
that are very different and we take a look at both.
This episode of HPR is brought to you by Ananasthos.com.
Get 15% discount on all shared hosting with the offer code HPR15.
That's HPR15.
Better web hosting that's Ananasthos.com.
Welcome back to Hacker Public Radio.
This is Mike, continuing like talking about blockchains.
In particular, on the last episode I mentioned the Mimble Wimble Protocol,
which gives blockchains extreme privacy, scalability, and fungibility.
Through this concept I call cryptography over complexity.
So, having explained the basics of Mimble Wimble,
today I want to talk about the two major implementations of that.
There are two working very different blockchains, Grim and Beam.
There are others in the works.
Notably, Litecoin is working on a sidechain using Mimble Wimble, and so is Monero.
They're not very far along though, and these two blockchains
launched earlier this year. They launched in January, in fact.
So, the first one to talk about is Grim.
Grim is an open source implementation of Mimble Wimble written in Rust, which we're a big fan of here.
Grim uses a proof of work algorithm called Kuku Cycle, or actually a family of algorithms.
Variants called things like Kuku2 and KukuRoo.
Now, you might have noticed that the Mimble Wimble protocol in and of itself
doesn't give you enough to launch a blockchain.
There are still pieces you need to add, decisions you need to make.
And that's kind of nice, because the two major implementations that we're looking at
are very different. One of the things that's missing from the specification is the mining algorithm.
Grim uses a proof of work algorithm called Kuku Cycle, a family of algorithms, actually.
And we'll go into the details of that in just a second.
Grim is totally free and open source. Has been since day one.
They have no foundation, no company, no ICO. None of this stuff.
I believe they do have one full-time programmer at this point,
who is being funded through donations that they got.
When and if those run out, they won't have a full-time programmer again.
This is entirely volunteers driving this project.
So that proof of work algorithm they use, they actually use two variants of this thing called
Kuku Cycle. Kuku Cycle is unlike what we usually see in blockchains. Typically we see
hashing functions used because they have nice properties.
But here we're using a graph theoretic algorithm. So the idea is this.
A Kuku Cycle is finding a cycle in a bipartite graph.
Finding a cycle in a bipartite graph. So just a brief graph theory, a refresher for those of you
that may have forgotten. A bipartite graph is a graph such that you can partition the nodes into
two sets so that every edge connects a node in one set to a node in the other set.
And it has unique properties like cycles in that graph are always even numbered cycles.
And a cycle, I should back up a little bit here and define terms.
Usually when we talk about graphs, people talk about binary trees, people talk about
dags. Directed a cyclic graphs, you see this everywhere, right? Git is a great example.
You see it in the blockchain world for sure instead of as a replacement for a blockchain data structure.
So an a cyclic graph is one which for every node, there does not exist a cycle.
Sounds kind of like a double negative definition there. And a cycle is a path from a node that
leads back to that same node. So if there is no cycle for any of the nodes in a graph,
it is a cyclic. That's the traditional dag that you're used to. This is the opposite that we're
talking about here. Having nothing to do with being a bipartite graph, the properties are the
edges have no direction, unlike a directed a cyclic graph. And there is a cycle. That is the goal
of the minor. Instead of coming up with a hash that has a certain number of leading zeros,
solving the puzzle here entails finding the cycle in this graph. And it's not trivial to do because
this cycle needs to be of length 42. There's a lot of nodes and edges. And in fact, these parameters
are adjusted to adjust the difficulty algorithm. Both of the blockchains we're going to talk about
today have one minute block intervals. That is to say the average time between blocks is one minute.
And it's adjusted every block based on the past 60 blocks. So this graph theoretic proof-of-work
system is a memory bound algorithm. And what that means is it's designed to be asic-resistant.
The goal being to find that cycle in a bipartite graph instead of a hash result that has a certain
number of leading zeros. So the idea here is both of these chains that we're talking about,
grin and beam, they launch with proof-of-work systems. Now proof-of-work is definitely a proven way
to protect a network, to secure a blockchains system. But when you first launch, there's kind of
a danger period at first. If somebody can quickly make asics and show up on your network with an
overwhelming amount of hash power they can take over the network. So to mitigate that risk,
the Grin team chose this Kuku cycle family of algorithms to resist that. Both teams took the strategy
of taking a proof-of-work algorithm and changing it every six months at first to get off to a good
start where asics wouldn't take over the network. And then shift strategies over time to allow the asics
in. Because you want that in the long term, it's just risky in the short term.
So Grin, for example, is using two variants of this Kuku cycle. If I'm not mistaken, they're called
Kuku 2, 31, and Kuku 2, 29. And basically one of them is asic-resistant, and the other one ends up
being asic-friendly. So initially, almost all the block rewards go to the asic-resistant algorithm,
and it shifts over time. At the end of two years, all of the block rewards go to the asic-friendly
algorithm. Now Grin also has this notion of history compression. If you remember, I mentioned that
when miners assemble the blocks, they aggregate the transactions, and then they have this cut-through
process to eliminate excess inputs and outputs. So a macro block is this notion that you can combine
old blocks in the blockchain. These blocks have a single large transaction in them that can be
combined with the single large transaction in the subsequent block. You combine those into one
block and combine the transactions into one transaction. And I believe in Grin, this is done by
default every one day. You don't want to do this to the recent most blocks, but older blocks.
Beam, however, the other blockchain has replaced this with another scheme. So speaking of beam,
beam started a year later working on their code, but they actually launched a little bit earlier.
They were the first one to actually launch their system, which does not share a common code base
at all. Beam uses a completely different code base written in C++ instead of Rust. It's free and
open source. They don't use variants of cuckoo cycle for their proof of work algorithm. They use a
modified equa hash. Equa hash being, I believe, Blake 2 hashing. This was used by Ethereum,
modified for use in the Zcash project. And they've taken a variant of this. I think they just tweaked
the parameters and used this. And for those that don't know, Blake 2 was one of those competitors
trying to become the new Shaw 3 when this was looking for a Shaw 3 algorithm to replace the aging
Shaw 2 family. So beam, the most striking difference between it and Grin is this is run by a
for profit company financed by a founders reward just like Zcash. So they got investors right
up front to front them the money to run their company. They went out and they hired a bunch of
programmers. This probably influenced the choice of C++. It's easy to hire those programmers.
And they've been doing a lot of coding. This is why they were able to launch so much faster. They've
implemented a lot of features. And, you know, the monetary policy is very different here too.
They've really designed this to be more of a store of value from the looks of it. This is a store
of value privacy coin. I'd say that because they have a fixed amount in total just like Bitcoin.
It's a larger number, but it's still a fixed amount. And the block rewards are mostly front-loaded.
There's a halving every four years just like Bitcoin. Whereas Grin has a unique emission schedule.
Their coin issuance schedule is unlike that I've seen on any other blockchain. There's a constant
rate of emission. There's a block every one minute with 60 grins. So there's one grin per second
forever. There's no having. There's no fixed amount. So you can probably tell just from the description.
This is not designed to be a strong store of value, but more of a means of exchange. They want
people to use this. And there's no penalty for not getting in in the early days. Probably already
you can tell there are very significant differences between these two projects.
Now Beam, as I said, has a legion of programmers and they have been very active. One of the most
active GitHub repos in all of the blockchain world. So they've done some cool things. For one thing,
if you remember back to the dandelion protocol, each step along the way in the stem of the dandelion,
a node would take the transaction and before passing it along to one of their peers,
they would combine it with transactions that they see that are available. Combine the transaction,
that is. Well, if there are not a lot of transactions on the network at a given point in time,
without any other mechanism, the transaction itself just gets passed along from node to node.
And they don't get that advantage. So what Beam has implemented is they have a feature called
decoy outputs that they add in. Make believe outputs that are added just for the purpose of
obscuring that correlation between inputs and outputs in these transactions that are pending.
They've also done great work at getting user-friendly wallets, including all major platforms.
And they've implemented some of the basic things like atomic swaps, which are actually tricky
in this system. The reasons I'll get into in a minute. They certainly have an ambitious roadmap
as well. All kinds of things which we're not going to have time to really discuss in detail.
The thing I'm most excited by is confidential assets. This is a proof of concept only at this point,
but the idea is to extend that same Peterson commitment idea. But instead of
blinding factors obscuring the value of the UTXO that's being spent in a transaction,
you're going to obscure the actual ownership of an asset, a token. So this is a way that other tokens
can be issued. And the custom user-generated assets or tokens can be issued as well
in a confidential manner, which is something new to the blockchain world. This is the same sort of
thing that Monero is working on with their Mimble Wimble sidechain called Tari, T-A-R-I.
I don't think it's very far along, but this was something noticed by I believe Andrew Polstra again
who said it should be doable, and these teams are working on it, both Beam and Monero.
So there's plenty of other exciting things in the works. Lalantis Mimble Wimble is a tricky concept
that will bring a lot of features, including a multi-sig capability. And at this point,
I might as well mention something I've been evasive about so far. When it comes to multi-sig,
you know, if you're from the Bitcoin world, you know multi-sig is implemented through this
scripting capability that Bitcoin has. It's a simple script, and similarly in Ethereum,
there's a smart contract that you can deploy to let you do multi-signature or multi-party
signatures. So this is pretty easy in conventional blockchains, but pretty tricky here because there
are no scripts. There are no scripts. No scripting capability whatsoever here. Not a stripped-down
bare-bones scripting language. None. This is necessary because if you look at a Bitcoin transaction
that has a script, well, where is the script? It has to be in that transaction associated to an
address, and Ethereum's smart contract lives at an address. The problem here being there are no
addresses. If you try to associate it to an input or an output of a transaction, what happens
if that gets pruned? So this is problematic for other reasons too. I mean, in this system,
inputs and outputs really want to be indistinguishable from one another. This is about privacy after
all, as well as scalability, and scripts certainly distinguish transactions. So without that
capability here, which you can't have because you want to preserve that pruning capability to keep
this blockchain small, multi-sign and other features like it have to be implemented using some
mathematical trickery. Well, it's not deceptive trickery. It's just fancy math, fancy cryptography.
I don't understand exactly how it works, but Andrew Pulsera has this notion of scriptless
scripts that is basically ways to do this aside from running a little script. This, just like
Lelantis and confidential assets before that, is beyond the scope of this particular podcast.
If it is interesting to you, though, you should look this stuff up because it's fascinating
research that's going on. Okay, so back to the beam roadmap. I should mention that hardware support
is doing well as well. There's treasure support that is currently working. It's just awaiting
approval from the official treasure team. Ledger support is work in progress. They've also implemented
payment channels, which is basically like the lightning network on Bitcoin. There's is called
laser beam and it's not a feature on the main blockchain yet. It's a proof of concept at this point.
And finally, I want to mention they have an auditing function that is in the works. And this is
an important one to them because beam wants to cater to the business user. You know, when it comes
to privacy coins, the need that is out there, there's absolutely a solid demand for financial privacy.
This is at both a personal level, which is addressed nicely by Grin and at a business user level,
which beam is aiming to satisfy. So imagine I'm operating a business on the blockchain. That is to say
customers pay me in cryptocurrency. And I pay my operating expenses in cryptocurrency. I don't
necessarily want my competitors to see which vendors I'm using. How much I'm paying my suppliers
for things. Maybe I negotiated a better rate. Or how much I'm paying for my payroll.
Maybe they want to find out how much I'm paying my lead programmer and offer him a little bit more,
right? And at a personal level, of course, maybe that lead programmer doesn't really want their
landlord to know. They just got a big promotion because the landlord's been dying to raise the rent
anyway. Or perhaps their insurance company would really like to know or be shocked to find out
that they just paid money to book a skydiving trip. At any rate, this auditing function would allow
businesses to operate on the blockchain with financial privacy and yet disclose everything they
need to to be fully open and compliant in the eyes of governments and government regulators.
So that's the basic rundown of these two projects, Grin and Beam. One other thing about Wallet,
this brings me back to Mimbo Wimble in general. Wallets in general are tricky in Mimbo Wimble.
In the traditional blockchain world, of course, a wallet, which is probably a misnomer.
A wallet is not a container for money. A wallet manages private keys. So, for example, in Bitcoin,
a traditional HD wallet, I will enter a seed phrase and that wallet generates a hierarchy of
private keys. Private keys then can be associated with public keys that are dry from those
and addresses generated from those. So, wallet can simply keep track of those addresses.
A new wallet that you put that seed phrase in can generate that exact same set of private keys
thus the D in HD deterministic and derive all those same addresses and check the balance and
check for UTXOs residing at those addresses. So, here, wallets can't exactly go checking
previous transactions. They're not visible on the blockchain. There's no addresses to go checking.
So, what is a wallet to do? So, the wallet needs to actually check the UTXO set
and see and match those private keys that it's generated to the UTXOs themselves.
Wallets also have a tough time because unlike a conventional wallet, like a Bitcoin wallet,
you can't simply generate a transaction, sign it with the private key and throw it over the wall
and be done with it. There's this interactive process that needs to happen with another wallet,
the wallet of the recipient. So, there's custom coding that has to happen
and this makes it very difficult to integrate into a multi wallet, for example,
like Jax or Exodus or one of these. It's not like adding another coin.
Here, you need to do some custom coding to allow the interaction by some means with another wallet
to construct those transactions. That's a tough sell for a multi wallets. It's a little easier for
exchanges, if you think about it, in exchange has a hot wallet that's always online and somebody
comes along with a wallet and wants to withdraw from that exchange or deposit to that exchange
by definition, they're online at the same time. So, both wallets can interact right then and
there synchronously, whereas a normal wallet is going to need to have some mechanism to interact
asynchronously with the receivers wallet, probably having time out periods and so on.
The Beam team has constructed a kind of a message board, I guess, to facilitate this to make
it a little easier and you set time out values. Grin wallets still require that you establish
communications out of band and this is what you really want to do anyway to exchange that initial
information. Remember, I can't just send a request to join in to some address on the blockchain.
There are no addresses. I need to know an identifier for your wallet if I want to interact with you.
So, long story short wallets are a challenge in Mimbo Wimble and of course the other big challenge
is the fact that there are no scripts and you really want to have some way to implement simple
things which have been implemented or are feasible and in the process of being implemented.
Atomic swaps are working. Multi-six support is in progress so they're getting there but it's
an uphill battle. In summary, I would just say Mimbo Wimble blockchains go a long way toward
scalability and privacy because there are no addresses. These transactions are interactive.
There's no amounts recorded on the blockchain or even visible in the transactions themselves.
There's better scaling because transaction history is not stored on the blockchain.
Only the UTXO set. Proofs are small and resource-efficient. They're not using ZK Snarks here.
They're using bulletproofs. They're using some fancy Peterson commitments.
They're on the downside. There's no Bitcoin style scripting available.
So that's a challenge. Wallets are a challenge but this gives a really strong privacy
and really great scalability. Better than I've seen in live working blockchains out there.
So these Mimbo Wimble projects are worth looking at and this is a pretty good protocol.
For reference on these guys you can go to grin.mw for the grin project.
Beam.mw for the bean project and I just like the fact they use MW top level domains for Mimbo Wimble.
And that's about it for Mimbo Wimble. Thanks again for listening. I hope you got something out of it.
And if so, remember this is what you like about Hacker Public Radio.
All the great info and the variety of different kinds of content you get to hear.
Thanks again for listening. This has been might be Mike for Hacker Public Radio. Talk to you soon.
You've been listening to Hacker Public Radio at Hacker Public Radio dot org.
We are a community podcast network that releases shows every weekday, Monday through Friday.
Today's show, like all our shows, was contributed by an HBR listener like yourself.
If you ever thought of recording a podcast and click on our contributing
to find out how easy it really is. Hacker Public Radio was founded by the digital
dog pound and the infonomican computer club and is part of the binary revolution at binwreff.com.
If you have comments on today's show, please email the host directly, leave a comment on the website
or record a follow-up episode yourself. Unless otherwise status, today's show is released on
creative comments, attribution, share a light, 3.0 license.