0.4.16 - the good , the bad and the ugly

[theoretical]

@Gentso1 I agree, and I posted an actionable proposal for improving communication at https://bitsharestalk.org/index.php?topic=9182

[Gentso1]

What are these shortwalls?

Is it something temporary?

The behavior for several versions has been to cancel short orders below the feed.

In 0.4.16, that is changing; short orders below the feed now execute at the feed.

You can view the feed as "pushing up" the price for all the shorts that fall below it, to the level of the feed.  If a short is pushed up so far that the shorter's collateral is less than 1/2 (i.e. order.collateral < feed_price * order.quantity) then the short won't execute.

Before 0.4.16, short collateral was always price times quantity.  Now, the shorter can optionally set collateral to be more than price times quantity.  Why would the shorters want to do this?  There are two incentives:

- A higher collateral short is able to be pushed up by the feed instead of being cancelled when the feed tries to move up through it.
- When bidders try to buy through the short wall, the system prefers higher collateral shorts to execute first.

Here is the thread discussing these changes:  https://bitsharestalk.org/index.php?topic=9029.0

EDIT, actually answering the question:  The "short wall" I assume is the combination of all short orders below the feed, which the system has pushed up to the feed level via the above mechanism.

Someone needs to write a clear explanation.

yea it would be nice to know things like this BEFORE or at least once they are implemented......idk maybe under some kind changes to this version or something like that.

[theoretical]

What are these shortwalls?

Is it something temporary?

The behavior for several versions has been to cancel short orders below the feed.

In 0.4.16, that is changing; short orders below the feed now execute at the feed.

You can view the feed as "pushing up" the price for all the shorts that fall below it, to the level of the feed.  If a short is pushed up so far that the shorter's collateral is less than 1/2 (i.e. order.collateral < feed_price * order.quantity) then the short won't execute.

Before 0.4.16, short collateral was always price times quantity.  Now, the shorter can optionally set collateral to be more than price times quantity.  Why would the shorters want to do this?  There are two incentives:

- A higher collateral short is able to be pushed up by the feed instead of being unable to execute when the feed tries to move up through it.
- When bidders try to buy through the short wall, the system prefers higher collateral shorts to execute first.

Here is the thread discussing these changes:  https://bitsharestalk.org/index.php?topic=9029.0

EDIT, actually answering the question:  The "short wall" I assume is the combination of all short orders below the feed, which the system has pushed up to the feed level via the above mechanism.
EDIT again:  Change "cancelled" to "unable to execute" in the first of the two incentives.

Someone needs to write a clear explanation.

[GaltReport]

What are these shortwalls?

Is it something temporary?

yea whats up with this?

I took it to just be a visual marker of where the shorts start, price wise.

[Gentso1]

What are these shortwalls?

Is it something temporary?

yea whats up with this?

[svk]

Actually, I think SVK is refreshing his chain. I'm down to 39 missed again :) .

One of my collection scripts crashed for some unknown reason, I've relaunched it using foreverjs so it should keep running until I have time to figure out what the issue is!

You're back to 59 now, which I believe is correct.

Don't remind me  :'(

Haha, your overall reliability is still great though :)

[Riverhead]

Actually, I think SVK is refreshing his chain. I'm down to 39 missed again :) .

One of my collection scripts crashed for some unknown reason, I've relaunched it using foreverjs so it should keep running until I have time to figure out what the issue is!

You're back to 59 now, which I believe is correct.

Don't remind me  :'(

[svk]

Actually, I think SVK is refreshing his chain. I'm down to 39 missed again :).

One of my collection scripts crashed for some unknown reason, I've relaunched it using foreverjs so it should keep running until I have time to figure out what the issue is!

You're back to 59 now, which I believe is correct.

[Riverhead]

Actually, I think SVK is refreshing his chain. I'm down to 39 missed again :).

[Riverhead]

I had some issues too. One machine reports my delegate missed about 4 blocks, others that I only missed one. For example on here: http://www.bitsharesblocks.com/delegates I show 56 total missed blocks. However on my Delegate I show:

Code Select Expand


6939  riverhead-del-server-1          13.29210660 %  5278     59       98.89 %       5 %      99.80772 BTSX       546753      v0.4.16


[CalabiYau]

Restart delegate as I found the machine running on the wrong chain.

Code Select Expand


   545552
     26e8fb9cae7f31249e1314c34fba192fa8f8c345                     spartako1              1       410 2014-09-21T17:35:30        -1     YES                 YES
     ac8ba2a73a3dac799fe54cb1ad7fccb5bc29a8f1        www2.minebitshares-com              3      2267 2014-09-21T17:37:50         0     N/A                  NO
         545580
     7682aacc16c2b4077ff37ab36febe07e658d81cb        riverhead-del-server-1              5      1276 2014-09-21T17:46:20        -1     YES                  NO
     34136cdfc995af6b79e59a86336e26da04ad974c                 dpos.crazybit              1       382 2014-09-21T17:40:20     11371     YES                 YES
         545636
     b34c1c611e50cf400c2e023d876ac7810dac87c3         btsx.chinesecommunity              0       166 2014-09-21T17:50:10        -1     YES                 YES
     d9b679d434be6ef11576deac06bf1569b21b0bfd               delegate.webber              2       722 2014-09-21T17:54:30         0     N/A                  NO
         546260
     6cc0550eb4e5ea13c642b1098815916823e2b6ed                titan.crazybit              1       410 2014-09-21T19:37:10         0     YES                 YES
     0cde6d50bd417fc07dbad0c8c90daf4a55463230                     calabiyau              2      2019 2014-09-21T19:49:20        -1     N/A                  NO
         546293
     fa4ac65214a818f387bb8eb91ee548985d871151              delegate.cgafeng              0       166 2014-09-21T19:42:50         0     YES                 YES
     993f7692d68e136ff2575c9b1bca63f99ae271b0                    maqifrnswa              1      1775 2014-09-21T19:48:30         0     N/A                  NO
--- in sync with p2p network
     


First sight seems that the delegates with < TX winning the race....

[emski]

dacunlimited said delegates with RC-1 version must upgrade to the final version before block 554800

Question:
if  a delegate can't upgrade until then but a couple of hours after (7-10 hours ),  what will happen?
Will the delegate miss blocks?

All delegates that havent upgraded will likely ignore blocks produced by upgraded delegates.
This will create a fork where only non-upgraded delegates will produce blocks.
On the "real" chain these delegates will be seen as if they are missing blocks.

[liondani]

dacunlimited said delegates with RC-1 version must upgrade to the final version before block 554800

Question:
if  a delegate can't upgrade until then but a couple of hours after (7-10 hours ),  what will happen?
Will the delegate miss blocks?

[vlight]

My guess is that it should start working from block 554800:
https://github.com/dacsunlimited/bitsharesx/releases

[joele]

I'm getting this msg when shorting, tried diff prices below & above margin msg still appears

Order failed: Assert Exception (10) !"New short operation is not supported yet!"