Permissioned Rune minting

[lifofifoX]

Any thoughts on utilizing parent child provenance to restrict who can mint a Rune?

Following 3 options associated with etching inscription (say, first inscription revealed in etching tx) provenance could offer a wide range of options to the etcher.

• self - Etching inscription must be an input to the mint transaction.
• children - A child inscription of etching inscription must be an input to the mint transaction.
• siblings - A child inscription of etching inscription's parent(s) must be an input to the mint transaction.

Example:

parents:
- 6ac5cacb768794f4fd7a78bf00f2074891fce68bd65c4ff36e77177237aacacai0

etching:
  rune: THE•BEST•RUNE
  divisibility: 2
  premine: 1000.00
  supply: 10000.00
  symbol: $
  terms:
    amount: 100.00
    cap: 90
    restrict: self | children | siblings

inscriptions:
- file: mango.avif

• self - mango.avif inscription must be an input to the mint transaction.
• children - A child inscription of mango.avif inscription must be an input to the mint transaction.
• siblings - A child inscription of 6ac5cacb768794f4fd7a78bf00f2074891fce68bd65c4ff36e77177237aacacai0, parent of mango.avif inscription, must be an input to the mint transaction.

Premine can be disallowed for children restriction.

[cryptoni9n]

Hi @lifofifoX - I believe Casey suggested something similar here, but qualified it by saying only if the change was absolutely necessary would it be done. I think another reason that request closed was because a good-enough use case for the change was not presented. I'm not sure if this should be considered a dupe of #3677 or not. What do you think?

[lifofifoX]

I'd argue that allowing children of an inscription opens up more possibilities than just the stable coin use case. For example, you could have a rune that can only be minted by holders of certain collections. I don't have any concrete use case, besides introducing a new variable to degening with Runes.

[HubertusVIE]

It was argued extensively in #3677 which is a dupe.

"A good-enough use case for the change was not presented" is an inaccurate statement. A significant number of people posted various real-world use cases and product/legal/financial reasons why.

This "not good enough" was a vote of one person (= Casey) against all others.

We (the Bitcredit Protocol initiative) have meanwhile resorted to using BRC-20 5Byte. We don't like it but we have enough on our plates. If someone develops self-mint, we'd soon switch to this "new" Runes, in all likelihood.

[cryptoni9n]

"A good-enough use case for the change was not presented" is an inaccurate statement. A significant number of people posted various real-world use cases and product/legal/financial reasons why.

This "not good enough" was a vote of one person (= Casey) against all others.

Yes, this is what I meant - not good enough to be accepted into the code stream by Casey - not a comment on my opinion of the merit of the use cases.

[lifofifoX]

My proposal here is a little broader than restricting minting to a small group of people, as per #3677. That's why I opened a new ticket. Tying provenance with degening with open mints is much more interesting to me than the stable coin use case.