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.

[HubertusVIE]

much more interesting to me

Sure, whatever gets this going.

[casey]

I would say this is not a dupe of #3677, because #3677 only considered allowing the etching parent inscription to be allowed to mint, whereas this issue proposes also gating mints to children and siblings of the etching parent.

I am still not convinced that gating mints to the parent is worthwhile, because I still think that just premining a bunch in advance is a fine workaround.

Gating mints to children and sibling inscriptions is a bit more interesting, however, you can still just premine the rune and air drop it to holders of inscriptions.

However, all that being said, doing this would tie the inscription and rune protocols together, which I do not think we want to do.

Indexing runes takes 30 minutes and results in an index.redb which is only about a gigabyte. Indexing inscription takes about six hours, and results in an index.redb which is 60-80 gigs. If we tied the two protocols together, it would be impossible to index runes without inscriptions.

Additionally, the runes protocol is extremely compact, simple, and well thought out. The inscriptions protocol is much more complex and crufty.

I do like this idea, but there are real costs, and I think it's not an acceptable tradeoff.

[lifofifoX]

Thanks @casey. That's a fair point 👍

[HubertusVIE]

Thanks @Casey, I get the cost argument. Is there any "cheaper" way?

[casey]

Hmm, thinking out loud, the reason it's expensive is because it uses possession of an inscription to determine whether a mint transaction is valid. This is expensive because it adds a dependency on inscriptions and ordinals. Alternatively, we could use possession of another rune to determine whether or not a mint transaction is valid.

So, you would etch rune A, and then when etching rune B, you would say that for a mint of rune B to be valid, the mint transaction inputs have to contain some amount of rune A. Rune A could have a supply of 1, if you wanted only a single person to be able to mint more of rune B, or it could have a larger supply, if you wanted the ability to allow multiple people to mint rune B. You could also specify the amount of rune A that would have to be in the transaction in order to mint rune B. So you could gate it to anyone holding 1 or more of rune A, or gate it to anyone holding 1000 or more of rune A.

This would have the same desirable properties as gating mints to an inscription holder, namely that it wouldn't be tying permission to mint to a single address, since you could transfer rune A to a new address.

This does however have somehwat dangerous protocol implications that I'm not sure are acceptable.

Runes has a very simple strategy for invalid transactions and future upgrades: If a transaction is invalid (which also includes transactions by future versions of ord, as seen by a old version of ord), etchings and mints in that transaction do occur, but any input runes, and any proceeds of a mint or etching are also burned.

The reason that etchings and mints occur in otherwise invalid transactions is that if they didn't, an upgrade which rendered old invalid transactions valid could invalidate previously valid mints.

Consider rune X with a mint cap of 1. In version 0, ord sees:

• Invalid transaction A minting rune X
• Valid transaction B minting rune X

ord v0 credits the mint to transaction A, and transaction B doesn't receive the mint.

If transaction A is valid according to v1, then v1 still credits the appropriate transaction.

If v0 ignored transaction A, and credited the mint to transaction B, then balances would change between v0 and v1, which would be catastrophic.

Now, back to gated mints. Let's say we have rune ABC which is needed to mint rune XYZ.

Ord v0 sees this:

• Invalid transaction A with rune ABC in inputs.
• Valid transaction B with input from A minting XYZ.
• Valid transaction C with with rune ABC in inputs minting XYZ.

In this case, ord would credit transaction C with the mint, since B didn't contain any of rune ABC.

Ord v1 sees this:

• Valid transaction A with rune ABC in inputs.
• Valid transaction B with input from A minting XYZ.
• Valid transaction C with with rune ABC in inputs minting XYZ.

In this case, ord would credit transaction B with the mint, since A was valid under the new rules, and would not credit transaciton C, since the mint in B had already happened.

This would lead to a balance change between v0 and v1, which would be bad.

[cryptoni9n]

This does however have somehwat dangerous protocol implications that I'm not sure are acceptable.

Would it be possible to work around the requirement of including a rune in the etching by gating on the etching address somehow? It would be a much more restrictive system, and might tie the runes and address indexes together, but could it get around the 'upgrade changes the rules/version balance mismatch' issues you described?

[casey]

@cryptoni9n This would be possible, but I'm not a fan of such a design. It means you couldn't, for example, migrate to a new address type or custody setup, because the mint permission was tied to a specific address.

One way of getting around it would be to require that the rune with permissioned minting had a huge number of mints allowed, like 2**64 or more. This would avoid the possibility of, after an upgrade, a mint becoming invalid because an previous transaction was now valid under the new rules.