OmniLayer / spec

Omni Protocol Specification (formerly Mastercoin)
The Unlicense
342 stars 116 forks source link

Transaction details of accepting multiple currencies in a crowdsale #249

Open dexX7 opened 10 years ago

dexX7 commented 10 years ago

The spec states:

This is accomplished, while the crowdsale is active, by the crowdsale owner's address sending additional Transaction type 51 messages with:

  • a Currency Identifier Desired value,
  • the Number Properties per Unit Invested value for the specified Currency Identifier Desired, and
  • all other fields null (\0) or zero (0)

So my interpretation was:

Version: 1 < set
Type: 51 < set
Ecosystem: 0
Property type: 0
Previous property: 0
Category: \x00
Subcategory: \x00
Name: \x00
Url: \x00
Data: \x00
Property desired: 6 < set
Properties per unit: 1 < set
Deadline: 0
Early bird bonus: 0
Percentage for issuer: 0

Hex: 0001003300000000000000000000000000000006000000000000000100000000000000000000

Whereby @m21 said:

You are setting Ecosystem to 0 in your script. That's not allowed AFAIK.

@marv-engine @dacoinminster:

Seems like this is a bit unclear - at least for me. Would welcome a clarification on this topic.

marv-engine commented 10 years ago

@dexX7 @m21 @dacoinminster The next paragraph in that section says:

The same validity requirements must apply to these fields as applied to the crowdsale's original Transaction type 51 message. The values in the other data fields of the new message must be null (\0) or zero (0). The values from those fields in the crowdsale's original Transaction type 51 message, including Early Bird Bonus %/Week and Percentage for issuer, apply to all accepted currencies for the crowdsale.

The last sentence in that paragraph was supposed to be clear, but maybe it isn't or it gets overlooked. The reason for having those values=0 is to prevent the tx51 from being interpreted as a new crowdsale if for some reason the active one had been closed.

We haven't been consistent in how tx's are updated or cancelled. Tx20 has an Action field, tx51 is as described above for updates (w/ tx53 to close/cancel a crowdsale).

A common, clear approach would go a long way toward eliminating confusion and uncertainty.

@dexX7 Per the second paragraph of https://github.com/mastercoin-MSC/spec#new-property-creation-via-crowdsale-with-variable-number-of-tokens the starting block number is still TBD, if that answers your question about tx51 v1 being live.

dexX7 commented 10 years ago

Hey @marv-engine, thanks for the reply. The question, if it's live was related to the current mastercore master on testnet and @m21 mentioned that it's "live for months", but it turned out there was a misunderstanding.

The quoted part is nevertheless indeed what appears confusing to me, because I'm unsure what it actually means. Validity requirements are mentioned and the base definition states a few things such as "property name" must not be blank or null as well as a reference to the validity constraints for each message field type. To my understanding a validity constraint is for example "a property must exist" or "the name field must not be empty" - please correct me, if my misunderstanding starts here.

The confusing part for me derives from all other fields null (\0) or zero (0) because almost all fields are usually not optional and explicitly this conflicts with (for example) "property name" must not be blank or null in my opinion.

In general I think being as explicit as possible should be aimed for, so instead of saying "this or that applies", I'd list what exactly applies here.

Would you mind to post a complete example please, because I'm still not 100 % sure how it would be done? :)

Edit:

We haven't been consistent in how tx's are updated or cancelled. ... A common, clear approach would go a long way toward eliminating confusion and uncertainty.

Is it too late to do so, given that it's not live nor even implemented?

Edit: If this is still on the table, I'd turn adding another accepted currency into a seperated transaction type to remove ambiguously and especially to reduce the number of filler-fields. Tx 53 (manual close) is super explicit and short which I think is great. Same applies for granting and revoking tokens. E.g.:

Version: 0
Type: 52 (yes, let's replace "promote property")
Currency desired: nnn
Properties per unit Invested: mmm