Hi Mastercoiners,
I would like to devote some of my spare time to help with the Mastercoin project, that is because I want to be part of what it feels for me the right direction for bitcoin.
I presented bitcoin the first time at a local Barcamp in March 2013 and try be an advocate of it since then.
---
My Skills:
* I coded for food for over 15y in Java and am currently in a position of project manager and software architect in a governmental innovation center in Italy.
* I am a Scrum Master and experienced project manager
* I further have a academic background in Economics and Computer Science, and think of myself as a hobby data scientist.
--
I'm interested in the distributed exchange development.
To get in touch write to [email protected]
Topic: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) - page 38. (Read 129207 times)
November 19, 2013, 04:39:09 AM
November 19, 2013, 03:08:33 AM
Haha no I just updated it, we were on at the same time, you didn't miss it 
November 19, 2013, 03:07:56 AM
That's fine as well. I'm just saying that it specified nowhere how Purchase Orders should be paid. I just think the spec should be clear on the fact that you don't have to pay everything in one go. I've added some clarification it in this pull request.
Great
sorry I missed the pull I'll head on over and check it out now. November 19, 2013, 03:05:02 AM
While I'm on I'll also just note that the upload I did for a sneakpeek is not handling exchange transactions properly - I'm working on a fix - also I just want to be super clear about this, the sneakpeek is for the other devs to compare so we can pick up differences, everyone else please DO NOT trust it for any real usage, it's simply not ready yet.
November 19, 2013, 03:03:36 AM
That's fine as well. I'm just saying that it specified nowhere how Purchase Orders should be paid. I just think the spec should be clear on the fact that you don't have to pay everything in one go. I've added some clarification it in this pull request.
November 19, 2013, 02:58:04 AM
That still doesn't answer the main question though.
Should multiple transaction be accumulated and should the sum be used to match the purchase order
or
Should the highest transaction be counted and matched to a purchase order
Should multiple transaction be accumulated and should the sum be used to match the purchase order
or
Should the highest transaction be counted and matched to a purchase order
Can you clarify accumulation?
Currently I look at things like this; say for example User A agrees to buy 5 MSC for 1 BTC. User A then sends 5x 0.2 BTC in separate payments within the time limit. My interpretation would be 5 separate purchases of 1 MSC each. Net result buyer +5 MSC seller +1 BTC.
If you accumulated all those payments into one single payment of 1 BTC, this purchases 5 MSC. Net result buyer +5 MSC seller +1 BTC.
Apologies I might be missing the point here but if the net result is the same, why try to handle accumulation at all?
November 18, 2013, 06:16:24 PM
Developers; I've been thinking about invalidating Purchase Offers which want to buy from a Selling Offer when the Selling Offer is exhausted. Normally you adjust the amount bough to the total amount for sale. But it's not stated what to do when the amount is actually zero. Technically it doesn't matter anyway because both transactions have zero impact on the balance but just to let people know what's going on, and make sure they don't end up paying I would still like to invalidate these type of transactions.
Just an example to make sure everybody understands me.
User A sells 10 MSC
User B buys 8 MSC and gets them
User C buys 2 MSC and gets them
User D sends his request for 5MSC just a little after C and gets added behind him in the block.
Right now user D's transaction would come through but the accepted amount would be 0 MSC. I would propose to invalid this transaction so it's clear this offer is sold out.
+1Just an example to make sure everybody understands me.
User A sells 10 MSC
User B buys 8 MSC and gets them
User C buys 2 MSC and gets them
User D sends his request for 5MSC just a little after C and gets added behind him in the block.
Right now user D's transaction would come through but the accepted amount would be 0 MSC. I would propose to invalid this transaction so it's clear this offer is sold out.
User D's transaction should be invalid.
Hi - i'm a few weeks our of date on progress here, but have just read the last few pages, if there is a quick answer why this is the preferred approach i'd love to hear it, but considering a "late" buy offer as invalid seems a bit non-sensical to me.
Does this suggest orders must be individually matched against counter-party offers? If so, how will support high volume trading scenarios?
I would expect any confirmed order (including an order attempting to fill a currently open offer) to remain valid until filled or cancelled - is there a reason why this model is not appropriate here?
Similarly I would expect an order for more than an offered amount to result in an open order for the outstanding quantity - no?
November 18, 2013, 04:09:21 PM
Good, I was hoping for that answer. I am about to head to bed but will write up a PR in the morning. If somebody disagrees let me know.
November 18, 2013, 04:07:57 PM
That still doesn't answer the main question though.
Should multiple transaction be accumulated and should the sum be used to match the purchase order
or
Should the highest transaction be counted and matched to a purchase order
Should multiple transaction be accumulated and should the sum be used to match the purchase order
or
Should the highest transaction be counted and matched to a purchase order
If we're talking about attempts to reserve MSC for purchase, the latest attempt replaces any earlier ones. I doubt the spec says that explicitly, but it should.
If we're talking about attempts to pay for MSC which has been reserved, then definitely accumulate, otherwise the buyer potentially loses money!
A pull request clarifying all this would be most welcome
November 18, 2013, 03:49:52 PM
That still doesn't answer the main question though.
Should multiple transaction be accumulated and should the sum be used to match the purchase order
or
Should the highest transaction be counted and matched to a purchase order
Should multiple transaction be accumulated and should the sum be used to match the purchase order
or
Should the highest transaction be counted and matched to a purchase order
November 18, 2013, 01:25:09 PM
The pull request looks good, but it does not appear to address the issue of what happens when the user sends a different payment than what they reserved. I think the right thing to do is to honor the payment as a purchase if at all possible.
For instance, if they send less payment before the time limit expires, the amount purchased is adjusted downward appropriately. If they pay MORE than what they reserved and there are still unreserved coins for sale, we adjust the amount purchased upwards, even though they didn't reserve that much. Obviously if another buyer reserves the remaining coins before the over-payment in the block-chain or the seller decides to cancel, the first one recorded in a block wins.
Another example is if the buyer foolishly sends payment without reserving anything at all. I don't think we can count that as a purchase, since it's effectively a bitcoin payment which happens to have an output to the Exodus Address. We can't be certain that they were trying to buy MSC with that payment.
For instance, if they send less payment before the time limit expires, the amount purchased is adjusted downward appropriately. If they pay MORE than what they reserved and there are still unreserved coins for sale, we adjust the amount purchased upwards, even though they didn't reserve that much. Obviously if another buyer reserves the remaining coins before the over-payment in the block-chain or the seller decides to cancel, the first one recorded in a block wins.
Another example is if the buyer foolishly sends payment without reserving anything at all. I don't think we can count that as a purchase, since it's effectively a bitcoin payment which happens to have an output to the Exodus Address. We can't be certain that they were trying to buy MSC with that payment.
November 18, 2013, 07:42:39 AM
Yeah that's one of the other suggestions that I offered. It would make parsing easier but reduce the flexibility of the system.
November 18, 2013, 07:37:13 AM
I've added a PR to group the selling/purchase offer clarifications. Developers, please read through them and see if you agree so far.
Example 1
User A creates a Selling Offer for 10 MSC @ 0.1 a coin with a time limit of 6 in block 20.
User B sends a Purchase Offer to buy 5 MSC in block 22.
User B sends a payment to User A of 0.3 BTC in block 23.
Nothing more happens.
User B Purchase Offer gets adjusted to buy 3 MSC and gets validated.
Example 2
User A creates a Selling Offer for 10 MSC @ 0.1 a coin with a time limit of 6 in block 20.
User B sends a Purchase Offer to buy 5 MSC in block 22.
User B sends a payment to User A of 0.3 BTC in block 23.
User B sends a payment to User A of 0.8 BTC in block 24.
User B paid 0.11BTC in total, enough to completely satisfy his order.
Example 1
User A creates a Selling Offer for 10 MSC @ 0.1 a coin with a time limit of 6 in block 20.
User B sends a Purchase Offer to buy 5 MSC in block 22.
User B sends a payment to User A of 0.3 BTC in block 23.
Nothing more happens.
User B Purchase Offer gets adjusted to buy 3 MSC and gets validated.
Example 2
User A creates a Selling Offer for 10 MSC @ 0.1 a coin with a time limit of 6 in block 20.
User B sends a Purchase Offer to buy 5 MSC in block 22.
User B sends a payment to User A of 0.3 BTC in block 23.
User B sends a payment to User A of 0.8 BTC in block 24.
User B paid 0.11BTC in total, enough to completely satisfy his order.
Another option is the seller has to pay the full btc amount. No partial payment allowed.
Ex.
User A creates a Selling Offer for 10 MSC @ 0.1 a coin with a time limit of 6 in block 20.
User B sends a Purchase Offer to buy 5 MSC in block 22.
User B sends a payment to User A of 0.5 BTC in block 24.
If user B sends a partial payment, it is ignored. System will wait only for the exact amount.
November 18, 2013, 05:13:37 AM
I've added a PR to group the selling/purchase offer clarifications. Developers, please read through them and see if you agree so far.
I also found out I missed a line in the spec that said that the actual purchase offer should be adjusted based on the amount of funds received in the actual payment. I missed this and will need to add it to mastercoin-explorer.
Now how should we deal with this? Should we only count the highest payment to an address? Should we collect all payments send in the timeframe and add them together? Allowing to be paid in parts? Should we change the spec to say we only allow the exact payment amount?
I personally would like to collect all payments received during the block time limit and group them together and then adjust the Purchase Offer according to how many coins were received in total, although the amount can never be more then the Purchase Offer's initial amount.
Example 1
User A creates a Selling Offer for 10 MSC @ 0.1 a coin with a time limit of 6 in block 20.
User B sends a Purchase Offer to buy 5 MSC in block 22.
User B sends a payment to User A of 0.3 BTC in block 23.
Nothing more happens.
User B Purchase Offer gets adjusted to buy 3 MSC and gets validated.
Example 2
User A creates a Selling Offer for 10 MSC @ 0.1 a coin with a time limit of 6 in block 20.
User B sends a Purchase Offer to buy 5 MSC in block 22.
User B sends a payment to User A of 0.3 BTC in block 23.
User B sends a payment to User A of 0.8 BTC in block 24.
User B paid 0.11BTC in total, enough to completely satisfy his order.
I also found out I missed a line in the spec that said that the actual purchase offer should be adjusted based on the amount of funds received in the actual payment. I missed this and will need to add it to mastercoin-explorer.
Now how should we deal with this? Should we only count the highest payment to an address? Should we collect all payments send in the timeframe and add them together? Allowing to be paid in parts? Should we change the spec to say we only allow the exact payment amount?
I personally would like to collect all payments received during the block time limit and group them together and then adjust the Purchase Offer according to how many coins were received in total, although the amount can never be more then the Purchase Offer's initial amount.
Example 1
User A creates a Selling Offer for 10 MSC @ 0.1 a coin with a time limit of 6 in block 20.
User B sends a Purchase Offer to buy 5 MSC in block 22.
User B sends a payment to User A of 0.3 BTC in block 23.
Nothing more happens.
User B Purchase Offer gets adjusted to buy 3 MSC and gets validated.
Example 2
User A creates a Selling Offer for 10 MSC @ 0.1 a coin with a time limit of 6 in block 20.
User B sends a Purchase Offer to buy 5 MSC in block 22.
User B sends a payment to User A of 0.3 BTC in block 23.
User B sends a payment to User A of 0.8 BTC in block 24.
User B paid 0.11BTC in total, enough to completely satisfy his order.
November 18, 2013, 03:17:13 AM
Code:
ac7593ff4fb4a9bc6b053fc12af10e4fc04db73e0fb467d1dbc2466c86c5936b
f67cc2760446b1458c4012bbe7d5f6129badcf4ac6896f82a4de7ec238103216
87018464d016a067e5c8fedc07551c027bd011f43f6d3a02e9a1e252b551ba82
The transactions above are invalid because
No Offer to Sell from Seller 1EAuHj8Z6rTCHPxXfaGzzPsZevC2mg1XAj for Currency "Test MSC"
November 17, 2013, 07:59:54 PM
Code:
select * from transactions_processed where TYPE='purchase'
c7103de53a8ea3a20cec9a74543132f98302f75ab1868092e911dd5516f322a5 16rAwebBXhJAM9ALf3fLFbaHKz24r2o3UN 18xEZx3po1iJWP5H2aM3Do11dCGQyaebnT NULL purchase 1383386099 267480 1 2 35721301 NULL 323200 NULL NULL 20000000 9087a1b72536f3b2909943553ba6d4e320565eeea1e42379dd4337b532f09fd8
baba8972de24528bd56ec4ab3ce5fcead28eb45ac418eb87aace08d3da062a9b 1EAuHj8Z6rTCHPxXfaGzzPsZevC2mg1XAj 1AMfFzbrhhizKDpqebYVYFGaTwdtSt5ux2 NULL purchase 1384704190 270151 1 1 35721741 NULL 2020000 NULL NULL 10100000 35822ef50d1c5639c80ded37b6580396ecc163bdbad34b3865b9e67b7f0787b3
ac7593ff4fb4a9bc6b053fc12af10e4fc04db73e0fb467d1dbc2466c86c5936b 1EAuHj8Z6rTCHPxXfaGzzPsZevC2mg1XAj 1F73UPD5xBKgTSRd8q6QhuncVmDnJAHxYV NULL purchase 1384708399 270160 1 1 35721744 NULL 10000000 NULL NULL 50000000 35822ef50d1c5639c80ded37b6580396ecc163bdbad34b3865b9e67b7f0787b3
f67cc2760446b1458c4012bbe7d5f6129badcf4ac6896f82a4de7ec238103216 1EAuHj8Z6rTCHPxXfaGzzPsZevC2mg1XAj 13tKKPNwDZGKhBK8gAHns7bXe2wtqhvzDb NULL purchase 1384699499 270144 1 2 35721727 NULL 20000 NULL NULL 100000 35822ef50d1c5639c80ded37b6580396ecc163bdbad34b3865b9e67b7f0787b3
87018464d016a067e5c8fedc07551c027bd011f43f6d3a02e9a1e252b551ba82 1EAuHj8Z6rTCHPxXfaGzzPsZevC2mg1XAj 1F73UPD5xBKgTSRd8q6QhuncVmDnJAHxYV NULL purchase 1384699499 270144 1 2 35721728 NULL 2000000 NULL NULL 10000000 35822ef50d1c5639c80ded37b6580396ecc163bdbad34b3865b9e67b7f0787b3
I'm only getting the first 2 as valid. The rest invalid. I'll check my codes.
Thanks - I'll double check my parsing (given how close those payments are together and that they're to the same seller it's certainly possible I've got a bug somewhere counting the same payment in multiple trades).
November 17, 2013, 07:12:52 PM
Code:
select * from transactions_processed where TYPE='purchase'
c7103de53a8ea3a20cec9a74543132f98302f75ab1868092e911dd5516f322a5 16rAwebBXhJAM9ALf3fLFbaHKz24r2o3UN 18xEZx3po1iJWP5H2aM3Do11dCGQyaebnT NULL purchase 1383386099 267480 1 2 35721301 NULL 323200 NULL NULL 20000000 9087a1b72536f3b2909943553ba6d4e320565eeea1e42379dd4337b532f09fd8
baba8972de24528bd56ec4ab3ce5fcead28eb45ac418eb87aace08d3da062a9b 1EAuHj8Z6rTCHPxXfaGzzPsZevC2mg1XAj 1AMfFzbrhhizKDpqebYVYFGaTwdtSt5ux2 NULL purchase 1384704190 270151 1 1 35721741 NULL 2020000 NULL NULL 10100000 35822ef50d1c5639c80ded37b6580396ecc163bdbad34b3865b9e67b7f0787b3
ac7593ff4fb4a9bc6b053fc12af10e4fc04db73e0fb467d1dbc2466c86c5936b 1EAuHj8Z6rTCHPxXfaGzzPsZevC2mg1XAj 1F73UPD5xBKgTSRd8q6QhuncVmDnJAHxYV NULL purchase 1384708399 270160 1 1 35721744 NULL 10000000 NULL NULL 50000000 35822ef50d1c5639c80ded37b6580396ecc163bdbad34b3865b9e67b7f0787b3
f67cc2760446b1458c4012bbe7d5f6129badcf4ac6896f82a4de7ec238103216 1EAuHj8Z6rTCHPxXfaGzzPsZevC2mg1XAj 13tKKPNwDZGKhBK8gAHns7bXe2wtqhvzDb NULL purchase 1384699499 270144 1 2 35721727 NULL 20000 NULL NULL 100000 35822ef50d1c5639c80ded37b6580396ecc163bdbad34b3865b9e67b7f0787b3
87018464d016a067e5c8fedc07551c027bd011f43f6d3a02e9a1e252b551ba82 1EAuHj8Z6rTCHPxXfaGzzPsZevC2mg1XAj 1F73UPD5xBKgTSRd8q6QhuncVmDnJAHxYV NULL purchase 1384699499 270144 1 2 35721728 NULL 2000000 NULL NULL 10000000 35822ef50d1c5639c80ded37b6580396ecc163bdbad34b3865b9e67b7f0787b3
I'm only getting the first 2 as valid. The rest invalid. I'll check my codes.
November 17, 2013, 04:51:41 PM
I modified it and I now get the proper amount. Although if we want to do it totally correct we should round the last digit up so in theory it should be 8932.02250395 instead of 8932.02250394. If we can agree on this I can finally consider vesting to be perfect
My figure for your test scenario is 8932.02250394725, so yep that should indeed be 8932.02250395, not 8932.02250394. I must not have had my Weetbix that morning
Developers; I've been thinking about invalidating Purchase Offers which want to buy from a Selling Offer when the Selling Offer is exhausted. Normally you adjust the amount bough to the total amount for sale. But it's not stated what to do when the amount is actually zero. Technically it doesn't matter anyway because both transactions have zero impact on the balance but just to let people know what's going on, and make sure they don't end up paying I would still like to invalidate these type of transactions.
Just an example to make sure everybody understands me.
User A sells 10 MSC
User B buys 8 MSC and gets them
User C buys 2 MSC and gets them
User D sends his request for 5MSC just a little after C and gets added behind him in the block.
Right now user D's transaction would come through but the accepted amount would be 0 MSC. I would propose to invalid this transaction so it's clear this offer is sold out.
Just an example to make sure everybody understands me.
User A sells 10 MSC
User B buys 8 MSC and gets them
User C buys 2 MSC and gets them
User D sends his request for 5MSC just a little after C and gets added behind him in the block.
Right now user D's transaction would come through but the accepted amount would be 0 MSC. I would propose to invalid this transaction so it's clear this offer is sold out.
In my implementation user D's transaction would be considered invalid. Once the transaction from User C was processed the sell offer from User A would be 'closed' (as fulfilled) thus when we then go to process user D's accept offer it would be unmatched and thus rejected.
Zathras, it seems I am lacking some validations on my end on Purchase Offers that you do have. Could you take a look at this post and tell me why Masterchest rejects that offer?
Edit: I'm guessing this is because there is no selling order to match to? You consider that an invalid transaction? I think this is a good way to go, shall I add this to the spec?
Edit: I'm guessing this is because there is no selling order to match to? You consider that an invalid transaction? I think this is a good way to go, shall I add this to the spec?
If an accept offer is sent to an address without an 'open' sell offer then yep I consider it invalid.
I only recalculate and validate dev mastercoins only if the exodus address sends msc.
IMO we should calculate dev MSC in each block (and this is what Masterchest does). Consumers should be able to check the MSC balance of the Exodus address at any time just like any other.
Confirmed payment for first distributed exchange msc transaction. (I think this is from tachikoma's wallet)
Up until yesterday there was only one complete distributed exchange purchase that was actually valid. There are now five
Code:
select * from transactions_processed where TYPE='purchase'
c7103de53a8ea3a20cec9a74543132f98302f75ab1868092e911dd5516f322a5 16rAwebBXhJAM9ALf3fLFbaHKz24r2o3UN 18xEZx3po1iJWP5H2aM3Do11dCGQyaebnT NULL purchase 1383386099 267480 1 2 35721301 NULL 323200 NULL NULL 20000000 9087a1b72536f3b2909943553ba6d4e320565eeea1e42379dd4337b532f09fd8
baba8972de24528bd56ec4ab3ce5fcead28eb45ac418eb87aace08d3da062a9b 1EAuHj8Z6rTCHPxXfaGzzPsZevC2mg1XAj 1AMfFzbrhhizKDpqebYVYFGaTwdtSt5ux2 NULL purchase 1384704190 270151 1 1 35721741 NULL 2020000 NULL NULL 10100000 35822ef50d1c5639c80ded37b6580396ecc163bdbad34b3865b9e67b7f0787b3
ac7593ff4fb4a9bc6b053fc12af10e4fc04db73e0fb467d1dbc2466c86c5936b 1EAuHj8Z6rTCHPxXfaGzzPsZevC2mg1XAj 1F73UPD5xBKgTSRd8q6QhuncVmDnJAHxYV NULL purchase 1384708399 270160 1 1 35721744 NULL 10000000 NULL NULL 50000000 35822ef50d1c5639c80ded37b6580396ecc163bdbad34b3865b9e67b7f0787b3
f67cc2760446b1458c4012bbe7d5f6129badcf4ac6896f82a4de7ec238103216 1EAuHj8Z6rTCHPxXfaGzzPsZevC2mg1XAj 13tKKPNwDZGKhBK8gAHns7bXe2wtqhvzDb NULL purchase 1384699499 270144 1 2 35721727 NULL 20000 NULL NULL 100000 35822ef50d1c5639c80ded37b6580396ecc163bdbad34b3865b9e67b7f0787b3
87018464d016a067e5c8fedc07551c027bd011f43f6d3a02e9a1e252b551ba82 1EAuHj8Z6rTCHPxXfaGzzPsZevC2mg1XAj 1F73UPD5xBKgTSRd8q6QhuncVmDnJAHxYV NULL purchase 1384699499 270144 1 2 35721728 NULL 2000000 NULL NULL 10000000 35822ef50d1c5639c80ded37b6580396ecc163bdbad34b3865b9e67b7f0787b3
I currently test by simulating blockchain transactions (as I just drop dummy transactions into my transaction list), but I might start pushing some of mine actually out onto the blockchain since it looks like we're all starting to converge in terms of implementation compatibility
Thanks!
November 17, 2013, 10:43:59 AM
Confirmed payment for first distributed exchange msc transaction. (I think this is from tachikoma's wallet
http://mymastercoins.com/Orders.aspx?CurrencyID=1
Buying MSC
Waiting for Payment Payment Confirmed Expired
Date Amount to Purchase Purchased Unit Price Total BTC Transfer Fee Tx ID CFS ID Buyer ID Seller ID Max Block Time Confirm TxID
11/17/2013 4:03:10 PM .101 .101 .2 .0202 .001 3919 162 9046 9044 270161 Payment Confirmed 3921
http://mymastercoins.com/Orders.aspx?CurrencyID=1
Buying MSC
Waiting for Payment Payment Confirmed Expired
Date Amount to Purchase Purchased Unit Price Total BTC Transfer Fee Tx ID CFS ID Buyer ID Seller ID Max Block Time Confirm TxID
11/17/2013 4:03:10 PM .101 .101 .2 .0202 .001 3919 162 9046 9044 270161 Payment Confirmed 3921
November 17, 2013, 10:36:03 AM
Edit: I'm guessing this is because there is no selling order to match to? You consider that an invalid transaction? I think this is a good way to go, shall I add this to the spec?
Same here. No selling order to match the transaction, it is invalid.
Jump to: