search

rgb-archive / spec

[OLD!] RGB Protocol specifications for Bitcoin-based digital assets
https://rgb-org.github.io/
147 stars 26 forks source link

To meta-script or not to meta-script? #23

Closed afilini closed 6 years ago

afilini commented 6 years ago

Honestly, I don't think we really need a meta-script language. We could just add some "blueprints" for contracts, so that we define their behavior, while the issuer only needs to fill up some fields.

The first two blueprints I can think of are:

  1. The old token issuance where the issuer "prints" N tokens and sends all of them to a specific address
  2. The "crowdsale" issuance, where the users who buy these tokens are actually printing them for themselves, by proving that they sent a payment to a specific BTC address.

I agree that we need a versioning system, but I would use it to "tag" changes in the behavior of the blueprints themselves. Something like:

Crowdsale issuance (type 0x02), version 1.0: Everyone can buy the tokens

Crowdsale issuance (same type, 0x02), but version 2.0: There is one more field that allows the issuer to force users to send segwit transactions only.

This doesn't really make any sense, it's just an example of the following concept: every blueprint (contract) have a specific type, and a version number. By changing the version number we conceptually keep the same "behavior", while we can add some more features/improved privacy/security and even more.

This kind of structure allow users (or wallets) to ban specific contract types, while welcoming version updates on the kind they accept. Instead, with a "general" RGB version number we could risk forks when a controversial change is applied together with some useful updates, since someone would like to accept the "useful updates" while rejecting the "controversial change", possibly resulting in a fork.

Oh, and this would allow us to add a meta-script language in the future, by creating a new blueprint with a field that contains the script itself.

tiero commented 6 years ago

So, your scope is to replicate a inheritance capability? that's nice.

I agree that some versioning control more advanced than just tag, should be in place.

I do think that 1 and 2 are the same, I mean you can still do a crowdsale and printing tokens (pre-mine?) in advance, right?

afilini commented 6 years ago

No, 1 and 2 are pretty different, that's why they have different types. With one you can do "pre-mine", while with the other you can do crowdsales

tiero commented 6 years ago

Ok, having only "centralized" blueprints can be tedious and slow process (incremental proposals?) compared to having a met-script language where you leave more freedom to issuers to craft their own without consensus.

PS: I don't have any ideas atm of different issuance mechanism (behaviors) to justify the meta script, but it can be a cool proposition.