search

lightninglabs / taproot-assets

A layer 1 daemon, for the Taproot Assets Protocol specification, written in Go (golang)
MIT License
464 stars 111 forks source link

[feature]: allow deriving group key upfront to simplify minting #749

Open babyface001 opened 10 months ago

babyface001 commented 10 months ago

current group key and group anchor is hard to use.

can we request group key first, then mint grouped assets with requested key.

babyface001 commented 10 months ago

group anchor is only for batch group key need finalize

guggero commented 10 months ago

Do you want to add more groups into the same batch or a new one? If the same batch, then use group_anchor (name of the asset that is the first asset in the group). If for a new batch, you can look up the group key of the asset in the previous batch.

babyface001 commented 10 months ago

why 2 strategy?

my finalize call is not sync, so if it finalized, group_anchor will be invalid.

babyface001 commented 10 months ago

if group key can be requested before mint then we just need 1 strategy

babyface001 commented 10 months ago

mint grouped asset become:

  1. get a group key
  2. mint asset with this key.
babyface001 commented 10 months ago

no need to care batch. or groups

guggero commented 10 months ago

Yeah, I guess it would make things a bit simpler, good point.

jharveyb commented 10 months ago

The group key is tweaked with some asset, so I think the closest thing you'd be able to do would be to generate the internal key for the group key ahead of minting? And then use that when creating the batch.

But I don't think that change would help for the issue you are mentioning.

babyface001 commented 10 months ago

@jharveyb

now I mint one asset for group key, then mint the others with this key.

but supply is +1 for collectible asset.

can we do a deploy to get the group key, then mint other assets use deploy key.

jharveyb commented 10 months ago

If you don't want to count the value of the first asset of the group in the total supply of the group, you could maybe use an asset that is provably unspendable. We have a spec for this already:

https://github.com/lightninglabs/taproot-assets/blob/76bb5ae01fc0aa147233f332c468943f8c47b053/asset/burn.go#L12

https://lightning.engineering/api-docs/api/taproot-assets/taproot-assets/burn-asset

However this wasn't designed for minting an unspendable asset, so it would need some changes to work for that case. If you used this, clients could ignore that first unspendable asset and only count the future assets in the group for the total asset supply.

jharveyb commented 6 months ago

With the changes in #866 , you would be able to create parts of the group key externally before you start minting. But the final key still depends on the first asset minted of the group.

One option would be to mint the first asset to create the group key, and then burn it, so it's value doesn't affect total supply.