300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread)

[Bitoy]

Thanks for your results Bitoy (Seriously was your username always Bitoy? I always read it as BitBoy, sorry about that.) they are very helpful.

Did we establish that Mastercoin messages that were send after an Purchase Offer has been opened couldn't be used as funds for such offers?

I don't like discriminating payments based on their possible intend, you are sending somebody funds, so why shouldn't these count? What do you guys think?

It's Bitoy.  (Bitboy sounds good also 

Here is my 2 cents
To keep it simple transactions should not be treated as payment.

consider this example.

1. User A sends a sell offer
2. user B sends a purchase offer to User A
3. User B changes his mind and sends  another purchase offer to User A
 
Will  transaction 3 be considered a payment for  transaction 2?

[Tachikoma]

I would say yes. It's basically free MSC for User B. Why not give it.

[zathras]

Thanks for your results Bitoy (Seriously was your username always Bitoy? I always read it as BitBoy, sorry about that.) they are very helpful.

Did we establish that Mastercoin messages that were send after an Purchase Offer has been opened couldn't be used as funds for such offers?

I don't like discriminating payments based on their possible intend, you are sending somebody funds, so why shouldn't these count? What do you guys think?

Hehe that gave me a chuckle every time I see you post to 'BitBoy' I keep wondering if I should point that out

Actually at the current time I do the same as Bitoy; Bitcoin transactions with an output to Exodus but no Mastercoin data go into an 'unknown' table which I subsequently search for payments.  If it's got Mastercoin data a decodable Mastercoin transaction it's not looked at as a payment.  

The spec doesn't call for payments & Mastercoin transactions in the same Bitcoin transaction, but it doesn't specifically exclude it either so I guess it's another topic we should get consensus on and lock into the spec.

I'm ambivalent on this really, it's not much work to adapt to allow it.  Haven't had time to think about future implications though.

Thanks!

[zathras]

Thanks for your results Bitoy (Seriously was your username always Bitoy? I always read it as BitBoy, sorry about that.) they are very helpful.

Did we establish that Mastercoin messages that were send after an Purchase Offer has been opened couldn't be used as funds for such offers?

I don't like discriminating payments based on their possible intend, you are sending somebody funds, so why shouldn't these count? What do you guys think?

It's Bitoy.  (Bitboy sounds good also  

Here is my 2 cents
To keep it simple transactions should not be treated as payment.

consider this example.

1. User A sends a sell offer
2. user B sends a purchase offer to User A
3. User B changes his mind and sends  another purchase offer to User A
 
Will  transaction 3 be considered a payment for  transaction 2?

I would say yes. It's basically free MSC for User B. Why not give it.

Would this not result in a bunch of unintended 'micro' transactions of 0.00000### MSC?

[Tachikoma]

Thanks for your results Bitoy (Seriously was your username always Bitoy? I always read it as BitBoy, sorry about that.) they are very helpful.

Did we establish that Mastercoin messages that were send after an Purchase Offer has been opened couldn't be used as funds for such offers?

I don't like discriminating payments based on their possible intend, you are sending somebody funds, so why shouldn't these count? What do you guys think?

Hehe that gave me a chuckle every time I see you post to 'BitBoy' I keep wondering if I should point that out

I wish you did, now I feel like an ass :p

Thanks for your results Bitoy (Seriously was your username always Bitoy? I always read it as BitBoy, sorry about that.) they are very helpful.

Did we establish that Mastercoin messages that were send after an Purchase Offer has been opened couldn't be used as funds for such offers?

I don't like discriminating payments based on their possible intend, you are sending somebody funds, so why shouldn't these count? What do you guys think?

It's Bitoy.  (Bitboy sounds good also 

Here is my 2 cents
To keep it simple transactions should not be treated as payment.

consider this example.

1. User A sends a sell offer
2. user B sends a purchase offer to User A
3. User B changes his mind and sends  another purchase offer to User A
 
Will  transaction 3 be considered a payment for  transaction 2?

I would say yes. It's basically free MSC for User B. Why not give it.

Would this not result in a bunch of unintended 'micro' transactions of 0.00000### MSC?

Yes, it already did in my implementation. My implementation of sorting through the money is pretty dumb. That part of the code knows nothing about Mastercoin data or what it looks like. So I can't right now check if it's a possible Mastercoin transaction.

I agree that it's probably cleaner to reject these 'micro transactions' though. Unless somebody can think of a reason to do not do it let's say we don't allow these payments. Grazcoin, if you could chime in that would be great.

[Bitoy]

I would say yes. It's basically free MSC for User B. Why not give it.

It's a side effect (given that its a good one for the buyer).  


But As Zathras pointed out it will create unintented micro transaction bloat.

[dacoinminster]

Guys - this is yet another example of a spec-interpretation issue with more than one right answer. I originally did not intend MSC messages to count as BTC payments for purchases, but if that makes things simpler, then I'm ok with that. However, keep in mind also that we want to keep the user interface simple, and these mini-purchases might confuse people.

As you know, we're working out the details of hiring some of you full-time. Depending on how that works out, one of you will probably be in charge of coordinating these discussions and making decisions when it's not too controversial. I'll get involved on the controversial ones

[Tachikoma]

Guys - this is yet another example of a spec-interpretation issue with more than one right answer. I originally did not intend MSC messages to count as BTC payments for purchases, but if that makes things simpler, then I'm ok with that. However, keep in mind also that we want to keep the user interface simple, and these mini-purchases might confuse people.

As you know, we're working out the details of hiring some of you full-time. Depending on how that works out, one of you will probably be in charge of coordinating these discussions and making decisions when it's not too controversial. I'll get involved on the controversial ones

I'm guessing that's our final vote. Grazcoin I'm going to assume you have no problems with discarding these payments so we can move on!

[grazcoin]

Guys - this is yet another example of a spec-interpretation issue with more than one right answer. I originally did not intend MSC messages to count as BTC payments for purchases, but if that makes things simpler, then I'm ok with that. However, keep in mind also that we want to keep the user interface simple, and these mini-purchases might confuse people.

As you know, we're working out the details of hiring some of you full-time. Depending on how that works out, one of you will probably be in charge of coordinating these discussions and making decisions when it's not too controversial. I'll get involved on the controversial ones

I'm guessing that's our final vote. Grazcoin I'm going to assume you have no problems with discarding these payments so we can move on!

discard. move on.
if a tx has some type (simple send, sell, accept), it is not a payment.

[grazcoin]

Although my validation is not finalized (missing some code in dist exchange, in simple send from exodus, and on perfect sequence), I already export the mastercoin_verify
https://masterchain.info/mastercoin_verify/
where are the others to compare?
I would like to know at least if some part is similar ;-)

[djohnston]

LETS GET THESE GREAT DEVELOPERS FULL TIME ON MASTERCOIN

In my opinion the best way to do this is reliably and predictably vest the Dev MSC generated each month and we would have $312,500 USD in BONUSES, to add to the already great BTC bounties we offer.

If that's split between the current four Devs they would have made $78,125 USD in Dev MSC EACH MONTH the last three months = $234,375 USD and they would have quit their jobs by now. It really is that simple.

Even if we have 12 full time Developers working right now they would still be making $26,041 per month each just in bonuses from Dev MSC!

There would have to be 36 full time developers splitting the Bonus evenly to equal $8,680 USD per month and they would still be better off to work for the BTC and Dev MSC than take a $6,000 per month salary.

I say we unleash our most powerful weapon, thus far left neutered and under used for lack of a specified "Distribution Rate" in the MSC protocol.

I hope you will all vote in this poll going on right now and support the idea of actually using this Dev MSC that sitting there unused right now, for the most important purpose of all. Actually developing Mastercoin features and rewarding those who are doing just that.

https://bitcointalk.org/index.php?topic=348028.0

[zathras]

Quick (well not so quick if you read it!) X-post from rbdrbd's thread just in case any of the other devs who don't use .NET want to see how my library encodes transactions.

Run the result through decoderawtransaction to see what it's doing.

DEVELOPERS ONLY.  THIS IS NOT READY FOR END USERS.  THANKS!

Hey rbdrbd,

Here's the cli wrapper you asked for.  Just provides a binary to expose the library functions for encoding transactions.  Note there is no state or validation here, we're just creating the transaction.  The result can be signed & broadcast if you're happy with the output.

Please use with care, it's completely untested (there could be bad numeric conversions or other bugs for example) so only test against a wallet with fractional amounts

Let me know how you get on with it under Mono.  I'll take a look at putting sqlite support into the engine over the weekend, but for the next few days I really need to hunt down these bugs that are messing up my DEx states.

Thanks!

Built against .NET4.  Pick it up from here.  Note, use the -type=type switch to select between send, sell & accept.

Simple send:
Use the bitcoinrpc switches from the engine and -am (amount) -to (to address) -fr (from address) and -cu (currency type) switches.  For example:

Code:

MasterchestCLI.exe -bitcoinrpcserv=127.0.0.1 -bitcoinrpcport=8332 -bitcoinrpcuser=ooo -bitcoinrpcpass=ooo -type=send -fr=1KUu56RMsafvgwxkiGHmptrLLmBgQ16uQG -to=1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8 -cu=MSC -am=1.234

Sell offer:
Use the bitcoinrpc switches from the engine and -am (sale amount) -fr (from address) -cu (currency type) -of (offer amount) -tl (timelimit) -mf (minfee) switches.  For example:

Code:

-bitcoinrpcserv=127.0.0.1 -bitcoinrpcport=8332 -bitcoinrpcuser=ooo -bitcoinrpcpass=ooo -type=sell -fr=1KUu56RMsafvgwxkiGHmptrLLmBgQ16uQG -cu=MSC -am=1.234 -of=0.5 -tl=6 -mf=0.0001

Accept offer:
Use the bitcoinrpc switches from the engine and -am (purchase amount) -fr (from address) -to (to address) -cu (currency type) switches.  For example:

Code:

-bitcoinrpcserv=127.0.0.1 -bitcoinrpcport=8332 -bitcoinrpcuser=ooo -bitcoinrpcpass=ooo -type=accept -fr=1KUu56RMsafvgwxkiGHmptrLLmBgQ16uQG -to=1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8 -cu=MSC -am=1.234

[vokain]

As soon as my damned laptop will sync the blockchain 100% I will join in on testing!! Wish I could help more on this front in the mean time guys.  Also, can our devs please check the last few posts on the main thread, around the same time as this time stamp? I'd like you to weigh in your thoughts about things very relevant to you.

[Tachikoma]

Although my validation is not finalized (missing some code in dist exchange, in simple send from exodus, and on perfect sequence), I already export the mastercoin_verify
https://masterchain.info/mastercoin_verify/
where are the others to compare?
I would like to know at least if some part is similar ;-)

http://mastercoin-explorer.com/mastercoin_verify/addresses

Mine is there. However at the moment my data is not working properly yet. I still need to find the time to update my distributed exchange code after yesterday's decision.

[Bitoy]

MyMastercoins Wallet

Mymastercoins.com engine to parse the transactions
Allows multiple address in one wallet (You must create an account in bitcoin-qt named MYMSC)
Can be easily expanded for multiple currency


Things to do
Test the multisig sending module of zathras (still waiting for the blockchain to load).
And charting features



http://mymastercoins.com/mmc/mmc2.jpg

http://mymastercoins.com/mmc/mmc3.jpg

http://mymastercoins.com/mmc/mmc4.jpg

http://mymastercoins.com/mmc/mmc5.jpg

http://mymastercoins.com/mmc/mmc6.jpg

[Tachikoma]

Grats on getting that out in the wild!

[Bitoy]

Although my validation is not finalized (missing some code in dist exchange, in simple send from exodus, and on perfect sequence), I already export the mastercoin_verify
https://masterchain.info/mastercoin_verify/
where are the others to compare?
I would like to know at least if some part is similar ;-)

Hi Grazcoin,

Please try
http://www.mymastercoins.com/jaddress.aspx
http://www.mymastercoins.com/jtransactions.aspx?Address=$Addresshere

[Bitoy]

Grats on getting that out in the wild!

I was hoping to get this out next week just so that we can post tramsactions but the blockchain loading is really very slow (50 weeks to go

[zathras]

Grats on getting that out in the wild!

I was hoping to get this out next week just so that we can post tramsactions but the blockchain loading is really very slow (50 weeks to go

Ouch.  Did you not have too much luck running bitcoind over at AWS and making your RPC calls to bitcoind there for your initial testing?  Please don't hesitate to let me know if you need help with this btw, anything to help with development speed

[vokain]

Is there anything I can help with in the meantime while Bitcoin-QT is syncing?