Adding a link that explains how we can construct a mapping of real world time to monetary units [1]. This enables us to run an experiment where time is money which I believe may be the first global, open and permissionless experiment of such kind. I think Grin (accidentally?) implemented this monetary experiment first in 2019.

[1] https://gist.github.com/phyro/27e4100255bdf8be79a19bc98750944f

This topic is about the simplicity of system design, not about the UX which is also important, but an entirely different thing.


The question is, could it be simpler? And today we know the answer is affirmative.


Satoshi being brilliant doesn't mean he knew everything. He discovered a new space but didn't research all of it because he was aware of the analysis paralysis problem and had to start with something that wasn't the best system possible, but was good enough.

Bitcoin is a new monetary experiment with a predictable and hard-cap max supply. It's great and full of innovation, but it's not the only experiment that's new and worth trying.


An emission equal across time creates a time-cap max supply which is predictable and new too. It's also a lot simpler and more intuitive because it does away with halvings.


I think a big drawback here is the social side of it. Everyone's focused on experiments that improve the system by adding new op codes and very few try to improve it under today's constraints. This in turn creates politics and conflicts around which op codes should be added which I don't find particularly productive.

I'm confused why we're trying to guess what happened. Grin had open communication channels way before it launched so everything's publicly available. Much better than just sharing our unsubstantiated opinions would be to take the time to read these channels or ask someone that knows.

I'm afraid that's not the philosophy behind Grin. Features add complexity and there's a sea of projects whose focus is nothing but continuous adding of something so that people can hype themselves up around the next "revolutionary" thing. Grin will likely remain what it is today, just like Bitcoin. And while it does have a much better privacy than Bitcoin due to confidential transactions, it's not about maximizing privacy coin at all cost. Mimblewimble is good at achieving a lot with very little complexity. It would be a shame to throw away the simplicity and elegance of this design just to inject a short term dopamine rush into speculators.

It's Grin's 5th birthday. 

I agree with this. Grin is one of those rare projects that takes time to get off the ground. It goes "all-in" on simplicity and fairness, even more so than Bitcoin, which we all love and support. Perhaps the most unique feature of them all is the monetary policy, which not only ensures a fair distribution over decades, it also mimics time. From what I can tell, it's the closest to a "time is money" experiment we've been able to create, and it's the supply following time that creates a slow start. Unfortunately, there's no way around it (unless you have a time machine), but this also means very few projects will try such experiments. It's not a "privacy coin", but rather a monetary experiment vastly different from Bitcoin's that might be worth bringing to life. The community is indeed small today, but also quite different from what you'll see in other projects. I can't recall when I've seen people talking about getting rich with Grin and that's a good thing. Grin will be celebrating its 5th birthday soon, so if anyone wants to show some love, come blow a candle on the forums on January 15th.

As a general suggestion for those who enjoy commenting, it's often wise to share our thoughts only on topics we are knowledgeable about. There is already an abundance of misinformation circulating, so let's try to not add to the noise with additional uninformed opinions.

It's possible what follows contains logical mistakes.

I was toying with a similar idea where each output would be its own Utreexo. Since that's a forest of trees, an output would need to keep the roots and each root would have the amount sum of the elements in the tree. This way, we'd know the amount the Utreexo UTXO holds and can do the inflation check.
Much like Utreexo, a transaction comes with is a list of inclusion proofs [proof1, proof2,...] which gives us the inputs. A transaction also defines the outputs that are created. We check the signature and that the transaction is well balanced and then delete the inputs from the Utreexo tree and add outputs as new elements to the Utreexo.
I'm not sure I remember correctly, but I believe anyone can delete an element if they have the forest roots and the inclusion proof and anyone can add an element if they have the element and the roots. Since we have both as part of a transaction validation, anyone can update the Utreexo accumulator.

This obviously isn't compatible with Bitcoin today, but may be an interesting direction to think in. Those interested in a specific Utreexo may have the tree saved locally and could share it with others in the tree if someone lost their inclusion proofs.
It may even be permissionless to put your UTXO in any Utreexo. Simply spend a regular UTXO and add it as an element to Utreexo which should be possible because we have the forest roots for all of them.

Rather than seeing the energy consumption as a problem, we should see it as a solution. The energy consumption of Bitcoin is its security. If you do away with energy or reduce it, you change the security model.

You can secure the order of transactions with a virtual or physical resource.

Bitcoin chooses the latter and secures the chain as long as the majority of computations are directed at the honest chain. We know computations require energy to execute and because we're doing so many computations (300 exa/s), this consumes a ton of energy (physical resource) that secures our chain.
Here comes the interesting part. If you want to secure yourself from really high energy attacks (e.g. state-level energy attacks), you have no choice but to combat them with higher energy. Thus, Bitcoin consuming energy levels of countries is really the only way to keep it *really* secure from large scale attacks.

You could argue that instead of energy, we can use other resources from the physical world like space and time. Some consensus attempts try to use these, but my intuition is that it can't possibly have the same level of "hardness" or "cost" to it because space doesn't really "move" around and hence there's no work to it. Admittedly, this is very layman view and I never really looked at how exactly they try to achieve this.

Chains like Ethereum secure the order with a virtual resource called a coin. This resource is completely disconnected from the physical world. Some would argue they are connected because we can have physical consequences (e.g. prison time in case of a theft), but this is just our interpretation of it. The resource itself is inherently disconnected from the physical world because it's defined inside this made up system itself. As a consequence, it comes with no real physical cost and no physical constraints. The reason why you may want to have physical constraints is because the world we live in is a system we don't know how to exploit, at least not yet. This means leaders/countries don't have magic knobs to bend the rules and gain an advantage. Physical world is objectively fair, it encodes no assigned ranks or leader positions.

Perhaps the simplest model to think about is to look at what happens when you pay with banknotes in a store.

Suppose you have $20 and $10 banknotes and pay for an item that costs $22.

You give two banknotes $20 and $10, the cashier takes $22 and you get $8 back.

Bitcoin mimics this process. We just call these banknotes "outputs" and they can hold arbitrary value. So in this case, a transaction would
1. use two outputs with $20 and $10 (in btc of course) and
2. create two new outputs. One holding $22 whose owner was the cashier and one holding $8 with you as the owner

We call used outputs "inputs". It effectively splits some of the existing piles of coins (inputs aka old outputs) into new piles of coins (new outputs) and sets the owners as defined. Just like in a store. 

What tromp probably referred to is the simplicity of the system design. Make sure to check this video [1] if you're interested in the topic.

If you read the content of the linked page, you can see separate functionalities being enumerated like consensus model, emission, blockchain format, sync format, supply audit, PoW Algo etc.
If we define these as vectors and define 0 to be the simplest solution that can theoretically exist then we can, with some bias, assign a value to each dimension.
This means a blockchain can be seen as a point in a multidimensional space where (0,0,0,0,0,0,0,0,0) is the theoretically simplest possible blockchain to exist.
Of course we don't know what that looks like. But from the systems I've seen, I would agree Grin is by far the closest to that origin point and thus the closest to the theoretical optima of blockchain system simplicity.
That said, Bitcoin is closer to origin point than most of the other chains, but it's quite a bit more complex than the design linked. With regards to making Bitcoin simpler, it can be made simpler to use, but system complexity is unlikely to go away because you'll need to support all the current functionality which includes its expressiveness (scripting).

1 - https://www.youtube.com/watch?v=LKtk3HCgTa8

Everything was that easy - this recipe has been executed.

Let's say a block can accept exactly 1000 transactions. Imagine we have two forks Bitcoin1 and Bitcoin2 both of which are valued at $10 per coin and have the same supply.

Bitcoin1 has blocks with a single transaction along with a coinbase output.
Bitcoin2 has blocks with 1000 transactions all paying the minimum fee to cover their transaction size.

Which one do you think secures more energy per block?

My comment was referring to a single singature, not a chain of signatures. I'll comment a bit on the chain of signatures though. You can always encode a new transfer sequence as a linear chain of onchain outputs i.e. a sequence of single input, single output transactions is the simplest form. People could "define" (I put it in quotes because it's a social construct) the coinbase address to own the block PoW.
This PoW could in theory be agreed on to be transfered with a chain of signatures defines as a chain of outputs. This should work as a concept. The PoW obviously isn't in the address at the head of the chain, but it was never in any of the historical addresses. It's there because of our agreement and the fact that nobody could've tampered with the transfers.

Rather than signing dates, they should sign a hash of the block header that was mined 10 minutes ago. This proves it was impossible for a message to be signed by creating plenty of msgs or whatever. It's exciting seeing an early Bitcoin signature, thanks for the entertainment OneSignature.

I agree, hence why I added the "(unless they expect greater returns in some reasonable amount of time)" which you left out of the quote.

It is true. Think of it this way. The network asks humans to provide security to the network in terms of energy in each step. Since the amount of energy is nontrivial (the whole basis of Nakamoto security), the network promises some compensation to those that protect the network. Nobody is going to mine at a loss (unless they expect greater returns in some reasonable amount of time) so the network security will be roughly the same as the compensation amount because of the incentives/game theory. At the moment, the compensation is a sum of two variables:
1. subsidy - a fixed reward that mints new coins. This variable is design such that it phases out over time
2. fees - a "tax" to incentivize your transaction to take the space on the chain

With time, the subsidy variable disappears into "basically nothing" value and you're only left with the fees. This directly corresponds to the number of transactions as a lower boundary. The network security will be based on it's usage which means on the number of onchain transactions and the competition to capture the block space (bumping the fees as a bribe mechanism).

I tried to explain some of the differences in PoW/PoS here https://phyro.github.io/nakamoto/. It doesn't go into theory or touches subjects like coin distribution. It focuses more on the difference in how a new block is added. Let me know if I got some things wrong.

I can answer about Grin. Please correct me if I'm wrong about BOLT12 as I've only skimmed over it. The main concept of BOLT12 seems to be to share information from A to B directly through some hops, in this case by routing over the lightning network.
The first thing to note in a lightning environment is that you must have something online to sign the transfer which I guess in this case is the lightning node. In Grin, we have a Slatepack standard (https://docs.grin.mw/grin-rfcs/text/0015-slatepack/) which does something similar.
When someone wants to send some coins from address A to B (address is an offchain information) it derives an onion service address from the address and attempts to share the information by trying to communicate with the onion url.
The other party needs to run the listener on the other end by running that onion service so it has a similar online requirement to the lightning network and it hops over Tor rather than the lightning network. This functionality is supported by the wallet.
If it succeeds in finding the service, the two parties exchange the messages over this communication channel, otherwise you receive an encrypted message for that recipient address to copy/paste to them on whatever communication channel you want (yes, manually copy pasting).

I think both LN and Grin are in the process of figuring out which transport methods work best and iterating on these. There will be something better than BOLT12 and there will be something better than Slatepacks, but both are a great start in the right direction.

The most inline with Bitcoin design would be the Mimblewimble chain format because, unlike other designs discussed in this thread, it achieves better privacy by making the protocol simpler. It also comes with the simplest mixer which, as far as I know, is much more efficient than any mixer on Bitcoin.
I don't think Monero's ring sigs are worth considering at this point. The idea was very interesting years ago, but at least to me, it seems like a relatively bad tradeoff to make today. You're much better off adopting ZCash's newest z2z variant or something like a variant of Lelantus.

Btw, regarding drawbacks listed in Grin. Interactivity is a tradeoff rather than a drawback. Let me list some benefits of interactivity that are overlooked:

1. It allows one transaction flow to create all possible transactions (you can't build a payjoin or other multiparty tx with a noninteractive transaction)
2. Payjoins could in theory become the default behaviour (read more about payjoins here https://en.bitcoin.it/wiki/PayJoin)
3. Any transaction party can decide to bump fees if they want to speed up transaction inclusion in a block
4. Any transaction can provably commit to a document (with a multisig)
5. No more need for a test transaction before sending the money
6. In MW, the receiver proves the ability to spend the output when they receive it. It becomes impossible to send to an address whose private key was lost
7. Parties can pay for their own onchain objects e.g. if the receiver wants to create 7 outputs, they can do so, but they pay 7*output_fee + 1/num_participants*sig_fee

Benefits of interactive-only transactions (Mimblewimble design):

1. Every transaction comes with a cross-input-output-signature-aggregation
2. You get full wallet control - unlike in Bitcoin and other cryptocurrencies where you control only what you spend, you can actually control what you receive
3. No more taint/dust/ads output injection attacks
4. Potential for the unification of onchain and lightning transaction flows (or at least making these very similar)
5. You know which outputs you own can exist since you've created them. This means there's no need to scan the blocks for your outputs if you don't reuse the seed on multiple wallets e.g. a hot wallet on the mobile phone.
6. Since you create the outputs, it becomes possible to label the outputs at creation. Whether that's some kind of graph coloring, note keeping or something else

Drawbacks:

1. Cold storage becomes tedious
2. Exchange integration becomes more painful
3. Interactive experience (not necessary to be online at the same time)

Note that if drawback 3. is so bad that it can't be widely adopted, this means that neither can the lightning network because it also requires interactivity.
Point 1. and 2. are of such nature that a solution needs to be built once so it's really a O(1) cost and after this, you're good to go.

Requirement that both agree to release it is what enables fraud. If I pay you X in exchange for some good Y and you refuse to give me Y after you were paid X, then I should be able to prove (regardless of how you feel about it) that I paid X to get Y. Otherwise you can only ever transact with the people you trust which makes it unusable as a payment system. You have to protect the payer from a fraudulent payee.