Enhancement Suggestions for SRC721

[btcopenstamp]

[new]
Check the latest version at https://github.com/btcopenstamp/src-721/tree/dev

[old]
In order to establish a unified indexer for SRC721 and promote the development of the Stamp ecosystem, the OpenStamp team offers the following insights based on the conventional issuance of ERC721 projects and some remarks from Derp. This extends the current SRC721 standard and is proposed for reference and discussion:

1. Roles

   • Owner: The address that holds the collection deployment stamp. The owner changes as the stamp is transferred.
   • Operator: The agent providing signature authorization. The primary function is for the owner to delegate the minting service to handle project issuance. The pubkey in the deploy json data corresponds to the operator's Bitcoin public key.

2. Authority Operations

   • Change Operator: The owner can initiate a protocol operation to change the operator.
   • Generate Reveal Signature: The owner signs the hash(traits data objects) to obtain a signature. If the first input of the transaction is the owner, no signature is required.
   • Generate Mint Signature: The owner/operator signs the token id + hash(traits data objects) + user address to obtain a signature.

3. Unique, Valid, Whitelist/MEV considerations and solutions for NFTs

   • Uniqueness: A collection can contain NFTs with identical traits. Uniqueness is denoted by token id.
   • Validity: The layers/traits of NFTs within a collection should be determined by the issuer, rather than arbitrarily assigned by users.
   • Whitelist: The issuer can specify a whitelist of addresses.
   • MEV: There may be MEV attacks during public sale if the signature data does not contain the user address.

   A unified solution to the above issues:

   The signature in the mint operation is generated by the operator/owner. The signature data is token id + hash(stamp's traits data objects) + user address. The current SRC721 standard suggests using a merkle root and merkle proof for whitelist verification, but this method may increase transaction costs due to larger on-chain data (mainly merkle proof). Therefore, it is suggested to remove the merkle tree verification method.

   Potential issue: To avoid wasting transaction fees, each token id can only be allocated to one address during the mint stage. However, if the user obtains the signature for the corresponding token id and does not publish the transaction, that token id cannot be minted. Therefore, during issuance, each token id will have a lock-up period. After this period, the project issuer or minting service needs to release the token id again.

4. Signature Algorithm

   The deploy json should include a signature algorithm field. The default should be Elliptic Curve Digital Signature Algorithm (ECDSA).

5. Minting Fee

   • Off-Protocol: Collection issuers can collect fees off-protocol via a whitelist.
   • On-Protocol: Add a "fee recipient" field to the deploy json, defaulting to the owner address, to serve as the recipient of the minting fee. Add a "price" field in satoshi to denote the fee per mint operation; absence indicates no charge. If the price field is greater than 0, a valid mint transaction must include an output for the fee recipient (default to owner address if not specified), and the amount cannot be less than the price. This adds complexity to the protocol but reduces workload for project issuers.

6. Additional Operations Needed for the Specification

   • Change of operator by the owner.
   • If minting fees are to be collected on-protocol, an operation for the owner to change the minting fee is needed.

Feel free to join the discussion, share your thoughts, and help us make SRC721 better. We look forward to your feedback and active participation.

[DerpHerpenstein]

As discussed, the points raised are valid and need to be resolved. Here are my thoughts:

1) Roles: I think this is a good way to go. It will allow the owner to delegate minting to a service, which can make the process seamless.

2) Authority Operations: I think Change Operator and Generate Reveal Signature are good. This allows the owner of the collection to reveal if they would like, but also can allow a mint service to do reveal on their behalf. I'm not so sure about generate mint signature. To be clear, this functionality is definitely needed, and as we discussed putting id+traits+address into the same object certainly helps to minimize the overhead, but after spending a little bit of time exploring this solution today, it looks like this will increase the size of the mint op by a minimum of 90 bytes just for the sig. This is smaller then a merkle proof, so it is definitely a step in the right direction, but it is still very large, considering the entire mint op is around 130 bytes when base64 encoded. To ensure the mint costs remain reasonable we need the solution to not add two more utxo's if at all possible.

3) Unique, Valid, Whitelist/MEV considerations and solutions for NFTs: same comments as two. Just to reiterate, i think this type of solution is the way to go, we just need it to be at least half that size. Perhaps if we base64 encode the raw hash and sign that. I will explore this more.

4) Signature Algorithm: Sounds good, use bitcoins-cli default algo unless otherwise specified

5) Minting Fee: I think this is a good idea as well. There needs to be a path forward to easily earn income for these projects.

6)Additional Operations Needed for the Specification: these look good

So for DEPLOY the optional "pubkey" property should be changed to "operator" to make the function of that property obvious and the value should be a bitcoin address. To my knowledge there have been no deploys using this feature so a change wont effect anyone. Additionally an optional price property denominated in satoshi should be added.

A new op called "update" that will allow for changing mutable aspects of collection should be added

{
"p": "src-721",
"op": "update",
"operator": "1ABC...321", // the bitcoin address of the new operator [optional]
"price":"10000" // the price for the mint in satoshis [optional]
}

And some more work still needs to be done to reduce the footprint of authoritative mints.

[btcopenstamp]

Hi Derp. Thanks for sharing your thoughts.

Regarding controlling the encoding of mint json data within two utxos, we can wait to reference the encode rules defined in the coming new Stamp protocol. I believe the new stamp protocol will greatly simplify the coding rules while introducing a compression mechanism. Maybe we could ask the devs of StampChain to share more details about the this.

I didn't quite understand what you mean by 'reduce the footprint of authoritative mints', could you elaborate on that?

[DerpHerpenstein]

Sorry for the delayed response. its been a very bust week. that sounds good. I look forward to seeing updates to the protocol that will reduce the footprint of these types of mint operations.

What i meant was that by using the signature of a hash of information to prove that a mint was valid, the size goes up quite a bit. Using a SHA256 hash of (token id + traits+ user address) will add another 90 bytes of data (before base64 encoding) which doubles the SRC721 mint cost. If the sha256 is in bytes and not hex then base64 encoded that number can get slashed in half down to 44 bytes. We could even do the sha256 in bytes, then truncate to 128 bits and base64 encode for a proof of 22 bytes, or 64 bits and 11 bytes?. I'm not 100% sure what the best route is. We need a reasonably secure way to allow an authority to provide a hash proving the mint was authorized, but it has to be small enough to not drive the src721 cost to 2x what it currently is

[DerpHerpenstein]

b83762b

feel free to make a PR

[btcopenstamp]

Cool. We will check it.

[DerpHerpenstein]

What do you think about the idea of having a "mode" property that allows for changing the drop type?

Right now in the mint ts[] stores the traits. If you wanted to do a random drop with a known trait distribution, you could remove ts[] and add an ID like you talked about. then in the reveal function, a weight percentage array is used to assign a weight to each trait and a seed is used to randomize a deterministic distribution so that each id gets a random sample of traits determined by the weight.

I'm tinkering with a simple example to show how it could work. but it gives eth like drop functionality and doesn't require a owner/operator signature for each mint. Im thinking the easier we can make this process the better it will be

[n4kashu]

what about a mode without randomization? Authoritative mint where randomization is done by artist (as it usually is..) and then minted are pre-compiled sets of traits. Assuming mint will be performed by single entity, maybe a simple allowed wallet whitelist for minting would do the trick with authorization. (for example owner and operator only allowed, or public mode..)

this way it can work with or without reveal, based on preference of artist..

[DerpHerpenstein]

@n4kashu In this scenario, would the idea be that only the operator can initiate the generation of the src721? All transactions that don't start with the operator would be considered invalid? This could definitely work. This would require a transaction by the user and a second transaction by a minting service.

In the above scenario, I'm trying to imagine a way to make it so anyone with knowledge of how to manually generate an src721 can do so in a single transactions without being able to game the system.

[n4kashu]

yes thats what I meant with this usecase. Only owner and operator can mint a valid src-721from the collection
and yes it would require 2 transactions but thats exactly how minting services do work atm.

From service provider a separate endpoint and automation to do the mint + distribute funds raised immediatelly will be needed.

I believe this is rather easy to implement on protocol level and it does not bloat the datapart..It expects work from service provider but I believe its doable.. lets see how openstamp will see this part.

[btcopenstamp]

@DerpHerpenstein @n4kashu

Hi, I apologize for the late response. I'll first provide some basic information, and I'll need some time to think the specific design.

1. Unfortunately, the new Stamp protocol applies only to SRC20 transactions. SRC721 transactions will still follow the CounterParty transaction format, so we can't rely on the new protocol design to reduce data volume just yet.

2. Within the Mint JSON, I believe we only need to retain one of the symbol and c (which points to the deploy stamp). This could reduce the length of the Mint JSON. If the symbol is not unique within the entire SRC721 protocol index, then it's necessary to keep the c attribute.

3. The first multisig UTXO can only encode 27 bytes of data (after deducting CounterParty protocol information and prefix stamp:), and each subsequent UTXO can encode 53 bytes of data. If you want to control the data of the Mint transaction within two UTXOs, then the hexadecimal number of the data Base64 must be a maximum of 80 bytes.

4. Having a "mode" property is a great idea. One potential issue is that without an authorization control process, it may lead to some invalid transactions with the same tokenId. Additionally, it's crucial to ensure the randomness of the algorithm as much as possible. I'm unsure whether most artists prefer this fully random generation process or a pre-generation process that can be adjusted offline.

5. {"p":"src-721","op":"mint","c":"A9286823293586848000","id":"10000"} requires 3 UTXOs.

[n4kashu]

For the mode with operator only mint would require offline randomization process. It desired to have full set of pre-generated trait sets. This can be easily randomized (order) and fed into minting automation. Or even during mint it can pick randomly a number, just to make sure one is not minted already.. But in general It depends on usecase. For something I could use pure random but If I want to create balanced collection I need control over weights and I can tell you that its a process to get a good balance...

re 5. I would expect that a set of traits will be passed in this transaction ( should look like a simple array of numbers , count as per layer count..) or am I wrong?

[btcopenstamp]

You are right about the 5th point. It's just an example of the complete random mode.

By the way, for the complete random mode, we don't even need token id. We just assign the token id one by one to the valid mints. So the final mint json would be like {"p":"src-721","op":"mint","c":"A9286823293586848000"} that can be encoded into 2 utxos.

For the whitelist mint of complete random mode, the only way to keep 2 utxo of mint operation is a mode that only operator can mint.

Just share some thoughts on different situations.

[DerpHerpenstein]

I think the idea of a random mode that is set by coefficients in the reveal op is probably the most ideal mint solution and gives us a very clear path forward toward mass adoption. Using the base64 encoded data with the stamp prefix we can keep the size down to two UTXOs.

its worth noting we can get this type of mint into a single utxo if we change the format from base64 to ascii and drop the "stamp:" in favor of a special purpose mint format like:
721|mint|A95428956661682176

This is exactly 27 characters so it will fit into a single UTXO making mint costs the same as sending btc to a multisig. Perhaps thats a bit too much change for the moment, as the proposed solution by btcopenstamp doesn't require any major indexer changes. This should definitely be looked at more closely long term.

For the mint randomization function, collection creators would provide a set of coefficients in the reveal op that correspond to the layers giving each layer a coefficient and a seed use to deterministically generate the dataset

seed: "Can literally be any string"
t0:[a12..3, a12..4, a12..5]
ct0:[1,1000,10000] // must add up to 10,000, allows for random generation as little as 0.01% of the time

let layerSeed = sha256(seed+tokenId+layerNumber) % 10000
for(let i=0;i<ctx.length;i++)
if(layerSeed <= ctx[i])
return(i)

---

This type of minting above could be used in combination with a simple whitelist token burning type of mint to give the founders a good mix of control over the mint process and randomization, without adding the additional overhead of needing to have an authority sign portions of every transaction to ensure validity. The original deploy can list a wl-token, which would require the minters to burn their WL token and make the memo the asset they want included in the collection and then after a time, the owner can call an update function and set the wl-token to null opening the mint to anyone for the remainder of the supply.

This hybrid approach would allow the src721 transactions to remain small, gives the collection creator the option to use a wl-token to authorize specific users to mint early, and ensures that the collection creator does not lock their collection into a specific mint service. I think it gives a very balanced and sustainable path forward.

What do you guys think?

[DerpHerpenstein]

i started writing the idea into: https://github.com/DerpHerpenstein/src-721/tree/dev_minimalist_idea

I need to work up a simple example of how the rarity distribution would be calculated

[n4kashu]

I was trying to wrap my head around the rarity distribution, that would definitelly help. if I can run few tests on the model. But assuming Ill be able to assign weight to traits per layer (each layer separately) im ok with that. This is what im simulating on my traits anyway. Tho I would also recommend to have a mode/possibility to mint with defining the traits in the mint message manually. Randomizing is a nice feature to have, and im for using it if it is applicable but the most added value in src-721 is not randomization rather the image stacking function.. I believe that the mint with 2 UTXO is sufficiently small, the 1UTXO alternative is rather minimalistic.. :P but we are are the very beginning and there will not be better time to make fundamental changes..