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

Full support for SLP Tokens #328

Closed
zquestz opened this issue Dec 11, 2019 · 10 comments
Closed

Full support for SLP Tokens #328

zquestz opened this issue Dec 11, 2019 · 10 comments
Labels
enhancement help wanted

Comments

@zquestz
Copy link
Contributor

@zquestz zquestz commented Dec 11, 2019

BCHD seeks to be a one stop shop for BCH developers, but the lack of SLP support means that devs will require more software to actually do more complex BCH projects. With SLP gaining more momentum every day, it is essential we begin the work to support SLP directly in BCHD!

I am opening this issue so we can explore what the exact implementation would look like. I will share my ideas, but am definitely open to suggestions and comments!

For now, I believe these should be ONLY available as gRPC endpoints, as I do not believe more effort should be put into the JSON API unless absolutely necessary.

So, for me the key features would be:

  1. Indexing of all minting transactions so we can implement a GetSLPTokenInfo endpoint. You would pass in a Token ID and it would return all metadata about the token. For instance this would include how many tokens were minted, the token name, and other basic metadata.

  2. Returning SLP information for all transactions. Any transaction that moves SLP tokens should include the SLP transaction details along with the normal BCH transaction information. That way all existing transaction fetching endpoints would also include SLP details. For instance GetTransaction should also return SLP info if SLP tokens were moved or minted.

  3. Index of SLP address to transactions. This would be very similar to the existing address index, however specifically for the SLP use case. This would be fetched via a new endpoint GetSLPAddressTransactions.

  4. Also provide a UTXO lookup specifically for SLP outputs. This would be via a new GetSLPAddressUnspentOutputs endpoint.

This should give developers almost everything they need for doing SLP work in wallets and explorers. For statistics on how many tokens, total number of SLP transactions, and other general information I believe we can continue to leverage tools like SLPDB. No need for that directly in BCHD as those queries are VERY expensive and not required for wallet use cases.

If anyone else has suggestions or amendments to this issue, I would love to make this a living doc.

I am working with the team now on what the bounty should be, but first we need to make sure the work is clearly scoped so everyone knows exactly what must be delivered.

Hopefully within the next few days we can iron out this proposal and put up an official bounty!

@zquestz zquestz added enhancement help wanted labels Dec 11, 2019
@zquestz
Copy link
Contributor Author

@zquestz zquestz commented Dec 11, 2019

Test vectors are available at: https://github.com/simpleledger/slp-unit-test-data

@zquestz
Copy link
Contributor Author

@zquestz zquestz commented Dec 11, 2019

Specifications: https://github.com/simpleledger/slp-specifications

@FreeTrade
Copy link

@FreeTrade FreeTrade commented Dec 11, 2019

Just a minor addition - it would be helpful to have a flag to exclude the return of SLP containing utxos for when a developer does not want to accidentally burn SLP tokens. Currently I'm using SLP546-Aware for this purpose (ignoring all utxo with outputs of 546) it works, but it's not ideal.

@Ekliptor
Copy link
Contributor

@Ekliptor Ekliptor commented Dec 11, 2019

Why not add a JSON API too?
In PHP protocol buffers/gRPC comes with a huge memory footprint because for every HTTP request the whole library has to be loaded (using the official "composer require google/protobuf" plus gRPC) into a new process. Thus performance goes down.
The faster in C written PHP extension for protobuf unfortunately is not installed on most "cheap" WordPress hosting providers: https://pecl.php.net/package/protobuf
Using JSON API calls for things like GetSLPAddressTransactions would definitely be better here.

That said, I want to be helpful and am willing to help with/add a JSON API for those endpoints to BCHD myself after the gRPC implementation is done.

@zquestz
Copy link
Contributor Author

@zquestz zquestz commented Dec 12, 2019

Why not add a JSON API too?
In PHP protocol buffers/gRPC comes with a huge memory footprint because for every HTTP request the whole library has to be loaded (using the official "composer require google/protobuf" plus gRPC) into a new process. Thus performance goes down.
The faster in C written PHP extension for protobuf unfortunately is not installed on most "cheap" WordPress hosting providers: https://pecl.php.net/package/protobuf
Using JSON API calls for things like GetSLPAddressTransactions would definitely be better here.

That said, I want to be helpful and am willing to help with/add a JSON API for those endpoints to BCHD myself after the gRPC implementation is done.

This is a good point, however I think our initial focus will be on the gRPC side. Once that is completed we can revisit adding JSON API calls. They should also be much easier to implement once the initial work is done. The scope for this is already big enough and I don't want to increase the size of an already large project.

@semgers
Copy link

@semgers semgers commented Dec 12, 2019

I think you pretty much nailed it. The only thing is, with regards to getting token information, this has proved quite hard, namely:

Indexing of all minting transactions so we can implement a GetSLPTokenInfo endpoint. You would pass in a Token ID and it would return all metadata about the token. For instance this would include how many tokens were minted, the token name, and other basic metadata.

If part of the response is the total active circulating supply, which I think it should be, you would have to index all the UTXOs for the token or alternatively all the burn transactions.

From my experience, the most important endpoints are 3 and 4. Even having those two right now would be awesome. Great job!

@zquestz
Copy link
Contributor Author

@zquestz zquestz commented Dec 12, 2019

I think you pretty much nailed it. The only thing is, with regards to getting token information, this has proved quite hard, namely:

Indexing of all minting transactions so we can implement a GetSLPTokenInfo endpoint. You would pass in a Token ID and it would return all metadata about the token. For instance this would include how many tokens were minted, the token name, and other basic metadata.

If part of the response is the total active circulating supply, which I think it should be, you would have to index all the UTXOs for the token or alternatively all the burn transactions.

From my experience, the most important endpoints are 3 and 4. Even having those two right now would be awesome. Great job!

Well luckily we need to index all SLP utxos and transactions, so I think that we can actually provide an accurate endpoint for reporting the SLP token information! I think we can easily detect tokens that are burned and report the accurate circulating supply. =)

@christroutner
Copy link

@christroutner christroutner commented Jan 16, 2020

On the topic of burned tokens. There are two ways to burn an SLP token:

  • The most obvious is to simply spend the UTXO without attaching an OP_RETURN. This will un-color the coin. This often requires two transactions for deliberate burns.

  • The better way is to spend the token as a legit SLP transaction. But in the OP_RETURN specify the normal quantity, minus the amount you want to burn. This requires just a single transaction.

It's important the BCHD support and track both forms of burning.

@zquestz
Copy link
Contributor Author

@zquestz zquestz commented Jun 4, 2020

For those interested in Go SLP support, a library has just sprung up. =)

https://github.com/simpleledgerinc/GoSlp

@zquestz
Copy link
Contributor Author

@zquestz zquestz commented Mar 13, 2021

This has been merged!

@zquestz zquestz closed this as completed Mar 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement help wanted
Projects
None yet
Development

No branches or pull requests

5 participants