Didn't he sent the MSC to himself? My version things he did and thus after that transaction he still has 1000 MSC.

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?

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

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

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?

A: Balance 50


A: Balance 20 - Reserved 30


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


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


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

Does it work for real mastercoins?

Is there anyway to get test-mastercoins?
Maybe one of the original investors that has no interest in using them is willing to send them? :-)

Hi aTiz,

I tried to buy your 1 tsmc but it failed. I think your transaction fee is too small.  Try changing it to 0.0001.


http://mymastercoins.com/Orders.aspx?CurrencyID=2

For tx a497e4fd11d2223e2129828e44b0d2110b2bb0ec3cb8a0f36bbd28f37a15ceef would that not fall to peek & decode?  I'm reading things as basically seqnums should be correct & outputs should be the same, but if they're not and thus there is packet ambiguity we can then fall back to p&d.  This is why Masterchest thinks it's valid.  Thoughts?

EDIT:  There have been quite a few questions around when p&d is allowed, perhaps that's in need of some clarification in the spec?

Downloaded on Win 7 PC. Requires 4 files for download. Disabled antivirus and firewall that gets in the way. Pretty big files to download. Will update later.