Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transaction details of accepting multiple currencies in a crowdsale #249

Open
dexX7 opened this issue Sep 8, 2014 · 2 comments
Open

Transaction details of accepting multiple currencies in a crowdsale #249

dexX7 opened this issue Sep 8, 2014 · 2 comments

Comments

@dexX7
Copy link
Member

dexX7 commented Sep 8, 2014

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
Copy link

@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
Copy link
Member Author

dexX7 commented Sep 9, 2014

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants