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

masterchain.info is ready:
https://github.com/grazcoin/mastercoin-tools/commit/80e08ca64bf09ab0ba6c6625185e494758be442f

Yes, we have an block number! Only 2 days! Thank you Dacoinminster and others.

And the official changeover block to trade MSC on the distributed exchange is . . .

(drumroll)

290630

History suggests that our target date of 2014-03-15 00:00:00 GMT should fall somewhere between blocks 290607 and 290630. I chose the later number because I want to make sure we get every last ounce of testing we deserve

Ok.  So we are invalidating only "concurrent accept".


Invalid Purchase offer transactions due to minimum miners fee not reached.

b9a870a6c1bc12c954b1b01fbdb86a8f71aa8c31ff77624dd8b58f84ef21bbfb     
b31a720e9b8ede0b6aa0c3b10ed1a7274b257d489f81e11470499281cb0402d7     
61d922eb409fcd932798cb519f97ba65de18099c501b324ae86b4658530da92b     
f6bb04e866fcf7a267f1af5659a7350a87b2c132ee1253757846c5be0b455a42     
8a8c2e7fe253fe8635d34ecc71510955d3a344546410db6961b35cd51809d3ea     
77702fd6333eb5a67fa03b6fdb0fda04981bd671fd2a9175e2bee43340770940

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

invalidate concurrent accepts from the same address:
https://github.com/grazcoin/mastercoin-tools/commit/08b46cc77e17b8813d3c5e5c357ffd4f557612c6
example:
https://masterchain.info/sellaccept.html?tx=263b7c420b2456b3f04eea4d92ddf35b95703859173a321c9fdeb71e6c1f5328¤cy=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¤cy=TMSC

Grazcoin

Is this transaction invalid ?
a7120ed05e1b42f48fec59d0a3b56202d15a0bb8272653f995ac584f16e67c09


What happened is Buyer 1G3P5bws8wRVrVfKWxv8F85pRjs9qXyyA6 placed a
 
Purchase offer 0.002
6ea30cd210ae4521c58d026114f16ef4e63c86d9550de5dba72f588f789aa69c
for Sell Offer
8b2deeb03c2590bbc6698ab3d663eb920e8bb7e89437a7984a54b8d0154d6741


Paid for 0.002

Tried to Purchase again 0.007 from the same Sell Offer
8b2deeb03c2590bbc6698ab3d663eb920e8bb7e89437a7984a54b8d0154d6741

Case 4 and 5 have the first master protocol packet as the second public key, which to date has been an assumed - but will now be a locked in - specification.
Case 6 has the first master protocol packet as the first public key, which moving forward has been agreed will not be valid.

Thanks
Zathras

Awesome, really not much of a change.

Not sure about this:

Case 4 and 5 basically allow to have no input public key included, but case 6 requires one, more or less?

Great, please see inline

Thanks. Yes and I agree, keeping it as simple as possible, would be good.

Okay, I'll try to cover a few cases I found:


1. https://blockchain.info/tx/bda81e0c2117fb6ecefb92143995a6ebc3d9569f54c4a0c074ff3070bcf3e011

Input: compressed public key
Output: compressed input public key, data-package #1, data-package #2

No conflict.


2. https://blockchain.info/tx/95b10a4721a69a1028e70fd2ccd0692219095fb6f5087b9e72b155a3e0832602

Input: uncompressed public key
Output: uncompressed public key, data package #1

Conflict: "Has one or more 1-of-n OP_CHECKMULTISIG outputs each containing at least two compressed public keys, one of which must be the senders address" (has only one compressed public key)


3. https://blockchain.info/tx/f8e2eb56f50f7a98a8c76ef45ed591aedd8aa973c5f4dfd5b7685aae4b48ae6c

Input: uncompressed public key
Output: compressed public key, data package #1

Public key was compressed, but that's no conflict.


4. https://blockchain.info/tx/4842af86dac35a2c294f56511c7d08362330e82bd5fcae32c07119844e019b0a

Input: uncompresssed public key
Output: compressed public key with flawed prefix byte, data package #1

Conflict: "As one signatory must be the sender for redemption purposes, ..."

"Has one or more 1-of-n OP_CHECKMULTISIG outputs each containing at least two compressed public keys, one of which must be the senders address" (not the case, because of a small flaw during the compression [prefix "02" instead of "03"], so this output is neither redeemable nor the sender's address)


5. https://blockchain.info/tx/2ae17011888e9a2e6c752999774cd6d88feb7c0751abe72a602be89858e44f6a

Input: compressed public key
Output: unknown package, data package #1

Conflict: "As one signatory must be the sender for redemption purposes, ..."

"Has one or more 1-of-n OP_CHECKMULTISIG outputs each containing at least two compressed public keys, one of which must be the senders address" (not the case, because the first package has no relation to the input address)


6. https://blockchain.info/tx/1ce1e44f40da1f7eddca5f81d72d76a005f8f45b83ee1f9b07ca901f3e6ec235

Input: uncompressed public key
Output: data package #1, compressed public key

This is an edge case. All data packages are ordered (it's only one) and it includes the sender's address.

Awesome

I think what Dexx is getting it is allowing a sequence of Master Protocol packets anywhere in the multisig outputs, as long as the packets are contiguous.  I'm not sure that's necessary at this stage (I think if we're to lock in packet ordering then let's keep it simple).  Also re 1-of-3, yep I know technically we can go higher but not while maintaining widespread support.  My own view is that we'll see OP_RETURN before better native multisig handling in the reference client, but that's pure speculation of course.

Dexx, I know you posted an analysis a few pages back but could you pick say two or three transactions, post them & a brief summary on why you think they're invalid/contain junk.  Happy to take a look

1. Ok will enforce the req minimum fees require for purchase accept.

2.  I think it should be.   A buyer can place only one purchase offer transaction on any sell offer transaction.

I'm using blockchain

047992ccb171ca59d39432dc93eba2301188b68ead661dd9fdfe3dda47e2f27ebfff9a0a069d4cb 3851ce19fe5be7ea1b772ee4b678e3bdcc7769713cd675e14c7   Senders Public

021bf733f7beb3932563cd8e8a3ec13fb22047f0694a0b6e8a2ad08e63bba57cbb   This is packet 2?

026c3fe6ffe4fdf222b80142d95c275753e49587546ef02c40e3e06ee449b27109  Packet 1


The important thing in the spec is the packets must be in order.

Ex. Valid
Packet 1
Packet 2
Junk
Packet 3

Ex. Invalid.  It can't be jumbled

Packet 1
Packet 3
Junk
Packet 2

I guess I'd like to hear the other devs comment about these packets with "junk" in them which are there already. Can you point a couple of them out?

I'd like to know what logic currently makes them valid. That is what will probably end up in the spec, just to avoid changing anything.

No, I'm not. The order of packages should be required.

I tried to formalize this with something like "use the longest sequence of MSC data-packages within a transaction's output with ascending sequence numbers, starting from 01 and in the case that multiple multisig outputs are available, the same should apply, but starting from last-seq-num + 1", here an example:


This gives some space to cover the transactions that are already out which don't fit exactly in the schema "sender-pubKey, data #1, data #2".

I don't suggest to change anything, but to be very specific about how packages are handled.

dexx, are you suggesting something other than what is described in your github issue? :https://github.com/mastercoin-MSC/spec/issues/78

There you say:


I think that is the current behavior, and the spec just needs a note about it.

Didn't receive the mail you quoted, but including the pubKey shouldn't be required, at least on the spec level, and as you said, it's not validated at the moment anyway. Keep also in mind that the number of n-of-m multisig parts will rise and won't be limited to 3. Actually those are already "accepted", but the standard client refuses to send them.

Hey Dexx,

If it helps, being discussed on email as we speak, packet order is explicit in each multisig, so assuming the first multisig in the transaction was n=2:

Sequence numbers can then be used as a sanity check to double check the packet order is as expected.

Slighthly edited the post with an example which should cover all potential cases without rendering anything invalid, but with as much space for errors as possible.