Topic: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) - page 27. (Read 129207 times)

Mymastercoins is back online.  (Using blockchain.org )

Please check address
14n2uAowcMTmCKMu4k4LZsWude3CttAgQR

Received 1000 msc balance 1000

Sent 1 msc balance 999

Sending  1000 msc.  Should be invalid since he only has 999
e258bca169d90801ba9e3f0536fef04af2f26fd13af045cfb7700ba9cca9c89e

Sent 300 balance 699
3ce917299c9d8b4834df51f640e9715ef8b6201cfd494238a7b2bd17863cc724

If you want to find out more we have a great wiki that we are always working on and trying to improve:

http://wiki.mastercoin.org/index.php/Main_Page

We also have our own forum

https://talk.mastercoin.org/index.php?p=/


Welcome aboard!

I'm really excited about this project and MSC in general... I'm NOT a coder but I am a mathematician; I have interests in multidimensional space and geodesics; I'm really good w/ visualizing and manipulating quadratics, regression, fourier analysis and the like... If I could be of any help I'd love to be involved.   


My biggest disappointment when I got involved w/ crypto was the realization that there was no "distributed exchange". 


I'd also like to buy 4 MSC... whatever is a fair rate from one of you guys that is "involved" I'm really sketched out by the marketplace right now following that shady deal w/ that doge coin guy

Got 4 for   .25 / btc each ?!?


Send PM if one of you has a few hours to chat via IM and get me more in tune w/ the project.


Created a post about MSC today in my new "Litepresence Report on Crypto"

http://www.ronpaulforums.com/showthread.php?437044-The-Litepresence-Report-on-Cryptocurrency&p=5358993&viewfull=1#post5358993



If you guys have any other key links regarding MSC please let me know, I'd like to spread awareness. 



way cool!

keep up the good work.


If you find some free time I have tons of questions... yes I've read the whitepaper  and a good part of this thread.   



litepresence

I think that is what Zathras is doing, I would check out his tools on his Github. Or ask him directly how he manages that.

Blockexplorer.com is stuck at block 277595.  That is where I get data.

  Is there a way to get exodus trans using bitcoind?

Bitoy I see that your implementation has a whole lot of different numbers all of a sudden. Any idea where these differences are coming from?

Hey guys I'm back! Catching up on a lot of stuff just wanted to say this:

I just added support for sending to yourself today. There is no reason to disallow this although it makes no sense.

But also sending mastercoins to oneself is allowed.

Ok if sending to one self is the change then you can remove that address since it is a change address.

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).

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.

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

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

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.

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.

I decode this tx differently:
https://masterchain.info/simplesend.html?tx=c2a904dd47797736617bf5df555f029064de0fc2ff5ba71197638e469caae7f5¤cy=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?

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.

Yes you are right, I made a mistake there


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

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

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.