Topic: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) - page 9. (Read 129205 times)

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:


Can we agree on this?

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.

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.

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

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.

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.

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

Does your (and the others) implementation allow to include the payment within the accept offer transaction?

* 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 ;-)

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:
agree. price is 0.01.
agree. price is 0.01.
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
The 50 reserved MSC for Alice return to the balance.
A sell offer of the other 50 MSC, each for 0.02 is active.
A sell offer of the other 50 MSC, each for 0.02 is active.

Masterchest currently allows multiple payments as per spec - it's one of the consensus discrepancies between Graz & I.

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

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

From our dev mailing list (in regards to sending multiple bitcoin payments to a sell offer):

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.

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

Zathras,

I check:
https://masterchest.info/lookuptx.aspx?txid=7af41a8ccbfd45f2591386fa3688eae4c15b853776f3f1fce4509c910d46f418
and it says that 0.01792170 TMSC were bought with price of 0.02231931 BTC/TMSC (total 0.0004 BTC)

I don't agree with the price calculation, so I check the sell offer:
https://masterchest.info/lookuptx.aspx?txid=fdebcfcaf4d7bceddd206dc1f334d7c5ccb7a6890c0cfe9d7926be6d7d5e2f58
there are 44.80423511 TMSC available and you note there the same price.

I calculate the price in a different way:
https://masterchain.info/selloffer.html?tx=fdebcfcaf4d7bceddd206dc1f334d7c5ccb7a6890c0cfe9d7926be6d7d5e2f58¤cy=TMSC
The seller originally wanted to sell 1000 TMSC and get 1 BTC - this is 0.001 BTC/TMSC.
He had only less than 50 available at the time of the sell order, so eventually he will get much less than 1 BTC, but for buyers, it is just like other buyers have accepted most of the sell offer and left less than 50 TMSC.

How did you get to your price?

Grazcoin

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.

Hey Graz,

From the spec:

I read that as meaning we should allow multiple payments so that's why you see 0.2 on Masterchest

Thanks
Zathras

First DEx alpha of my wallet is up - https://bitcointalksearch.org/topic/masterchest-wallet-alpha-testing-thread-484025