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

I already use p&d first when processing class a transactions.   
However
ecb792bf58c67120d6d62149f542271c33e3df046460aebc2bae1012e5ba52e5
Will not pass p&d level 2 because the data seq is 75 and there is no seq no 74 as recipient address.

This has been going on in my mind as well; I just was afraid of putting it out there. Since we only allow Class A for Simple Sends P&D is actually a really viable way of doing things. When writing my P&D description in the post above I realised that we are doing a lot of extra things.

I think if we take P&D as standard that everything will be a lot easier to parse. I will do some thinking and see if I can formulate a way of parsing Class A so that P&D is the initial thing we try.

I think transaction ecb792bf58c67120d6d62149f542271c33e3df046460aebc2bae1012e5ba52e5 would automatically be solved if we rewrite the spec to always use P&D and go from there.

Hey guys,

Sorry about not getting the update in last night (for those following the thread but not on the dev email list my SSD unfortunately died an early death).  Replaced, restored & back up and running.  Update has just gone in now.

No major feature releases in this update, mainly bugfixes (only visible change of note is Masterchest.info will now display a warning when you're checking your balance if there is a consensus disagreement).  Just a little added protection for the community.

Re address 1LjT88X7Zu8BdbqJw8vfRa83NJuzYL9kqm, that's one I'm going to need to investigate further.  I haven't yet identified a root cause.  Checking my validation output I found two entries for that address.  I checked the balances table and the engine has somehow produced a second row for this address and another address with incorrect balances.  It's that second entry that's being picked up by the consensus check.  There should only ever be one entry for each address in the balances table.  I'm in the process of debugging to hunt down how this could have occurred & squish the bug.

Re transaction ecb792bf58c67120d6d62149f542271c33e3df046460aebc2bae1012e5ba52e5, this is invalid according to spec.  The data address seqnum is 75, the ref address seqnum is 76, and the change address seqnum is 77.  
Change address is 77, +1 of the reference address.  Explicitly invalidated with current wording.  Either that paragraph needs to be rewritten or the transaction should be invalidated by you guys.  At face value it seems too restrictive when we have P&D available so I'm not against (after testing this is the only tx affected by the change) rewording it to something like:

Re transaction c2a904dd47797736617bf5df555f029064de0fc2ff5ba71197638e469caae7f5, good example of whether P&D should be used for anything decodable.  All the outputs are the same AND there are duplicate sequence numbers.  But I do agree P&D code can identify the data & reference addresses successfully.  

I've got to throw it out there - I think largely the unasked question - where is the value in all these rules for Class A at all if P&D could be used in any decodable scenario?  

Essentially P&D requires a valid data packet and a second address with a seqnum +1 that of the data packet for the reference - that's it.  Everything else can be discarded if the rules that relate to them are optional.  I thus see two viable options really:

1) Allow any P&D decodable transaction to validate.  Strip the spec on Class A.  Simplify the ruleset and take out everything related to change, same output values etc.  All that is required for a valid Class A is a P&D decodeable data packet and another single address with data packet seqnum+1 for the reference (plus an output to Exodus of course).
2) Restrict P&D to specific scenarios.  Outline & detail these in the spec via a matrix of valid and invalid cases.
3) Keep the rules as current and allow P&D fallback for any decodable transaction.  This is the case that I see no value to, if P&D can always be used, then the rules are not enforced (and thus effectively pointless).

It may seem crazy at first look given how much effort we've expended on supporting Class A, and I'm not necessarily saying I've thought through 1) in detail, but if the end decision does end up being "P&D can be used for anything decodable" then perhaps it's time to throw out all the excess baggage and make P&D the decoding method rather than a fallback.  Would be interesting to see if that changed state at all.

Oh also FYI Tachikoma, consensus check runs at the end of every blockscan update (5 minutes currently) mate.

Thanks
Zathras

Bitoy, Grazcoin, Zathras; could you all give me your URL's for the test MSC verification API?

I want to prepare for the DEx consensus

Edit: Already mailed it out as well since I want this sooner rather then later.

I think the consensus output needs to be updated; I don't know how frequently this happens.

The site itself is showing the right balance

That is actually my address, I indeed should have the balance of 60~

Any reason why the consensus is showing 10?

Bitoy I also commented these things on the pivotal stories; https://www.pivotaltracker.com/s/projects/976834

Although you are free to repeat them here of course

Zathras,

Please check
ecb77ee990de29745de949462e1f6e44584c310a0da12c9fbdf86dbe6ffabcfc

It is valid under peek and decode level 1.

This should fix address
1Q1sFqsi8S5DxV5hz6sWLamGBp9To93iG7
15a4XCuWmx2cCQVf8wZK7mqdvj5uwo1vby

Hi Zathras

In your site
1LjT88X7Zu8BdbqJw8vfRa83NJuzYL9kqm Has a balance of 60.12630845 MSC
https://masterchest.info/lookupadd.aspx?address=1LjT88X7Zu8BdbqJw8vfRa83NJuzYL9kqm

In the consensus masterchest balance is 10

Hey guys, sorry for the lack of forum posts recently - it's probably easier to continue talking via email for the next couple of weeks while I catch up at work (burdens of management unfortunately, no-one wants to do any work & everything is an escalation over Christmas!).

Anyway, just to let you know a quick update to Masterchest.info is going up tonight.  Will be about a 15 min delay for new transactions later this evening while the engine is upgraded but I'll drop an FYI message on the front page while it's going on.

Thanks

Updated pivotal, thanks

Fixed   Mymastercoins problem with transaction 
192b812c37b9f1e1940b3590b30aef8bf972dce8f4aabc5e908d556e26826506

We are almost there! I've updated the Pivotal tracker with all the transactions that don't match. Please check the labels for your implementations and either tell me why your implementation has the right way or fix it. :}

Ok that is also what I have for transaction.


Peek and decode level 1.

This is what I think we should be doing, and which I will probably add to the spec to make it explicit.

1. Try a normal decode.

• Collect all outputs that have the same value as the Exodus output
• Loop through these outputs and see if you can find a proper sequence number
• If the sequence is found this it the recipient address

If this fails try option 2.

2. Try an exclusion based peek & decode (Peek and Decode - Level 1)

• Collect all outputs that have the same value as the Exodus output
• Remove the data address and the Exodus output.
• If one address remains this is the recipient address.

If this fails try option 3.

3. All output based peek & decode. (Peek and Decode - Level 2)

• Collect all outputs, this includes non-Exodus valued outputs.
• Look for the sequence number
• If the sequence number is found this is the recipient address.

This way we start with the most likely option and widen the net until we have a valid match.

I am a bit behind sleep so let me know if this makes any sense

In my implementation, which should be doing this, it looks like this:

For transaction
ecb77ee990de29745de949462e1f6e44584c310a0da12c9fbdf86dbe6ffabcfc

1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P - (Unspent) 0.0006 BTC
15a4XCuWmx2cCQVf8wZK7mqdvj5uwo1vby - (Spent) 0.0006 BTC
15efTnSCG13druGmetEp1AULCEqudtCSwq - (Unspent) 0.0006 BTC
1Q1sFqsi8S5DxV5hz6sWLamGBp9To93iG7 - (Spent) 0.0119344 BTC

If this goes to peek and decode. Is address 1Q1sFqsi8S5DxV5hz6sWLamGBp9To93iG7 Included?

If it is included there will be 2 possible recipient address which makes the transaction invalid.

Almost there

99.54%

8 Address left to sync =)

https://masterchest.info/consensus.aspx

I see.  He sent 1 msc back to himself.  My implementation sent it to the change address. Will update the codes.

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