Bitcoin Forum
April 24, 2014, 05:50:58 AM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
   Home   Help Search Donate Login Register  
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 [40] 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65
  Print  
Author Topic: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread)  (Read 60868 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
Bitoy
Sr. Member
****
Offline Offline

Activity: 336


View Profile

Ignore
January 04, 2014, 02:55:25 PM
 #781

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.
1398318658
Hero Member
*
Offline Offline

Posts: 1398318658

View Profile Personal Message (Offline)

Ignore
1398318658
Reply with quote  #2

1398318658
Report to moderator
1398318658
Hero Member
*
Offline Offline

Posts: 1398318658

View Profile Personal Message (Offline)

Ignore
1398318658
Reply with quote  #2

1398318658
Report to moderator
1398318658
Hero Member
*
Offline Offline

Posts: 1398318658

View Profile Personal Message (Offline)

Ignore
1398318658
Reply with quote  #2

1398318658
Report to moderator
Unbeatable Service & Product Support
Grab Your Miners at GAWMiners.com
Order Before April 25th to receive
Double your Hashing Power for 1 week!

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1398318658
Hero Member
*
Offline Offline

Posts: 1398318658

View Profile Personal Message (Offline)

Ignore
1398318658
Reply with quote  #2

1398318658
Report to moderator
1398318658
Hero Member
*
Offline Offline

Posts: 1398318658

View Profile Personal Message (Offline)

Ignore
1398318658
Reply with quote  #2

1398318658
Report to moderator
1398318658
Hero Member
*
Offline Offline

Posts: 1398318658

View Profile Personal Message (Offline)

Ignore
1398318658
Reply with quote  #2

1398318658
Report to moderator
Tachikoma
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW

Ignore
January 04, 2014, 06:09:09 PM
 #782

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 Smiley

In my implementation, which should be doing this, it looks like this:
Code:
D, [2014-01-04T19:00:21.722073 #41217] DEBUG -- : Found data for address 15efTnSCG13druGmetEp1AULCEqudtCSwq
D, [2014-01-04T19:00:21.722818 #41217] DEBUG -- : Looking for data sequence 51 +1 == 52
D, [2014-01-04T19:00:21.723860 #41217] DEBUG -- : Sequence: 148 for 1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P
D, [2014-01-04T19:00:21.724157 #41217] DEBUG -- : Sequence: 50 for 15a4XCuWmx2cCQVf8wZK7mqdvj5uwo1vby
D, [2014-01-04T19:00:21.724448 #41217] DEBUG -- : Sequence: 51 for 15efTnSCG13druGmetEp1AULCEqudtCSwq
D, [2014-01-04T19:00:21.724496 #41217] DEBUG -- : Target address not found attempting 'peek & decode' Level 1, checking exodus-sized outputs.
D, [2014-01-04T19:00:21.725218 #41217] DEBUG -- : Only one possible target left; found target address.

SimpleSend transaction from 1Q1sFqsi8S5DxV5hz6sWLamGBp9To93iG7 for 5.00000000 Mastercoin to 15a4XCuWmx2cCQVf8wZK7mqdvj5uwo1vby.

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported | Kojn: LTC/BTC Payment processor for merchants
Bitoy
Sr. Member
****
Offline Offline

Activity: 336


View Profile

Ignore
January 05, 2014, 12:51:23 AM
 #783

Ok that is also what I have for transaction.


Peek and decode level 1.

Tachikoma
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW

Ignore
January 05, 2014, 10:13:40 AM
 #784

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. :}

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported | Kojn: LTC/BTC Payment processor for merchants
Bitoy
Sr. Member
****
Offline Offline

Activity: 336


View Profile

Ignore
January 05, 2014, 03:08:38 PM
 #785

Fixed   Mymastercoins problem with transaction  Smiley
192b812c37b9f1e1940b3590b30aef8bf972dce8f4aabc5e908d556e26826506
Tachikoma
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW

Ignore
January 05, 2014, 05:02:52 PM
 #786

Updated pivotal, thanks Smiley

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported | Kojn: LTC/BTC Payment processor for merchants
zathras
Full Member
***
Offline Offline

Activity: 238



View Profile

Ignore
January 06, 2014, 08:14:58 AM
 #787

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 Smiley

Smart Property & Distributed Exchange: Master Protocol for Bitcoin
Bitoy
Sr. Member
****
Offline Offline

Activity: 336


View Profile

Ignore
January 06, 2014, 12:20:33 PM
 #788

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
Bitoy
Sr. Member
****
Offline Offline

Activity: 336


View Profile

Ignore
January 06, 2014, 12:46:18 PM
 #789

Zathras,

Please check
ecb77ee990de29745de949462e1f6e44584c310a0da12c9fbdf86dbe6ffabcfc

It is valid under peek and decode level 1.

This should fix address
1Q1sFqsi8S5DxV5hz6sWLamGBp9To93iG7
15a4XCuWmx2cCQVf8wZK7mqdvj5uwo1vby

Tachikoma
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW

Ignore
January 06, 2014, 12:47:49 PM
 #790

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 Smiley

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported | Kojn: LTC/BTC Payment processor for merchants
aTriz
Sr. Member
****
Offline Offline

Activity: 280



View Profile

Ignore
January 06, 2014, 01:05:00 PM
 #791

Hi Zathras

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

In the consensus the balance is 10

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

Any reason why the consensus is showing 10?

Profit-Switching Optional Auto-Trading Pool -> http://hashco.ws
Hashcows BTC Donations:13QcFh3kRV8G5eAfjom52abcnYnsM6Tw4Q
Tachikoma
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW

Ignore
January 06, 2014, 01:06:50 PM
 #792

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 Smiley

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported | Kojn: LTC/BTC Payment processor for merchants
Tachikoma
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW

Ignore
January 06, 2014, 07:00:35 PM
 #793

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 Smiley

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

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported | Kojn: LTC/BTC Payment processor for merchants
zathras
Full Member
***
Offline Offline

Activity: 238



View Profile

Ignore
January 07, 2014, 09:49:09 AM
 #794

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.  
Quote
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
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:
Quote
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 may be identified by sequence number, which must not equal or be +1 of the sequence number for the data address

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 Smiley
Zathras

Smart Property & Distributed Exchange: Master Protocol for Bitcoin
Tachikoma
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW

Ignore
January 07, 2014, 10:10:41 AM
 #795

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?

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.

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported | Kojn: LTC/BTC Payment processor for merchants
Bitoy
Sr. Member
****
Offline Offline

Activity: 336


View Profile

Ignore
January 07, 2014, 03:18:33 PM
 #796

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?

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.

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.
Tachikoma
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW

Ignore
January 07, 2014, 03:53:04 PM
 #797

Shouldn't the recipient be 76?

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported | Kojn: LTC/BTC Payment processor for merchants
Bitoy
Sr. Member
****
Offline Offline

Activity: 336


View Profile

Ignore
January 08, 2014, 03:21:54 AM
 #798

Shouldn't the recipient be 76?

You are correct 76.  Therefore transaction is valid under p&d level 2. ( class a is draining my brain  Smiley
Bitoy
Sr. Member
****
Offline Offline

Activity: 336


View Profile

Ignore
January 08, 2014, 09:08:22 AM
 #799

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 Smiley

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

For Test MSC
http://mymastercoins.com/jaddress.aspx?CurrencyID=2
Tachikoma
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW

Ignore
January 08, 2014, 05:02:43 PM
 #800

I added an issue with a suggestion for the updated P&D rules specification for the spec to helpfully make it all clear once and for all.

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported | Kojn: LTC/BTC Payment processor for merchants
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 [40] 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!