-
Notifications
You must be signed in to change notification settings - Fork 11
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
Is tx 51 v1 live? #118
Comments
Yes TX 51 has been live for months. |
Invalid as well:
Constructed with:
|
I opened OmniLayer/spec#249, but I'm still curious - could you please post a valid example? |
Hey DexX, I have provided this feedback a few times now. The spec is getting out of For clarity, no implementation supports crowdsales of multiple properties, Other examples are send to owners, this is listed in the spec and reads as It's imperative in my view that the spec clearly reflects which features I've also suggested that the right way to handle this is to have a master TL:DR; we have spec owners & the spec needs to be maintained in a less Thanks
|
Ah I see, thanks for the insight. I fully agree. :) |
Ugh. Good point. I usually think of the spec as "What are we building?" On Mon, Sep 8, 2014 at 1:42 AM, dexX7 notifications@github.com wrote:
|
Todo for me: I'll see if I can update the spec to accurately separate what On Tue, Sep 9, 2014 at 1:55 PM, J.R. Willett jr.willett@gmail.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). |
Rereading my response, sorry it came across as my being a bit of an ass - I Thanks
|
I thought what you wrote was quite reasonable - maybe you never hit "send" I just looked at the "Unlocking Features" section, and it seems to be Maybe the change we need is to have each feature refer back to that table On Tue, Sep 9, 2014 at 2:33 PM, zathras-crypto notifications@github.com
|
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. |
@zathras-crypto: OmniLayer/spec#246 P2sh support (live on testnet afaik) I think a few actions may reduce maintence needs and could be beneficial in general:
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). |
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):
The transaction appears to be invalid:
I looked at the code and I think it's not implemented, but given the complexity, I'm not really sure about this.
The text was updated successfully, but these errors were encountered: