BitShares Forum
Main => General Discussion => Topic started by: bytemaster on September 02, 2014, 09:55:50 pm
-
0.4.11 release candidate has been posted to master at https://github.com/dacsunlimited/bitsharesx.git
https://github.com/dacsunlimited/bitsharesx/releases/tag/0.4.11-RC1
More market fixes so RC1 users still will have to upgrade:
https://github.com/dacsunlimited/bitsharesx/releases/tag/0.4.11-RC2
Changes in this update:
1) Major bugs fixes in the GUI
2) Shorts can sell at up to 10% below the peg *if* there are offers to buy above the peg. The difference is captured as fees, gives priority to shorts willing to pay the highest fee.
3) Enhancements for canceling orders when managing a wallet imported from backup.
4) Deterministic key generation is now done on a per-account basis rather than per-wallet. This should help place orders in the proper account when recovering from backups.
5) Average price gets set to the "median feed"
6) Major network bug fixes.
All hard-fork changes are currently scheduled to go into effect Friday at Noon.
Test GUIs should be provided by DAC Sun Limited soon.
-
Should seed nodes and delegates update to this ? (before official release I mean)
-
Should seed nodes and delegates update to this ? (before official release I mean)
Well if the release testing goes well then you will be ahead of the game. Delegates that are less pro-active can wait until the official tag is declared as 0.4.11.
No major new changes will be made between master and 0.4.11.
-
5) Average price gets set to the "median feed"
I think this really means "the JSON-RPC field and the spot in the GUI that previously displayed the average price now display the median feed price but have not been relabeled." If this is, in fact, what it actually means, then I think we should relabel them before we drop the release candidate status.
BitShares has enough confusing, technical, somewhat poorly documented terminology as it is. There's absolutely no need to go re-defining terms like "average price" to mean something completely different from what people expect it to mean!
-
5) Average price gets set to the "median feed"
I think this really means "the JSON-RPC field and the spot in the GUI that previously displayed the average price now display the median feed price but have not been relabeled." If this is, in fact, what it actually means, then I think we should relabel them before we drop the release candidate status.
BitShares has enough confusing, technical, somewhat poorly documented terminology as it is. There's absolutely no need to go re-defining terms like "average price" to mean something completely different from what people expect it to mean!
The GUI reads median price... that particular comment was based upon technical internals.
-
I've tested clean synchronization - no issues except it waits for almost 1 minute before it starts synchronizing.
I've updated the seed node to this version.
I'll delay updating the delegate.
It looks OK so far. It seems like it uses far less memory (or previous version leaks). I'll monitor that.
-
0.4.11 release candidate has been posted to master at https://github.com/dacsunlimited/bitsharesx.git
Changes in this update:
2) Shorts can sell at up to 10% below the peg *if* there are offers to buy above the peg. The difference is captured as fees, gives priority to shorts willing to pay the highest fee.
Are you trying to get 200 bitBTC as fee for the system with this. :)
But they will be unbacked by almost any BTSX... :o
OK I see, 10 % sanity check.
-
This segfault occurs when quitting the GUI (after it has been open for a while).
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./BitSharesX'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000aadcfa in boost::asio::detail::task_io_service::post_immediate_completion (this=0x18, op=op@entry=0x7ff070596450,
is_continuation=is_continuation@entry=false) at /usr/include/boost/asio/detail/impl/task_io_service.ipp:264
264 if (one_thread_ || is_continuation)
(gdb) bt
#0 0x0000000000aadcfa in boost::asio::detail::task_io_service::post_immediate_completion (this=0x18, op=op@entry=0x7ff070596450,
is_continuation=is_continuation@entry=false) at /usr/include/boost/asio/detail/impl/task_io_service.ipp:264
#1 0x0000000000aadf00 in boost::asio::detail::epoll_reactor::start_op (this=0x7ff070027380, op_type=op_type@entry=1, descriptor=155,
descriptor_data=@0x7ff07048ff00: 0x7ff04c001250, op=0x7ff070596450, is_continuation=<optimized out>, allow_speculative=true)
at /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:253
#2 0x0000000000aaf268 in boost::asio::detail::reactive_socket_service_base::start_op (this=0x7ff07045d168, impl=..., op_type=1, op=<optimized out>,
is_continuation=<optimized out>, is_non_blocking=<optimized out>, noop=false) at /usr/include/boost/asio/detail/impl/reactive_socket_service_base.ipp:214
#3 0x0000000000ab2256 in async_send<boost::asio::const_buffers_1, boost::_bi::bind_t<void, void (*)(fc::shared_ptr<fc::promise<unsigned long> > const&, boost::system::error_code const&, unsigned long), boost::_bi::list3<boost::_bi::value<fc::shared_ptr<fc::promise<unsigned long> > >, boost::arg<1>, boost::arg<2> > > > (handler=...,
flags=0, buffers=..., impl=..., this=0x7ff07045d168) at /usr/include/boost/asio/detail/reactive_socket_service_base.hpp:216
#4 async_send<boost::asio::const_buffers_1, boost::_bi::bind_t<void, void (*)(fc::shared_ptr<fc::promise<unsigned long> > const&, boost::system::error_code const&, unsigned long), boost::_bi::list3<boost::_bi::value<fc::shared_ptr<fc::promise<unsigned long> > >, boost::arg<1>, boost::arg<2> > > > (
handler=<unknown type in /redacted/bitsharesx/programs/qt_wallet/bin/BitSharesX, CU 0x30d2e56, DIE 0x31418e3>, flags=0, buffers=..., impl=...,
this=0x7ff07045d140) at /usr/include/boost/asio/stream_socket_service.hpp:330
#5 async_write_some<boost::asio::const_buffers_1, boost::_bi::bind_t<void, void (*)(fc::shared_ptr<fc::promise<unsigned long> > const&, boost::system::error_code const&, unsigned long), boost::_bi::list3<boost::_bi::value<fc::shared_ptr<fc::promise<unsigned long> > >, boost::arg<1>, boost::arg<2> > > > (
handler=<unknown type in /redacted/bitsharesx/programs/qt_wallet/bin/BitSharesX, CU 0x30d2e56, DIE 0x3115ea8>, buffers=..., this=0x7ff07048fef8)
at /usr/include/boost/asio/basic_stream_socket.hpp:732
#6 fc::asio::write_some<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::const_buffers_1>
(s=..., buf=...) at /redacted/bitsharesx/libraries/fc/include/fc/asio.hpp:122
#7 0x0000000000db0399 in fc::detail::rate_limiting_group_impl::writesome (this=0x7ff070433770, socket=...,
buffer=0x7ff049e6d7a0 "\337\362n\342\360\274\v\005\065\366LJ", length=16) at /redacted/bitsharesx/libraries/fc/src/network/rate_limiting.cpp:249
#8 0x0000000000a5ccc7 in fc::ostream::write (this=this@entry=0x7ff07048fed8, buf=buf@entry=0x7ff049e6d7a0 "\337\362n\342\360\274\v\005\065\366LJ", len=16)
at /redacted/bitsharesx/libraries/fc/src/io/iostream.cpp:365
#9 0x0000000000be22ae in bts::net::stcp_socket::writesome (this=0x7ff07048fe80, buffer=0x7ff070001fb0 "\b", len=<optimized out>)
at /redacted/bitsharesx/libraries/net/stcp_socket.cpp:93
#10 0x0000000000a5ccc7 in fc::ostream::write (this=this@entry=0x7ff07048fe80, buf=buf@entry=0x7ff070001fb0 "\b", len=len@entry=16)
at /redacted/bitsharesx/libraries/fc/src/io/iostream.cpp:365
#11 0x0000000000bc30d0 in bts::net::detail::message_oriented_connection_impl::send_message (this=0x7ff07048fe70, message_to_send=...)
at /redacted/bitsharesx/libraries/net/message_oriented_connection.cpp:251
#12 0x0000000000bc3bb8 in bts::net::message_oriented_connection::send_message (this=this@entry=0x7ff070465af8, message_to_send=...)
at /redacted/bitsharesx/libraries/net/message_oriented_connection.cpp:328
#13 0x0000000000bbda96 in bts::net::peer_connection::send_queued_messages_task (this=0x7ff070465a90)
at /redacted/bitsharesx/libraries/net/peer_connection.cpp:236
#14 0x0000000000bbf5dc in operator() (__closure=<optimized out>) at /redacted/bitsharesx/libraries/net/peer_connection.cpp:301
#15 fc::detail::void_functor_run<bts::net::peer_connection::send_message(const bts::net::message&)::<lambda()> >::run(void *, void *) (functor=<optimized out>,
prom=0x7ff070466660) at /redacted/bitsharesx/libraries/fc/include/fc/thread/task.hpp:83
#16 0x0000000000a4e115 in fc::task_base::run_impl (this=0x7ff070466670) at /redacted/bitsharesx/libraries/fc/src/thread/task.cpp:43
#17 0x0000000000a4cbb3 in run_next_task (this=<optimized out>) at /redacted/bitsharesx/libraries/fc/src/thread/thread_d.hpp:398
#18 fc::thread_d::process_tasks (this=0x7ff0700008c0) at /redacted/bitsharesx/libraries/fc/src/thread/thread_d.hpp:422
#19 0x0000000000a4ce21 in fc::thread_d::start_process_tasks (my=140670647929024) at /redacted/bitsharesx/libraries/fc/src/thread/thread_d.hpp:378
#20 0x0000000000deedee in make_fcontext ()
#21 0x00007ff0700008c0 in ?? ()
#22 0x0000000000000000 in ?? ()
-
Thanks for all the hard work gang. :)
-
Can someone give a quick back-of-the-envelope rationale for change number 2 (or point me to the discussion)? Does "the peg" mean the median price feed? So now we should expect a discontinuous market price: if we're right at the peg, as soon as someone places a bid a tiny bit above the peg, some short 10% below the peg matches him? Sounds like it could get very confusing for traders.
Sent from my SCH-S720C using Tapatalk 2
-
Chain/Node server updated and running without issue. Linux GUI is running fine and even made few trades :D . There is still that weird huge gap between the sections though so there is a lot of scrolling. Anyway, it's been running for a while now without issue.
-
Can someone give a quick back-of-the-envelope rationale for change number 2 (or point me to the discussion)? Does "the peg" mean the median price feed? So now we should expect a discontinuous market price: if we're right at the peg, as soon as someone places a bid a tiny bit above the peg, some short 10% below the peg matches him? Sounds like it could get very confusing for traders.
Sent from my SCH-S720C using Tapatalk 2
I guess the "peg" means the median price published by delegates?
-
Can someone give a quick back-of-the-envelope rationale for change number 2 (or point me to the discussion)? Does "the peg" mean the median price feed? So now we should expect a discontinuous market price: if we're right at the peg, as soon as someone places a bid a tiny bit above the peg, some short 10% below the peg matches him? Sounds like it could get very confusing for traders.
Sent from my SCH-S720C using Tapatalk 2
Dear shorts,
you can now place your orders below the peg (up to 10% below), if you so desire. Such short orders will execute only if the bid is above the peg, thogh.
The change is justified by the simple principal - "The system does not mind getting more fees', if the free trading parties wish to give those fees to us.
-
Can someone give a quick back-of-the-envelope rationale for change number 2 (or point me to the discussion)? Does "the peg" mean the median price feed? So now we should expect a discontinuous market price: if we're right at the peg, as soon as someone places a bid a tiny bit above the peg, some short 10% below the peg matches him? Sounds like it could get very confusing for traders.
Confusing? Everyone gets exactly what they asked for. If you short Q quantity at P price, then you get a short position for Q units with 2*Q*P collateral if the order is totally filled. If you enter a Bid for Q quantity at P' price, then you spend exactly Q*P' and get exactly Q units if the order is totally filled.
If P << P' (that is, top of Ask/Short book is much less than top of Bid book), then the system takes the difference.
As for the rationale -- basically there is so much demand to short the dollar, above and beyond the peg. So much that they are willing to pay a premium, in the form of setting a short price below the peg and hoping BitUSD will sink even lower. In the older version, the short-heavy Ask book was moving the price far away from the peg by pushing all the way down the Bid book which was much thinner (I think the sorts of people who are actively trading BTSX right now think BTSX is going to the moon and short dollars, trying to add leverage to their BTSX holdings). In the new version 0.4.11, shorts are allowed to compete with each other for a limited Bid pool based on the premiums they are willing to pay, but the premium now goes to the network in the form of fees, instead of to BitUSD buyers in the form of really cheap BitUSD.
-
Thanks tonyk and drltc for the explanations. I like it.
Sent from my SCH-S720C using Tapatalk 2
-
2) Shorts can sell at up to 10% below the peg *if* there are offers to buy above the peg. The difference is captured as fees, gives priority to shorts willing to pay the highest fee.
Is it possible and if so what do you think of the idea of - the accumulated fees that are captured from (2) being redistributed evenly as interest to BitAsset holders based on their current holdings.
Edit So while BTSX holders get the current daily burn.
(2) goes only to BitAsset holders somehow as daily interest.
(Display daily & current annualised rate on wallet opening. Considering shorting demand this interest rate will be considerable.)
Many crypto exchanges offer daily interest like bter. It shouldn't effect the peg but will maximise demand for BitAssets.
This + stable wallet = great wealth 8) 8) 8)
-
This segfault occurs when quitting the GUI (after it has been open for a while).
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./BitSharesX'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000aadcfa in boost::asio::detail::task_io_service::post_immediate_completion (this=0x18, op=op@entry=0x7ff070596450,
is_continuation=is_continuation@entry=false) at /usr/include/boost/asio/detail/impl/task_io_service.ipp:264
264 if (one_thread_ || is_continuation)
(gdb) bt
#0 0x0000000000aadcfa in boost::asio::detail::task_io_service::post_immediate_completion (this=0x18, op=op@entry=0x7ff070596450,
is_continuation=is_continuation@entry=false) at /usr/include/boost/asio/detail/impl/task_io_service.ipp:264
#1 0x0000000000aadf00 in boost::asio::detail::epoll_reactor::start_op (this=0x7ff070027380, op_type=op_type@entry=1, descriptor=155,
descriptor_data=@0x7ff07048ff00: 0x7ff04c001250, op=0x7ff070596450, is_continuation=<optimized out>, allow_speculative=true)
at /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:253
#2 0x0000000000aaf268 in boost::asio::detail::reactive_socket_service_base::start_op (this=0x7ff07045d168, impl=..., op_type=1, op=<optimized out>,
is_continuation=<optimized out>, is_non_blocking=<optimized out>, noop=false) at /usr/include/boost/asio/detail/impl/reactive_socket_service_base.ipp:214
#3 0x0000000000ab2256 in async_send<boost::asio::const_buffers_1, boost::_bi::bind_t<void, void (*)(fc::shared_ptr<fc::promise<unsigned long> > const&, boost::system::error_code const&, unsigned long), boost::_bi::list3<boost::_bi::value<fc::shared_ptr<fc::promise<unsigned long> > >, boost::arg<1>, boost::arg<2> > > > (handler=...,
flags=0, buffers=..., impl=..., this=0x7ff07045d168) at /usr/include/boost/asio/detail/reactive_socket_service_base.hpp:216
#4 async_send<boost::asio::const_buffers_1, boost::_bi::bind_t<void, void (*)(fc::shared_ptr<fc::promise<unsigned long> > const&, boost::system::error_code const&, unsigned long), boost::_bi::list3<boost::_bi::value<fc::shared_ptr<fc::promise<unsigned long> > >, boost::arg<1>, boost::arg<2> > > > (
handler=<unknown type in /redacted/bitsharesx/programs/qt_wallet/bin/BitSharesX, CU 0x30d2e56, DIE 0x31418e3>, flags=0, buffers=..., impl=...,
this=0x7ff07045d140) at /usr/include/boost/asio/stream_socket_service.hpp:330
#5 async_write_some<boost::asio::const_buffers_1, boost::_bi::bind_t<void, void (*)(fc::shared_ptr<fc::promise<unsigned long> > const&, boost::system::error_code const&, unsigned long), boost::_bi::list3<boost::_bi::value<fc::shared_ptr<fc::promise<unsigned long> > >, boost::arg<1>, boost::arg<2> > > > (
handler=<unknown type in /redacted/bitsharesx/programs/qt_wallet/bin/BitSharesX, CU 0x30d2e56, DIE 0x3115ea8>, buffers=..., this=0x7ff07048fef8)
at /usr/include/boost/asio/basic_stream_socket.hpp:732
#6 fc::asio::write_some<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::const_buffers_1>
(s=..., buf=...) at /redacted/bitsharesx/libraries/fc/include/fc/asio.hpp:122
#7 0x0000000000db0399 in fc::detail::rate_limiting_group_impl::writesome (this=0x7ff070433770, socket=...,
buffer=0x7ff049e6d7a0 "\337\362n\342\360\274\v\005\065\366LJ", length=16) at /redacted/bitsharesx/libraries/fc/src/network/rate_limiting.cpp:249
#8 0x0000000000a5ccc7 in fc::ostream::write (this=this@entry=0x7ff07048fed8, buf=buf@entry=0x7ff049e6d7a0 "\337\362n\342\360\274\v\005\065\366LJ", len=16)
at /redacted/bitsharesx/libraries/fc/src/io/iostream.cpp:365
#9 0x0000000000be22ae in bts::net::stcp_socket::writesome (this=0x7ff07048fe80, buffer=0x7ff070001fb0 "\b", len=<optimized out>)
at /redacted/bitsharesx/libraries/net/stcp_socket.cpp:93
#10 0x0000000000a5ccc7 in fc::ostream::write (this=this@entry=0x7ff07048fe80, buf=buf@entry=0x7ff070001fb0 "\b", len=len@entry=16)
at /redacted/bitsharesx/libraries/fc/src/io/iostream.cpp:365
#11 0x0000000000bc30d0 in bts::net::detail::message_oriented_connection_impl::send_message (this=0x7ff07048fe70, message_to_send=...)
at /redacted/bitsharesx/libraries/net/message_oriented_connection.cpp:251
#12 0x0000000000bc3bb8 in bts::net::message_oriented_connection::send_message (this=this@entry=0x7ff070465af8, message_to_send=...)
at /redacted/bitsharesx/libraries/net/message_oriented_connection.cpp:328
#13 0x0000000000bbda96 in bts::net::peer_connection::send_queued_messages_task (this=0x7ff070465a90)
at /redacted/bitsharesx/libraries/net/peer_connection.cpp:236
#14 0x0000000000bbf5dc in operator() (__closure=<optimized out>) at /redacted/bitsharesx/libraries/net/peer_connection.cpp:301
#15 fc::detail::void_functor_run<bts::net::peer_connection::send_message(const bts::net::message&)::<lambda()> >::run(void *, void *) (functor=<optimized out>,
prom=0x7ff070466660) at /redacted/bitsharesx/libraries/fc/include/fc/thread/task.hpp:83
#16 0x0000000000a4e115 in fc::task_base::run_impl (this=0x7ff070466670) at /redacted/bitsharesx/libraries/fc/src/thread/task.cpp:43
#17 0x0000000000a4cbb3 in run_next_task (this=<optimized out>) at /redacted/bitsharesx/libraries/fc/src/thread/thread_d.hpp:398
#18 fc::thread_d::process_tasks (this=0x7ff0700008c0) at /redacted/bitsharesx/libraries/fc/src/thread/thread_d.hpp:422
#19 0x0000000000a4ce21 in fc::thread_d::start_process_tasks (my=140670647929024) at /redacted/bitsharesx/libraries/fc/src/thread/thread_d.hpp:378
#20 0x0000000000deedee in make_fcontext ()
#21 0x00007ff0700008c0 in ?? ()
#22 0x0000000000000000 in ?? ()
Please let me know if you can repeat this error in further runs. Also, before you shut down, can you check how many connections and how much memory you are using? Are you just operating with default settings, or have you increased node count or anything like that?
-
0.4.11 (with GUI) Running good so far.
Still getting this weird thing/bug ( present in the last 2-3 versions) - The first time ever to close the app. it freezes.
-
well with 0.4.11 I am actually able to open the GUI and fully sync, so its usable again which is good.
Only thing I noticed is the margin orders table is empty.
-
The transfer tab is still empty for me in 4.11
You should make it more clear for users, why there is overlap in the market.
It looks like the market is broken, and not everyone is reading up in here.
-
active delegates spartako,spartako1,spartako2 updated to 0.4.11-RC1 without problem:
default (unlocked) >>> getinfo
{
"blockchain_head_block_num": 389578,
"blockchain_head_block_age": "9 seconds old",
"blockchain_head_block_timestamp": "2014-09-03T13:39:20",
"blockchain_average_delegate_participation": "100.00 %",
"blockchain_confirmation_requirement": 1,
"blockchain_accumulated_fees": "315,234.67322 BTSX",
"blockchain_delegate_pay_rate": "2.60610 BTSX",
"blockchain_share_supply": "1,999,913,503.33380 BTSX",
"blockchain_blocks_left_in_round": 80,
"blockchain_next_round_time": "at least 13 minutes in the future",
"blockchain_next_round_timestamp": "2014-09-03T13:52:40",
"blockchain_random_seed": "619790d36101e5d5fdf93739f4c69f06ba4332c3",
"client_data_dir": "/home/spartako/.BitSharesX",
"client_version": "0.4.11",
"network_num_connections": 11,
"network_num_connections_max": 30,
"ntp_time": "2014-09-03T13:39:29",
"ntp_time_error": -0.0025490000000000001,
"wallet_open": true,
"wallet_unlocked": true,
"wallet_unlocked_until": "31 years in the future",
"wallet_unlocked_until_timestamp": "1910-04-06T08:48:37",
"wallet_last_scanned_block_timestamp": "2014-07-24T09:23:30",
"wallet_scan_progress": "? %",
"wallet_block_production_enabled": true,
"wallet_next_block_production_time": "6 minutes in the future",
"wallet_next_block_production_timestamp": "2014-09-03T13:45:30"
}
-
It appears the Windows 0.4.11 RC did not pull in the changes to the GUI. I will let DAC Sun know so they can rebuild it. Thanks for help testing.
-
delegate.bitder updated to
0.4.11-RC1. No problems so far.
Edit: updated to 0.4.11-RC2. No problems so far.
-
build and client running without issues so far. +5%
-
'display bug' partly fixed?!?
First off, I am probably not running the very last 0.4.11 version as I installed it last night (US time zones),
>> about
{
"bitshares_toolkit_revision": "cfad07c39a1cc56b67b8715721e5aaba60a67611",
"bitshares_toolkit_revision_age": "21 hours ago",
"fc_revision": "a0b3a9a92d28ec0b3a08b45b8c1449737f56dd34",
"fc_revision_age": "24 hours ago",
"compile_date": "compiled on Sep 3 2014 at 00:09:09"
}
But the order amounts now refresh/change to the correct remaining (as opposed to initial) amount.
The same can not be said about the order book? Getting 'out' and back 'in', of this particular assets screen, seem to do the refreshing... but only for the ask side of the order book. 8)
-
Upgraded delegate node to 0.4.11-rc1 yesterday. Running well so far.
upgraded to 0.4.11-rc2.
-
RC2 released: https://github.com/dacsunlimited/bitsharesx/releases/tag/0.4.11-RC2
More market fixes so RC1 users still will have to upgrade.
-
Is win binary coming shortly, or my time is better spent upgrading linux to RC2 ?
Ok I see the win version is up.
-
I have asked DAC Sun to produce a Windows 64 bit version. The crypto is 2x faster in 64 bit.
-
RC2 is working well as expected. It's nice seeing blocks coming through with multiple transactions.
-
upgraded to 0.4.11-rc2.
GUI
Win 7 /32 bit
Still hangs up in the first ever attempt to close the app.
This has been the case on Win and Ubuntu for the last 2-3 releases.
[RESOLVED in 0.4.12]!!!
The difference is that at least now with 0.4.11-rc2 , the force close, does not leave any btsx processes running.
-
I have asked DAC Sun to produce a Windows 64 bit version. The crypto is 2x faster in 64 bit.
I will give it a go when this happens
-
First a question. Is the bitBTC:bitUSD going to have feed based median price?
If yes, it now shows:
Median Price
31.1896
BitBTC/BitUSD
-
First a question. Is the bitBTC:bitUSD going to have feed based median price?
If yes, it now shows:
Median Price
31.1896
BitBTC/BitUSD
No price feed for that pair, that is a GUI bug.
-
Im on RC2 and it shows the median at the top which is nice. Still would be even better to show it on the graph as well.
The overlapping has now stopped, I cant figure out if that is because of the new median-limit rule, or if its because the demand for BitUSD has increased.
-
0.4.11 release candidate has been posted to master at https://github.com/dacsunlimited/bitsharesx.git
https://github.com/dacsunlimited/bitsharesx/releases/tag/0.4.11-RC1
More market fixes so RC1 users still will have to upgrade:
https://github.com/dacsunlimited/bitsharesx/releases/tag/0.4.11-RC2
Changes in this update:
1) Major bugs fixes in the GUI
2) Shorts can sell at up to 10% below the peg *if* there are offers to buy above the peg. The difference is captured as fees, gives priority to shorts willing to pay the highest fee.
3) Enhancements for canceling orders when managing a wallet imported from backup.
4) Deterministic key generation is now done on a per-account basis rather than per-wallet. This should help place orders in the proper account when recovering from backups.
5) Average price gets set to the "median feed"
6) Major network bug fixes.
All hard-fork changes are currently scheduled to go into effect Friday at Noon.
Test GUIs should be provided by DAC Sun Limited soon.
Still needs work. Transaction scanning seems to be stuck at 0% progress. Still unable to recover lost balances, but it isn't crashing anymore at least.
-
0.4.11 release candidate has been posted to master at https://github.com/dacsunlimited/bitsharesx.git
https://github.com/dacsunlimited/bitsharesx/releases/tag/0.4.11-RC1
More market fixes so RC1 users still will have to upgrade:
https://github.com/dacsunlimited/bitsharesx/releases/tag/0.4.11-RC2
Changes in this update:
1) Major bugs fixes in the GUI
2) Shorts can sell at up to 10% below the peg *if* there are offers to buy above the peg. The difference is captured as fees, gives priority to shorts willing to pay the highest fee.
3) Enhancements for canceling orders when managing a wallet imported from backup.
4) Deterministic key generation is now done on a per-account basis rather than per-wallet. This should help place orders in the proper account when recovering from backups.
5) Average price gets set to the "median feed"
6) Major network bug fixes.
All hard-fork changes are currently scheduled to go into effect Friday at Noon.
Test GUIs should be provided by DAC Sun Limited soon.
Still needs work. Transaction scanning seems to be stuck at 0% progress. Still unable to recover lost balances, but it isn't crashing anymore at least.
same with me...
Because of this I deleted all folders except "wallets" and I am syncing from start again...
right now at "Last block was synced 20d 15h 42m 26s ago" ...
When syncing is complete I will make a "wallet_rescan_blockchain" to see what happens....
-
Looks this version works as expected.
I'll just post what I observed:
Just after I started the client I got 8 connections.
About 10 seconds after that connections dropped to 1.
I did not receive 2 blocks on time (392804 and 392805) and my delegate block production slot was just in that timeframe (392806). That resulted in a fork as my delegate knew only for 392803 at that particular moment.
Next delegate however decided to mine sign blocks on the right chain (previous 392804 and 392805). At that moment my delegate was showing: previous 2 blocks as missed (392804 and 392805), my block (392806), and the next block(392807) didn't show up at all (as it was sequential to 392805 which appears missed on my end). It was right after receiving 2 blocks on the right chain (after mine) when my delegate resynchronized and started to display its slot as missed. At the seed node however my delegate's block was marked missed on arrival as the seed node knew about the previous two blocks (392805 and 392804).
This looks like perfectly correct behavior to me (except dropped connections).
After that my delegate's connections got back to normal (20+) and everything run smoothly.
Here are the blocks in question:
392808 2014-09-03T22:38:00 www2.minebitshares-com 0 166 0.00000 BTSX 23 0.000833
392807 2014-09-03T22:37:50 delegate.bitder 0 166 0.00000 BTSX 33 0.000775
392806 2014-09-03T22:37:40 dac.bts500 0 166 0.00000 BTSX 43 0.003128
MISSED 2014-09-03T22:37:30 lotto-delegate N/A N/A N/A N/A N/A
392805 2014-09-03T22:37:20 delegate2.xeldal 1 424 0.10000 BTSX 63 0.005878
392804 2014-09-03T22:37:10 delegate.liondani 0 166 0.00000 BTSX 73 0.000258
392803 2014-09-03T22:37:00 daslab 0 166 0.00000 BTSX 2 0.012986
392802 2014-09-03T22:36:50 delegate3.xeldal 1 424 0.10000 BTSX 2 0.003205
FORKED BLOCK FORKING BLOCK ID SIGNING DELEGATE TXN COUNT SIZE TIMESTAMP LATENCY VALID IN CURRENT CHAIN
--------------------------------------------------------------------------------------------------------------------------------------------------------------
392803
7fa067f0d776c5d8f1372e0a5ca4a9c997d62523 lotto-delegate 0 166 2014-09-03T22:37:30 0 YES NO
56b7877893610ff3353ec7435596fe3c2add8583 delegate.liondani 0 166 2014-09-03T22:37:10 73 YES YES
And a note for the future - "When updating you should make sure your updated delegate has enough connections before turning on block production (and simultaneously turning off the old delegate)".
PS: Not sure if this will be helpful for anyone as it was just me explaining to myself what happened. However I lost too much time to write it down and I'll post it anyway
-
updating
-
updating to RC2
help.chinese
chinese
-
This segfault occurs when quitting the GUI (after it has been open for a while).
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./BitSharesX'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000aadcfa in boost::asio::detail::task_io_service::post_immediate_completion (this=0x18, op=op@entry=0x7ff070596450,
is_continuation=is_continuation@entry=false) at /usr/include/boost/asio/detail/impl/task_io_service.ipp:264
264 if (one_thread_ || is_continuation)
(gdb) bt
#0 0x0000000000aadcfa in boost::asio::detail::task_io_service::post_immediate_completion (this=0x18, op=op@entry=0x7ff070596450,
is_continuation=is_continuation@entry=false) at /usr/include/boost/asio/detail/impl/task_io_service.ipp:264
#1 0x0000000000aadf00 in boost::asio::detail::epoll_reactor::start_op (this=0x7ff070027380, op_type=op_type@entry=1, descriptor=155,
descriptor_data=@0x7ff07048ff00: 0x7ff04c001250, op=0x7ff070596450, is_continuation=<optimized out>, allow_speculative=true)
at /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:253
#2 0x0000000000aaf268 in boost::asio::detail::reactive_socket_service_base::start_op (this=0x7ff07045d168, impl=..., op_type=1, op=<optimized out>,
is_continuation=<optimized out>, is_non_blocking=<optimized out>, noop=false) at /usr/include/boost/asio/detail/impl/reactive_socket_service_base.ipp:214
#3 0x0000000000ab2256 in async_send<boost::asio::const_buffers_1, boost::_bi::bind_t<void, void (*)(fc::shared_ptr<fc::promise<unsigned long> > const&, boost::system::error_code const&, unsigned long), boost::_bi::list3<boost::_bi::value<fc::shared_ptr<fc::promise<unsigned long> > >, boost::arg<1>, boost::arg<2> > > > (handler=...,
flags=0, buffers=..., impl=..., this=0x7ff07045d168) at /usr/include/boost/asio/detail/reactive_socket_service_base.hpp:216
#4 async_send<boost::asio::const_buffers_1, boost::_bi::bind_t<void, void (*)(fc::shared_ptr<fc::promise<unsigned long> > const&, boost::system::error_code const&, unsigned long), boost::_bi::list3<boost::_bi::value<fc::shared_ptr<fc::promise<unsigned long> > >, boost::arg<1>, boost::arg<2> > > > (
handler=<unknown type in /redacted/bitsharesx/programs/qt_wallet/bin/BitSharesX, CU 0x30d2e56, DIE 0x31418e3>, flags=0, buffers=..., impl=...,
this=0x7ff07045d140) at /usr/include/boost/asio/stream_socket_service.hpp:330
#5 async_write_some<boost::asio::const_buffers_1, boost::_bi::bind_t<void, void (*)(fc::shared_ptr<fc::promise<unsigned long> > const&, boost::system::error_code const&, unsigned long), boost::_bi::list3<boost::_bi::value<fc::shared_ptr<fc::promise<unsigned long> > >, boost::arg<1>, boost::arg<2> > > > (
handler=<unknown type in /redacted/bitsharesx/programs/qt_wallet/bin/BitSharesX, CU 0x30d2e56, DIE 0x3115ea8>, buffers=..., this=0x7ff07048fef8)
at /usr/include/boost/asio/basic_stream_socket.hpp:732
#6 fc::asio::write_some<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::const_buffers_1>
(s=..., buf=...) at /redacted/bitsharesx/libraries/fc/include/fc/asio.hpp:122
#7 0x0000000000db0399 in fc::detail::rate_limiting_group_impl::writesome (this=0x7ff070433770, socket=...,
buffer=0x7ff049e6d7a0 "\337\362n\342\360\274\v\005\065\366LJ", length=16) at /redacted/bitsharesx/libraries/fc/src/network/rate_limiting.cpp:249
#8 0x0000000000a5ccc7 in fc::ostream::write (this=this@entry=0x7ff07048fed8, buf=buf@entry=0x7ff049e6d7a0 "\337\362n\342\360\274\v\005\065\366LJ", len=16)
at /redacted/bitsharesx/libraries/fc/src/io/iostream.cpp:365
#9 0x0000000000be22ae in bts::net::stcp_socket::writesome (this=0x7ff07048fe80, buffer=0x7ff070001fb0 "\b", len=<optimized out>)
at /redacted/bitsharesx/libraries/net/stcp_socket.cpp:93
#10 0x0000000000a5ccc7 in fc::ostream::write (this=this@entry=0x7ff07048fe80, buf=buf@entry=0x7ff070001fb0 "\b", len=len@entry=16)
at /redacted/bitsharesx/libraries/fc/src/io/iostream.cpp:365
#11 0x0000000000bc30d0 in bts::net::detail::message_oriented_connection_impl::send_message (this=0x7ff07048fe70, message_to_send=...)
at /redacted/bitsharesx/libraries/net/message_oriented_connection.cpp:251
#12 0x0000000000bc3bb8 in bts::net::message_oriented_connection::send_message (this=this@entry=0x7ff070465af8, message_to_send=...)
at /redacted/bitsharesx/libraries/net/message_oriented_connection.cpp:328
#13 0x0000000000bbda96 in bts::net::peer_connection::send_queued_messages_task (this=0x7ff070465a90)
at /redacted/bitsharesx/libraries/net/peer_connection.cpp:236
#14 0x0000000000bbf5dc in operator() (__closure=<optimized out>) at /redacted/bitsharesx/libraries/net/peer_connection.cpp:301
#15 fc::detail::void_functor_run<bts::net::peer_connection::send_message(const bts::net::message&)::<lambda()> >::run(void *, void *) (functor=<optimized out>,
prom=0x7ff070466660) at /redacted/bitsharesx/libraries/fc/include/fc/thread/task.hpp:83
#16 0x0000000000a4e115 in fc::task_base::run_impl (this=0x7ff070466670) at /redacted/bitsharesx/libraries/fc/src/thread/task.cpp:43
#17 0x0000000000a4cbb3 in run_next_task (this=<optimized out>) at /redacted/bitsharesx/libraries/fc/src/thread/thread_d.hpp:398
#18 fc::thread_d::process_tasks (this=0x7ff0700008c0) at /redacted/bitsharesx/libraries/fc/src/thread/thread_d.hpp:422
#19 0x0000000000a4ce21 in fc::thread_d::start_process_tasks (my=140670647929024) at /redacted/bitsharesx/libraries/fc/src/thread/thread_d.hpp:378
#20 0x0000000000deedee in make_fcontext ()
#21 0x00007ff0700008c0 in ?? ()
#22 0x0000000000000000 in ?? ()
Please let me know if you can repeat this error in further runs. Also, before you shut down, can you check how many connections and how much memory you are using? Are you just operating with default settings, or have you increased node count or anything like that?
Dan N. reports they have duplicated this crash and have a probable fix. It will have to wait for 0.4.12.
-
Windows 64 bit version was just posted by DAC Sun Limited...
https://github.com/dacsunlimited/bitsharesx/releases
This version should be significantly faster than the 32 bit version, but may have new undiscovered crashes. Please test.
-
Windows 64 bit version was just posted by DAC Sun Limited...
https://github.com/dacsunlimited/bitsharesx/releases
This version should be significantly faster than the 32 bit version, but may have new undiscovered crashes. Please test.
I get error: "The application was unable to start correctly..." for 64-bit version.
-
I run the exe in Wine and it feels much better now. The "check for updates" looks promising. The flickering between the windows also is gone. Props to the devs. Please keep bug fixing for Wine because of people like me with old hardware and Linux only, thaaaaaanks :)
-
I made 2 short orders on bitBTC/BTSX market and I can't cancel both of them !
TYPE PRICE (BTSX/BITBTC) QUANTITY (BITBTC) COST (BTSX) COLLATERAL (BTSX) ACTION
Short 15,500.00 1.00 15,500.00 canceling..
Short 15,800.00 1.00000000 15,799.99999 canceling..
RPC Server Error: In method 'wallet_market_cancel_order': unknown market order (20011)
-
I made 2 short orders on bitBTC/BTSX market and I can't cancel both of them !
TYPE PRICE (BTSX/BITBTC) QUANTITY (BITBTC) COST (BTSX) COLLATERAL (BTSX) ACTION
Short 15,500.00 1.00 15,500.00 canceling..
Short 15,800.00 1.00000000 15,799.99999 canceling..
RPC Server Error: In method 'wallet_market_cancel_order': unknown market order (20011)
There is a wallet_market_cancel_order2 call that may work for you.
-
I made 2 short orders on bitBTC/BTSX market and I can't cancel both of them !
TYPE PRICE (BTSX/BITBTC) QUANTITY (BITBTC) COST (BTSX) COLLATERAL (BTSX) ACTION
Short 15,500.00 1.00 15,500.00 canceling..
Short 15,800.00 1.00000000 15,799.99999 canceling..
RPC Server Error: In method 'wallet_market_cancel_order': unknown market order (20011)
I got the same error. I'm going to take a hiatus from trading until we have a bug free client. At this time I will focus on restoring my balances and canceling previous trades.
-
Windows 64 bit version was just posted by DAC Sun Limited...
https://github.com/dacsunlimited/bitsharesx/releases (https://github.com/dacsunlimited/bitsharesx/releases)
This version should be significantly faster than the 32 bit version, but may have new undiscovered crashes. Please test.
I get error: "The application was unable to start correctly..." for 64-bit version.
Ditto:
(http://i.imgur.com/L23RRkr.png)
-
I made 2 short orders on bitBTC/BTSX market and I can't cancel both of them !
TYPE PRICE (BTSX/BITBTC) QUANTITY (BITBTC) COST (BTSX) COLLATERAL (BTSX) ACTION
Short 15,500.00 1.00 15,500.00 canceling..
Short 15,800.00 1.00000000 15,799.99999 canceling..
RPC Server Error: In method 'wallet_market_cancel_order': unknown market order (20011)
There is a wallet_market_cancel_order2 call that may work for you.
on "Overview" tab I see one of them pending (?) ...
How can I find the order id for both to cancel them?
-
@dani
wallet_market_order_list <base_symbol> <quote_symbol> [limit] [account_name]
wallet_market_order_list2 <base_symbol> <quote_symbol> [limit] [account_name]
blockchain_list_pending_transactions
-
Ohhh
'Account Orders History'
Finally, cool! +5%
-
I made 2 short orders on bitBTC/BTSX market and I can't cancel both of them !
TYPE PRICE (BTSX/BITBTC) QUANTITY (BITBTC) COST (BTSX) COLLATERAL (BTSX) ACTION
Short 15,500.00 1.00 15,500.00 canceling..
Short 15,800.00 1.00000000 15,799.99999 canceling..
RPC Server Error: In method 'wallet_market_cancel_order': unknown market order (20011)
There is a wallet_market_cancel_order2 call that may work for you.
on "Overview" tab I see one of them pending (?) ...
How can I find the order id for both to cancel them?
I "canceled" my shorts by buying bitBTC with the pricing of my shorts (?) and covered my position...
PS To refresh my bitBTC balance so I can cover my position I must go all the time to console and "wallet_rescan_blockchain" !!!
on the previous versions the balances after order executions are automatically refreshed to the new balance stand (now manual only!)
thanks but I didn't use them as said...
@dani
wallet_market_order_list <base_symbol> <quote_symbol> [limit] [account_name]
wallet_market_order_list2 <base_symbol> <quote_symbol> [limit] [account_name]
blockchain_list_pending_transactions
-
updating to RC2
completed.
looks no problem
mtang.outofcontrol
-
I "canceled" my shorts by buying bitBTC with the pricing of my shorts (?) and covered my position...
How did you close them without the transaction ID?
Or did you do it in the GUI? If so just check if you are not long and short those bitBTCs.
-
after run wallet_regenerate_keys
the wallet_scan_progress always run from 0%~1.2%, again and again
version rc1 is ok, but rc2 can't work
-
The GUI is misrepresenting, the margin orders info - the 'Total' by doing, I do not exactly know what with the amount; and 'Collateral' by dividing it by 1000.
-
forget it, I have repair my wallet by import from an init json file.
maybe the backup json file is not good, which is backup automatic from a upgrade.
after run wallet_regenerate_keys
the wallet_scan_progress always run from 0%~1.2%, again and again
version rc1 is ok, but rc2 can't work
-
Still needs work. Transaction scanning seems to be stuck at 0% progress. Still unable to recover lost balances, but it isn't crashing anymore at least.
Considering I managed to refresh my new balances (after new orders executed) rescaning the blockchain it must be only a visual bug (0% progress)
-
Windows 64 bit version was just posted by DAC Sun Limited...
https://github.com/dacsunlimited/bitsharesx/releases (https://github.com/dacsunlimited/bitsharesx/releases)
This version should be significantly faster than the 32 bit version, but may have new undiscovered crashes. Please test.
I get error: "The application was unable to start correctly..." for 64-bit version.
Ditto:
(http://i.imgur.com/L23RRkr.png)
Same issue for me too, is their going to be another build released soon or should we just go back to using the old version?
-
Windows 64 bit version was just posted by DAC Sun Limited...
https://github.com/dacsunlimited/bitsharesx/releases (https://github.com/dacsunlimited/bitsharesx/releases)
This version should be significantly faster than the 32 bit version, but may have new undiscovered crashes. Please test.
I get error: "The application was unable to start correctly..." for 64-bit version.
Ditto:
(http://i.imgur.com/L23RRkr.png)
Same issue for me too, is their going to be another build released soon or should we just go back to using the old version?
32 Bit Version worked for me.
-
updating to RC2
expect a good result
-
Windows 64 bit version was just posted by DAC Sun Limited...
https://github.com/dacsunlimited/bitsharesx/releases (https://github.com/dacsunlimited/bitsharesx/releases)
This version should be significantly faster than the 32 bit version, but may have new undiscovered crashes. Please test.
I get error: "The application was unable to start correctly..." for 64-bit version.
Ditto:
(http://i.imgur.com/L23RRkr.png)
Same issue for me too, is their going to be another build released soon or should we just go back to using the old version?
32 Bit Version worked for me.
It only seems to be a issue with the 64 bit version. Has anyone been able to run the 64bit version successfully?
-
confirmed. 64 bit has issues. I get the exact same error on my windows 8.1 64 bit.
-
after run wallet_regenerate_keys
the wallet_scan_progress always run from 0%~1.2%, again and again
version rc1 is ok, but rc2 can't work
This may be fixed in the next version.
-
update to 0.4.11-RC2