BitShares Forum
Main => General Discussion => Topic started by: tonyk on September 21, 2014, 04:48:17 am
-
Short collateralization graph coming to a vault near you :)
No issues, so far with - x86 exe on win7/32bit.
...Other than about 20-30K BTSX missing -I will have to figure out from what kind of transaction(s).
...It seems fine doing the basic mental calculation, just the collateral is no longer available in the GUI...
-
What are these shortwalls?
Is it something temporary?
-
WIN 7 / 64 - BitSharesX-0.4.16-x64
After reindexing - open markets:
Stopped working
Problem Event Name: BEX64
Application Name: BitSharesX.exe
Application Version: 0.0.0.0
Application Timestamp: 541e250e
Fault Module Name: StackHash_01aa
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Offset: 0000000100430260
Exception Code: c0000005
Exception Data: 0000000000000008
OS Version: 6.1.7601.2.1.0.256.4
Locale ID: 2055
Additional Information 1: 01aa
Additional Information 2: 01aa1384bc5922653aa8f4d61c975ddc
Additional Information 3: 82b1
Additional Information 4: 82b1291b39823c8f835a7981f590456c
-
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!"
-
My guess is that it should start working from block 554800:
https://github.com/dacsunlimited/bitsharesx/releases
-
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?
-
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.
-
Restart delegate as I found the machine running on the wrong chain.
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....
-
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:
6939 riverhead-del-server-1 13.29210660 % 5278 59 98.89 % 5 % 99.80772 BTSX 546753 v0.4.16
-
Actually, I think SVK is refreshing his chain. I'm down to 39 missed again :).
-
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.
-
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 :'(
-
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 :)
-
What are these shortwalls?
Is it something temporary?
yea whats up with this?
-
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.
-
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.
-
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.
-
@Gentso1 I agree, and I posted an actionable proposal for improving communication at https://bitsharestalk.org/index.php?topic=9182