Added reserve clause to Selling Order description

[maran]

I suggested this addition to the spec a couple of weeks back. Grazcoin and Zathras are also behind it. Original discussion starting here: https://bitcointalk.org/index.php?topic=292628.msg3427465#msg3427465.

[ripper234]

I vote nay. In fact, I would like @maran and the other developers to adjust their pull request to implement option 2, not option 1.

https://bitcointalk.org/index.php?topic=292628.msg3521564#msg3521564

[ripper234]

Moving the discussion here, quoting my reply on bitcointalk (please use this issue to discuss, not bitcointalk):

Posting an offer that is larger than the amount of MSC you hold is actually an important feature in my book.
Gox had this a while back.

You might want to let the system know you want to sell, even if you don't have the balance yet.
Then, immediately when you receive funds (e.g. you're waiting for a 3rd party to pay you), these funds turn into a live offer.

The UI and offer matching engine should filter "live offers" from offers that lack funding.

I support option #2, not #1.

[maran]

Let me paint you a picture.

User A: puts a sell order online for 100MSC.
User B: Sends a Purchase Offer for 100MSC at the same time User A sends 50MSC to User C.
User B: Now either gets an invalid Purchase Offer or sees his offer modified while the Selling Order still stands.

This is confusing and sucky UX if you ask me. I stand by option 1.

In fact, I would like @maran and the other developers to adjust their pull request 
to implement option 2, not option 1.

As far as I know this is not a dictatorship. I would like to hear everybody's opinion before we put this to a vote.

[ripper234]

There is no "At the same time" in Mastercoin. All operations are always ordered by the blockchain.

This is a fundamental property of Willett's original spec, and we must maintain it - this is what enables us to solve a super complicated problem like decentralized exchange, really really quickly. From our code's perspective, there is always one order that comes before the other.

Now - User B's offer can either allow for partial fulfillment, or not.
If User B allows partial order fulfilment, then User B just buys 50 MSC and is left with an open order to buy 50 more MSC.
If User B chooses not to allow partial order fulfillment, then his offer is just not matched and waits a counter offer for the required amount.

Of course this is not a dictatorship! I just voiced my opinion here ... I used the word "vote".

[maran]

The fact remains that by reserving the amount of a 'Selling Order' you increase the user experience for the end user.

I literally quoted you where you are 'asking' us to adjust the pull request. The fact that you ask me to change it after we already had three votes for gave me the impression you think your one vote is stronger then our three votes. I will abstain from saying anything else until other voices are heard.

[ripper234]

Sorry about giving the wrong impression!

I was just not part of the original discussion ... and am request a revote.
Anyway the vote process is not "the Mastercoin developers vote", it's "the people with stake in Mastercoin vote". When that is implemented we can do it official. Until then the Mastercoin Foundation is representing people with stake. It is our goal to decentralize this process ASAP.(https://trello.com/c/IbhPeSg0/10-write-spec-for-proof-of-stake-voting).

Now to the actual matter - I think at least one of us doesn't understand the other. @dacoinminster, would you like to have your say? Waiting for more replies.

[maran]

No problem. I'm just passionate about the project and want to make sure everybody gets their voice heard. I'm ok with either solution although I prefer the first one for UX reasons. Let's wait for J.R. I will rewrite the spec after we hear from him.

[oferrotem]

Hey there,
I'm enthusiastic about Mastercoin, I bought some from the Exodus address, and I'm watching this repository, so I got this conversation to my inbox recently.

I might be missing something, but I think that these "standby" orders are really useful and important enough to be a feature.
I agree that the usability of a product is the most important thing (because you create a product to be useful to all users, not only to the 20% early adopters), but in this case I believe a good UX/UI solution can be found, such as placing this option under "advanced", marking it differently, etc.
I don't know if there are other reasons against it (such as a significant longer time-to-market?), but if UX/UI is the only one I think it's solvable.

Cheers,
Ofer.

[ripper234]

+1

Time to market isn't an issue in this specific case, it's relatively minor
difference.
It's better the protocol itself is made correctly from the start and not
patched afterwards just to achieve "time to market".

Ron Gross
Co-Founder & CEO @ Bitblu
bitblu.com | ripper234.com
Schedule my time at meetme.so/RonGross

On Sat, Nov 9, 2013 at 5:57 PM, Ofer notifications@github.com wrote:

Hey there,
I'm enthusiastic about Mastercoin, I bought some from the Exodus address,
and I'm watching this repository, so I got this conversation to my inbox
recently.

I might be missing something, but I think that these "standby" orders are
really useful and important enough to be a feature.
I agree that the usability of a product is the most important thing
(because you create a product to be useful to all users, not only to the
20% early adopters), but in this case I believe a good UX/UI solution can
be found, such as placing this option under "advanced", marking it
differently, etc.
I don't know if there are other reasons against it (such as a significant
longer time-to-market?), but if UX/UI is the only one I think it's solvable.

Cheers,
Ofer.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1#issuecomment-28130103
.

[dacoinminster]

This discussion, as I understand it, is essentially about whether someone can do a simple-send with MSC funds that are currently offered for sale. I would say that this should be possible, but that doing so would instantly change the number of coins available for sale (as if the user had published a message changing or canceling the order amount, and then did the simple send). We could force the user to change their sell order amount first, and THEN send the MSC, but that seems like an extra step we don't need.

Obviously if somebody else accepts the offer of coins available for sale first, the simple-send will be invalid.

HOWEVER, implementing this might get too complicated. If this change to the spec makes implementations easier and user experiences better, then I support it. I don't feel strongly about this either way.

[dacoinminster]

Thinking about this a bit further, once we have a ton of different ways to send MSC, through betting and so on, handling this situation for each type of transaction might get too complicated. I think there is a pretty good case that can be made here for just debiting the amount for sale from the users' balance until the sell order is explicitly cancelled or changed. I like to keep things simple, and that seems simpler.

I guess what I'm saying is, I support this pull request, though I still don't feel strongly about it.

[zathras-crypto]

I'm supportive of this. Masterchest currently 'locks' funds allocated to a sell offer & these funds are only available to spend again by changing or cancelling the sell offer.

This way we always have a known state and known set of balances.

Not 'locking' the funds significantly complicates the implementation as it means for every other transaction type we have to first evaluate what's currently happening with that users exchange transactions (a complexity not required if we simply 'lock'/'reserve' funds assigned to a sell offer.)

[grazcoin]

Thinking about it again - I changed my mind, and I am for option 2.
Adding the "reserved funds" seems like a wrong architecture decision.
I don't think avoiding it increases the complexity of implementation too much, but it sure simplifies the user actions side and opens new dynamics.
The protocol takes care of all the required calculations and the UI gives the users the correct state at any moment.

[Bitoy]

Compromise option 3
Funds should not be locked immediately. Funds are locked if someone accepts it.
Ex.

User A post 300 coins for sale
User B accepts 300 ( but hasn't paid)

System locks the 300 coins of User A . It is only released if User B pays or until time runs out.

Scenario 2
User A post 300 coins sell offer
User A simple sends 200 coins. (UserA Balance is now 100)
sell offer must show only 100 (whatever is lower between User A balance and sell offer.)
User B will see only 100 coins for sale

[ripper234]

@Bitoy can you explain the difference between Option 2 and Option 3?

[Bitoy]

Its the same :) Sorry I misread option 2 (I thought option 2 means users a can still send 200 coins even if it is accepted by user B.).

But one thing I'd like to see is the option to allow user b to buy 100 coins even if he posted for 300. we can add another param partial or all in the buyer acceptance so that user b can choose if it is ok to partially fill his order or not (someone suggested this in bitcointalk)

[Bitoy]

Ok I think I prefer now option 2. It is "fair" to both seller and buyer.

[zathras-crypto]

I think we need a clarification here - Tachikoma's pull is for a protocol rule, not necessarily how it must be delivered to the end user.

If (and I stress the 'if') the desire is to allow users to send MSC they otherwise have tied up in a sell offer, there is nothing to stop wallets changing the sell offer accordingly before transmitting the send - there is no reason for this to be 'harder' for the end user (or even visible if we don't want).

I'm still of the view that without this pull we're adding a lot of complexity to every future transaction type (plus of course simple send) by requiring extra evaluation of exchange sell offers, purchase offers, payments and timelimits etc. As we scale out the burden becomes larger.

I guess the point I'd like to make is users interact with software, not the protocol. We can do creative things in software that aren't explicitly designed for in the protocol. We can still deliver sends while funds are 'locked' if so desired, we just do it wallet-side.

The one case I am interested in is Ron's - Ron, could you elaborate a bit? Say for example we did allow sells over and above what the holder has in MSC - are we not then allowing manipulation of the market? Ie what's to stop me holding 5MSC but posting a 100K MSC sell wall at a low price to encourage a downward trend? And won't end users be frustrated by their inability to actually trade on what they'll see as a fake offer? Or are you proposing that the offer only becomes visible to others once funded? In which case, where's the value? (excuse my trading naivety!)

EDIT: Just re-read your comment Ron, so essentially you envisage the offers only being displayed when funded, so it's a method for selling funds received at an address at a given price in an automated manner? I'd appreciate your views on how important this would be (1-10) so we can weigh it against the (potential) extra complexity?

Thanks! :)

[ripper234]

You are not manipulating the market.
The software and thus market can distinguish between funded orders (those
with actual BTC waiting to be matched) and unfunded orders (which are just
out there for fun).

Sellers will mostly ignore such fake walls.

It's a UI issue.

Ron Gross
Mastercoin Executive Director
mastercoin.org | ripper234.com
Schedule my time at meetme.so/RonGross

On Tue, Nov 12, 2013 at 9:04 AM, zathras-crypto notifications@github.comwrote:

I think we need a clarification here - Tachikoma's pull is for a protocol
rule, not necessarily how it must be delivered to the end user.

If (and I stress the 'if') the desire is to allow users to send MSC they
otherwise have tied up in a sell offer, there is nothing to stop wallets
changing the sell offer accordingly before transmitting the send, there is
no reason for this to be 'harder' for the end user (or even visible if we
don't want).

I'm still of the view that without this pull we're adding a lot of
complexity to every future transaction type (plus of course simple send) by
requiring extra evaluation of exchange sell offers, purchase offers,
payments and timelimits etc. As we scale out the burden becomes larger.

I guess the point I'd like to make is users interact with software, not
the protocol. We can do creative things in software that aren't explicitly
designed for in the protocol. We can still deliver sends while funds are
'locked' if so desired, we just do it wallet-side.

The one case I am interested in is Ron's - Ron, could you elaborate a bit?
Say for example we did allow sells over and above what the holder has in
MSC - are we not then allowing manipulation of the market? Ie what's to
stop me holding 5MSC but posting a 100K MSC sell wall at a low price to
encourage a downward trend? And won't end users be frustrated by their
inability to actually trade on what they'll see as a fake offer? Or are you
proposing that the offer only becomes visible to others once funded? In
which case, where's the value? (excuse my trading naivety!)

Thanks! :)

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1#issuecomment-28272778
.

[zathras-crypto]

Yep, sorry I think my edit went in at the same time as your post. I re-read your comments & think I understand what your shooting for. I'd like to understand how important you guys see it as next so we can weigh pros/cons. Thanks! :)

[ripper234]

There are no cons, so let's go with #2.

:)

If anyone disagrees, let's discuss.

Ron Gross
Mastercoin Executive Director
mastercoin.org | ripper234.com
Schedule my time at meetme.so/RonGross

On Tue, Nov 12, 2013 at 9:39 AM, zathras-crypto notifications@github.comwrote:

Yep, sorry I think my edit went in at the same time as your post. I
re-read your comments & think I understand what your shooting for. I'd like
to understand how important you guys see it as next so we can weigh
pros/cons. Thanks! :)

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1#issuecomment-28274034
.

[zathras-crypto]

2 posts up :)

Seriously though, we need to be clear about what use cases we want to enable with option 2 as there's no getting around the fact it introduces more complexity. JR is right on point there about when we're looking at betting and other future transactions - they ALL get more complicated if we go option 2.

As I mentioned above if the deliverable is simple sends with funds tied up in a sell offer, this problem can be solved without the extra complexity of option 2.

If the deliverable is selling over and above your balance, then yep that needs option 2 but if that's the only use case that option 2 enables we need to know how important it is as I'm currently seeing it as a small limited-use feature for a big development cost.

Thanks! :)

[ripper234]

I don't think the complexity is critical.
Think of it as a boolean flag on each offer.
Only if the flag is set to true then the offer is "real"
Otherwise, it's not.

I honestly don't see the complication.
Can someone else try to explain our positions to each other?

Ron Gross
Mastercoin Executive Director
mastercoin.org | ripper234.com
Schedule my time at meetme.so/RonGross

On Tue, Nov 12, 2013 at 10:04 AM, zathras-crypto
notifications@github.comwrote:

2 posts up :)

Seriously though, we need to be clear about what use cases we want to
enable with option 2 as there's no getting around the fact it introduces
more complexity. JR is right on point there about when we're looking at
betting and other future transactions - they ALL get more complicated if we
go option 2.

As I mentioned above if the deliverable is simple sends with funds tied up
in a sell offer, this problem can be solved without the extra complexity of
option 2.

If the deliverable is selling over and above your balance, then yep that
needs option 2 but if that's the only use case that option 2 enables we
need to know how important it is as I'm currently I'm seeing it as a small
limited-use feature for a big development cost.

Thanks! :)

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1#issuecomment-28274962
.

[maran]

No offence to you Ron but you haven't really done any coding on Mastercoin so far so I'm not really convinced you should be able to say that the complexity is not critical.

We will need to do extensive querying whenever we parse an 'Purchase Offer' and calculate the available coins for sale based on all known transaction types since we can't assume the available amount for sale is actually available. If you reserve the funds, like most exchange software does, you can guarantee those funds are available and it makes parsing the transactions a lot easier since you only need to check how many of the reserved coins are already sold.

Anyway. I think both sites of the argument have been heard and J.R. should just decide one of the options so we can move on. It's important we keep the momentum going and discussions like these can really drag out.

[ripper234]

Well ... I am able to say what I want, of course I might be talking
complete rubbish ... you guys are here to report from the trenches.

I think waiting for our Spec Master to speak is a great idea.

Ron Gross
Mastercoin Executive Director
mastercoin.org | ripper234.com
Schedule my time at meetme.so/RonGross

On Tue, Nov 12, 2013 at 1:10 PM, Maran notifications@github.com wrote:

No offence to you Ron but you haven't really done any coding on Mastercoin
so far so I'm not really convinced you should be able to say that the
complexity is not critical.

We will need to do extensive querying whenever we parse an 'Purchase
Offer' and calculate the available coins for sale based on all known
transaction types since we can't assume the available amount for sale is
actually available. If you reserve the funds, like most exchange software
does, you can guarantee those funds are available and it makes parsing the
transactions a lot easier since you only need to check how many of the
reserved coins are already sold.

Anyway. I think both sites of the argument have been heard and J.R. should
just decide one of the options so we can move on. It's important we keep
the momentum going and discussions like these can really drag out.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1#issuecomment-28285201
.

[maran]

Hahah, that's true.

Let's wait for our fearless leader on this one :)

[grazcoin]

I started coding option 2, and until now I don't see any major complexity. We have a serial system and each new tx changes the state of balances map. I treat sell offer as a "wish" from the user, and the buyers see at each specific moment only the actual available part (which is zero if no funds are available and partial order if only part of the funds are available). The buyers do not get confused.

Option 2 makes it easier for the seller. No need to make each time a new (modified) sell order just because he has to send come coins somewhere. He sends what he likes, and the UI reflects the new picture to the buyers.
The accept may meet then a modified offer, and be partially met. I don't see a problem with that. If the buyer doesn't like the partially met deal - he can take the loss of the "required fee", and leave the deal unpaid.

As for the betting feature - this is already something else. Setting a bet is like sending the funds to a locked place, until the bet is resolved. I would treat it as a simple send to a third address and this third address sometimes sends back funds later (win), or not (lose).

The only case that things may get more complicated is a reorder to the blockchain, but this doesn't happen too often, and anyways it is a known sickness of mastercoin. We said before that more confirmations are needed when mastercoin are used.

[zathras-crypto]

Agreed, let's wait for JR :)

I realize it's not always easy to articulate opposing viewpoints. Perhaps I can grossly oversimplify by noting a few points:

• Exchange is a complex beast
• Transactions are NOT linear in our exchange, future transactions (eg payments) change the amounts of previous transactions (eg sell offers).
• Option 1 ('Locking') as I see it helps to isolate these complexities to exchange transactions only

I'll say no more :P & will of course attempt to implement whatever is decided.

JR, care to weigh in with a final call?

Thanks! :)

[dacoinminster]

Sorry - I need to figure out how to turn on email notifications for these discussions.

I've read through the discussion, and I'm going to merge this pull request once I figure out how to deal with the conflicts.

[ripper234]

Which version of it?

Ron Gross
Mastercoin Executive Director
mastercoin.org | ripper234.com
Schedule my time at meetme.so/RonGross

On Wed, Nov 13, 2013 at 11:37 PM, dacoinminster notifications@github.comwrote:

Sorry - I need to figure out how to turn on email notifications for these
discussions.

I've read through the discussion, and I'm going to merge this pull request
once I figure out how to deal with the conflicts.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1#issuecomment-28436284
.

[maran]

I mistakingly based this PR of my master branch instead of the branch with the clause in it. I have a new branch ready merged on the latest spec if we decide to move forward with this.

[ripper234]

@maran sorry I'm not following. I must be missing some information, can you rephrase?

[maran]

Oh sorry, that was mostly intended for J.R. He asked me to make the pull request based on the latest version of the spec. I did that but haven't submitted it yet, since I see you still have some questions about it for J.R.

[dacoinminster]

Sure. I believe the pull request described option 1 (if I read it correctly), and I believe that will be the simplest implementation.

Once @maran submits a new pull request, I think we should merge it. If I'm reading the comments above correctly, the devs seem to be in agreement that option 1 is best, and it seems best to me too.

[ripper234]

@dacoinminster are you sure this is the right move? Can you make your own explaination of what you think option1 is better than option 2 besides "the devs think it's best"? Specifically can you reply to my own arguments?

Anyway if it's possible to migrate from option 1 to option 2 easily later, we can start with option 1 and just delay this argument/discussion.

[ghost]

@zathras-crypto and @maran seem to support Option 1; @Bitoy and @grazcoin seem to support Option 2.

The question, as I see it, is whether a simple send will alter the value of an open sell order (Option 2), or whether a send that would do so should simply to be an invalid transaction (Option 1). Both possibilities seem to me to be fair, valid and straightforward, as far as parsing goes. Option 1 is simpler, sure; but Option 2 is more powerful, I think.

Let's not rush to make a decision---let's see if we can achieve consensus.

[dacoinminster]

The problem gets hairier when we have 10 different transaction types that need to have special processing for
when the coins being used for that transaction happen to also be for sale. I just think its way simpler to not allow coins to be used for other things if they are for sale.

I see an opportunity here to avoid a whole slew of weird corner cases and extra testing. Each new feature increases testing complexity already, and if we have an opportunity to make that easier, we should!

[ripper234]

As I just told @dacoinminster in chat:
I think we have to ask professional traders how much they need option 2
type bids.
I have connections to eToro people, I will forward this thread to them and
ask for their opinion.

If you guys know any pro traders, please invite them to comment here as
well.

Ron Gross
Mastercoin Executive Director
mastercoin.org | ripper234.com
Schedule my time at meetme.so/RonGross

On Thu, Nov 14, 2013 at 8:58 PM, dacoinminster notifications@github.comwrote:

The problem gets hairier when we have 10 different transaction types that
need to have special processing for
when the coins being used for that transaction happen to also be for sale.
I just think its way simpler to not allow coins to be used for other things
if they are for sale.

I see an opportunity here to avoid a whole slew of weird corner cases and
extra testing. Each new feature increases testing complexity already, and
if we have an opportunity to make that easier, we should!

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1#issuecomment-28511884
.

[maran]

Asking power users is actually a good idea. 👍

We could always add a different type of exchange message later. Make this the "Simple Selling Offer" and perhaps later make a "Expert Selling Offer" that has more features. It could support things like stop-loss, trailing-stop and the 'always sell' feature you mentioned. I'm not a trader so I wouldn't know what would work exactly but splitting it could help us keep momentum at the moment.

[dacoinminster]

Good point. Let's do the simple selling offer right now, rather than burn too much time in discussion. We can always add a more advanced selling offer later if the market wants it.

[maran]

@ripper234 is that something you could get behind?

[ripper234]

FULL SPEED AHEAD!

:)

Ron Gross
Mastercoin Executive Director
mastercoin.org | ripper234.com
Schedule my time at meetme.so/RonGross

On Thu, Nov 14, 2013 at 11:17 PM, Maran notifications@github.com wrote:

@ripper234 https://github.com/ripper234 is that something you could get
behind?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1#issuecomment-28523703
.

[maran]

We can close this one if everything is ok with it and merge #4 :)