Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Group Tokenization as SLP 2.0 #35

Open
A60AB5450353F40E opened this issue Mar 26, 2021 · 1 comment
Open

Group Tokenization as SLP 2.0 #35

A60AB5450353F40E opened this issue Mar 26, 2021 · 1 comment

Comments

@A60AB5450353F40E
Copy link

TL;DR talk / collect statements about re-branding Group Tokens as SLP 2.0

As many of you are probably aware, Group Tokenization now exists as a CHIP. I believe it addresses many of the historical concerns about group tokens, because it has evolved since the time you may have last looked at it! I'll first give a brief intro before getting to the point of this thread.

Under the hood, it's only a few additional consensus rules and all they do is sum the token quantities of OP_GROUP marked outputs and check that they balance. Existing rules are not touched so implementation risk is conveniently contained. Token management authorities are checked the same - qty. field is reused as a bitfield and those also have to logically balance according to the rules so consensus logic doesn't need to look around, all the info required to validate the TX is contained in the TX, and it's simple arithmetic ops to check it. This enables both the tokens and authorities to benefit from full power of SPV, SIGHASH, Script, and any other future protocol improvements such as TX introspection. The scaling "big O" is unchanged as we can process token logic alongside BCH logic.

Tokens are thus dual-currency outputs (bch+token) and because of existing dust limit, creation of any token UTXO creates marginal demand for BCH so even if the token becomes worthless there will be incentive to remove the token from the UTXO to reclaim that BCH. I thought this was an interesting side-effect but now I think it's an important feature because it addresses the issue of both UTXO garbage collection and paying for UTXO prime real-estate and keeps incentives around BCH in check. This was just a brief intro, any discussion regarding group tokens should happen on the research forum thread I linked above.

Shortly after that CHIP got some attention, a telegram group was formed. There was talk about rebranding Group Tokenization, and some have proposed to call it SLP 2.0.

It may be good for BCH & SLP image if our group consensus tokens were marketed as SLP 2.0. I believe that having native tokens fits well into vision of Bitcoin: a peer-to-peer electronic cash system. Cash was never a single currency, and it will never be a single currency, and BCH blockchain is perfect for cash-like uses (without impeding on the utility and incentives surrounding the main currency).

SLP2.0 + cash narrative could give power not only to users but also to community branding and marketing efforts which will all add up to success of BCH and could help it grow big!

I think there's already some agreement forming around this, so it would be good to add your statements somewhere so it's not buried in Telegram history.

PS There are some other related discussions that might be of interest:

https://bitcoincashresearch.org/t/shooting-gallery-inject-slp-into-consensus-100-compatibility-with-current-ecosystem/354

https://bitcoincashresearch.org/t/slp-token-migration-strategies-upon-introduction-of-a-miner-validated-token-schemes/294

@A60AB5450353F40E
Copy link
Author

Ok so I clarified the idea with James Cramer on Telegram. It's not a rebranding, more like OP_GROUP would enable SLP2.0 which would use OP_GROUP under the hood but the consensus tech should be brand neutral, it's just an enabler. Similarly how OP_RETURN now enables SLP1.0. Builders get to do branding, and someone else could build their own ecosystem using OP_GROUP and brand it something else.

James Cramer: I was thinking more like SLP2.0 would simply leverage the OP_GROUP op code, I do t understand why it needs to be renamed or re branded. 2.0 would just be like a specific token implementation using op_group tech.
Me: right, like you now leverage OP_RETURN to have SLP 1.0
James Cramer: Yep, excellent way to explain it
Me: ok, I just felt like we need to write it down somewhere so it's all more coordinated
James Cramer: Sure, makes sense; So it’s not a rebranding? Right? I don’t think we want to spend much energy on that; We should spend more energy coming up with reasons why we should do op_group on mainnet. Pros/Cons and compare and contrast slpv1 vs v2 etc.; Get statements from business using v1 and their thoughts on what they want in a token system.
Me: that would be great, I can't do that alone tho so any help is appreciated
James Cramer: Then that can be presented to anyone opposing the v2 idea. And then they have a chance to do a rebuttal
Me: yeah, not rebranding, but if SLP would plan to use group for SLP2.0 then it would be nice to have that as a statement; on a second thought it makes more sense to have the consensus change brand neutral, because anyone else could also brand their token solution something else while also using opgroup under the hood
James Cramer: Yep I agree; I can put some draft statement together that argues for v2
Me: great! and if you don't mind, I'd like to c&p this conv. under that issue so the approach is clear
James Cramer: Feel free

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant