short order didn't match now

[vikram]

Is this bug somehow related to the slow synchronization for the last few days? I see a lot of fake transactions in my wallet, which kept occurring until i canceled short order

Synchronization in general has become a lot slower from increased market activity.

The fake transactions in your wallet are mostly likely due to this bug; the next release will prevent such fake transactions from occurring. If you want to remove the existing ones, take a look at the wallet_remove_transaction command. But be careful not to delete any real transactions.

[xeroc]

Known bug .. market is halted due to a rounding loop in the delegates

[mf-tzo]

Damn rounding errors resulted in neither the full bid nor full ask getting filled leaving dust on the orders.

I had a check in the engine to make sure that one order or the other was always filled and to exit if not to prevent sending all delegates into an infinite loop.   That check triggered and stopped the GLD market.

The rounding errors were much higher than I anticipated possible (I had checks in there for this)... I have since implemented a more robust approach to rounding that should address this issue.  Yet another test case  for us to add. 

Note: we had test cases for it working even test cases with rounding errors....  just not test cases with rounding errors this large.

But I am not talking about GLD market. I can't short on bitusd market even if I put an order to short @ 28 and the bid price is 31...

[tonyk]

And so  my 'time bending' theory bites the dust...

[xeroc]

This does not account for missed blocks which we do not know in advance. The genesis time is also more of a symbolic birthtime of the DAC; it is not 1 block interval before block 1.

Ah .. I see .. I always thought missed blocks still have there number thanks for pointing out .. do we have counter in the wallet for the number of missed blocks somewhere

[vikram]

just wrote a small python script to figure out the exact time:
https://github.com/xeroc/pytshares/blob/master/timeofblock.py

2014-09-28 02:38:50 UTC

??
According to your script the fork already happened 

oh .. didn't notice .. seems to be a bug in my script ..

//edit: this is odd I basically just do the following in python
     genesisTime + confirmationTime*blockNum
so what's wrong?

This does not account for missed blocks which we do not know in advance. The genesis time is also more of a symbolic birthtime of the DAC; it is not 1 block interval before block 1.

[Riverhead]

Shouldn't the bitUSD buyer using 1,072,478.01492 BTSX for his/her purchase be informed that his bot (I assume it is a bot) is losing money for him?

Not that I mind the dividend but...

There's no way to know who it is.

[bytemaster]

Damn rounding errors resulted in neither the full bid nor full ask getting filled leaving dust on the orders.

I had a check in the engine to make sure that one order or the other was always filled and to exit if not to prevent sending all delegates into an infinite loop.   That check triggered and stopped the GLD market.

The rounding errors were much higher than I anticipated possible (I had checks in there for this)... I have since implemented a more robust approach to rounding that should address this issue.  Yet another test case  for us to add. 

Note: we had test cases for it working even test cases with rounding errors....  just not test cases with rounding errors this large.     

[mf-tzo]

So I assume therefore that 0.4.18 is still buggy and a new version will replace it soon?

[johncitizen]

I shouldn't complain since I had some short orders and BTSX price fell more so these should have been actioned at lower prices but...

It would be nice if I can manage to finally short some bitusd. What am I doing wrong?

Top bid price I see is 350 @ 31.01
Top ask I see is 500 @ 31.99
price feed is @ 32.7370

Are the above correct? What price should I put in order to short bitusd? I would think that 31.01 would be ok and my order will get instantly actioned.

I am on v.0.4.18 RC1 which I downloaded from DACsunlimited webiste..

On 0.4.18 and cannot short the BitUSD or GLD

Driving me crazy watching those orders sit still. I spammed that 31.01 trying to get it but no avail. Tried shorting those high BitGLD buy orders at 44,000 too.

Hahaha... glad to see im not the only shark!

[mf-tzo]

I shouldn't complain since I had some short orders and BTSX price fell more so these should have been actioned at lower prices but...

It would be nice if I can manage to finally short some bitusd. What am I doing wrong?

Top bid price I see is 350 @ 31.01
Top ask I see is 500 @ 31.99
price feed is @ 32.7370

Are the above correct? What price should I put in order to short bitusd? I would think that 31.01 would be ok and my order will get instantly actioned.

I am on v.0.4.18 RC1 which I downloaded from DACsunlimited webiste..

[xeroc]

just wrote a small python script to figure out the exact time:
https://github.com/xeroc/pytshares/blob/master/timeofblock.py

2014-09-28 02:38:50 UTC

??
According to your script the fork already happened 

oh .. didn't notice .. seems to be a bug in my script ..

//edit: this is odd I basically just do the following in python
     genesisTime + confirmationTime*blockNum
so what's wrong?

[tonyk]

That's sounds Chinese to me my friend..

Based on your scrypt when is the estimation? In the mean time I can put whatever short orders I want and cancel them I assume and short orders will initiate after the hard fork at the current market prices?

Has a final decision been made regarding how long the shorts can keep their position open until they are forced to cover? Or this is still indefinite?

I think it is just a proposal, with high likelihood to become reality, but not in v.0.4.18

[mf-tzo]

That's sounds Chinese to me my friend..

Based on your scrypt when is the estimation? In the mean time I can put whatever short orders I want and cancel them I assume and short orders will initiate after the hard fork at the current market prices?

Has a final decision been made regarding how long the shorts can keep their position open until they are forced to cover? Or this is still indefinite?

[tonyk]

just wrote a small python script to figure out the exact time:
https://github.com/xeroc/pytshares/blob/master/timeofblock.py

2014-09-28 02:38:50 UTC

??
According to your script the fork already happened