|
grazcoin
|
 |
March 06, 2014, 11:01:25 PM |
|
Masterchest currently allows multiple payments as per spec - it's one of the consensus discrepancies between Graz & I.
* The multiple payments feature would require from me a UI change, as I also give links to the payment. UI is something we took very seriously, and it would require repeating the testing for each one of the devices/architectures/browsers/resolutions we support. * This feature is not something that a normal user uses (the payment is anyway from a single address, so why shouldn't the buyer pay the whole amount immediately - if he suddenly wants more, he could accept again). * I mentioned that there can be some complications when multiple accepts are running in parallel. * Disabling this feature for the coming release would not be very difficult if you already implemented the feature. You could use it on the next version. So please leave it aside and save me the work ;-) |
|
|
|
|
|
|
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
dexX7
Legendary
 Offline
Activity: 1106
Merit: 1024
|
|
March 07, 2014, 12:02:14 AM |
|
* This feature is not something that a normal user uses (the payment is anyway from a single address, so why shouldn't the buyer pay the whole amount immediately - if he suddenly wants more, he could accept again). Does your (and the others) implementation allow to include the payment within the accept offer transaction? |
|
|
|
|
zathras
|
|
March 07, 2014, 02:35:27 AM |
|
Masterchest currently allows multiple payments as per spec - it's one of the consensus discrepancies between Graz & I.
* The multiple payments feature would require from me a UI change, as I also give links to the payment. UI is something we took very seriously, and it would require repeating the testing for each one of the devices/architectures/browsers/resolutions we support. * This feature is not something that a normal user uses (the payment is anyway from a single address, so why shouldn't the buyer pay the whole amount immediately - if he suddenly wants more, he could accept again). * I mentioned that there can be some complications when multiple accepts are running in parallel. * Disabling this feature for the coming release would not be very difficult if you already implemented the feature. You could use it on the next version. So please leave it aside and save me the work ;-) It's been this way (multiple payments) since the early days I'm sure? Just to clarify mate are you saying you want to close out the accept as soon as the first payment is received? And if it's under the amount reserved, the remaining reserved get added back to the sell order (even if the accept has not yet expired)? Just want to make sure we're on the same page, then I'll review my code to see how much of a change this is. I'd also like to hear from Bitoy on what he thinks too. Thanks  Zathras |
|
|
|
|
zathras
|
|
March 07, 2014, 02:39:13 AM |
|
* This feature is not something that a normal user uses (the payment is anyway from a single address, so why shouldn't the buyer pay the whole amount immediately - if he suddenly wants more, he could accept again). Does your (and the others) implementation allow to include the payment within the accept offer transaction? Masterchest doesn't allow this - accept offers (buys) sit in a 'pending' state until confirmed in the blockchain. They then hit 'unpaid' and you can then send payment. The protocol specifies bitcoins included with Master Protocol messages (such as the accept for example) are not counted towards any DEx transaction. Other Master Protocol messages (for instance if the buyer wants to change his offer) are not counted towards the actual purchase, even though bitcoins are sent to the selling address as part of encoding the messages.
|
|
|
|
|
Bitoy
|
|
March 07, 2014, 05:34:35 AM |
|
* This feature is not something that a normal user uses (the payment is anyway from a single address, so why shouldn't the buyer pay the whole amount immediately - if he suddenly wants more, he could accept again). Does your (and the others) implementation allow to include the payment within the accept offer transaction? From the spec. Please note that the buyer is allowed to send multiple bitcoin payments between the Purchase Offer and expiration block which are accumulated and used to adjust the Purchase Offer accordingly. Sending multiple payments before the purchase offer expires is allowed in mymastercoins. |
|
|
|
|
|
Bitoy
|
|
March 07, 2014, 05:48:46 AM |
|
For mymastercoins The user initially wanted to sell 1000 tmsc for 1 btc But he only has 44.80423511 system calculates price as 1/44.80423511 = 0.02231931864 per tmsc |
|
|
|
|
|
grazcoin
|
|
March 07, 2014, 09:43:31 AM |
|
* This feature is not something that a normal user uses (the payment is anyway from a single address, so why shouldn't the buyer pay the whole amount immediately - if he suddenly wants more, he could accept again). Does your (and the others) implementation allow to include the payment within the accept offer transaction? No payment within accept offer transaction. The whole idea of separating the payment from the accept is to avoid race conditions where 2 pay for one sell offer and only one gets the coins. |
|
|
|
|
grazcoin
|
|
March 07, 2014, 09:47:42 AM |
|
Masterchest currently allows multiple payments as per spec - it's one of the consensus discrepancies between Graz & I.
* The multiple payments feature would require from me a UI change, as I also give links to the payment. UI is something we took very seriously, and it would require repeating the testing for each one of the devices/architectures/browsers/resolutions we support. * This feature is not something that a normal user uses (the payment is anyway from a single address, so why shouldn't the buyer pay the whole amount immediately - if he suddenly wants more, he could accept again). * I mentioned that there can be some complications when multiple accepts are running in parallel. * Disabling this feature for the coming release would not be very difficult if you already implemented the feature. You could use it on the next version. So please leave it aside and save me the work ;-) It's been this way (multiple payments) since the early days I'm sure? Just to clarify mate are you saying you want to close out the accept as soon as the first payment is received? And if it's under the amount reserved, the remaining reserved get added back to the sell order (even if the accept has not yet expired)? Just want to make sure we're on the same page, then I'll review my code to see how much of a change this is. I'd also like to hear from Bitoy on what he thinks too. Thanks Zathras Well, maybe it would be easier for me to implement it than lobby against it :-) I managed to think of a UI solution for this feature which will not require additional major testing effort and the actual parsing shouldn't be too difficult. So for now - forget my request of disabling the feature. I also have some ideas for edge cases for this feature. I will create them on TMSC once my implementation is done. |
|
|
|
|
grazcoin
|
|
March 07, 2014, 09:53:15 AM |
|
For mymastercoins The user initially wanted to sell 1000 tmsc for 1 btc But he only has 44.80423511 system calculates price as 1/44.80423511 = 0.02231931864 per tmsc I assume the user never thought of a price of 0.02231931864 per tmsc (btw, how many digits are here?) when he entered 1000 tmsc for 1 btc. Also J.R. directed towards the 1/1000 calculation: How hard is it to infer the unit price from the initial post and remember it for the duration of the sell?
What I mean is, literally don't even store the btc desired. Just calculate the unit price from btc desired and msc for sale and store that instead. Is that difficult? I think that is the most intuitive behavior.
Can we agree on this? |
|
|
|
|
Bitoy
|
|
March 07, 2014, 12:23:43 PM |
|
I assume the user never thought of a price of 0.02231931864 per tmsc (btw, how many digits are here?) when he entered 1000 tmsc for 1 btc. Also J.R. directed towards the 1/1000 calculation: How hard is it to infer the unit price from the initial post and remember it for the duration of the sell?
What I mean is, literally don't even store the btc desired. Just calculate the unit price from btc desired and msc for sale and store that instead. Is that difficult? I think that is the most intuitive behavior.
Can we agree on this? Ok let's calculate the price as 1/1000 but the btcdesired must also be adjusted. |
|
|
|
|
|
Bitoy
|
|
March 07, 2014, 01:58:47 PM
Last edit: March 07, 2014, 04:21:14 PM by Bitoy |
|
Updated MyMastercoins parser
Finally consensus in 1BKpa19m5Xy9SvSzC5djPWtCfbuynSDwmb
MM=8.33 1LifmeXYHeUe2qdKWBGVwfbUCMMrwYtoMm MCHAIN=8.23
MM=8.335 1HG3s4Ext3sTqBTHrgftyUzG3cvx5ZbPCj MCHAIN=8.435
MM=39.26343884 1EqTta1Rt8ixAA32DuC29oukbsSWU62qAV MCHAIN=39.26343888
MM=8.335 1HG3s4Ext3sTqBTHrgftyUzG3cvx5ZbPCj MCHEST=8.035
MM=39.26343884 1EqTta1Rt8ixAA32DuC29oukbsSWU62qAV MCHEST=38.8813538
|
|
|
|
|
|
grazcoin
|
|
March 07, 2014, 04:25:48 PM |
|
I assume the user never thought of a price of 0.02231931864 per tmsc (btw, how many digits are here?) when he entered 1000 tmsc for 1 btc. Also J.R. directed towards the 1/1000 calculation: How hard is it to infer the unit price from the initial post and remember it for the duration of the sell?
What I mean is, literally don't even store the btc desired. Just calculate the unit price from btc desired and msc for sale and store that instead. Is that difficult? I think that is the most intuitive behavior.
Can we agree on this? Ok let's calculate the price as 1/1000 but the btcdesired must also be adjusted. Good. No problem to internally calculate the values as you like, but if you show on the user interface the btcdesired value, you should still show the original value, just like the original amount. The sell offer values stay as they were given. |
|
|
|
|
Bitoy
|
|
March 07, 2014, 04:37:12 PM
Last edit: March 07, 2014, 06:48:03 PM by Bitoy |
|
Grazcoin,
2 payments from 1HG3s4Ext3sTqBTHrgftyUzG3cvx5ZbPCj to 1LifmeXYHeUe2qdKWBGVwfbUCMMrwYtoMm from 1 purchase offer
aa799134259de13c1249b2c538d32103eec9d0327f1c82195409a75c6a215180
d09ffc8f6b41176dc5a63f3110574cc42fb9fa8668b696b63b516bc0206001df
This should fix the 2 below
MM=8.33 1LifmeXYHeUe2qdKWBGVwfbUCMMrwYtoMm MCHAIN=8.23
MM=8.335 1HG3s4Ext3sTqBTHrgftyUzG3cvx5ZbPCj MCHAIN=8.435
724fc55b3f65ea1659d537be068cd3012a192e0c027c936b5fd2adc9b8d2f04b
Yours coins bought is .4
Edit
Mine is 0.33333336
Math.Round(BTCPaid * "AmountforSale" / "BTCDesired", 8 )
Math.Round(0.0004 *44.80423511 / 0.04480424 , 8 )
MM=39.26343884 1EqTta1Rt8ixAA32DuC29oukbsSWU62qAV MCHAIN=39.26343888
|
|
|
|
|
dacoinminster (OP)
Legendary
Offline
Activity: 1260
Merit: 1031
Rational Exuberance
|
|
March 07, 2014, 11:57:00 PM |
|
There is also a minimum fee that the seller can impose. This means if someone would like to accept an offer, he has to pay a minimum miners fee. If the seller post a high minimum fee, it will be expensive for the attacker to shut down the Dex.
Gotcha, thanks a lot! My very first thought was that this fee is to make sure the transaction confirms in time, but this makes a lot more sense now. I assume the reason why Bitcoin payments are not combined and included in the accept transaction is to prevent the case that two users buy at the same time and one of them is screwed. And only after balances are locked after the accept offer transaction was confirmed, it's really safe? This kind of dos protection could lead to very interesting mechanics and questions, e.g. "is it more profitable to sell higher and disable competitors or play fair" etc. Here is an idea: from a seller point of view I'm in conflict with my interests, because I want to have a minimum of fee required to have an edge against competitors, but at the same time I don't want to run into the risk of being dos-frozen. What if the dos-fee is sent to the seller instead of the miners and credited/considered as form of advance payment? Hey Dexx, Sorry, I only just noticed your post. I actually thought a long time about who to give the fee to. Giving the fee to the seller presents another attack vector, where the seller attempts to yank their sell order just as someone tries to accept it, and pocket the fee. Also, a seller could post a very attractive offer way below market with a high fee in hopes of getting a ton of fees from different people all at once. The problem gets easier if we do the fees in Mastercoin instead of bitcoin, but requiring a mastercoin fee in order to purchase mastercoin shuts out anybody buying for the first time. All this game theory makes my head hurt! edit: also, paying lots of larger-than-average fees to miners endears us to them, and we want them to like us! |
|
|
|
dexX7
Legendary
Offline
Activity: 1106
Merit: 1024
|
|
March 08, 2014, 12:42:28 AM |
|
Thanks for the response. The more I see, the more impressed I am. It's really well thought through. Being miner friendly is also a very, very good move to combat the argument that Master transactions are "abusing" the chain. where the seller attempts to yank their sell order just as someone tries to accept it, and pocket the fee. Interesting case. I assume block time is used throughout the protocol to ensure all clients are in the same state, so this would create a race condition where the seller cancels and the buyer accepts at the same time. Also, a seller could post a very attractive offer way below market with a high fee in hopes of getting a ton of fees from different people all at once. To avoid race conditions it's not possible to "accept offer and pay" in one transaction, but if it were, I'd transform the "required fee" into something like "required minimum partial payment". From a buyer's perspective running into the risk of a race condition may even be acceptable, if the risk-reward ratio is high enough, e.g. the risk of many buyers at the same time vs. a very appealing price or simply the comfort of a faster transaction (where partial payment = full payment). I guess it's all a trade off, but I agree, such things should be avoided whenever possible. I was wondering about the payment itself. Currently it's simply a transaction with the seller + exodus referenced and no message. I'm trying to figure out, if there is an edge case where I could scam a seller by buying something else and at the same time making the payment for an dex offer? At least related to dex it should be fine, as long as there is only one offer at the same time per seller allowed. |
|
|
|
dacoinminster (OP)
Legendary
Offline
Activity: 1260
Merit: 1031
Rational Exuberance
|
|
March 08, 2014, 01:16:56 AM |
|
I was wondering about the payment itself. Currently it's simply a transaction with the seller + exodus referenced and no message. I'm trying to figure out, if there is an edge case where I could scam a seller by buying something else and at the same time making the payment for an dex offer? At least related to dex it should be fine, as long as there is only one offer at the same time per seller allowed.
Yeah, only one offer per seller is allowed. "Buying something else" at the same time would just be a bitcoin double-spend, which is a problem Satoshi solved for us Thanks! |
|
|
|
dacoinminster (OP)
Legendary
Offline
Activity: 1260
Merit: 1031
Rational Exuberance
|
|
March 08, 2014, 01:30:05 AM |
|
I've looked over the consensus posts, and it appears that you guys are quickly converging: Graz is going to allow multiple payments, and then we just have to make sure we all round stuff the same way. Also, we need to determine the unit price from the initial sell order and remember it forever. Everybody please make sure your code is ready to take a block number for the switchover to allow real MSC trading on 3/15! We'll choose the block number once that day is closer For spectators, there are currently a LOT of ways to test the distributed exchange with bitcoins and test mastercoins, and WE WILL PAY YOU! Payouts for February are being decided, and we'll have another big payout at the end of March. Please test! |
|
|
|
dexX7
Legendary
Offline
Activity: 1106
Merit: 1024
|
|
March 08, 2014, 03:19:46 AM |
|
Speaking of tests. I want to make sure that everyone is aware of the Mastercoin faucet: http://mastercoin-faucet.comIn case you need more Test Mastercoins, send me a message with a note what you like to test. |
|
|
|
|
Bitoy
|
|
March 08, 2014, 05:42:42 AM |
|
Updated MyMastercoins.com
MM=8.33 1LifmeXYHeUe2qdKWBGVwfbUCMMrwYtoMm MCHAIN=8.23
MM=9.7505 1K6JtSvrHtyFmxdtGZyZEF7ydytTGqasNc MCHAIN=9.5005
MM=8.735 1HG3s4Ext3sTqBTHrgftyUzG3cvx5ZbPCj MCHAIN=8.335
MM=39.26343888 1EqTta1Rt8ixAA32DuC29oukbsSWU62qAV MCHAIN=47.38688888
MM=2.23456112 1BKpa19m5Xy9SvSzC5djPWtCfbuynSDwmb MCHAIN=1.11111112
Grazcoin, I thought we are near consensus. What happened to your 1EqTta1Rt8ixAA32DuC29oukbsSWU62qAV?
MM=9.7505 1K6JtSvrHtyFmxdtGZyZEF7ydytTGqasNc MCHEST=9.5005
MM=8.735 1HG3s4Ext3sTqBTHrgftyUzG3cvx5ZbPCj MCHEST=7.935
MM=39.26343888 1EqTta1Rt8ixAA32DuC29oukbsSWU62qAV MCHEST=38.8813538
|
|
|
|
|
|
Bitoy
|
|
March 08, 2014, 05:46:11 AM |
|
I've looked over the consensus posts, and it appears that you guys are quickly converging: Graz is going to allow multiple payments, and then we just have to make sure we all round stuff the same way. Also, we need to determine the unit price from the initial sell order and remember it forever. Everybody please make sure your code is ready to take a block number for the switchover to allow real MSC trading on 3/15! We'll choose the block number once that day is closer For spectators, there are currently a LOT of ways to test the distributed exchange with bitcoins and test mastercoins, and WE WILL PAY YOU! Payouts for February are being decided, and we'll have another big payout at the end of March. Please test! Ok will wait for the block number before sending the new version. |
|
|
|
|
|
