Given the difficulty of selling testnet Grin, ROI is negative:-(

Simplest possible consensus model: Proof of Work. Grin uses Nakamoto consensus just like Bitcoin.

Simplest possible emission: 1 grin per second forever. Grin uses Tail Emission from launch, the complete opposite of Bitcoin's Capped Supply. The latter is known to suffer from insecurity and mining instability once the block subsidy becomes insignificant, unless a constant backlog of high fee paying transactions can be created (which Bitcoin seems to manage with its constrained block size). Emission properties are further explored in [1a] and [1b].

Simplest possible blockchain protocol: Pure Mimblewimble. In Mimblewimble, outputs are Pedersen commitments r*G+v*H which combine value and blinding factor into a single curve point. The blinding factor serves both to hide the value and to control ownership. Correspondingly, a single (multi-)signature serves both to prove value balance (non-inflation) and to authorize transfer of ownership. The magic doesn't stop there, as transaction cut-through results in the collapse of the entire transaction history into a single transaction with no inputs and the current UTXO set as outputs [2].

Simplest possible blockchain sync: verify UTXO set. Grin still verifies transaction history by means of a ~100 byte kernel that remains for every transaction, but doesn't need to know anything about spent outputs.

Simplest possible (memory hard) Proof of Work Algorithm: Cuckatoo Cycle. Its mathematical specification is only 13 lines [3a] based on the very simple siphash-2-4 hash function. Which translates to just 42 lines of C code [3b]. Like Bitcoin, solutions can be instantly verified, but unlike Bitcoin, a single solution attempt (searching a graph) takes on the order of a second.

Simplest possible Difficulty Adjustment Algorithm: wtema. Just one line of code [4] that outperforms many other DAAs [5].

Simplest possible scripting functionality: scriptless scripts. Grin does away with Bitcoin's script and all its complexity, but retains a lot of its functionality, including multi-signatures, and both absolute and relative timelocks. It easily supports atomic swaps, discreet log contracts, and bidirectional payment channels. It lacks hash locks, but finds a superior alternative in adaptor signatures

The simplicity is reflected in the relatively small Rust codebase of the reference implementation [6] and the alternative C++ implementation [7].

[1a] https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a188d153

[1b] https://medium.com/@CryptoProfG/grin-money-explained-4-exploring-grins-monetary-model-e48b1761653

[2] https://phyro.github.io/what-is-grin/mimblewimble.html

[3a] https://github.com/tromp/cuckoo/blob/master/doc/mathspec

[3b] https://github.com/tromp/cuckoo/blob/master/doc/spec

[4] https://github.com/mimblewimble/grin/blob/master/core/src/consensus.rs#L371-L372

[5] https://read.cash/@jtoomim/bch-upgrade-proposal-use-asert-as-the-new-daa-1d875696

[6] https://github.com/mimblewimble/grin

[7] https://github.com/GrinPlusPlus/GrinPlusPlus

You can prevent it by creating a backlog of high-fee paying transaction, which Bitcoin has achieved by constraining the block size.

Congratulations on a smooth upgrade to version 5!
(technically it was not a hard fork as the old code would simply refuse to accept any block at height 1048320)

Goodbye, members of the CuckARoo family. You successfully kept out ASICs over the past 2 years.

Meanwhile, I'm awaiting delivery of a Cuckatoo32 ASIC to be used for testnet mining.

Not necessarily. You can have a minimum fee scaling factor in a configuration file.
After all, this is not a consensus parameter. So after the price has gone up by an order of magnitude
for a long enough period, you could agree to have as many nodes as possible to update this scaling factor
to be 10 times smaller. Over time, more and more nodes will adopt this new value, and allow
the mempool acceptance and relay of transactions with 10x smaller fees.

https://grinnews.substack.com/p/129-the-final-scheduled-fork-

Hard Fork Incoming!

Node changes:
Improve transaction fee calculation, as outlined in https://github.com/mimblewimble/grin-rfcs/blob/master/text/0017-fix-fees.md
Improve difficulty adjustment algorithm, as outlined in https://github.com/mimblewimble/grin-rfcs/blob/master/text/0018-fix-daa.md
(Partial) Parallel IBD: Preparation for support of an improved process for initial sync and download of blockchain data, as outlined in https://github.com/mimblewimble/grin-rfcs/blob/master/text/0020-pibd-messages.md

Wallet changes:
Late locking of outputs: Removing the need for outputs to be locked during transaction building before the final stage.
Remove http listener for external addresses: As per the deprecation announcement with v4.0.0, remove support for unsecured http listeners in favour of the slatepack 43 standard.

Countdowns:
https://www.nicehash.com/countdown/GRIN-forking-2021-01-17-12:00
https://grinnode.live/

Yes, an emission modeled after time, at 1 per second forever (600 block reward) would have been very interesting.
Then the inflation rate would currently be at around 8%, and would take decades more to fall under 2%.
That requires a lot of patience. But it could have made Bitcoin more attractive to later generations.

You failed to provide any convincing arguments for this though.
Precision will be added simply as a result of a satoshi becoming too valuable to be a smallest unit,
not because too much bitcoin has been lost (which we'll never know except by vague guesses).

I understand the sentiment of your post, that you think a tail emission makes much more sense
than a capped supply (I am in that camp myself).

But Bitcoin, being the dominant player that it its, may be one of the very few PoW coins that can make a hard cap work in the long run. It just needs to maintain that backlog of high fee paying transactions.

Assuming a yearly 1% loss rate, it will take approximately 1375 years for supply to dwindle down from 21M BTC to 21 BTC.
If by that time, each satoshi has subdivided further into 10^6 subunits, then the system can keep functioning mostly as is.
Adding on average one decimal every 229 years should suffice.

It looks like those coins combined account for less than 0.1% of Bitcoin's daily issuance, and thus have negligible contribution to Bitcoin security.

Not as much as you might think.
Both the cost of a 51% attack and the possible double spending gains scale linearly with Bitcoin price.
Security is about the mining reward being a sufficiently high fraction of circulating supply.

Actually, Bitcoin could use a variant of Mimblewimble that foregoes the privacy benefits.

A UTXO could be a triple <v, PK, sig> of an amount v, public key PK,
and a signature sig with PK on v to replace the range proof in MW.

A transaction tx is then a set I of inputs, a set O of outputs, and a signature with public key

    tx.PK = sum_{o in O} o.PK - sum_{i in I} i.PK

which the transacting parties can interactively construct just as in MW.

This preserves MW's ability to trivially aggregate transactions, and also allows for an additional "kernel offset"
to obfuscate original transaction boundaries (adjusting the above equation by offset*G).

This reduces z to about 100 bytes, and the Initial Block Download to 600M * 100B + 68M * 100B ~ 67 GB.

No; we'll just see 2 camps of people. The supply-cappers and the tail-emitters.
Both agree that mining rewards should always be very significant, in order to achieve long term security and stability.
These two conflicting visions also see different outcomes of inevitable coin loss,
which I believe is very unlikely to drop below 0.1% and may be closer to 1% on a yearly basis.

Capped Supply

A supply cap requires a block reward dwindling to insignificance (long before it reaches 0).
So the significant mining reward must come from large fees. Mining stability requires a steady backlog of fee paying transactions, which in turn requires a highly constrained block size. Coin loss will erode the circulating supply over time
and will eventually necessitate subdividing the smallest unit.

Tail Emission

With an eventual (or even from launch) constant block reward, fees are only needed to deter spam, and block size is less constrained. It could be more dynamic to deal with surges in transaction demand, or slowly grow over time. Coin loss will put a softcap on circulating supply.

People who stop believing in the 21M bitcoin cap could of course try to fork away, but such a fork would very much go against Bitcoin's main principle of immutability. and would likely fare no better than altcoins that embraced the tail emission from the start, which is probably what those people would instead gravitate to.

Bitcoin cash is interesting for being in the Capped Supply camp, while being unwilling to highly constrain the block size. Which looks like a recipe for long term insecurity and/or instability.

>It has always been offering a good level of privacy to users while the users sometimes decide to void that privacy by willingly linking their identity to their bitcoins.

I think the default level of privacy is poor. The reason is that people think of Bitcoin transactions as being non-interactive. The sender just sends some money to a receiver.

To avoid address reuse, one must go to the trouble of making transactions interactive. Namely, first have the receiver present a fresh address to the sender. In many cases this interaction is not even feasible. E.g. when asking for donations in Bitcoin.

So many payments end up reusing addresses, resulting in poor privacy. What you describe as willingness to link their identity to their bitcoins, is more often just unwillingness (laziness) or inability to unlink their identity from their bitcoins

Will Monero ever be as scalable as Bitcoin (with txs being an order of magnitude larger, and full nodes unable to forget everything about spent outputs) ?

Or ever have a fully auditable supply?

Kucoin was not so fine for this user:

https://forum.grin.mw/t/kucoin-account-hacked

It looks like you're discussing Initial Block Download communication costs.
Assuming 2-input, 2-output txs, I get

Bitcoin tx size x ~ 400 bytes (or is it closer to 500?)
MW kernel size y ~ 100 bytes
MW output + rangeproof size z ~ 700 bytes (600 with BP+)

Are you saying that 400 is somewhat larger than 100, and 700 is MUCH larger than 400 ?

Plugging in N_txn=600M and N_utxo=68M, we get IBD sizes of 240 GB for Bitcoin and 60 GB + 48 GB = 108 GB for MW.

This cut-through mechanism is the modus operandi of the Mimblewimble protocol [1], where it doesn't need interaction with any of the tx signers and can be applied across the entire blockchain history to slim down the Initial Block Download.

[1] https://github.com/mimblewimble/grin/blob/master/doc/intro.md

I guess they want to pretend every PoW is a hashcash, or are too lazy to properly account for different PoW.


No; a 1080Ti does only 0.46 gps on Cuckatoo32, according to https://whattomine.com/

I'll buy a day of Grin at that price....

(funny that a whole day of Grin now costs less than 1 BTC...)