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

Updated verification API for DEx #35

Merged
merged 2 commits into from
Jan 20, 2014
Merged

Conversation

maran
Copy link
Contributor

@maran maran commented Jan 12, 2014

We need some more tools in the verification API in order to keep automatic consensus going. With these added fields we will be able to determine which transaction is breaking consensus when it happens.

@ripper234
Copy link
Contributor

I suggest a deadline of 3-4 days for this pull request.

@zathras-crypto
Copy link
Contributor

As discussed, supported.

@ghost
Copy link

ghost commented Jan 13, 2014

"... the total amount a user actually spends on an open ..."

Aside from a pluralization nitpick looks good.

Just one question, regarding the Purchase Offers. Quoted from the spec,

If you send less than the correct amount of bitcoins, your purchase will be adjusted downwards. If you send >more then the correct amount of bitcoins and the Selling Offer has more Mastercoins still available your >order will be adjusted upwards.

The spec doesn't mention the outcome if you send more bitcoins than the SO requires and the SO doesn't have any more Mastercoins available. I might have missed it, but the assumption then is that those BTC are lost? Is this an assumption left to the reader?

@maran
Copy link
Contributor Author

maran commented Jan 13, 2014

That's how I read it as well. The BTC will have gone to the seller. Not sure if J.R. meant something else there.

@zathras-crypto
Copy link
Contributor

The extra BTC would be lost in that case. That's a hypothetical for
interacting directly with the protocol however - wallet software should
never allow you to send more BTC than the accept offer confirmed in the
blockchain specifies.

Thanks
Zathras
On Jan 14, 2014 7:46 AM, "Faiz Khan" notifications@github.com wrote:

"... the total amount a user actually spend_s_ on an open ..."

Aside from a pluralization nitpick looks good.

Just one question, regarding the Purchase Offers. Quoted from the spec,

If you send less than the correct amount of bitcoins, your purchase will
be adjusted downwards. If you send >more then the correct amount of
bitcoins and the Selling Offer has more Mastercoins still available your

order will be adjusted upwards.

The spec doesn't mention the outcome if you send more bitcoins than the SO
requires and the SO doesn't have any more Mastercoins available. I might
have missed it, but the assumption then is that those BTC are lost? Is this
an assumption left to the reader?


Reply to this email directly or view it on GitHubhttps://github.com//pull/35#issuecomment-32209557
.

@ghost
Copy link

ghost commented Jan 13, 2014

That sounds right. Thanks for the clarification.

@maran
Copy link
Contributor Author

maran commented Jan 13, 2014

@zathras-crypto Do you want to send a PR in for your suggestion on clarifying the Class A parsing?

@zathras-crypto
Copy link
Contributor

Yep, that's all coming - apologies in advance for the long post incoming
(prob later today).
On Jan 14, 2014 8:02 AM, "Maran" notifications@github.com wrote:

@zathras-crypto https://github.com/zathras-crypto Do you want to send a
PR in for your suggestion on clarifying the Class A parsing?


Reply to this email directly or view it on GitHubhttps://github.com//pull/35#issuecomment-32210978
.

@maran
Copy link
Contributor Author

maran commented Jan 14, 2014

@grazcoin

I modified the example to use 2 and 3. Good point. As for your other comments; I think the name changes belong in a different PR. The whole spec is full of these terms so they should be redone properly and all together.

I will wait 12 more hours in case something else comes up otherwise I'm merging tomorrow morning.

@ripper234
Copy link
Contributor

@maran 12 hours X 12 = 6 days :)
Merging.

ripper234 added a commit that referenced this pull request Jan 20, 2014
Updated verification API for DEx
@ripper234 ripper234 merged commit f176989 into OmniLayer:master Jan 20, 2014
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

Successfully merging this pull request may close these issues.

4 participants