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

I wan't to test the "MyMastercoins Wallet" features,
anyone can send me few Test MSC?
 
1AN1HQxgSxjz1y3Pe5tVT7zmg1FtqD8pN

Many thanks!

Sender (thanks for clarifying reference = recipient)
195NyMnCNF8GQYN6gKLuf5LsArgoi5NCW7 will be happy he still has 15 msc but someone won't be.  We have to sync ASAP.

I am having some trouble with this transaction. It isn't helping that I haven't fixed my tree validations yet... I will make some time this weekend to catch up!

Sorry to nitpick but for clarity reference address = recipient, not sender

Yep this fits peek & decode without ambiguity I believe (the sequence numbers are way off, but since the change output has a different amount & we ignore Exodus & peek the data address, there is only one address left which has to be the reference)

Peek & decode actually isn't in masterchest.info prod at the mo.  From dev:

Info:


Valid? (0=No, 1=Yes)


The other transaction you mentioned (this is valid on masterchest.info prod) - Valid? (0=No, 1=Yes)


TL:DR;
* Masterchest.info prod doesn't recognize the first transaction as it doesn't support peek & decode and the sequence numbers are bad. 
* Dev does recognize the first transaction via peek & decode and considers it valid.  It does not consider the second transaction you mentioned valid.

Dev is a bit of a mess at the moment (as I'm playing around with multiple outputs trying to break something ) but the peek & decode code will make it into the next engine update.

Tachikoma, are you interpreting all this the same way?

Thanks!

We will likely get swamped with service requests after this contest is completed and wallets become available to the general public, so we need start looking for someone now to address support operations.

Anyone know someone who might be interested in being the Support Lead for Mastercoin?  Who has experience with apps like zendesk, uservoice, atlassian, etc.


Please refer to this proposed RBB:
https://trello.com/c/2yclWbPg

discussion thread is here:
http://talk.mastercoin.org/index.php?p=/discussion/20/support-lead?new=1

Ok! I will check that later

58effd6afc7980392b17ba012943915a9be1db3a6d025969e5d5a197a3e25bc3

Is not in master-explorer and masterchest, and invalid in masterchain .  It's valid in mymastercoins.


I think it is valid because user sent it first.
Balance 215 msc
58effd6afc7980392b17ba012943915a9be1db3a6d025969e5d5a197a3e25bc3,  block. 273217  200 msc

Balance 15
Then sent
4c70f475496beac289e1db74204e0a3501aa920bafe8f618375aa88715e702a1,  block 273231. 215 msc

Which is invalid because he doesn't have enough msc.

Why shouldn't this be a valid transaction? Sorry I think I'm not seeing something.

There are transactions where the change address is the highest value.

Ex.
58effd6afc7980392b17ba012943915a9be1db3a6d025969e5d5a197a3e25bc3

Reference address
195NyMnCNF8GQYN6gKLuf5LsArgoi5NCW7 (0.00056 BTC - Output)

Out
195NyMnCNF8GQYN6gKLuf5LsArgoi5NCW7 - (Spent) 0.00028 BTC
1BaMPFdqMUQ4DLtPtRbfHkEFScBGmyvYA - (Unspent) 0.00006 BTC
1LdgFp2gLvWfkPnyTYAtH7ENnzgBDdNwfd - (Unspent) 0.00006 BTC
1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P - (Unspent) 0.00006 BTC


Should this transaction be valid or invalid? 

The data can be read using peek and decode. 

I'm going to make the code change in Dev, export balances before and after then diff - as long as it's just the address in question (ie doesn't affect any other transactions) then I'll look at doing a pull.  I do want to think this through a little more but from what I've looked at so far I haven't found any showstoppers to allowing multiple change outputs

I have started a thread for the purpose of syncing the different mastercoin implementations:

https://bitcointalksearch.org/topic/m.3882308


This way, we don't pollute the contest thread.

I am swamped at the moment but I will try to do some thinking on the whole multiple change addresses output and try to discover what kind of impact that will have on other transactions. We can't take this lightly, I do want to ask the owners of those addresses to freeze their coins if at all possible.
We should try to see what is the best for the protocol regardless of if somebody already considered this transaction valid, how painful that might be. To be continued.

Edit: I think the reason this worked for me was indeed the peek & decode code. I use it as fallback and it managed to find the correct details for this transaction since the output that are non-change are correct. I believe changing the spec to your suggestion would be safe since it would only allow more flexibility without invalidating current transactions.

Zathras, would you do the honors for the pull request, it was your suggestion after all

Thanks for looking into this.  It is good to get clarification at an early date.  These unusual deviations all need to be cleared up to prevent the chaos which comes without good concordance between systems. 

Will you let me know (post here) when a decision is made?  I don't want to trouble you with inquiries as I am anxious for you to finish the DEx like everyone else.  But, I also don't want this to be dropped without finality.  Anything I need to do?  Thanks again.

Agreed and I'm supportive of peek and decode for anything that isn't a core rule - I know my pedantic nature seems harsh sometimes but I think in the end the community will want us to follow the spec to the letter in our implementations - that's why the spec is evolving so we can change things by consensus if they're too strict

For clarity I'm not necessarily against multiple change outputs, I just haven't done enough investigation to recommend either way at the mo.

I see. In order for the transaction to work

Instead of

An additional output is permitted for the remainder of the input (the 'change' address)

To

Additional outputs are permitted for the remainder of the input (the 'change' address)


Good work on the strict implementation.  However the "peek and decode" gave "class A" a lot of flexibility.  If we are for flexibility then allowing  multiple change output should also be included.

Potentially - peek and decode is there to avoid ambiguity following rules for sequence numbers (eg to prevent users who used MastercoinAdviser to send from having a random chance of a sequence number collision (6 in 255 if change amount = other output amounts)).

Considering the wording, it's open to interpretation I think.  "Following the above rules" was intended to mean the rules covering sequence numbers and outputs being the same (ie the rules under "The following conditions must also be satisfied for the transaction to be considered decode-able:").  

It wasn't intended to cover the general rules (eg stating an output to exodus is required and an output for change is permitted etc) as if we applied that last resort peek & decode statement to all rules then technically even a Mastercoin transaction without an output to Exodus would be valid as long as it could be decoded via peek & decode.

But I do agree it's open to interpretation, so we should agree consensus between us all and I'll submit a pull to remove any ambiguity.

What do you guys think?

Thanks!

EDIT: TL:DR for an abundance of clarity as this won't be clear for those not familiar with the spec.  

Long story short, peek and decode was not intended to allow the rules in the preceding paragraph to be optional.  I do agree for the need for a clarification, whichever way we go however.  Hope this helps make my particular perspective a bit clearer.  

To allow multiple change outputs (still not ready to comment on whether we should allow this) we would either:
     a) Change the wording to state multiple change outputs are allowed as I mentioned a couple of posts back, or
     b) Move the change output statement into the next paragraph where peek & decode is applicable

From the spec, I've highlighted in navy what my intention was with regard to the purple-highlighted text:

The transaction data is encoded into said fake Bitcoin address which is then used as an output in a single Bitcoin transaction satisfying the following requirements:

• Has a single or the largest input signed by the sending address
• Has an output for the recipient address (the 'reference' address)
• Has an output for the exodus address
• Has an output for the encoded fake address (the 'data' address)
• Has all output values equal & above the 'dust' threshold (currently 0.00005430 BTC)
• An additional output is permitted for the remainder of the input (the 'change' address)

The following conditions must also be satisfied for the transaction to be considered decode-able:

• The reference address sequence number must be the data address sequence number + 1
• Ideally, all outputs should be the same (except the change). In fringe cases where the change output value is equal to the other output values the change address can be identified by sequence number, which must not equal or be +/-1 of the sequence number for either the reference address or the data address
• A last resort 'peek and decode' method may be used to identify the data packet in the event of ambiguity following the above rules. This involves decoding each packet and looking for the correct bytes for a simple send (the majority of bytes in a Class A simple send do not change). These byte checks are defined as:
  
  • Bytes two to eight must equal 00
  • Byte nine must equal 01 or 02
• Should there still be packet ambiguity or 'peek and decode' reveals more than one packet (simple sends are always one packet) the transaction is considered invalid.

Isn't the transaction covered by "peek and decode"?

OK transactions:
f0862dda475d17383e7c3c63ad5a015e8dfd77d627ca45ec2e1ba2579c29e0f9
8175fcd0221ee5cda1808f48861bef5c2d5e8b9acf91a7b0fade5768d35f6665

Are not considered Mastercoin transactions by my implementation.

This is because my implementation enforces a literal interpretation of the spec, being that only one additional output is allowed for change in Class A.  Both those transactions are attemping Class A but have two additional change outputs.

Technically speaking I can allow those through, but I'm trying to take myself out of the equation as I really don't think it's right for an individual developer to decide whether someone gets their money or not.  This is why I'm very literal with the spec.

We can perhaps do a pull that changes the spec for Class A to allow multiple change addresses as follows:

to

But before saying yay/nay to that I'd want to do some due diligence to see if that has any other impact I'm not seeing at first glance (ie like all of a sudden validating other past transactions that may previously have been seen as invalid and thus resent etc).

Thanks!

Looking into this now.

No worries  I'm currently working on putting encodedexpayment into the library - it may take a day or two to translate to the library though as I'm currently doing this directly in my wallet - the other library encode functions are a poor base for this (those functions take a shortcut because it's only a tiny fraction of a bitcoin and just look for a single input to cover the fees (to be precise an input >=0.0005) - encodedexpayment is a different beast (hence why I originally did it wallet-side) & needs to handle this differently - ie be capable of putting together multiple inputs to build enough to cover the payment).

Thanks!