-
Notifications
You must be signed in to change notification settings - Fork 40
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
v2 wishlist #12
Comments
Addition to FreezeAn additional use case for Freeze functionality would be memento tokens. Think of buying a t-shirt at a concert to prove you were there. That kind of use case. Proof that someone acknowledge you by sending you a token, but which should have no monetary value and should not be transferable. The token should
|
Fraud proofs If SLP included a mandatory field that said which inputs were to be used for tokens, and there was a rule that all such declared inputs must be valid, then it would make it much simpler to have proofs of invalid SLP transactions. |
Multi-sends It could be nice to add support for sending multiple token types in one transaction. This was considered during SLPv1 design but dropped due to the technical complications.
|
Updating token document URI/Hash At least 2 users have requested the ability to update the token document's URI and hash details. Here is a link to our previous discussions on how this could be accomplished in PR #11 |
Tree NFT Continuation of the NFT extension type 1 here https://github.com/simpleledger/slp-specifications/blob/master/NFT.md, allow a "Type 3" where the descendant "NFT" are also their own groups of "fungible tokens" that can generate descendants. An example will be an origin "items" groups of tokens that can be burned to generate "sword", "bow", "hammer"... tokens, which can then themselves generate NFTs, and so on, e.g. While it's relatively easy to extend existing protocol in a strictly hierarchical way ( |
Dividends for BCH holders |
I'm unclear on the scope of this issue:
How do we prevent this Issue from growing forever? How do we reach resolution and close it? |
Each version/type of token is essentially a different token protocol. For example, NFT1 is not token type 1 because it has more rules than Token Type 1. Version 2 would be a total rewrite of a token protocol. If the new token type is a minor ruleset extension, like NFT1, then the spec writing can be handled like NFT1 was. |
It's worth emphasizing though, it's not a complete rewrite as future SLP2 transactions are supposed to be detected by existing SLP wallets, which should flag all those transaction outputs as 'possibly tokens' and hence not spend them. So, it should be safe to send SLP2 tokens to any It would be a good idea to make sure all the wallet devs are aware of this, and specify carefully the rules that future SLP versions will absolutely follow, so that they know which transactions need to be flagged as do-not-spend. For example one question I am wondering is whether SLP2 will still require the OP_RETURN to be on position 0. After all, the most elegant way to do multitoken is if standardness rules allow multiple OP_RETURNs, and each one can deal independently with a different token type. But that would mean that even if a transaction is valid SLP1, then it still might need to be flagged as do-not-spend because another output had an SLP2 OP_RETURN on it. |
Good clarification, the new v2 spec would have to keep SLP lokad id and version fields for general compatibility. To your second point, it would be valuable to come up with a test plan for checking all of the existing wallet implementations to see how they handle SLPX type transactions. Based on the current implementations we have it seems like SLP1 would never be able to safely support multi-token sends and this could only be supported with a new token specification. So, in this case, wouldn't the safest path forward to have the new token version's metadata starting on vout=0, since all existing wallets look there first and don't look anywhere else. The new token version could have the possibility of having additional metadata on vout > 0, but keeping in mind none of the additional metadata could be a SLP1. It's definitely a good thing to bring up, and now I will be keeping in mind moving forward. |
Seems like the best path forward to me. Food for thought:I'm a huge fan of the memo.cash protocol. It's a damn shame it doesn't comply with the Lokad spec, but putting that aside, the structure of the protocol is extremely expressive. I think that structure could provide inspiration for incorporating some of the ideas on this wish list, and essentially passing commands to SLPDB or other token validation software. |
Could be, but we can easily amend SLP design requirements for wallets that they need to scan all outputs. (This isn't a change to SLPv1 spec, which would still require its message to live on output 0) Given how far away SLP2 is from existing, if we did this now then it would give ample time for wallets to conform to this requirement. Note that if SLP2 doesn't require its OP_RETURN to live on vout 0, then SLP1 indeed could participate in a multitoken send with an SLP2 token, just not with other SLP1 tokens. Also you could do SLP2-SLP2 multitoken transaction, SLP2-SLP3, or SLP2-wormhole multitoken, or whatever. |
I was going to write a rebuttal type response, but then I realized that there is no way to enforce a wallet to respect multi-send on a consensus level regardless of the specification rules. Yes, I agree. we should add this v1 wallet implementation requirement to respect multiple OP_RETURNs. |
As long as the lokad and version bytes line up with the existing parsers, then there probably isn't a reason we couldn't change it up a bit for the rest of the fields in v2. |
I think it would be a good idea to extend a minting function within the GENESIS tx. And by this I mean that you could have a script which dictates how MINT can be called. It could default to the current functionality for backward compatibility, but then allow anyone to define how toxens can be minted. I'm building a proposal that would require an anyone can mint capability. christroutner |
Unless I'm missing something in your specific use case, I think its already possible in v1. There are a couple of us working on some minting smart contracts implementations. |
Nice |
I should have elaborated that I'm thinking of a generic minting function which would make the architecture smoother for NFT. It should be possible to use a script instead of a baton to define who can mint to achieve an anyone-can-mint use case. |
Another potential enhancement. Mark brought up the fact that it can be difficult to verify your SPICE because anyone can create a SPICE token with identical parameters (name, url, ...). This is especially bad in the neighbourhood for stablecoins (quick look for USDH on simpleledger.at and I see tons of USDH and USDT, etc... this could really really make scams mega easy. Such a system would create a market for authorities. ticker symbols could still be reused but differentiated based on their signer and the authoritator would be responsible for ensuring that there can't be dup tickers under their watch, and consensus rules could be built around this. We could implent a POS system to disincentivize authorities acting bad |
You can already become an authority yourself, just set up a website and publish some token ids you trust, no need for fancy specs. Your wallet is likely already such an authority by being selective about which icons to use. |
I'm proposing evolving a spec for it to scale to mass use |
In the BCH dev meeting #18, we discussed the possibility of using the OP_RETURN in a more general-purpose way so that it could encompass multiple protocols, like SLP. Something to think about for a future protocol change. Make the SLP protocol in a way that is extensible and the OP_RETURN can be used for other things too. Personally, I like using OP_RETURN to reference data in IPFS. That is a great way to expand the protocol infinitely off-chain. |
Dividends
Allow for all holders of a token to receive future rewards / dividends / airdrops.
And/or a method for sending to all holders of said token.
Grouping / Unique assets
somewhat NFT-related. Be able to create
ITEM
token, and an additional token can be attached/grouped accordingly. for exampleITEM
.sword ,ITEM
.shield, etc.anyone who looks up sword/shield would see they're a part of
ITEM
. andITEM
.sword.asdf might be the only sword of that type in existence.Messaging
Some form of protocol or compatibility with an existing broadcast system. The token would have a 'feed' or a channel to send messages/news updates transmitted based on the token_id. Every on chain transaction can be a hash of the actual message/update for time-stamping and censorship-resistance.
Voting
built in voting protocol for anyone who creates a token to easily use w/o any programming knowledge required.
Update-able Metadata
native support for updating website, email, etc.
TICKER and maybe name should be static.
Licensing
A spec/protocol to follow so services can query an address to quickly verify the authenticity of a token representing a license. Some licenses might expire after 1 year, some may be considered invalid if they are moved more than once, etc.
Private assets
An issuer broadcasts that
NEW
token can only be held by person A,B,C and D. Their identities are encrypted (or maybe CDS is used) but only the issuer knows who A,B,C,D are.Freeze / Unfreeze
ability to 'banlist' or freeze certain bad actors' addresses.
The text was updated successfully, but these errors were encountered: