CHIP 2023-08 AuthGuard Standard

CHIPs Standards Track
,
#1

AuthGuard is a standard for authchain management which makes updating the authchain more secure and convenient. It does this by placing the authchain under a self-replicating covenant which requires the AuthKey NFT to be spent. This way normal wallets can hold the AuthKey NFT without having the risk of accidentally transferring the authHead or needing to make a separate wallet just for holding the AuthHead UTXO.

This standard came out of the work of @bitcoincashautist on an AuthGuard contract, the implementation by @joemar_taganna and the Paytaca team and my work on CHIP-2023-07 Minting Baton Covenant (MBC) Standard for Fungible Tokens

AuthGuard is a standardized covenant for managing an authchain which tokenizes the authority to issue reserved supply and publish metadata updates. Tokenizing the authority to update the authchain with an AuthKey NFT makes updating the authchain more secure and convenient.

The AuthGuard standard allows the AuthKey NFT to be held in a normal CashTokens wallet without running the risk of accidentally spending the authchain. By tokenizing the authority to update the authchain, there is no need for regular wallets to add specific authHead coin-control or to use a separate wallet just for the authHead UTXO, instead any CashTokens wallet can be used to keep the AuthKey NFT.

The authchain contains both the issuance and the metadata updates, but key rotations of the authority are done by transferring the AuthKey NFT.

6 Likes
#2

Things escalating quick in the BCH scene in terms of technical development & improvement on CashTokens.

Selene is quite a way off from getting the priority on to CashToken integration, but Iā€™ll be keeping an eye on this for when the time comes definitely. Looks like a great and useful initiative.

3 Likes
#3

An authchain is not exclusive to tokens, I expect it to be used much wider than that, when we finally get some tooling up and running that can be used by normies.

The more holistic view towards BCMR would then lead me in the direction that Iā€™d have a watch-only wallet in my app which holds all the auth-chains Iā€™m interested in. That same wallet would have any number of private keys for owned authchains, which creates UTXOs segregated from my spending money.

From a wallet builder point of view, Iā€™d argue that what I outlined here is the longer term solution that needs to be build to have something useful for every use-case. When that is built I expect that the problem this CHIP is meant to solve will also already be solved.

It is even quite likely that BCMR support hits my wallet well before full token support is added (cashtokens are already supported, but doesnā€™t really have many features) which would make the above solution a little tricky.

In the meantime your CHIP may make sense. Please do make it possible to exit the contract in a special case so its not forever locked into this more elaborate way of doing things.

1 Like
#4

Thanks for the review!

This standard fully acknowledges that BCMR metadata will be used for identities much wider than just tokens. However, a pressing current need for fungible token projects is how to mark some portion as the reserved supply which this proposal describes in a very simple way.

The issue here still is that your wallet needs to add authchain tooling support for updating the authchain (publishing new opreturns), whereas with the current proposal, the wallet only holds the authKey needed for extending the authchain. Then a general authchain management app can be made and can connect to different wallets with the wallet connect protocol. This means that you could hold many AuthKeys on the same wallet with a single private key, which simplifies back-ups.

Right, adding the option to release the authchain from the authguard is probably a good idea :+1:

#5

hmm, maybe Iā€™m missing something obviousā€¦

In my original plan I;

  1. add a new account inside my wallet for authchain management (both mine and others). This is needed whatever I do, so ā€œfreeā€.

In your proposal I additionally:

  1. Need to add the creation of a token in order to make an authchain conforming to your CHIP.
  2. need to add a way to detect and avoid spending that utxo.
  3. Add something called ā€œwallet connect protocolā€.

And independent of the two, someone needs to create a way to manage an authchain.

Did I misunderstand?

#6

So currently you would either need to create a brand new wallet to hold the authHead, or you hold the AuthHead in a wallet with coin-control (like electron cash) and you freeze the UTXO to not accidentally spend it.

The problem with this set-up is that it still requires special tooling to publish on-chain metadata updates in the authchain. The AuthGuard solution allows you to use an existing CashTokens wallet to hold your AuthKey and allows to for an ā€œAuthGuard appā€ to be developed once which then works with wallet connect. This way the Paytaca wallet or the cashonize wallet can be used for authmanagement without needing to add any specific authchain tooling to the wallet: just cashtokens support & wallet connect.

We discussed this privately too, but responding here for the public record.

1 Like
#7

Yeah, the expected setup where the user has one of these features, was assumed on my part:

  • ability, in your wallet, to have a separate seed-phrases for different sets of addresses.
    Because then you can just segregate your auth-head to a different authheads-only account.
  • OR ability of the wallet to do coin control, like you stated.

So, since you lack those in the stated wallets BUT you do have cash-tokens built in, for your specific case this all makes sense.

Iā€™ll stick to my original plan of attack and as long as there is a simple way to exit the token and simply move the authhead to a non-token utxo there should not be any issues.

1 Like
#8

A new token-creation tool ā€œCashTokens Studioā€ developed by the Paytaca team is now out for chipnet & implements the AuthGuard Standard!

Joemar (CEO of Paytaca) explained:

there is one more thing we want to add before mainnet release: ability to edit and publish BCMR in an editor with a built-in validator against the BCMR standard schema.
for easily editing bcmr json or creating a new one for any use case
auto-uploaded to ipfs too

image
image1280Ɨ709 56.7 KB

image
image1109Ɨ1280 107 KB

image
image1280Ɨ1226 93.5 KB

2 Likes
#9

I made an issue to the BCMR spec to drop ā€˜mutable NFTā€™ marker for reserved supply on authHead, this way it would be fully compatible with the AuthGuard standard. Currently no token correctly follows the reserved supply strategy suggested by the BCMR spec which is a good indication it could be improved.

The Paytaca ā€˜CashTokens Studioā€™ is already useable on Chipnet and is now being upgraded to use the WalletConnect V2 standard to work with multiple wallets in the BCH ecosystem in preparation for a mainnet launch.

I added the ā€˜CashTokens Studioā€™ in the Implementations section of the AuthGuard spec.

1 Like
#10

The BCMR spec has been updated and now no longer requires the mutable NFT market for the reserved supply on AuthHead as of version v2.1.0 (draft currently).

The CashTokens studio is also officially released since December so itā€™s now available for Bitcoin Cash mainnet and it also support the BCH Wallet Connect V2 standard which allows it to connect with Paytaca, Zapit & Cashonize. Congrats on the release! @joemar_taganna

1 Like