A new grin ツ is emitted every second, forever, meaning the emission rate stays constant and completely linear. As time passes, the relative dilution becomes smaller; After 10 years, it falls below 10%. After 20, below 5%. This results in a decreasing inflation rate, known as disinflation.
+
This simple design serves to ensure the long-term security and stability of grin, as well as provide a fair process of distribution. We'll set to explore those topics more thoroughly.
+The first four years of bitcoin's emission rate are identical to the first four of grin. Bitcoin had a full reward for 4 years, followed by half that for the following 4 years. So compared to a constant supply, after 8 years, the total amount of coins emitted is only 25% less. Compare that to daily price fluctuations.
+The more resources being spent on mining a proof-of-work chain, the less it's susceptible to various mining attacks, most prominently 51% attacks. The financial resources deployed, or the overall mining revenue, are often referred to as security spend, which is solely determined by the incentives provided as block rewards. This reward is composed both of transactions fees, and of the block subsidy, i.e. newly generated coins.
+Grin introduces a constant block subsidy in order to remain sufficiently secure over the coming years and decades. Block reward is then guaranteed, regardless of how full the blocks are, or how much users are willing to pay in fees for faster confirmation.
+Furthermore, this type of emission removes a lot of uncertainty, and avoids the shortcomings of the standard rapidly decreasing emission which has yet to be proven stable and effective on a longer time horizon.
+Most blockchains are designed to generate and distribute most of the currency supply early on, to directly benefit a few, and then increasingly rely on transaction fees to incentivize mining.
+One apparent issue with this approach is that the overall security spend is likely to decrease as time passes, making the chain fundamentally less secure in the face of mining attacks, whether by selfish attackers or state actors. This results in a "tragedy of the commons", as individual users strive to pay a minimum amount of fees, while also depending on the security that their fees are paying for.1
+Even then, the stability of a chain sustaining itself through high transaction fees is questionable.2 It becomes potentially prone to a new set of mining attacks, all of which could be avoided given similar mining revenues earned through a block subsidy.
+How the coin gets distributed carries significant importance. Grin was not created to quickly enrich a few early users, but to provide digital cash to all.
+The constant issuance establishes a fair coin distribution3, where equal opportunity is given to everyone, in any point in time. New users should not feel discouraged or disadvantaged when adopting a new form money.
+In contrast, distributing a very large portion of the coins early, mostly benefits the first users but presents an unwelcoming narrative to new ones, as it assigns them a substantially smaller portion of the network's value. This in turn affects the currency's long-standing story of distribution.4
+As it stands today, the ownership of bitcoin is very centralized and will likely remain so. The situation is far worse in most other cryptocurrencies.
+Such concentration may give birth to a narrow group of individuals and organizations who may have an exorbitant amount of control over the market price. More importantly, they have the power to influence the project and its ecosystem more than any others, since early, disproportioned hoarding carries a good deal of centralization pressure.
+A constant emission aims to support grin's intent of being at the hands of many people and being used to transact freely, as a privacy-preserving medium of exchange.
+Additional properties of constant emission that are worthy to consider:
+Privacy is the foundation of a peer-to-peer electronic cash. In its essence, cash cannot distinguish between individuals, it does not reveal the amounts transferred or owned, and it holds no bias to the history of a specific coin or person. Cash is neutral, the way money should be.
+By cleverly employing mimblewimble along with several other methods, grin is able to achieve these qualities, while also keeping in mind its core design attributes of simplicity and scalability. Let's explore how and to what extent.
+First, there are no amounts. A mimblewimble implementation natively uses Confidential Transactions, meaning all amounts are hidden; They are provably impossible to uncover, yet easily verified. Even before anything else, simply hiding amounts makes any analysis significantly more challenging.
+transaction
+| Inputs | +Outputs | +
|---|---|
| 08c482407fac2.....e335bf2f10d82 | +085cc6944467b.....a3f1d4274b79b | +
| + | 097b2588fd494.....494e43580476b | +
Each transaction also carries rangeproofs and a kernel, which are mostly irrelevant for this topic.
+The above illustrates a normal transaction of 1 input and 2 outputs. The outputs (an input is also a reference to an output) are commitments, a 33 bytes blurb to any observer. There's no address to tie an identity to, and it's not clear which output is the change of the sender, and which belongs to the receiver.
+In a Bitcoin-like system, there are multiple ways in which a user might (accidentally or intentionally) link an address to his identity. Consequently, it is often trivial for analysis to link many of his addresses. Not only does his own privacy suffer, but also the entire network's privacy diminishes as a result.
+While a grin commitment is one unique output, a bitcoin address may be used to receive an unlimited amount of outputs. An interesting analogy could then be used to emphasize the difference:
+block
+| Inputs | +Outputs | +
|---|---|
| 08c482407fac2.....e335bf2f10d82 | +097b2588fd494.....494e43580476b | +
| 0857b6b7eb6a2.....a0a283ed35974 | +09f731e071316.....42dae69672dca | +
| 085e205dea687.....8b8aeac7562c6 | +085cc6944467b.....a3f1d4274b79b | +
| 09035d331b17a.....bb76238f605fb | +094262a95a67a.....2f246f6ce60ce | +
| 0961ee1db49ad.....602489c9c4517 | +09cf2db66b748.....7327297b8e69c | +
| + | 09c2751af8fe9.....fc745808238b6 | +
| + | 0900015eec3c1.....d52d78fca78de | +
The outcome is a non-interactive CoinJoin with hidden amounts. It is named non-interactive since all transactions are aggregated into one without any coordination required between the different parties. This is possible to do at the protocol level, and is simply done automatically whenever several transactions meet each other.
+An observer knows how many transactions are included in the block, since each one carries a kernel, but nothing more. Any further information is impossible to obtain by looking at the chain.
+A sent funds to B, and then B sent them over to C, any trace of B's involvement can be completely removed, such that the result is seen as A -> C.cut-through
+| Inputs | +Outputs | +⇒ | +Inputs | +Outputs | +
|---|---|---|---|---|
| A | +B | +⇒ | +A | ++ |
| B | +C | +⇒ | ++ | C | +
This is could be done at any level of transaction building; Before broadcast, during peer propagation, or in a block. While this trick's use cases are limited, it is a unique manifestation of the "right to be forgotten" in a blockchain.
+Despite the fact that chain analysis can extract very little (if any) information about users and outputs, it is possible to monitor peer-to-peer network activity and obtain the transactions before they're included in a block and aggregated with others. By setting up sniffing nodes connected to many peers, you can figure out which outputs are being spent by what transaction, allowing you to build a partial transaction graph by separating the aggregation done at the block level. It's unclear at this point if meaningful information could be derived from this, as the trail of data stops there.
+As of today, an almost complete transaction graph can be constructed. But as usage grows this will gradually become harder. Likewise, many privacy-enhancing techniques can be employed to easily remove linkability of outputs. Fortunately, with mimblewimble these may be added natively, such that nobody knows when a user takes extra privacy precautions to obfuscate the transaction graph, therefore no coins become "tainted".
+An important piece of information that commonly leaks is the IP address that originally sent the transaction. Normally, a transaction is just broadcast to all connected peers and immediately spreads on the network, allowing for statistical analysis to deduce where it originated. In a peer-to-peer network, this might be hard as transactions are relayed, but over multiple transactions it becomes trivial.
+To tackle this issue, grin employs Dandelion++ (originally proposed as a BIP), a protocol designed to hide a transaction's origin IP address. Dandelion has two phases; a stem phase and a fluff phase. Once a transaction is initially broadcast, it enters the stem phase, in which it hops between individual peers. At a random point, the transaction enters its fluff phase and is spread (fluffed) among the entire network.
This makes it almost impossible to deduce a reliable IP address, and renders statistical analysis impractical.
+
Moreover, Dandelion provides an additional benefit unique to mimblewimble, as it allows for transactions to be aggregated at a very early stage. Right before a transaction starts its fluff phase, it enters a 30s waiting period in which it will be aggregated with any other transactions it meets, thus obscuring linkability of inputs and outputs that a sniffing node may have learned. However, the privacy gained from aggregation before fluffing depends on having many other transactions.
+Privacy is complex and information leakage is surprisingly easy. Privacy-preserving systems need to be extremely strong to ensure reasonable amounts of protection. Unfortunately, they often fail in practice simply because they are cumbersome to use, causing people to revert to convenience.
+Grin is committed to long term privacy protection and will continue to advance in that direction, while remaining practical and accessible to all, regardless of a person's sophistication or available resources.
+ + + + + + + + + + + + + +Proof of work is a consensus mechanism which allows anyone to extend the blockchain, by providing a piece of data that is both difficult to produce and easy to verify (according to set parameters). Proof of work also serves as the basis for the security and distribution of the coin.
+Grin has an average block time of 60 seconds and employs Cuckoo Cycle1, a memory bound proof of work algorithm, or more specifically, a variation of it named Cuckatoo that is meant to simplify ASICs.
+The algorithm finds length-42 cycles in a bipartite graph. The current (and final) grin PoW is Cuckatoo32+, in which a graph must have at least 232 + 232 nodes. For a comprehensive introduction, read here.
+Q: Why use a memory-hard proof of work?
+A: The point is that chips dominated by memory have rather different characteristics from computational chips; they run much cooler, dissipating less heat per unit of area. This shifts the mining cost from mostly OPEX (electricity) to mostly CAPEX (hardware cost), which delays obsolescence and allows mining in places with higher electricity costs.
+Grin has two PoW algorithms:
+During the first 2 years of grin, the algorithms gradually balance themselves to satisfy the current ratio, starting from 90/10 and eventually becoming 0/100, such that the only proof of work remaining after those initial 2 years would be Cuckatoo32+. This period includes scheduled hardforks every 6 months, in which Cuckaroo29 is modified in order to interrupt possible ASIC development for it.
+The above simplifies a bit, since in practice Cuckatoo31+ was initially the primary PoW but was phased out completely after 18 months, for reasons we won’t discuss here. You can read about it on this post.
+ASICs are special pieces of hardware especially designed to do a specific task as quickly and efficiently as possible. In our context, they solve PoW a algorithm at a much faster rate than general purpose hardware, such as consumer GPUs. The common arguments against ASICs are about how they raise the barrier to entry for mining, and the centralization that may occur when a single ASIC manufacturer has complete market dominance.
+These issues are mostly solved once a mature, competitive market for ASICs appears. However, as became apparent with bitcoin, this natural process may take time. Grin’s Cuckatoo32+ simplifies ASIC design in hope to reduce the time until they become widely distributed and accessible.
+The choice of upholding some ASIC-resistance in the first 2 years was made to ensure fair initial distribution, in which no single party has a disproportional mining advantage at launch, before the market becomes populated and competitive enough.
+Let’s see why encouraging ASIC development might be beneficial2 in the first place:
+The security of a chain depends both on the amount of capital allocated to mine it (CAPEX), and on the cost of electricity & operation (OPEX). But the CAPEX is only relevant if the mining hardware's main function is to mine our specific chain and is mostly useless otherwise.
+We should want to avoid having the chain prone to attack by large hardware operators who own no stake in its success (no skin-in-the-game), since they can attack it and divert their hardware to other uses without incurring any loss to their capital.
+Therefore, to achieve optimal security, two conditions must be met:
+There’s increasingly more evidence that ASICs are inevitable, as dedicated hardware will always have ways in which it can improve upon general purpose hardware. While it is possible to make ASIC manufacturing more difficult, over a long period it is likely to end up a centralizing force in itself, as it makes the chain vulnerable to secret ASIC operations3.
+A Mimblewimble chain is massively-prunable, which allows it to stay lightweight and cheap to verify. Its core essence is this unique balance of privacy and scalability.
+For a mimblewimble chain to be valid everything has to balance out, such that all outputs minus all inputs equals 0 (plus fees). Given that spending an output is practically just copying it to the input side of the equation, then that spent output can be completely removed from the chain and the balance still holds.
+(switch between tabs)
+| Inputs | +Outputs | ++ |
|---|---|---|
| + | t r a n s a c t i o n | ++ |
 |
+ |
+Kernel | +
| + | t r a n s a c t i o n | ++ |
|
+ |
+Kernel | +
| + |  |
++ |
| + | t r a n s a c t i o n | ++ |
|
+ |
+Kernel | +
|
+ |
++ |
| + |  |
++ |
| + | t r a n s a c t i o n | ++ |
|
+ |
+Kernel | +
|
+ |
++ |
| Inputs | +Outputs | ++ |
|---|---|---|
| + | t r a n s a c t i o n | ++ |
|
+✱ ✱ |
+Kernel | +
| + | t r a n s a c t i o n | ++ |
| ✱ ✱ |
+✱ ✱ |
+Kernel | +
| + | |
++ |
| + | t r a n s a c t i o n | ++ |
| ✱ ✱ |
+✱ ✱ |
+Kernel | +
|
+✱ ✱ |
++ |
| + | |
++ |
| + | t r a n s a c t i o n | ++ |
| ✱ ✱ |
+ |
+Kernel | +
| ✱ ✱ |
+ |
++ |
| Inputs | +Outputs | ++ |
|---|---|---|
| + | t r a n s a c t i o n | ++ |
|
++ | Kernel | +
| + | t r a n s a c t i o n | ++ |
| + | + | Kernel | +
| + | |
++ |
| + | t r a n s a c t i o n | ++ |
| + | + | Kernel | +
|
++ | + |
| + | |
++ |
| + | t r a n s a c t i o n | ++ |
| + | |
+Kernel | +
| + | |
++ |
An output is considered 'spent' once it is used as an input. As demonstrated above, every single input can disappear as well as every spent output. What remains is only the set of unspent outputs and all transaction kernels (~100 bytes).
+In order to verify the entire history starting from the genesis block, a verifier needs:
+An output is a 33 bytes commitment accompanied by a 640 byte rangeproof.
+Following this logic, the chain mostly grows by the number of users, instead of the number of overall transactions. In fact, it often shrinks in size when more inputs are used than new outputs are created.
+Building, verifying and storing transactions requires minimal resources. Anyone can verify the entire chain on a phone or cheap hardware, and fully participate in areas with poor network connectivity.
+Comparison for bitcoiners
+At the time of this writing, there were 560M bitcoin transactions since its genesis. Anybody who wishes to verify the current state must replay each and every transaction in its history. They will go over billions of outputs to eventually derive the current set of 66M unspent outputs.
+Mimblewimble shrinks the transaction history such that a chain with bitcoin's history would be kept at around 1/4 the size. This difference becomes much more exciting if one remembers that confidential transactions are extremely resource consuming, since each output requires a large rangeproof. If the current bitcoin blockchain had hidden amounts, it's size would have been on the order of several terabytes.
+ + + + + + + + + + + + + +On Mon Aug 01 2016 a user named majorplayer logged into the #bitcoin-wizards IRC channel, dropped a text file hosted on a Tor server and then disappeared. The document1 was titled MIMBLEWIMBLE and authored under the pseudonym Tom Elvis Jedusor. It described a protocol which is both private and extremely lightweight.
Tom Elvis Jedusor is the French name for Tom Riddle (Lord Voldemort) from the Harry Potter book series. +Mimblewimble is a tongue-tying spell.
+-!- majorplayer [...] has joined #bitcoin-wizards
+<majorplayer> hi, i have an idea for improving privacy in bitcoin. my friend who
+knows technology says this channel would have interest
+http://5pdcbgndmprm4wud.onion/mimblewimble.txt
+-!- majorplayer [...] has quit [Client Quit]
+Its title:
+MIMBLEWIMBLE
+Tom Elvis Jedusor
+19 July, 2016
+The following day, users nsh and andytoshi (Andrew Poelstra) began discussing the idea proposed in the paper. The anonymous writer left several un-answered questions in the document, along with a general lack of details, so there was much to discuss. The conversation included a memorable moment:
<nsh> gotta be some way this is sneaky, otherwise it's too good to be true...
+<andytoshi> hah, yeah, i know the feeling
+On Oct 10 2016, Andrew Poelstra published a follow-up paper2 about Mimblewimble, which introduced several refinements to the original proposal and describes further its technical details.
+On Oct 20 2016, a pseudonymous developer using the name Ignotus Peverell, announced in the bitcoin wizards IRC channel that he began work on a minimal implementation of the protocol, which he named Grin.
+Ignotus Peverell is the wizard who was gifted the Cloak of Invisibility by Death. +Grin is short for the Gringotts Wizarding Bank.
+-!- igno_peverell [~user@104.238.169.137] has joined #bitcoin-wizards
+<igno_peverell> I have a minimal implementation of MimbleWimble available. It's very far from complete but has the basics, included the summing of Pedersen commitments:
+<igno_peverell> https://github.com/ignopeverell/grin
+<igno_peverell> Any feedback or review is greatly appreciated. Thanks!
+Igno was joined on GitHub by other developers who took interest in the project, several of them bearing pseudonyms of other Harry Potter characters.
+While Mimblewimble serves as the foundation to a blockchain, it constitutes a relatively small part of a complete cryptocurrency, and many choices were yet to be made. Thus, began the journey to create a full implementation. A community of contributors and users slowly started to form around grin.
+Grin's genesis block was mined on January 15th, 2019. It was, and still is, young and experimental. It currently goes through rapid changes, as its first 2 years include agreed-upon hardforks in 6-months intervals.
+Several months after launch, Ignotus Peverell disappeared and has yet to return.
+Developers distributed around the world are contributing to build grin, some of them funded by donations to work on the project full-time. Development will always remain completely transparent and open for anybody to join.
+Mimblewimble transactions are interactive, meaning both parties need some kind of communication to interact with each other and exchange the necessary data to create a transaction.
+Let's see how a standard transaction flow looks like:
+
The slate is a sheet of incomplete transaction data. Wallets transfer it back and forth until the full signature is complete.
+In more detail, the process goes as follows:
+An address, often referred to as a Slatepack Address, is provided by the receiver. It is important to note; This slatepack address is only used to support peer-to-peer interaction, and is completely different from the familiar on-chain address, as it's not part of the ledger. It is in fact an ed25199 public key which serves a double role:
Sender begins building the transaction slate, encrypts it with the receiver's address (a public key), and passes it over.
+One nice side-effect of interactive transactions is that coins can't accidentally be sent into the "void" (a public key/address which nobody controls).
+The interaction between sender and receiver happens in one of two ways.
+As mentioned earlier, the slatepack address is also used to derive a Tor address. By default, the sender's wallet will try to communicate with the receiver's wallet via Tor.
+If the connection succeeds, all the rest is done automatically by the two wallets and no manual action is required. The process is exactly as described above, but it all happens under the hood without further intervention.
+However, if the Tor connection between the wallets is not successful for whatever reason, grin defaults to manually exchanging slate text messages, also called slatepacks. manually.
+Synchronous communication can also happen through regular http, but it requires opening port 3415 and thus might be complicated. We don't cover it here as this method will soon be deprecated.
+Recall that slates are simply partial transactions. Slatepacks are slates encoded inside compact, neatly organized and encrypted text messages.
+Using this method, 2nd and 3rd steps, where the sender and receiver pass the slate to one another, would be done manually by exchanging these slatepack messages. To do so, almost every available communication channel will work; e-mail, forum, chat, social media, letters, pigeons etc. Creativity is the only limit.
+The address (public key) initially provided by the receiver will be used to the encrypt the slatepacks, so that only the transacting parties are able to see the data inside.
+Non-encrypted Slatepacks
+It is possible to skip the 1st step (providing an address) and straight up send a non-encrypted slatepack to the receiver. Keep in mind that in this case, if the communication channel is compromised or public, observers may learn some transaction information.
+Invoice transactions are built much the same way, but with a different order where the receiver initiates the transaction by asking for a certain amount of coins.
+