Is tx 51 v1 live?

[dexX7]

I tried to create a crowdsale with two curriencies, but it's unclear to me, if this is even live and if this is the case, how it's done. I looked at the spec and that's my interpretation (link):

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

The transaction appears to be invalid:

{
  "txid" : "305c754a023a2bf8736ea72c94d92602a22d1d4283e1a55c8e7f3a4a688017b6",
  "sendingaddress" : "mvayzbj425X55kRLLPQiuCXWUED6LMP65C",
  "ismine" : true,
  "confirmations" : 21,
  "fee" : 0.00010000,
  "blocktime" : 1410134896,
  "type" : "Create Property - Variable",
  "propertyid" : 0,
  "divisible" : true,
  "amount" : "0.00000000",
  "valid" : false
}

I looked at the code and I think it's not implemented, but given the complexity, I'm not really sure about this.

[m21]

Yes TX 51 has been live for months. You are setting Ecosystem to 0 in your script. That's not allowed AFAIK.

[dexX7]

Invalid as well:

{
  "txid" : "3e3ae02c52fe119eba50f3b1824166037b80f03541a1070d2a68fcf278e4c5a9",
  "sendingaddress" : "mvayzbj425X55kRLLPQiuCXWUED6LMP65C",
  "ismine" : true,
  "confirmations" : 1,
  "fee" : 0.00010000,
  "blocktime" : 1410160544,
  "type" : "Create Property - Variable",
  "propertyid" : 0,
  "divisible" : true,
  "amount" : "0.00000000",
  "valid" : false
}

Constructed with:

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

sendrawtx_MP "mvayzbj425X55kRLLPQiuCXWUED6LMP65C" "" "0001003301000000000000000000000000000006000000000000000100000000000000000000"

[dexX7]

I opened https://github.com/mastercoin-MSC/spec/issues/249, but I'm still curious - could you please post a valid example?

[zathras-crypto]

Hey DexX,

I have provided this feedback a few times now. The spec is getting out of hand. People are merging changes that are not yet live making the spec read as if they are.

For clarity, no implementation supports crowdsales of multiple properties, nor does any implementation support crowdsales of Bitcoins.

Other examples are send to owners, this is listed in the spec and reads as if live, but not even listed in the 'unlocking features' section raising ambiguity on whether it is live. Promotion of smart property also reads as if live, but is not. MetaDex (tx21) also reads as if live, but it is not, and so on.

It's imperative in my view that the spec clearly reflects which features are live and doesn't descend into ambiguity, I've raised this on a number of occasions.

I've also suggested that the right way to handle this is to have a master spec branch that contains current live features, and forks for features where they can be discussed and debated and merged in along with a love blockheight when they are ready to go.

TL:DR; we have spec owners & the spec needs to be maintained in a less vague fashion. Just my views mate :)

Thanks Z On Sep 8, 2014 5:48 AM, "dexX7" notifications@github.com wrote:

I tried to create a crowdsale with two curriencies, but it's unclear to me, if this is even live and if this is the case, how it's done. I looked at the spec https://github.com/mastercoin-MSC/spec#accepting-multiple-currencies-in-a-crowdsale and that's my interpretation (link http://builder.bitwatch.co/?version=1&type=51&ecosystem=0&property_type=0&currency_identifier=0&text=00&text=00&text=00&text=00&text=00&currency_identifier=6&number_of_coins=1&timestamp=0&percentage=0&percentage=0&sender=mvayzbj425X55kRLLPQiuCXWUED6LMP65C ):

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

The transaction https://www.biteasy.com/testnet/transactions/305c754a023a2bf8736ea72c94d92602a22d1d4283e1a55c8e7f3a4a688017b6 appears to be invalid:

{ "txid" : "305c754a023a2bf8736ea72c94d92602a22d1d4283e1a55c8e7f3a4a688017b6", "sendingaddress" : "mvayzbj425X55kRLLPQiuCXWUED6LMP65C", "ismine" : true, "confirmations" : 21, "fee" : 0.00010000, "blocktime" : 1410134896, "type" : "Create Property - Variable", "propertyid" : 0, "divisible" : true, "amount" : "0.00000000", "valid" : false }

I looked at the code and I think it's not implemented, but given the complexity, I'm not really sure about this.

— Reply to this email directly or view it on GitHub https://github.com/mastercoin-MSC/mastercore/issues/118.

[dexX7]

Ah I see, thanks for the insight. I fully agree. :)

[dacoinminster]

Ugh. Good point. I usually think of the spec as "What are we building?" rather than "What can we do right now?" but it would be really nice to have some way to mark features which are currently implemented.

On Mon, Sep 8, 2014 at 1:42 AM, dexX7 notifications@github.com wrote:

Ah I see, thanks for the insight. I fully agree. :)

— Reply to this email directly or view it on GitHub https://github.com/mastercoin-MSC/mastercore/issues/118#issuecomment-54790530 .

[dacoinminster]

Todo for me: I'll see if I can update the spec to accurately separate what is built from what we plan to build.

On Tue, Sep 9, 2014 at 1:55 PM, J.R. Willett jr.willett@gmail.com wrote:

Ugh. Good point. I usually think of the spec as "What are we building?" rather than "What can we do right now?" but it would be really nice to have some way to mark features which are currently implemented.

On Mon, Sep 8, 2014 at 1:42 AM, dexX7 notifications@github.com wrote:

Ah I see, thanks for the insight. I fully agree. :)

— Reply to this email directly or view it on GitHub https://github.com/mastercoin-MSC/mastercore/issues/118#issuecomment-54790530 .

[dexX7]

I actually assumed the transaction overview was intended to equal "implemented and live" whereby the "future transaction" section is to be understood as roadmap. The more I think about it, I see need for another differentiation. "Future transactions" represent merely an idea while there are indeed some transactions which are not yet live, but (almost) finalized (e.g. meta-dex trading).

[zathras-crypto]

Rereading my response, sorry it came across as my being a bit of an ass - I must have been tired when I wrote it.

Thanks Z On Sep 9, 2014 11:09 PM, "dexX7" notifications@github.com wrote:

I actually assumed the transaction overview was intended to equal "implemented and live" whereby the "future transaction" section is to be understood as roadmap. The more I think about it, I see need for another differentiation. "Future transactions" represent merely an idea while there are indeed some transactions which are not yet live, but (almost) finalized (e.g. meta-dex trading).

— Reply to this email directly or view it on GitHub https://github.com/mastercoin-MSC/mastercore/issues/118#issuecomment-55036170 .

[dacoinminster]

I thought what you wrote was quite reasonable - maybe you never hit "send" on the rude version. :)

I just looked at the "Unlocking Features" section, and it seems to be up-to-date: https://github.com/mastercoin-MSC/spec/#unlocking-features

Maybe the change we need is to have each feature refer back to that table to raise its visibility.

On Tue, Sep 9, 2014 at 2:33 PM, zathras-crypto notifications@github.com wrote:

Rereading my response, sorry it came across as my being a bit of an ass - I must have been tired when I wrote it.

Thanks Z On Sep 9, 2014 11:09 PM, "dexX7" notifications@github.com wrote:

I actually assumed the transaction overview was intended to equal "implemented and live" whereby the "future transaction" section is to be understood as roadmap. The more I think about it, I see need for another differentiation. "Future transactions" represent merely an idea while there are indeed some transactions which are not yet live, but (almost) finalized (e.g. meta-dex trading).

— Reply to this email directly or view it on GitHub < https://github.com/mastercoin-MSC/mastercore/issues/118#issuecomment-55036170>

.

— Reply to this email directly or view it on GitHub https://github.com/mastercoin-MSC/mastercore/issues/118#issuecomment-55039396 .

[dexX7]

Where does this section mention "crowdsales can accept multiple currencies"?

There is an inline-note which states "Effective with version 1 of Transaction type 51 and block #(TBD)" and then refers to "accepting multiple currencies", but what I consider as problematic: the description to version 0, which is currently live, is not available anymore - and v0 -> v1 does not only cover accepting multiple currencies, but also changes bonus calculation, maximal amount constraints and IIRC a reduction from one crowdsale per ecosystem to one crowdsale per address.

[dexX7]

@zathras-crypto: In my opinion you raised valid points and after quickly going through pending PRs, I identified the following as relevant/ready-to-merge or should-be-reviewed, given they are intended to keep the spec in sync:

https://github.com/mastercoin-MSC/spec/pull/246 P2sh support (live on testnet afaik) https://github.com/mastercoin-MSC/spec/pull/242 Move black holes to future additions (clarifies current state) https://github.com/mastercoin-MSC/spec/pull/221 Match specw/code append/replace not yet supported (clarifies current state) https://github.com/mastercoin-MSC/spec/pull/218 minfee fix (reflects current behavior) https://github.com/mastercoin-MSC/spec/pull/213 Minor tightening up of Class B encoding rules (reflects current behavior more accurately)

I think a few actions may reduce maintence needs and could be beneficial in general:

1. Use of branches as proposed, e.g. "the-spec", "live-on-testnet", ...
2. Use of tags and releases to preserve "outdated" information such as a "tx version 0" while "tx version 1" is available - especially if both are "live" (https://github.com/mastercoin-MSC/spec/issues/188)
3. Versioning which provides information related to backwards-compability and such (also issue 188)
4. Split the spec into two documents: a "specification" and "description" (not the best word probably)

The last point is probably the most difficult one, but I think the current spec tries to serve both as "set of rules" as well as "source of reason, introduction and project description, general information" while both actually aim for different goals and might even be conflicting in some areas (e.g. "lengthy descriptions" as information vs "short definitions" for developers).