drop 'mutable NFT' marker for reserved supply on authHead

[mr-zwets]

I'd like to suggest dropping the 'mutable NFT' marker requirement for keeping the reserved supply on authHead.

If additional fungible tokens of a category may be needed in the future, token issuers should initially mint an excess supply (e.g. the maximum supply of 9223372036854775807) and hold the unissued tokens in the identity output with a mutable token (using any commitment value) to indicate they are part of the Unissued/Reserved Supply.

The idea of keeping the reserved supply at the authHead is great, the additional need for a mutable NFT marker however is unnecessary.
The AuthHead needs to be under control of the issuer anyways to be able to do future metadata updates, and by being the authHead it serves as a marker already.

This is already how the current CashTokens ecosystem is following the BCMR standard as implemented by the CashTokens-marketcap website TokenStork with multiple token projects following this convention: FURU, DOGECASH, XRBF & KOK

For complex multithreaded applications using mutable NFTs as markers, they could still use a marker at the authHead or alternatively the mutable NFTs could be markers in addition to the authHead.

It is great that the spec has thought of the advanced multithreaded covenant use-cases but it should not come at the cost of the simple straightforward usecase for centrally managed token projects.

This change to the reserved supply standard is also what I suggest in my AuthGuard standard 😄 👍

[bitjson]

Thanks for opening an issue! Yeah, I think it makes sense to make the mutable token optional.

There are also cases where issuers of fungible + NFT categories will want to demonstrate that no additional NFT can ever be created within the category.

Maybe this question ultimately becomes a BCMR extension – nearly all token projects will just leave their reserved supply in the authhead, and only a much more limited subset of tokens issued by covenant systems will use the mutable token-marked reserve UTXOs. If the token category's BCMR identity doesn't indicate that the reserved supply is marked by mutable tokens, clients can by default assume that only the authhead contains a reserved supply (or maybe a third state of "no reserved supply").

Though I don't think we need to worry about further defining that extension until someone publishes such a covenant system.

Anyways, happy to take a PR for this!

[mr-zwets]

Made a minimal PR for this: #13