BUIP077: (passed) Enable representative tokens via OP_GROUP on Bitcoin Cash

[theZerg]

BUIP077: Enable representative tokens via OP_GROUP on Bitcoin Cash

This BUIP proposes that BU implement the OP_GROUP opcode as described here: https://medium.com/@g.andrew.stone/bitcoin-scripting-applications-representative-tokens-ece42de81285, on the Bitcoin Cash blockchain.
This basically adds "native" colored coins to a blockchain. I believe that this additional feature will drive use and therefore adoption of Bitcoin Cash. Today Bitcoin Cash is a payment network. But with the inclusion of representative tokens, the blockchain can be used for asset holding, and the network's functionality will be expanded from payment to exchange.

Specifically this BUIP authorizes us to:

1. Implement OP_GROUP, including all tests etc required to ensure the correctness and safety of the change.
2. Enable this opcode on the BU "nol" network.
3. Work with the Bitcoin Cash community to enable this opcode via hard fork on the Bitcoin Cash blockchain


What is OP_GROUP?

OP_GROUP is a single additional opcode to the Bitcoin scripting language that effectively enables representative tokens (that is, "colored coins") on a blockchain. Unlike all current colored coin proposals and implementations, in the OP_GROUP system the miners validate the colored coins, as part of normal transaction validation. This means that, like bitcoins, invalid colored coin transactions will not appear on the blockchain (all other colored coin proposals can have illegal transactions on the blockchain and therefore rely on every client to validate every colored coin tx). Additionally, the OP_GROUP proposal clearly marks every UTXO with a "color". When you add these two features together, the result is that:
1. A user can't accidentally spend colored coins as normal bitcoin
2. SPV wallets can handle coin colorings with the same ease and security model as Bitcoins

This first version of OP_GROUP colored coins does not contain some of the advanced features that some other colored coins support. But I believe that it contains the key feature needed for colored coins -- enabling SPV wallets. This feature is missing from all other colored coins proposals.
Please read this link for details: https://medium.com/@g.andrew.stone/bitcoin-scripting-applications-representative-tokens-ece42de81285


EDIT:
Chris Pacia just wrote a great article describing the system very clearly:
https://www.yours.org/content/colored-coins-in-bitcoin-cash-b26804e05964/

 

[Justus Ranvier]

There are use cases that EPOBC can satisfy that this protocol does not appear to be capable of solving, such as if the quantity of units of a particular color must be provably immutable.

The proposal says mentions adding an opcode, but the link describes a soft fork so presumably that means redefining an existing opcode. Which opcode are you planning to redefine?

 

[Griffith]

@Justus Ranvier The proposal specifies a hard fork (which is what would be required to add an op-code.

In regards to the proposal itself:
I am against this proposal not because of the content but because of the timing. With everything else going on and the fact that we haven't yet completely solved the scaling issue, i don't think now would be the best time to add more features like this.

 

[theZerg]

@Justus Ranvier, you are correct that other solutions offer other features. For example, the various proposals that basically place a client-side validated custom blockchain in OP_RETURN can offer any feature, including complete smart contracts.

But these proposals cannot provide SPV wallet support.

I am trying to provide the simplest functionality that gets us basic assets on the blockchain, accessible via SPV wallets with the same security model.

We can subsequently add additional features if there is demand for them.

Given that a company or individual can always issue "series A" and then "series B" stocks/tokens, I do not understand why enforcing a limit on the issuance is important. Of course, a limit on the fundamental digital token (BCH) is very important due to the trustless requirements. But representative tokens/ blockchain assets imply trust in some entity that maintains the mapping.

On Reddit, Chris Pacia came up with a clever way to limit issuance (with an additional op code)...

Is there a compelling use case that I am missing?

 

[torusJKL]

and the fact that we haven't yet completely solved the scaling issue

@Griffith Scaling is never completely solved. Every time we approach a new wall we will tackle it and solve the problem at hand.

If we are waiting for the perfect solution we would paralyze ourselves.

 

[theZerg]

@Griffith Its unlikely that the scaling problem will be "completely solved" soon if ever. Yet, basic onchain scalability can allow us to scale 50-100x with the code I've already written in the giga block project.

But in the meantime, if we don't increase utility -- if we don't drive adoption by having compelling use cases -- we will never need to scale because there are plenty of other alt-coins to choose from.

 

[Justus Ranvier]

@theZerg I think the easiest example on a situation where immutability is needed is where the number of units is one. In a transaction-based coloring scheme like EPOBC you can create tokens whose identifier is a UUID that can not be forged or duplicated, even by the entity that originally created it.

 

[Christoph Bergmann]

Something like this should have done long before in Bitcoin. I don't understand every details, but when it lets miners / nodes validate colored coin tokens, it is a big deal. Maybe this could help Bitcoin to catch up with Ethereum token-wise.

 

[theZerg]

@Justus Ranvier, Chris Pacia's idea to create groups that can't be extended is to add another opcode (I forget what he called it so let's call it) OP_TX_EXPIRY. This opcode makes a transaction invalid unless committed before block or MTP time N.

Now you could make a P2SH script with that opcode, fund it and then load your OP_GROUP before the expiration time. Post expiration, you could never spend that P2SH script so you can't send any more coins into the OP_GROUP. And if you tried to exit from the OP_GROUP you'd burn the coin. I think not recovering the BTC from an exit in this case is OK because it would be wasting 1 satoshi.

I like his proposal because the OP_TX_EXPIRY opcode seems to me to be pretty general and therefore useful in other contexts.

For the first version though, I want to keep this as simple as possible and only add the one OP_GROUP opcode.

 

[theZerg]

Chris Pacia just wrote a great article describing the system very clearly:
https://www.yours.org/content/colored-coins-in-bitcoin-cash-b26804e05964/

 

[Mengerian]

I just voted for this BUIP

I think the Developer should use his discretion in the technical details described in the BUIP though, and have wide latitude to change the implementation in any way he feels makes sense to enable representative token in BCH.

If some better approach arises, he should not be bound by the specifics described in this BUIP.

 

[Christoph Bergmann]

I love this BUIP!

Signed message:
BUIP077: Yes!

Signature:
H2jVb2JpgRC/P57ixp/twR+36gr0xhbQI9NR/mil1nwaKYu489hJIPAvB82EWy5pqlBHCfuYIbEhsV9TFPS5pnw=

 

[Emil Oldenburg]

I'm very excited about this. Will be a lot of good use cases here.

I have one idea though, would it be possible to propose/encourage a standard when minting new coins? Like adding an optional OP_RETURN output with data that includes a name for the colored coin and a ticker name, like "Crypto Badgers/CRBG". So people would know that when the first mint is issued, it will be easy to track that this group should be named Crypto Badgers and trades as CRBG.

 

[theZerg]

yes, absolutely this is what I plan to do. The BUIP and writeup essentially covers the minimum compatible client.

 

[Jihan]

Any progress of this proposal?

It seems really good.

There are several important features that is needed for the token economy:

1. Coin offering, or contribution mode: it can open the contribution by anyone to the project.
2. The funding should be able to spread over time automatically, so that the funding will be less likely to be miss used by the project creators;
3. Token can be spread over time: token economy are about incentives. Make people to behave in the goodness of the long term of the project is usually needed. Token should be able to be able to locked up by a certain period of time;

4. Some other incentive related mechanism, which is very common in corporate governance process.

If these mechanisms does not exists in the decentralized protocol, then they usually will not be implemented in the ICO process, which is damaging the effectiveness of the economy; Or the crowd will need to rely some centralized service or individuals to force these mechanisms.

If it is possible, we may implement the proposal of OP_GROUP in a fast way, if the above two features can be implemented into the protocol by soft fork or no fork. If it needs to be implemented by hard fork to add those mechanisms, we should be certain that token and the software infrastructures which will have been built for the economy will not have to go through some unacceptably difficult upgrade process.