simpleledger / slp-specifications Goto Github PK

OP_RETURN

<lokad id: 'SLP\x00'>
(4 bytes, ascii) <token_type: 1>
(1 to 2 byte integer) <transaction_type: 'SEND'>
(4 bytes, ascii)
<token_id> (32 bytes)
<token_output_quantity1> (required, 8 byte integer)
<transaction_type: 'AND'> (4 bytes, ascii)
<token_type: 1> (1 to 2 byte integer)
<token_id> (32 bytes)
<token_output_quantity 2> (optional, 8 byte integer)

slp-nft-1.md

This quantity can is not the maximum if the minting baton is used to expand the minting supply

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 example ITEM.sword , ITEM.shield, etc.
anyone who looks up sword/shield would see they're a part of ITEM. and ITEM.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.

Can we have .svg version of the slp logo or hi-res version of the .png ? I would like to adapt the logo for one of my project using the protocol.

Thanks.

A user reviewing the spec caught a typo or lack of clarity in the field that is meant to represent the minimum byte requirement for a particular field. transaction_type for GENESIS transaction should be 7-bytes, not 4-bytes.

https://github.com/simpleledger/slp-specifications/blame/master/slp-token-type-1.md#L293

As posted on reddit (modified to address some feedback already gotten):

In the current SLP spec <token_ticker>, <token_name>, and <token_document_url>, henceforth name_fields, have fields where there is no maximum size for the names (they may be infinite bytes long).

In theory this is ok, but not having a max length on the field makes parsing this data impossible without making assumptions.

As pointed out, data in SLP needs to handle 4 forms, defined in:
Bitcoin script allows a given byte array to be pushed in various ways, and we allow this in SLP as well. For example, it is valid to push a 4-byte chunk (like the Lokad ID) in four different ways: 0x04 [chunk] (size then chunk),
0x4c 0x04 [chunk] (OP_PUSHDATA1 then size then chunk),
0x4d 0x04 0x00 [chunk] (OP_PUSHDATA2 then size then chunk),
or 0x4e 0x04 0x00 0x00 0x00 [chunk] (OP_PUSHDATA4 then size then chunk).

From purely a spec standpoint, this is problematic. There is no valid way to implement the full range of spec valid values. The spec is relying on the BCH implementation and OP_RETURN rules to ensure everything works out.

I think the spec should be adjusted to have 2^32-1 be the max value of the name_fields.

Afterthought: After thinking about it, i realize this isn't really a realistic issue and is essentially a nitpick. I dont think anyone would, without intent to specifically cause a fuss, actually try to make one of the name_fields that long. It mostly just felt wrong to see infinity as a valid length in a technical specification.

Edit: Most of my concern came from an incorrect calculation for OP_PUSHDATA4, i did 256 * 4 not 256 ^ 4

Redeem script shall have the following format: OP_DROP ... OP_DROP <PubKey> OP_CHECKSIG

Unlocking script shall have the following format: <signature> <data> ... <data> <redeem script>

The specification doesn't take any measures against the following attack:

• My node receiving this transaction quickly; changing the data and my other nodes broadcasting the newer transaction so that the tx/txid is changed and the following of the transactions are invalid.

because The specification says only the redeemscript of P2SH is covered by the signature.

Or does it?

If it doesn't then I suggest many times (OP_CAT OP_HASH160) and storing the final hash in the redeemscript and checking for equality.

The other attack is stealing the P2SH output coins. No, the signature covers output values.

SLP is registered coin type 245, some text should be added to the specification regarding this update.
https://github.com/satoshilabs/slips/blob/master/slip-0044.md

Hi everybody! I talked this idea over with Jonald and he couldn't find any obvious problems with it, so let's maybe discuss it wider.

What if instead of sending SLP tokens to P2PKH addresses (and risking accidental burn) we would send them to P2SH addresses that are unlocked by something like 'SLP' string (checked with OP_EQUAL to 'SLP') + the usual P2PKH unlocking params?

I think that might prevent accidental token burn, since regular wallets would have no idea how to spend this P2SH UTXO.

It seems to me that it's pretty backwards-compatible and opt-in, since if a wallet supports this scheme - it'll generate the P2SH-based simpleledger:... address to send to, but if you then want to send it to P2PKH - it works the same way. So, if some wallet implements that - it doesn't change anything - it's still interoperable with other P2PKH-based wallets out there.

I mean it could be something like SLP1.1 or something. An extension to the protocol that makes it safer, but is not obligatory to implement for other wallets.

About P2SH and HD wallets, we can simply generate and cache the P2SH address for every known private key and then see if there are any UTXOs there - that way even if we're starting from a seed, we'll be able to unlock P2SH. Additional benefit: non-compatible (old) wallets won't even see these UTXOs, thereby preventing burn.

Frankly, this accidental token burn is what really scares me in SLP tokens.

Of course, I haven't thought it in detail, so maybe there is an obvious problem that I haven't noticed.

Thank you!

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