"Is a colored coin a meta-coin?"
I think the term "meta-coin" has only been used by me.
I coined it back in 2014, when writing the first edition of 'Mastering Bitcoin.'
I wanted to differentiate between altcoins that have their own blockchain,
and coins that use metadata on top of another blockchain.
Nowadays, I don't think that term is useful. That distinction is a bit blurred.
Coins that use metadata on top of an existing blockchain...
according to my definition, colored coins are meta-coins,
as they do not have their own blockchain, and use metadata on top of another blockchain in order to exist.
In the particular case of colored coins, that usually refers to the Bitcoin blockchain.
Nowadays, we have all these tokens, which could in some ways be considered meta-coins;
they are metadata on top of Ethereum.
Then again, not really metadata, as they are [part of] full [Ethereum-based] smart contracts.
So the definition [of meta-coin] is a bit blurry.
Let's go to the second question. Albert asks:
"How would the colored coin appear on a blockchain? Can a transaction with a colored coin be distinguished?"
Yes, it can. What you will see on the blockchain, within the transaction that refers to a colored coin,
there will be some additional data in the OP_RETURN field, which is a non-spendable output of up to 80 bytes.
These 80 bytes usually have a prefix that identifies which protocol they are using.
For example, colored coins such as Colu or the Open Assets Protocol [use marker outputs to identify them].
If the transaction is part of a second-layer like CounterParty or Omni, the OP_RETURN field...
will contain a prefix that identifies it as a CounterParty or Omni metadata transaction.
As a result, you can identify colored coin transactions from secondary layers on the blockchain.
A similar question: "With regards to colored coins, how is a genesis transaction created?"
"Is the genesis transaction part of the genesis block?" No, it is not.
A genesis transaction is a transaction on Bitcoin that [uses] the OP_RETURN [field].
[The metadata within] that OP_RETURN identifies that a new colored coin has been created.
The OP_RETURN would have some kind of prefix identifying which colored coin protocol is being used
and would 'color' the specific coins in that transaction with ['marker outputs'] for the colored coins created.
That it is called the "genesis transaction" is confusing, I agree. We use the term [differently] in Bitcoin.
[In this context], it is the genesis of that colored coin. 'Genesis' is simply the Greek word for "birth."
So it is the transaction which gives birth to that colored coin.
"What is the difference between coins and tokens? Can [the difference] be defined in layman terms?"
Great question! I have wanted to talk about this for a while, because people use the terms interchangeably.
I think a good definition is this: a "coin" has its own blockchain, [whereas] a "token" does not.
A "token" is implemented on top of a "coin."
For example, the colored coins used in CounterParty, Omni, and [other implementations]...
those are all tokens and they work on top of bitcoin, which is a coin with its own blockchain.
All of the ERC-20 and ERC-721 tokens that exist in Ethereum, those are all tokens.
They don't have their own blockchain, they operate on top of the Ethereum blockchain.
People may use these terms interchangeably, which is very confusing for most new users.
I think one way to remove the ambiguity -- though it will not be a perfect rule and will probably be violated --
is to call things with their own blockchain "coins," and things which operate on top of another blockchain...
as a smart contract or secondary layer "tokens."
"Can anyone create their own coins using Ethereum?" Yes, [in a way]. Those are called "tokens."
In last week's class, we talked about the difference between "coin" and "token."
While this isn't a broadly accepted definition, I use it for convenience:
"coins" are things which have their own blockchain, "tokens" run on top of another blockchain.
ERC-20 tokens run on top of the Ethereum blockchain, which has its own coin called ether.
Similarly, the Bitcoin blockchain has its own coin called bitcoin. It also has the ability to support tokens,
such as those using CounterParty or Omni, which are not coins because they don't have their own blockchain.
A follow-up question: "How were Ripple and Litecoin created?"
Both Ripple and Litecoin are independent [coins], they are not tokens on another blockchain
They have very different [histories and] paths. Litecoin is primarily based on Bitcoin's codebase,
[which it has] slightly modified, has been following the development of Bitcoin very closely, and is meant as...
a "lighter, faster" version, exploring different trade-offs between scalability, security, and centralization.
It still retains more than about 99% of the Bitcoin codebase and keeps upgrading accordingly.
Ripple, on the other hand, is a completely separate codebase. It has nothing to do with the code in Bitcoin.
It has a different model for implementing its network [architecture] and the validation of transactions.
It uses a federated [system] instead of a [decentralized] blockchain.
It has different properties for security and scalability.
Richard is asking a slightly cheeky question: "Do you think building smart contract functionality on Bitcoin...
[would] make Vitalik blush?"
The full question is: "The ERC-20 standard for creating tokens has been hugely successful,
driving many individuals and businesses to Ethereum."
"Are you aware of any smart contract protocols allowing the creation of tokens secured to Bitcoin's blockchain?"
"Now that the Lightning Network is taking root,
could this be built upon to offer decentralized, permissionless token issuance, while combining...
Bitcoin's high security with Lightning's microtransactions and low execution costs?"
First of all, I don't think Vitalik will blush if Bitcoin does smart contracts [too].
As I have said before, I don't think Ethereum and Bitcoin are competing directly, nor do I think they can,
because the flexibility that exists in Ethereum...
makes it less suitable for doing the robust reserve currency functions of Bitcoin.
The robust reserve currency functions of Bitcoin make it less suitable for doing flexible smart contracts.
You can't get both. I know a lot of people will tell you that [we] can get both [in one or the other system].
Bitcoin maximalists will tell you that Bitcoin can do everything Ethereum can do, only better.
Ethereum maximalists will tell you that Ethereum can do everything Bitcoin [and other chains] can do, only better.
I don't think that is the case. In practice, there are engineering trade-offs that [must] be made,
where you can't get everything [in one].
When I was a consultant, I told my clients, "You can get best, fast, or cheap. Pick two of those."
"It will either be cheap and fast, but it won't be my best work. If it is best and fast, it won't be cheap."
"Or it will be cheap and best, but it will take a long time to do." Those were the options.
In computer science and other fields, we call that a trilemma, a dilemma but with three [options],
in which you can only pick two [of the three].
Blockchains have a lot of trilemmas in them, and these trilemmas are about optimisation [trade-offs]:
security, scalability, privacy; flexibility for smart contracts, immutability of the chain,
robust finality on the consensus algorithm.
Pick two. Generally, these become the trilemmas we [must] optimise for.
There are companies trying to find a way to reconcile some and optimise for different points in the trilemma.
You can fudge a bit [and go] in more directions, but you are not removing the trade-off.
I like systems that explicitly take a position on this trilemma and don't try to do everything.
The systems that try to do everything, suck at everything.
The systems with a specific philosophy [do well].
Bitcoin isn't trying to do flexible, complicated smart contracts because that comes at a security cost.
Ethereum isn't trying to work conservatively and slowly; moving fast and breaking things to do smart contracts...
is the sweet spot for that blockchain.
We could go into analysis of other blockchains and look at their various optimisations [some other time].
We used to have ICO-like [activity around] Bitcoin, before Ethereum came along [in 2015].
Bitcoin did it using the OP_RETURN data parameter to track metadata / colored coins such as CounterParty.
We also still have the Omni protocol. Both still exist on Bitcoin; you can still do colored coins / tokens.
There is also RSK, which is trying to build a drivechain that works in parallel with Bitcoin,
where you have smart contracts that are pegged to the bitcoin currency and Bitcoin's security model.
Again, these are different optimisations.
The market is already telling us that they would rather take the flexibility of Ethereum [with smart contracts].
That is a double-edged sword. You get the ICOs, [including] all the scams. Do we want that in Bitcoin?
If you look [back at Bitcoin's] history, in 2012, new coins and ventures were being down with alt-chains.
With the early altcoins, people [used] entirely new blockchains by forking the Bitcoin codebase.
Some of them made sense, most of them didn't.
Then we had the second-layer [tokens] in 2013 and 2014 with CounterParty and Omni.
We saw initial coin offerings. ICOs were not invented by Ethereum. Bitcoin [had them] two years prior.
Finally, Ethereum made them so easy to do that any programmer with basic JavaScript experience...
could code an insecure token and make a mess.
That is what has happened. I don't know if we want that [back] in Bitcoin. It dilutes the value proposition.
Rootstock is an interesting proposition, but we will see how that [experiment] plays out.