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

Anything that is valid now probably needs to stay valid. We're going to try to keep the current logic and formalize that in the spec.

I plan to add a note in the spec in the section about class B transactions: "Note that current implementations do not allow out-of-order sequence numbers, but rely on the immutability of transaction output ordering instead."

FYI currently none of the implementations validates the first key is redeemable by the sender as that's in no way required for transaction security (that's provided by the input signing) and as I think I mentioned compression can change the apparent address for a given key. Since it serves no purpose in the Master Protocol transaction itself I don't think any of us actually enforce any validation checks here - its only purpose is outside of the Master Protocol transaction and rather on the bitcoin side to redeem the output and recover the 0.00012BTC spent on fees at a later point in time.

Thanks
Zathras

Well, they offer also some further insight in form of "this is indeed a MSC data-package".

How about something like: "use the longest sequence of MSC data-packages within a transaction's output with ascending sequence numbers, starting from 01"? This gives some space to allow junk packages, even if amigiousness exists for the first package. Not that I encourage to include some, but I mention it in light of potentially not-exactly-the-input-pubKeys and unknown packages as listed a few posts earlier. Currently all those transactions are "valid".

Not sure how to handle a sequence that goes over two outputs, but I think the same should apply, but starting from last-seq-num + 1, e.g.:

Output 1:

Pos 0: junk
Pos 1: junk, seq num 01 (appearingly)
Pos 2: junk
Pos 3: Mastercoin data-package, seq num 01
Pos 4: Mastercoin data-package, seq num 02
Pos 5: junk

Longest sequence is pos 3 + pos 4, so take them.

Output 2:

Pos 6: junk
Pos 7: Mastercoin data-package, seq num 03
Pos 8: Mastercoin data-package, seq num 04
Pos 9: Mastercoin data-package, seq num 05

The longest sequence starting with a sequence number of 2 + 1 = 03 starts at pos 7 and ends with pos 9.

So the actual data-stream is within pos 3, 4, 7, 8, 9.

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!

 

I submitted a spec adjustment request: https://github.com/mastercoin-MSC/spec/issues/78

dexX7 is right.
Example sell offer is:
https://masterchain.info/selloffer.html?tx=ccc6c0ed758c42a950b1f54956d74db0a84783908fe41427a540b1221f5887e5¤cy=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

You probably mean:

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

^ this is the order of almost all transactions that were made in the past.


Given that DEX starts in a few days, I tend to agree with Bitoy, should probably locked into the stec temporarily. But solving this should stay high priority, the more packages there are, the less trivial is the solution. With four packages (e.g. the smart property stuff), it's already 24 combinations, with 5 packages it's 120. If a brute force approach is used.

Can we just change the specs ie

For multisig transaction the following order is followed

 first mastercoin packet
Second mastercoin packet (if required)
Senders  public key

Please don't introduce another peak and decode for multisig.

If  mymastercoins can't find a transaction type it will assume it is a payment and try to look for a purchase offer.

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¤cy=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

OK thanks, will check into that

The system does allow multiple transaction accepts - what we're talking about is multiple transaction accepts at the same time, from the same buyer.  That's where the complexity comes from.

I think you need to exchange "02" and "03". Here is some test data:


 

I've always thought that the system allows multiple transaction accepts.

Ex.  
Alice sell offer 100 tmsc for 1 btc
Bob sell offer 50 tmsc for .6 btc
Charles accepts 40  from Alice
Deb accepts 100 from Alice but gets only 60 (bec. Charles got it first )
Deb accepts 40 from Bob (because she wants 100 and got only 60)


So Deb has 2 transaction accepts.  

In grazcoins example it just happens that the buyer accepted 2 transaction from the same sell offer.   But we should treat it as regular multiple accept.

Actually dexx that's a REALLY good point about packet ordering - I've just checked my code and out of order packets would FAIL (ie if key 2 was seqnum 2 and key 3 was seqnum 1).  I'll look at getting a test transaction on the network to probe this further - I think that's an immediate issue.

Also my key compression is as follows:

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

A more accurate calculation would increase the complexity.
I already said that this is not the most common user behaviour, but I don't want to ban users from using multiple accepts.
As long as they pay the exact payment for each accept, everything works well.
If they want to split their payments in a funny way (partial payments and then over payments), they will have to check the exact rules.
That's a reasonable compromise.

Hey zathras,

thanks for the answers.


No objection for compression at all, but I think the "02" and "03" is in the wrong order. At least according to brainwallet.org.


My question is how to deal with those and other non-data-package-and-not-the-input-pubKeys in the future.


Ah, I see. Well, not much a difference. To get the sum you'd need to query the blockchain for each input to determine which one is used as input. But is this really needed on such a deep protocol level? In my opinion keeping things simple and more atomic may be preferred.


Yes, it's used for ordering, but the trouble starts, if you don't know the order before trying to extract the sqeuence numbers. Say you have 4 packages, one of them is your input pubKey, so we can remove that one, the other three are unknown. You may now create three SHA512 hashes of the input pubKey according to the spec and then try to deobfuscate each package with each hash - that's six combinations. If you find a combination which results in a sequence of 01, 02, 03 it would be perfect, but what if one of the pubKeys was actually not a properly and valid encoded data package, but something else? That's why I posted the transactions with unknown or potentially prefix-swapped pubKeys. This could lead to collisions and it's no longer clear, if it's indeed a data-package with sequence number n or simply junk that appeared to result in a conflict. Well, in the later case of compressed pubKeys with swapped prefix it wouldn't be a problem, because the first byte is stripped, but the broader issue remains and I'm trying to see this as general as possible. Maybe I miss something essential the whole time?




That's indeed counterintuitive.

OK great - it's good that you two work the same way, but do you guys not see this as a massive flaw?  User A has accepted 100 MSC and made full payment within the allotted timeframe, yet only receives 70 MSC?

That's exactly like mastercoin-tools works, so we have consensus also on the algorithm.

Also while I have you guys - I'm now enforcing the minimum fee requirements - you both validate this transaction 61d922eb409fcd932798cb519f97ba65de18099c501b324ae86b4658530da92b but it's invalid because the accept offer didn't have sufficient fees (0.00011 vs the required 0.0005).

Good though, as it led me to a bug in my wallet where accepts only sent with fee at 0.00011.

Thanks
Zathras