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

Can't wait to do some more windows testing, keep up the great work Tachikoma,  zathras, and Bitoy!

Free bump D:

Ok so I think we should allow p&d for unequal outputs.

I think it's better to support as much Class A transactions as possible and that the risks of perhaps misinterpreting, which might not ever happen, outweighs the amount of transactions that can be valid through p&d.

I will write up a pull request over the weekend that covers all bases to support this so we can have a final ook at it but I think it should be fine.

 

Hey buddy, I'll send hookers, pizza and cocaine if it will help.  Just get your head right and get back in the fight. 

Thanks for the endorsement J.R. I had a very long and intensive day, which is on-going, so I will see what should be decided on the p&d stuff tomorrow

sorry, not possible.  jk

Pretty funny solution: "Don't wait for me, Tachi calls it".  This is good because it favors progress.  If the decision is horrible, it can probably be retracted in the future, but 'waiting around' is the worse possible plan.  So, after a bit of debate - just pick 'A', or 'B' and move on - all the while JR is in the carribbean smoking a fat blunt on his new found wealth.  I wouldn't want to be bother either if I was sitting on 258 billion dollars - "get back to work Tachikoma!!!"

You guys are funny.

Sorry, I got way behind on email.

Yeah, I added the word "ideally". I was thinking that if the user is trying to do a Mastercoin transaction, and we can easily decode their intent, we should try to honor what they were trying to do.

HOWEVER, Class B transactions are only ever generated by Mastercoin clients, so it should be no problem to enforce stricter rules for them.

In summary, I think we should allow different amounts for class A, but not class B (or class C). We may need a change to the spec to clarify this.

Now, on to a much more important point: my periods of unavailability should not slow down this project. In the future, I'd like you guys to look to Tachikoma to make the final decision on points of interpretation of the spec (after giving everyone an opportunity to weigh in). If he says "let's ask J.R.", just remind him that J.R. put him in charge.

I will definitely weigh in on big/controversial changes, but this is not one, in my opinion, and we can't have you guys waiting on me! For instance, I will be on vacation and (mostly) offline 12/21 through 1/5, and therefore even LESS responsive than usual (plus it will probably take me a long time to catch up on email even once I am back).

For instance, if Tachikoma disagrees with my opinion above about class A/B/C, you can just go with what he says. The most important thing is that the implementations match, and that you don't have to wait for me.

Lastly, if you do need my attention for something, a direct email tends to get read and processed a lot quicker than forum post email notifications do. My email is: jr (dot) willett (at) gmail (dot) com

Thanks guys. Sorry for the long delay.

LoL this become creepy... Come on J.R. you can do it.

Thinking about this from a users perspective - the answer has to be 40, the protocol needs to ensure that an attempt to reduce liability cannot result in increasing it.

Following on - the protocol would need to ensure that the adjusted offer is recognised reserved based on the initial purchase offer, and as fulfilled once the initial purchase offer is fulfilled.

UserA has a balance of 50 tmsc
UserA sends a offer to sell 30 tmsc
UserB sends a purchase offer 10 tmsc (not yet paid)
UserA changes sell offer to 5 tmsc

What is the maximum tmsc can  UserA simple send to UserC?

35  = 50 - 10 - 5
40  = 50 - 10

....

...

Perhaps it's time to summon the magical being known as J.R. and let him make a decision on whether to p&r transactions that have unequal output amounts.

I'm of the view that we should button everything up as tight as possible so there can be no ambiguity as to how to decode a transaction.  End users are going to be using our respective wallet software soon enough, I'm actually for as smaller 'net' as possible for transaction validity, but I do accept we need to honor transactions sent to date.

I don't think it ever came up before. So let's make a decision on it now

I think my previous arguments still stand. We need to debate whether we want to opt-in for as much valid transactions that might be interpret wrong every once in a while. Or play it safe and require some baseline requirements (same value outputs) to be met in order to reduce the risk of interpreting it wrong.

Tested the following

UserA Post a sell offer 50 tmsc @ .001 each
15f7d532d988e4982ca2d9c5e99ee74810284939604adf772f59a75f7ecd9870


UserB post a purchase offer 1 tmsc @.001  waiting for payment
10c3c04b85b4d44372ce74ca8e25264626f15d5ce426487652d55e61221aa01a

UserA post a new offer 50 tmsc @ 0.1 each
5e7280c2abbbf8323ec0238a551f3da7fbf538c0a47c154b142eee6dbcd5a0aa

UserB pays UserA .0.001
ff9a479866950e7917ee98fd28291a22af9c9b7855228d3fe243fa87660a13ff

Result UserB gets 1 tmsc UserA is deducted 1 tmsc.

Good point, I've been focusing too much on the section below that (where p&d is described).  JR (I assume) changed the wording when merging the appendix and made it:


The term 'ideally' implies that it's not enforced.  My appendix as submitted didn't have the word 'ideally' in it so I thought I'd forgotten something somewhere and JR had added the term to show that it wasn't an enforceable requirement.

It's all starting to blur together have we had a conversation already about allowing/disallowing based on whether output amounts are the same?

Thanks!

We could indeed fall back to peek and decode however right now the spec says:


I have a feeling that allowing p&d on unequal output values might increase the risk of a change address being assigned as recipient address by accident.

I really want to catch human error whenever possible and support as many formats as possible but on the other hand when an error was clearly made it rather have it be invalidated then sent to the wrong address.

Can anybody think of a reason that could sway the argument one way or an other? 

Mymastercoins also see a497e4fd11d2223e2129828e44b0d2110b2bb0ec3cb8a0f36bbd28f37a15ceef as  a valid simple send.  

The way I read is  "if all things failed" use "peek and decode".  

Valid "Peek and decode"
1. A data address is found (after removing the exodus address and the sender address from the list of output address)
2. There is one recipient address

 If there are more than one recipient address,
    1.  Get the data address sequence no.
    2.  Look for an address with a sequence number that is 1 less than the data address sequence no.
    3.  If the address is not found the transaction is invalid.

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?

Thanks guys

Quick couple of modifications to the consensus checker taking into account some feedback, probably most notable is our consensus score.  Collaboratively we need this to hit 100% - round of beers on me when we do!