300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread)

[Bitoy]

UserA has a balance of 50 tmsc
UserA sends a offer to sell 30 tmsc
UserB sends a purchase offer 10 tmsc (not yet paid)
UserA changes sell offer to 5 tmsc

What is the maximum tmsc can  UserA simple send to UserC?

35  = 50 - 10 - 5
40  = 50 - 10

[1714951626]

1714951626

[1714951626]

1714951626

[1714951626]

1714951626

[Super T]

UserA has a balance of 50 tmsc
UserA sends a offer to sell 30 tmsc
UserB sends a purchase offer 10 tmsc (not yet paid)
UserA changes sell offer to 5 tmsc

What is the maximum tmsc can  UserA simple send to UserC?

35  = 50 - 10 - 5
40  = 50 - 10

Thinking about this from a users perspective - the answer has to be 40, the protocol needs to ensure that an attempt to reduce liability cannot result in increasing it.

Following on - the protocol would need to ensure that the adjusted offer is recognised reserved based on the initial purchase offer, and as fulfilled once the initial purchase offer is fulfilled.

[StarenseN]

Perhaps it's time to summon the magical being known as J.R. and let him make a decision on whether to p&r transactions that have unequal output amounts.

<aTriz beats on his drums!>....

LoL this become creepy... Come on J.R. you can do it.

[dacoinminster]

Good point, I've been focusing too much on the section below that (where p&d is described).  JR (I assume) changed the wording when merging the appendix and made it:

Ideally, all outputs should be the same (except the change).

The term 'ideally' implies that it's not enforced.  My appendix as submitted didn't have the word 'ideally' in it so I thought I'd forgotten something somewhere and JR had added the term to show that it wasn't an enforceable requirement.

It's all starting to blur together have we had a conversation already about allowing/disallowing based on whether output amounts are the same?

Thanks!

Perhaps it's time to summon the magical being known as J.R. and let him make a decision on whether to p&r transactions that have unequal output amounts.

<begins chanting>...

<aTriz beats on his drums!>....

LoL this become creepy... Come on J.R. you can do it.

You guys are funny.

Sorry, I got way behind on email.

Yeah, I added the word "ideally". I was thinking that if the user is trying to do a Mastercoin transaction, and we can easily decode their intent, we should try to honor what they were trying to do.

HOWEVER, Class B transactions are only ever generated by Mastercoin clients, so it should be no problem to enforce stricter rules for them.

In summary, I think we should allow different amounts for class A, but not class B (or class C). We may need a change to the spec to clarify this.

Now, on to a much more important point: my periods of unavailability should not slow down this project. In the future, I'd like you guys to look to Tachikoma to make the final decision on points of interpretation of the spec (after giving everyone an opportunity to weigh in). If he says "let's ask J.R.", just remind him that J.R. put him in charge.

I will definitely weigh in on big/controversial changes, but this is not one, in my opinion, and we can't have you guys waiting on me! For instance, I will be on vacation and (mostly) offline 12/21 through 1/5, and therefore even LESS responsive than usual (plus it will probably take me a long time to catch up on email even once I am back).

For instance, if Tachikoma disagrees with my opinion above about class A/B/C, you can just go with what he says. The most important thing is that the implementations match, and that you don't have to wait for me.

Lastly, if you do need my attention for something, a direct email tends to get read and processed a lot quicker than forum post email notifications do. My email is: jr (dot) willett (at) gmail (dot) com

Thanks guys. Sorry for the long delay.

[DGulari]

and therefore even LESS responsive than usual...

sorry, not possible.  jk

Pretty funny solution: "Don't wait for me, Tachi calls it".  This is good because it favors progress.  If the decision is horrible, it can probably be retracted in the future, but 'waiting around' is the worse possible plan.  So, after a bit of debate - just pick 'A', or 'B' and move on - all the while JR is in the carribbean smoking a fat blunt on his new found wealth.  I wouldn't want to be bother either if I was sitting on 258 billion dollars - "get back to work Tachikoma!!!"

[Tachikoma]

UserA has a balance of 50 tmsc

A: Balance 50

UserA sends a offer to sell 30 tmsc

A: Balance 20 - Reserved 30

UserB sends a purchase offer 10 tmsc (not yet paid)

A: Balance 20 - Reserved 20 - Reserved for Purchase Offer 10

UserA changes sell offer to 5 tmsc

A: Balance 35 - Reserved 5 - Reserved for Purchase Offer 10

What is the maximum tmsc can  UserA simple send to UserC?

The maximal amount user A can send is 20 tMSC. Once the Purchase Offer expires the amount will be changed to 30.

A lot of stuff J.R. said.

Thanks for the endorsement J.R. I had a very long and intensive day, which is on-going, so I will see what should be decided on the p&d stuff tomorrow

[DGulari]

Thanks for the endorsement J.R. I had a very long and intensive day, which is on-going, so I will see what should be decided on the p&d stuff tomorrow

Hey buddy, I'll send hookers, pizza and cocaine if it will help.  Just get your head right and get back in the fight. 

[Tachikoma]

Ok so I think we should allow p&d for unequal outputs.

I think it's better to support as much Class A transactions as possible and that the risks of perhaps misinterpreting, which might not ever happen, outweighs the amount of transactions that can be valid through p&d.

I will write up a pull request over the weekend that covers all bases to support this so we can have a final ook at it but I think it should be fine.

 

[aTriz]

Can't wait to do some more windows testing, keep up the great work Tachikoma,  zathras, and Bitoy!

Free bump D:

[Bitoy]

UserA has a balance of 50 tmsc

A: Balance 50

UserA sends a offer to sell 30 tmsc

A: Balance 20 - Reserved 30

UserB sends a purchase offer 10 tmsc (not yet paid)

A: Balance 20 - Reserved 20 - Reserved for Purchase Offer 10

UserA changes sell offer to 5 tmsc

A: Balance 35 - Reserved 5 - Reserved for Purchase Offer 10

What is the maximum tmsc can  UserA simple send to UserC?

The maximal amount user A can send is 20 tMSC. Once the Purchase Offer expires the amount will be changed to 30.

The maximum amount  userA can send is 35 (since 5 and 10 are withheld from the 50 balance).  When the purchase offer expires it max is 45.

[Super T]

UserA has a balance of 50 tmsc

A: Balance 50

UserA sends a offer to sell 30 tmsc

A: Balance 20 - Reserved 30

UserB sends a purchase offer 10 tmsc (not yet paid)

A: Balance 20 - Reserved 20 - Reserved for Purchase Offer 10

UserA changes sell offer to 5 tmsc

A: Balance 35 - Reserved 5 - Reserved for Purchase Offer 10

What is the maximum tmsc can  UserA simple send to UserC?

The maximal amount user A can send is 20 tMSC. Once the Purchase Offer expires the amount will be changed to 30.

The maximum amount  userA can send is 35 (since 5 and 10 are withheld from the 50 balance).  When the purchase offer expires it max is 45.

Bitoy - this doesn't seem right to me, it seems like this approach could end up harming users.

To frame this example using slightly different values:

1. UserA has 50 MSC
(Balance 50)

2. UserA lists 30 MSC for sale
(Balance 20 available, 30 reserved)

3. UserB sends purchase offer for all 30 MSC
(Balance 20 available, 30 reserved for purchase offer)

4. UserA changes offer to 20 MSC for sale
(Balance TBC1 available, TBC2 reserved, 30 reserved for purchase offer)

5. UserC sends purchase offer for 20 MSC
(Balance TBC3 available, TBC4 reserved, TBC5 reserved for purchase offer)

So UserA has attempted to reduce the size of a listed offer, this can't be allowed to result in a scenario in which the revised offer is treated as new and unreserved (and could result in all 50 of UserA's coins being sold).

The amount remaining available to UserA should be: Unsold balance - the greater of (all reserved purchases OR the revised offer amount).

So in the example above:

1. UserA has 50 MSC
(Balance 50)

2. UserA lists 30 MSC for sale
(Balance 20 available, 30 reserved)

3. UserB sends purchase offer for all 30 MSC
(Balance 20 available, 30 reserved for purchase offer)

4. UserA changes offer to 20 MSC for sale
(Balance 20 available, 30 reserved, 30 reserved for purchase offer)

5. UserC sends purchase offer for 20 MSC
(Balance 20 available, 30 reserved, 30 reserved for purchase offer)

Now - what if UserA was actually trying to sell the other 20 MSC?  I would expect them to increase the sell offer to 50 (although we still need to be sure this interpreted as an adjustment and not another 50, which is quite possible the same problem in reverse!).

Does this make any sense? Cheers

[Tachikoma]

UserA has a balance of 50 tmsc

A: Balance 50

UserA sends a offer to sell 30 tmsc

A: Balance 20 - Reserved 30

UserB sends a purchase offer 10 tmsc (not yet paid)

A: Balance 20 - Reserved 20 - Reserved for Purchase Offer 10

UserA changes sell offer to 5 tmsc

A: Balance 35 - Reserved 5 - Reserved for Purchase Offer 10

What is the maximum tmsc can  UserA simple send to UserC?

The maximal amount user A can send is 20 tMSC. Once the Purchase Offer expires the amount will be changed to 30.

The maximum amount  userA can send is 35 (since 5 and 10 are withheld from the 50 balance).  When the purchase offer expires it max is 45.

Yes you are right, I made a mistake there

UserA has a balance of 50 tmsc

A: Balance 50

UserA sends a offer to sell 30 tmsc

A: Balance 20 - Reserved 30

UserB sends a purchase offer 10 tmsc (not yet paid)

A: Balance 20 - Reserved 20 - Reserved for Purchase Offer 10

UserA changes sell offer to 5 tmsc

A: Balance 35 - Reserved 5 - Reserved for Purchase Offer 10

What is the maximum tmsc can  UserA simple send to UserC?

The maximal amount user A can send is 20 tMSC. Once the Purchase Offer expires the amount will be changed to 30.

The maximum amount  userA can send is 35 (since 5 and 10 are withheld from the 50 balance).  When the purchase offer expires it max is 45.

Bitoy - this doesn't seem right to me, it seems like this approach could end up harming users.

To frame this example using slightly different values:

1. UserA has 50 MSC
(Balance 50)

2. UserA lists 30 MSC for sale
(Balance 20 available, 30 reserved)

3. UserB sends purchase offer for all 30 MSC
(Balance 20 available, 30 reserved for purchase offer)

4. UserA changes offer to 20 MSC for sale
(Balance TBC1 available, TBC2 reserved, 30 reserved for purchase offer)

5. UserC sends purchase offer for 20 MSC
(Balance TBC3 available, TBC4 reserved, TBC5 reserved for purchase offer)

So UserA has attempted to reduce the size of a listed offer, this can't be allowed to result in a scenario in which the revised offer is treated as new and unreserved (and could result in all 50 of UserA's coins being sold).

The amount remaining available to UserA should be: Unsold balance - the greater of (all reserved purchases OR the revised offer amount).

So in the example above:

1. UserA has 50 MSC
(Balance 50)

2. UserA lists 30 MSC for sale
(Balance 20 available, 30 reserved)

3. UserB sends purchase offer for all 30 MSC
(Balance 20 available, 30 reserved for purchase offer)

4. UserA changes offer to 20 MSC for sale
(Balance 20 available, 30 reserved, 30 reserved for purchase offer)

5. UserC sends purchase offer for 20 MSC
(Balance 20 available, 30 reserved, 30 reserved for purchase offer)

Now - what if UserA was actually trying to sell the other 20 MSC?  I would expect them to increase the sell offer to 50 (although we still need to be sure this interpreted as an adjustment and not another 50, which is quite possible the same problem in reverse!).

Does this make any sense? Cheers

Just like with Bitcoin all sales are final. If you broadcast a Selling Offer for 50 MSC by error while you only wanted to sell 20 MSC you should just broadcast a new offer as soon as possible hoping that you are added to the block first.

That is if I understood you correctly

[Tachikoma]

Developers, I just made a pull request to change some things that should make way for always falling back on p&d. The changes are minimal so please see if I caught everything.

The pull is here.

[grazcoin]

c2a904dd47797736617bf5df555f029064de0fc2ff5ba71197638e469caae7f5
Is a valid Simple Send
Date:   10/14/2013 3:32:16 PM            
Sender:   182osbPxCo88oaSX4ReJwUr9uAcchmJVaL            
Amount Sent:   0.04300000 MSC            
Recipient:   18ArFG8cPDT5P8NVdjFuSGjkybRTW8VBji

I decode this tx differently:
https://masterchain.info/simplesend.html?tx=c2a904dd47797736617bf5df555f029064de0fc2ff5ba71197638e469caae7f5&currency=MSC

It was a tricky tx that I made once manually to check the different implementations.
All the outputs have the same value so it is hard to differ between change and recipient.
Is there a reason to prefer your decoding?

[Bitoy]

c2a904dd47797736617bf5df555f029064de0fc2ff5ba71197638e469caae7f5
Is a valid Simple Send
Date:   10/14/2013 3:32:16 PM            
Sender:   182osbPxCo88oaSX4ReJwUr9uAcchmJVaL            
Amount Sent:   0.04300000 MSC            
Recipient:   18ArFG8cPDT5P8NVdjFuSGjkybRTW8VBji

I decode this tx differently:
https://masterchain.info/simplesend.html?tx=c2a904dd47797736617bf5df555f029064de0fc2ff5ba71197638e469caae7f5&currency=MSC

It was a tricky tx that I made once manually to check the different implementations.
All the outputs have the same value so it is hard to differ between change and recipient.
Is there a reason to prefer your decoding?

The transaction has the following output.
1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P - (Unspent) 0.0000543 BTC
18ArFG8cPDT5P8NVdjFuSGjkybRTW8VBji - (Unspent) 0.0000543 BTC
18292miT6bBoZ4d5PAkjuwyMxktDep3h7h - (Unspent) 0.0000543 BTC
182osbPxCo88oaSX4ReJwUr9uAcchmJVaL - (Unspent) 0.0000543 BTC

Removing the exodus and sender address, only 2 address is left.

18ArFG8cPDT5P8NVdjFuSGjkybRTW8VBji
18292miT6bBoZ4d5PAkjuwyMxktDep3h7h

Using peek and decode, one address is the data (simple send).  The remaining address is the recipient.

[Bitoy]

Bitoy - this doesn't seem right to me, it seems like this approach could end up harming users.

To frame this example using slightly different values:

1. UserA has 50 MSC
(Balance 50)

2. UserA lists 30 MSC for sale
(Balance 20 available, 30 reserved)

3. UserB sends purchase offer for all 30 MSC
(Balance 20 available, 30 reserved for purchase offer)

4. UserA changes offer to 20 MSC for sale
(Balance TBC1 available, TBC2 reserved, 30 reserved for purchase offer)

5. UserC sends purchase offer for 20 MSC
(Balance TBC3 available, TBC4 reserved, TBC5 reserved for purchase offer)

So UserA has attempted to reduce the size of a listed offer, this can't be allowed to result in a scenario in which the revised offer is treated as new and unreserved (and could result in all 50 of UserA's coins being sold).

The amount remaining available to UserA should be: Unsold balance - the greater of (all reserved purchases OR the revised offer amount).

So in the example above:

1. UserA has 50 MSC
(Balance 50)

2. UserA lists 30 MSC for sale
(Balance 20 available, 30 reserved)

3. UserB sends purchase offer for all 30 MSC
(Balance 20 available, 30 reserved for purchase offer)

4. UserA changes offer to 20 MSC for sale
(Balance 20 available, 30 reserved, 30 reserved for purchase offer)

5. UserC sends purchase offer for 20 MSC
(Balance 20 available, 30 reserved, 30 reserved for purchase offer)

Now - what if UserA was actually trying to sell the other 20 MSC?  I would expect them to increase the sell offer to 50 (although we still need to be sure this interpreted as an adjustment and not another 50, which is quite possible the same problem in reverse!).

Does this make any sense? Cheers

You have a point Super T.  What if the seller accidentally entered 50 for sale but only wanted 20.

But by design a seller can only have one sell offer.  He has to immediately send a sale  offer of  20 in order to cancel his 50 (as Tachikoma pointed out) and hopes it gets confirmed first before any purchase offers.

[nmak]

Thanks for the endorsement J.R. I had a very long and intensive day, which is on-going, so I will see what should be decided on the p&d stuff tomorrow

Hey buddy, I'll send hookers, pizza and cocaine if it will help.  Just get your head right and get back in the fight. 

lol I like this guy. Ha ha.
 
Go for it tach, honestly wish I had done programming instead of system support.

[grazcoin]

c2a904dd47797736617bf5df555f029064de0fc2ff5ba71197638e469caae7f5
Is a valid Simple Send
Date:   10/14/2013 3:32:16 PM            
Sender:   182osbPxCo88oaSX4ReJwUr9uAcchmJVaL            
Amount Sent:   0.04300000 MSC            
Recipient:   18ArFG8cPDT5P8NVdjFuSGjkybRTW8VBji

I decode this tx differently:
https://masterchain.info/simplesend.html?tx=c2a904dd47797736617bf5df555f029064de0fc2ff5ba71197638e469caae7f5&currency=MSC

It was a tricky tx that I made once manually to check the different implementations.
All the outputs have the same value so it is hard to differ between change and recipient.
Is there a reason to prefer your decoding?

The transaction has the following output.
1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P - (Unspent) 0.0000543 BTC
18ArFG8cPDT5P8NVdjFuSGjkybRTW8VBji - (Unspent) 0.0000543 BTC
18292miT6bBoZ4d5PAkjuwyMxktDep3h7h - (Unspent) 0.0000543 BTC
182osbPxCo88oaSX4ReJwUr9uAcchmJVaL - (Unspent) 0.0000543 BTC

Removing the exodus and sender address, only 2 address is left.

18ArFG8cPDT5P8NVdjFuSGjkybRTW8VBji
18292miT6bBoZ4d5PAkjuwyMxktDep3h7h

Using peek and decode, one address is the data (simple send).  The remaining address is the recipient.

Why are you removing the sender address from the outputs?
There is nothing mentioning removal of such an address from the outputs of a basic simple send in the spec.
Normally there isn't any sender address among the outputs of basic simple send , e.g. (some other basic simple send):
https://blockchain.info/tx/feb9c1c2f1b274391275a2e92a6007397e087ba5d29ea896098c21d7400cd026
and if there is - it is either the recipient or the change.

Checking the sequence numbers of the outputs:
18292miT6bBoZ4d5PAkjuwyMxktDep3h7h  [77]
182osbPxCo88oaSX4ReJwUr9uAcchmJVaL  [77]
18ArFG8cPDT5P8NVdjFuSGjkybRTW8VBji  [78]

so there is ambiguity in the sequence numbers, and we have to peek.
peek and decode shows that 18292miT6bBoZ4d5PAkjuwyMxktDep3h7h is the data.

But my parsing still says the recipient is 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL

EDIT:
masterchest invalidates this transaction, which is also an option.
You can see that it is not part of the list:
https://masterchest.info/lookupadd.aspx?address=182osbPxCo88oaSX4ReJwUr9uAcchmJVaL

[Bitoy]

Why are you removing the sender address from the outputs?
There is nothing mentioning removal of such an address from the outputs of a basic simple send in the spec.
Normally there isn't any sender address among the outputs of basic simple send , e.g. (some other basic simple send):
https://blockchain.info/tx/feb9c1c2f1b274391275a2e92a6007397e087ba5d29ea896098c21d7400cd026
and if there is - it is either the recipient or the change.

Checking the sequence numbers of the outputs:
18292miT6bBoZ4d5PAkjuwyMxktDep3h7h  [77]
182osbPxCo88oaSX4ReJwUr9uAcchmJVaL  [77]
18ArFG8cPDT5P8NVdjFuSGjkybRTW8VBji  [78]

so there is ambiguity in the sequence numbers, and we have to peek.
peek and decode shows that 18292miT6bBoZ4d5PAkjuwyMxktDep3h7h is the data.

But my parsing still says the recipient is 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL

EDIT:
masterchest invalidates this transaction, which is also an option.
You can see that it is not part of the list:
https://masterchest.info/lookupadd.aspx?address=182osbPxCo88oaSX4ReJwUr9uAcchmJVaL

I removed the sender's address from the output because  its not logical for a sender to send msc to himself.
(If he did then the transaction will be invalid because there will be no recipient address.). 

However your implementation looks correct also because the sequence number of the data is 77 and the so the recipient address should have a sequence of 78. Which is the sender's address.  I think we need to clarify this with Tachikoma.

[grazcoin]

Why are you removing the sender address from the outputs?
There is nothing mentioning removal of such an address from the outputs of a basic simple send in the spec.
Normally there isn't any sender address among the outputs of basic simple send , e.g. (some other basic simple send):
https://blockchain.info/tx/feb9c1c2f1b274391275a2e92a6007397e087ba5d29ea896098c21d7400cd026
and if there is - it is either the recipient or the change.

Checking the sequence numbers of the outputs:
18292miT6bBoZ4d5PAkjuwyMxktDep3h7h  [77]
182osbPxCo88oaSX4ReJwUr9uAcchmJVaL  [77]
18ArFG8cPDT5P8NVdjFuSGjkybRTW8VBji  [78]

so there is ambiguity in the sequence numbers, and we have to peek.
peek and decode shows that 18292miT6bBoZ4d5PAkjuwyMxktDep3h7h is the data.

But my parsing still says the recipient is 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL

EDIT:
masterchest invalidates this transaction, which is also an option.
You can see that it is not part of the list:
https://masterchest.info/lookupadd.aspx?address=182osbPxCo88oaSX4ReJwUr9uAcchmJVaL

I removed the sender's address from the output because  its not logical for a sender to send msc to himself.
(If he did then the transaction will be invalid because there will be no recipient address.).  

However your implementation looks correct also because the sequence number of the data is 77 and the so the recipient address should have a sequence of 78. Which is the sender's address.  I think we need to clarify this with Tachikoma.

I see absolutely no problem with sending coins to oneself.
A restriction on such a send is no where in the spec (and in my opinion - shouldn't be).
Also in bitcoins, one can send to himself.
Even our protocol uses bitcoin's feature of sending to one self (change).