Hi Zathras,

Sorry, but I couldn't join at that time.
Although I think for protocol beauty reasons, there shouldn't be rules against buying from specific addresses ("self address"), I don't mind adding this rule if it takes us in a smoother way closer to consensus. It doesn't have any affect of balance consensus - only on transaction consensus.
I do insist on the option to send coins to one self - as I think it is important (having in mind a 3rd level protocol on top of mastercoin one day - but I think you support send to self anyway).

So bottom line:
If you see that it makes your life much easier, I'll code the change and request mymastercoin to follow.

Graz/Bitoy,

Closing in on consensus - but I think you guys have a problem in the way you're handling the blocking of simultaneous accepts from the same buyer.

You guys have accept 9ecd7a40eba06ea554fa42dadca1c4c94dc301040d656484a85c45d68d80963a as valid.

However that accept above was in block 289755.  

All the payments for the previous accept took place in block 289755.

As all the payments took place in block 289755 the previous accept is thus closed in block 289755.  A new accept should not be allowed until the next block, 289756 - otherwise we are encouraging new accepts while payments are still unconfirmed (which means we then need to go to checking whether the payments occurred 'earlier in the block' than the new accept etc)

Therefore accept 9ecd7a40eba06ea554fa42dadca1c4c94dc301040d656484a85c45d68d80963a should be invalid as its in the same block as the payments for the previous accept.

Thanks
Zathras

minimal fee enforcement fixed:
https://github.com/grazcoin/mastercoin-tools/commit/cad5aca3e371a6efa11196e2ddbcd694eb49ab3a
example:
https://masterchain.info/sellaccept.html?tx=61d922eb409fcd932798cb519f97ba65de18099c501b324ae86b4658530da92b&currency=TMSC

invalidate concurrent accepts from the same address:
https://github.com/grazcoin/mastercoin-tools/commit/08b46cc77e17b8813d3c5e5c357ffd4f557612c6
example:
https://masterchain.info/sellaccept.html?tx=263b7c420b2456b3f04eea4d92ddf35b95703859173a321c9fdeb71e6c1f5328&currency=TMSC

take care - once an accept offer expires or gets paid, a user can create a new one as there is no "concurrent accept" any more. I wouldn't like to prevent a user from buying at a later stage (e.g. long term sell offers that may run for years should let people buy more than once).
example for a valid accept after the previous is "done" (got fully paid):
https://masterchain.info/sellaccept.html?tx=9ecd7a40eba06ea554fa42dadca1c4c94dc301040d656484a85c45d68d80963a&currency=TMSC

Grazcoin

We had a productive meeting today, and Craig and I were able to make some decisions regarding the last remaining consensus issues:

1) Minimum fees must be respected, as has been in the spec since the beginning. I believe Bitoy and Grazcoin both need to make this change. Without this change, someone can shut down the whole dEX with spam transactions. The fix is simple: if someone tries to accept coins without paying the minimum fee, invalidate that transaction.


2) We're going to have to disable multiple accept offers. This was a harder decision to make, but it boils down to reducing complexity. Also, since graz and bitoy both need to make the minimum fee change, we can't keep the parsing libraries static. This should also be a simple fix: only one accept offer from a buyer to a seller. Additional accept offers are invalid.

3) Zathras is going to have to drop his change to respect packet sequence numbers in class B transactions. We simply can't afford the time, and we believe we can rely on the order of outputs not changing in the transaction, so sequence numbers are probably redundant for class B transactions. If we do packets out-of-sequence someday, we'll have to change the version number of all transaction types.

Sorry that further changes must be made, but we needed to choose a direction and stick with it. Both Craig and I are committed to this direction, and I'll be updating the spec to reflect #2 and #3.

Thanks guys!

 

dexX7 is right.
Example sell offer is:
https://masterchain.info/selloffer.html?tx=ccc6c0ed758c42a950b1f54956d74db0a84783908fe41427a540b1221f5887e5&currency=TMSC
The BIP11 part is:
"script": "1 [ 047992ccb171ca59d39432dc93eba2301188b68ead661dd9fdfe3dda47e2f27ebfff9a0a069d4cb 3851ce19fe5be7ea1b772ee4b678e3bdcc7769713cd675e14c7 ] [ 021bf733f7beb3932563cd8e8a3ec13fb22047f0694a0b6e8a2ad08e63bba57cbb ] [ 026c3fe6ffe4fdf222b80142d95c275753e49587546ef02c40e3e06ee449b27109 ] 3 checkmultisig",
Which is:

Sender's pubKey
Mastercoin data-package #1
Mastercoin data-package #2

note that if you look at the transaction on blockchain.info, the order of pubkeys inside the BIP11 looks opposite:
https://blockchain.info/tx/ccc6c0ed758c42a950b1f54956d74db0a84783908fe41427a540b1221f5887e5

Dexx got me thinking about packet ordering, and as we all know it's the sequence numbers that determine the order.  The order of outputs or keys within multisig outputs is not mandated by the spec, only that we grab all the public keys and order them by sequence number.

So for the first test, a simple send where the multisig still has the correct public keys and sequence number, it's just that the master protocol packet public key is before the senders public key in the multisig instead of the other way around.

MyMastercoins decodes it as an unmatched purchase (http://www.mymastercoins.com/default.aspx?TXID=1ce1e44f40da1f7eddca5f81d72d76a005f8f45b83ee1f9b07ca901f3e6ec235)
Masterchain declares it invalid based on unknown transaction type (5cc2) (https://masterchain.info/simplesend.html?tx=1ce1e44f40da1f7eddca5f81d72d76a005f8f45b83ee1f9b07ca901f3e6ec235&currency=TMSC)
Masterchest (after a bugfix) now decodes it correctly (https://masterchest.info/lookuptx.aspx?txid=1ce1e44f40da1f7eddca5f81d72d76a005f8f45b83ee1f9b07ca901f3e6ec235)

Next up I'm going to simulate a sell offer because it spans multiple packets, with the public key order in the multisig of [sender],[packetseqnum2],[packetseqnum1] which will again be a perfectly valid transaction, but will test each implementations ability to deal with ordering packets properly.

Thanks
Zathras

To be honest perhaps I'm misunderstanding your point, but if a user accepts 100 MSC across these multiple accepts and then fully pays for them within the time limit (including across multiple bitcoin payments) there is no reasonable compromise where the user only receives 70 MSC.

I do understand the complexity argument, but surely if we're talking about multiple accepts we should either do it right or not at all - even if doing it right increases complexity.  As I've mentioned before multiple accepts would be a problem for me - and I see no real prudence to implementing them in the structure described.

If we are to do multiple accepts, surely something like the sum of bitcoin payments within the various timelimits would need to be taken and applied to the accept offers (in blockchain order) incrementally at each respective unit price as each one is fully paid or something along those lines - sorry this is a new concept for me so haven't thought it through thoroughly.  My own view is that if I somehow need to code for multiple accepts, it has to be in a way that if a user accepts X and pays for X within the timelimit, then they receive X.

Thanks
Zathras

I think mymastercoins just didn't reserve funds for the running accept from the older sell offer - only reserved the 0.123 of the new offer.
But it is fixed now, isn't it (or the accept simply expired?)

COMPONENT STORE TRANSACTION DETAILS
   No transaction information is available.

I believe I did try that version yesterday.
Now when I try to download from your link, I somehow download a zip file with zero size from github.

I am not able to download the right file. Can you upload it to Dropbox or something?

I've looked over the consensus posts, and it appears that you guys are quickly converging: Graz is going to allow multiple payments, and then we just have to make sure we all round stuff the same way. Also, we need to determine the unit price from the initial sell order and remember it forever.

Everybody please make sure your code is ready to take a block number for the switchover to allow real MSC trading on 3/15! We'll choose the block number once that day is closer

For spectators, there are currently a LOT of ways to test the distributed exchange with bitcoins and test mastercoins, and WE WILL PAY YOU! Payouts for February are being decided, and we'll have another big payout at the end of March. Please test!

Running setup.exe from within the 2.01 zip, I get this:




After dragging the application files manually to a folder on my desktop, I run it and get this:



Hope that helps!