|
Bitoy
|
 |
March 05, 2014, 09:59:07 AM
Last edit: March 05, 2014, 10:32:53 AM by Bitoy |
|
Everytime you make a payment, the number of coins paid for is deducted from the Accept Offer balance until it is zero.
I was thinking about potential abuse scenarios. Is there anything that could be done for the case that someone with bad intentions submits a lot of accept offers for all available sales, then never pays or only pays a fraction and repeats this over and over again, every time a new sale is created or out of lock state to shutdown/freeze the complete order book? You are correct. It's equivalent to DoS the Distributed exchange. ( DosDex  . That is probably why the time limit must be kept to 10 or below. This means after 10 blocks and payment hasn't been received, it is an open sell offer again. Edit. 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. |
|
|
|
|
dexX7
Legendary
 Offline
Activity: 1106
Merit: 1024
|
|
March 05, 2014, 01:12:59 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? |
|
|
|
|
|
|
Bitoy
|
|
March 06, 2014, 03:02:52 AM |
|
Please check this transaction
e02efd2d3265c13894e05acff8082ad263132787d1a5b65ad22d92c801903ed1
Version 0 Action 3
e541d8ef699cc7bdf30d90ce694f7f0e00b5cf102257b9e94a7067c3fb8593df
Version 0 Action 1
If there is an Action in a Version 0 transaction, it is invalid.
Edit The following tx will also be invalid
cf68983afd0fb6126fd8bc49650831ccd7cbc6d1b257cf9617e5203542e295d2
15595590636afdf807462551fb58655a18419cfdb9a0ad9c866cf00f74108bc5
ab68bf2b0cd7fcd1f5acf03b286d565016335448c68737ba39600968b998cd9e
1b928ff05d0895dda13b691209948ac453c1b8f5bc59f08925814a2fc853116e
8708d411b92bb5741c2219452931a849c2e312906ec51f18e8499dcf9e1377eb
effcb1a90f15b39ef2295d8b1d5b3fa5c4a156936b5cfcb770ca68ac1e7ace0e
b85c843d40ff16a7ef71f233d0f0f8fa7931bbf16532df40149ef1f3533cade3
03597f0bc804ecc355b2c4344cd1526c51209f9e3efa6d62192ec4dd923755e6
|
|
|
|
|
|
Bitoy
|
|
March 06, 2014, 03:12:03 AM |
|
After removing the invalid transaction (reparsed the test server) due to version 0 with action code
MM=1.12345 1BKpa19m5Xy9SvSzC5djPWtCfbuynSDwmb MCHEST=2.23456112
MM=8.335 1HG3s4Ext3sTqBTHrgftyUzG3cvx5ZbPCj MCHEST=8.035
MM=39.99247169 1EqTta1Rt8ixAA32DuC29oukbsSWU62qAV MCHEST=38.8813538
MM=8.8766 1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826 MCHAIN=8.7532
MM=8.43 1LifmeXYHeUe2qdKWBGVwfbUCMMrwYtoMm MCHAIN=8.33
MM=0.082 1G3P5bws8wRVrVfKWxv8F85pRjs9qXyyA6 MCHAIN=0.072
MM=1.12345 1BKpa19m5Xy9SvSzC5djPWtCfbuynSDwmb MCHAIN=4.23456112
MM=8.335 1HG3s4Ext3sTqBTHrgftyUzG3cvx5ZbPCj MCHAIN=9.33499999
MM=39.99247169 1EqTta1Rt8ixAA32DuC29oukbsSWU62qAV MCHAIN=37.38688888
|
|
|
|
|
|
Bitoy
|
|
March 06, 2014, 02:42:34 PM |
|
(Balance ,reserve , available)
(100,0,100)
Sell offer 5 (100,5,95)
Purchase offer 5 (100,5,95)
Partial sold 1 (99,4,95)
Partial sold 1 (98,3,95)
Change sell offer 10 (98,10+3,85)
In the second change sell offer is the seller allowed to sell 10 or only 5. Since he has a purchase offer of 5 already?
Purchase offer expires (98,10,88)
|
|
|
|
|
MattFaus
Newbie
Offline
Activity: 1
Merit: 0
|
|
March 06, 2014, 05:55:28 PM |
|
I would like to contribute to this project, but I'm having trouble getting a development environment setup on Mac OS X 10.9.1 Mavericks. From what I have seen, the two camps are either Linux (omniwallet, which requires installing sx) or Windows (MasterChest, which requires Visual Studio). I spent an hour or so trying to get sx installed with homebrew instead of apt-get, but wanted to check in to see if anyone else is doing this first.
Are any other developers using Mac? If I am the first, would it be worthwhile to sort through all of the issues and write instructions for future Mac-based developers? What mastercoin-related project would be easiest to get setup on my platform?
Thanks for any help you can provide. I'm very excited about working on a distributed exchange platform.
|
|
|
|
|
|
|
dexX7
Legendary
Offline
Activity: 1106
Merit: 1024
|
|
March 06, 2014, 08:42:13 PM |
|
on mine, total of 0.1 was bought.
on yours, total of 0.2 was bought.
That was actually my transaction. This is what happend: - Create sell offer for 1 TMSC, price: 0.001 BTC/TMSC, required fee: 0.0001 BTC, block time: 5
- Send accept offer for 0.5 TMSC (= 0.0005 BTC)
- Send payment of 0.0001 BTC (= 0.1 TMSC)
- Send another payment of 0.0001 BTC (= 0.1 TMSC)
It appears that Masterchain consideres the accept offer as finalized after the first partial payment. However, there was still time left, so the second was legit, if I got everything correct. See also: spec #67 which clarifies the behavior of underpaid transactions. The involved transactions were: https://masterchain.info/selloffer.html?tx=187f48afaf8a1c39ad2332937be5a5d44535af9b9fab22b65a167f29948d145b (sell) https://masterchain.info/sellaccept.html?tx=ce1939bfc5bd83e3e04fb44b1fd287433dde7f39231a3984bf6a859bf56180ba (accept) https://masterchain.info/btcpayment.html?tx=d09ffc8f6b41176dc5a63f3110574cc42fb9fa8668b696b63b516bc0206001df (pay #1) https://masterchain.info/btcpayment.html?tx=aa799134259de13c1249b2c538d32103eec9d0327f1c82195409a75c6a215180 (pay #2) |
|
|
|
|
zathras
|
|
March 06, 2014, 09:09:35 PM |
|
|
|
|
|
|
zathras
|
|
March 06, 2014, 09:11:56 PM |
|
Hey Graz, 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. I read that as meaning we should allow multiple payments so that's why you see 0.2 on Masterchest Thanks Zathras |
|
|
|
|
grazcoin
|
|
March 06, 2014, 09:16:36 PM |
|
Well, having multiple payments for a single accept offer is a nice feature (although I don't really see the reason to use it), but we are on feature freeze for some time now (we were supposed to be in consensus already on 1.3.2014, and this additional feature was discussed and merged on 5.3.2014). Specifically, you could see on https://masterchain.info/sellaccept.html?tx=7af41a8ccbfd45f2591386fa3688eae4c15b853776f3f1fce4509c910d46f418¤cy=TMSC that my user interface assumes one payment for a sell offer, and I do not want to change that a week before we go live, when we still do not have consensus. Please consider unmerging this feature from the spec and postpone this feature to a future version. Also, this nice feature may add some complexity which you don't see on first look, e.g. when 2 (or more) accepts run in parallel: 1. sell offer with 10 blocks payment timeframe and 100 MSC is created. 2. user A accepts 70 MSC at block 290000, and pays for 40 at block 290005, and 30 at block 290006. 3. user B accepts 50 MSC at block 290005. |
|
|
|
|
|
|
zathras
|
|
March 06, 2014, 10:06:39 PM |
|
Ah - the problem with inferring unit price rather than setting it explicitly. I really don't like the way we have to do that. The thing is, the spec says nothing about adjusting the bitcoinsdesired field. It simply says if the amount for sale is above the balance, the amount for sale will be adjusted downwards to equal the balance. It doesn't mention that bitcoinsdesired should be changed so as far as the spec stands now that field should not be modified. So for example: + Alice has a balance of 1000 TMSC + Bob has a balance of 50 TMSC Both put up a sell for 1000 TMSC with 1 BTC bitcoins desired. Alice's sale amount remains unchanged. Bob's sale amount is adjusted downwards to his balance of 50 TMSC. The bitcoins desired fields remain unchanged in both sells. + Alice now has a sell up for 1000 TMSC for 1 BTC + Bob now has a sell up for 50 TMSC for 1 BTC This is horrible behaviour from a user PoV, but it is to spec I think. I actually think there are many more problems with inferring the unit price, especially when it comes to reserved funds. I'll pose another example I'd be really interested to hear from everyone how they think it would be handled from a unit price PoV: + Alice places a sell for amount 100 MSC with bitcoins desired as 1 BTC in block 1 - unit price is inferred at 1MSC/0.01BTC + Bob sends an accept 50 MSC for .5BTC in block 2 - unit price is inferred at 1MSC/0.01BTC. 50 MSC of alice's sell is now reserved. + Alice places an update sell with amount 50 MSC with bitcoins desired as 1 BTC in block 3 - unit price is inferred at 1MSC/0.02BTC + Bob does not pay for his accept and it expires in block 8 What is the sell state in block 9. How many MSC does Alice have for sale and at what unit price? Thanks Zathras |
|
|
|
dacoinminster (OP)
Legendary
Offline
Activity: 1260
Merit: 1031
Rational Exuberance
|
|
March 06, 2014, 10:09:57 PM |
|
Ugh. I apologize for not putting a unit price in the spec. That's awful.
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.
|
|
|
|
dacoinminster (OP)
Legendary
Offline
Activity: 1260
Merit: 1031
Rational Exuberance
|
|
March 06, 2014, 10:16:59 PM |
|
From our dev mailing list (in regards to sending multiple bitcoin payments to a sell offer): This is not a new change as of yesterday. It has been in the spec since 2/10. Here is the history of that in the spec:
on 2/10, this clarification was added: "Please note that all transactions between the Purchase Offer and expiration block should be accumulated and that this value must be used to adjust the Purchase Offer accordingly."
on 2/20, it was clarified to read "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."
The 2/10 change was a result of an email conversation which everyone was included on. (Sorry, I know there is a ton of email).
The change yesterday merely changed other language to more closely match what was already there. It was NOT a feature change.
Now, what graz is proposing here essentially means that as soon as someone sends payment, their reservation expires, and they can't send additional funds. I'm open to making this change if other people prefer it, but it has been in the spec for quite a while, and other implementations are doing what the spec currently says.
Zathras and Alvin, which way do your implementations go with this?
Let's try really hard to not draw this conversation out. Either way will work just fine.
Thanks,
-J.R. Incidentally, I agree with Graz that last-minute spec changes are BAD, which is why I lean towards keeping it as is and treating this as a masterchain bug which just needs to be fixed. However, if Alvin and Zathras say it's trivial to match Graz's code, I'm open to that. |
|
|
|
|
grazcoin
|
|
March 06, 2014, 10:24:19 PM |
|
Ah - the problem with inferring unit price rather than setting it explicitly. I really don't like the way we have to do that. The thing is, the spec says nothing about adjusting the bitcoinsdesired field. It simply says if the amount for sale is above the balance, the amount for sale will be adjusted downwards to equal the balance. It doesn't mention that bitcoinsdesired should be changed so as far as the spec stands now that field should not be modified. So for example: + Alice has a balance of 1000 TMSC + Bob has a balance of 50 TMSC Both put up a sell for 1000 TMSC with 1 BTC bitcoins desired. Alice's sale amount remains unchanged. Bob's sale amount is adjusted downwards to his balance of 50 TMSC. The bitcoins desired fields remain unchanged in both sells. + Alice now has a sell up for 1000 TMSC for 1 BTC + Bob now has a sell up for 50 TMSC for 1 BTC This is horrible behaviour from a user PoV, but it is to spec I think. I actually think there are many more problems with inferring the unit price, especially when it comes to reserved funds. I'll pose another example I'd be really interested to hear from everyone how they think it would be handled from a unit price PoV: + Alice places a sell for amount 100 MSC with bitcoins desired as 1 BTC in block 1 - unit price is inferred at 1MSC/0.01BTC + Bob sends an accept 50 MSC for .5BTC in block 2 - unit price is inferred at 1MSC/0.01BTC. 50 MSC of alice's sell is now reserved. + Alice places an update sell with amount 50 MSC with bitcoins desired as 1 BTC in block 3 - unit price is inferred at 1MSC/0.02BTC + Bob does not pay for his accept and it expires in block 8 What is the sell state in block 9. How many MSC does Alice have for sale and at what unit price? Thanks Zathras Indeed the spec is a little broken here. In order to overcome the lack of a price, my interpretation is that on each sell offer new/update, the price is calculated as (bitcoin amount desired) / (amount declared for sell). It is just a funny way to set the price, but once this is agreed - calculation becomes easier. Grazcoin |
|
|
|
|
zathras
|
|
March 06, 2014, 10:33:53 PM |
|
So we'd essentially be saying that we should infer the unit price before the sell amount is reduced to match available balance. I guess that would be more intuitive behavior. There needs to be something in the spec about it anywhere we're changing values though - so in this case we'd be changing the total bitcoinsdesired too when we state-process the transaction. I'll have a look at modifying my code to take this approach. I'd be really interested to hear everyone's answer to "What is the sell state in block 9. How many MSC does Alice have for sale and at what unit price?" if you have a moment to think about that scenario. Thanks Zathras |
|
|
|
|
zathras
|
|
March 06, 2014, 10:39:26 PM |
|
From our dev mailing list (in regards to sending multiple bitcoin payments to a sell offer): This is not a new change as of yesterday. It has been in the spec since 2/10. Here is the history of that in the spec:
on 2/10, this clarification was added: "Please note that all transactions between the Purchase Offer and expiration block should be accumulated and that this value must be used to adjust the Purchase Offer accordingly."
on 2/20, it was clarified to read "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."
The 2/10 change was a result of an email conversation which everyone was included on. (Sorry, I know there is a ton of email).
The change yesterday merely changed other language to more closely match what was already there. It was NOT a feature change.
Now, what graz is proposing here essentially means that as soon as someone sends payment, their reservation expires, and they can't send additional funds. I'm open to making this change if other people prefer it, but it has been in the spec for quite a while, and other implementations are doing what the spec currently says.
Zathras and Alvin, which way do your implementations go with this?
Let's try really hard to not draw this conversation out. Either way will work just fine.
Thanks,
-J.R. Incidentally, I agree with Graz that last-minute spec changes are BAD, which is why I lean towards keeping it as is and treating this as a masterchain bug which just needs to be fixed. However, if Alvin and Zathras say it's trivial to match Graz's code, I'm open to that. Masterchest currently allows multiple payments as per spec - it's one of the consensus discrepancies between Graz & I. |
|
|
|
|
grazcoin
|
|
March 06, 2014, 10:50:44 PM |
|
So we'd essentially be saying that we should infer the unit price before the sell amount is reduced to match available balance. I guess that would be more intuitive behavior. There needs to be something in the spec about it anywhere we're changing values though - so in this case we'd be changing the total bitcoinsdesired too when we state-process the transaction. I'll have a look at modifying my code to take this approach. I'd be really interested to hear everyone's answer to "What is the sell state in block 9. How many MSC does Alice have for sale and at what unit price?" if you have a moment to think about that scenario. Thanks Zathras I don't see any reason to change the original bitcoin desired or the original amount for sell. They were given by the seller, and we're not there to change his intention. We do have to keep our own accounting, and I do it in "amount available" inside the sell offer (e.g. https://masterchain.info/selloffer.html?tx=fdebcfcaf4d7bceddd206dc1f334d7c5ccb7a6890c0cfe9d7926be6d7d5e2f58¤cy=TMSC), and per address in reserved and open sell values (e.g. https://masterchain.info/Address.html?addr=1BKpa19m5Xy9SvSzC5djPWtCfbuynSDwmb¤cy=TMSC) As for the scenario you described: + Alice places a sell for amount 100 MSC with bitcoins desired as 1 BTC in block 1 - unit price is inferred at 1MSC/0.01BTC
agree. price is 0.01. + Bob sends an accept 50 MSC for .5BTC in block 2 - unit price is inferred at 1MSC/0.01BTC. 50 MSC of alice's sell is now reserved.
agree. price is 0.01. + Alice places an update sell with amount 50 MSC with bitcoins desired as 1 BTC in block 3 - unit price is inferred at 1MSC/0.02BTC
an update is pretty much like cancel and a new offer. there is the hanging accept of 50 MSC of Alice, which may be paid (and then vanish from reserved) or expired (and then move from reserved back to balance). except for this the new price is 0.02 + Bob does not pay for his accept and it expires in block 8
The 50 reserved MSC for Alice return to the balance. A sell offer of the other 50 MSC, each for 0.02 is active. What is the sell state in block 9. How many MSC does Alice have for sale and at what unit price?
A sell offer of the other 50 MSC, each for 0.02 is active. |
|
|
|
|
