0.4.11 Release Candidate 2 Testing

[Harvey]

update to 0.4.11-RC2

[vikram]

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.

[wesphily]

confirmed. 64 bit has issues. I get the exact same error on my windows 8.1 64 bit.

[Gentso1]

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.

Ditto:

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?

[newtree]

updating to RC2

expect a good result

[GaltReport]

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.

Ditto:

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.

[Gentso1]

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.

Ditto:

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?

[liondani]

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)

[alt]

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

[tonyk]

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.

[alt]

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

[tonyk]

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.

[mtang]

updating to RC2
completed.
looks no problem
mtang.outofcontrol

[liondani]

I made 2 short orders on bitBTC/BTSX market and I can't cancel both of them !

Code: [Select]

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   

[tonyk]

Ohhh

'Account Orders History'

Finally, cool!

[tonyk]

@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   

[liondani]

I made 2 short orders on bitBTC/BTSX market and I can't cancel both of them !

Code: [Select]

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?

[Riverhead]

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.

Ditto:

[luckybit]

I made 2 short orders on bitBTC/BTSX market and I can't cancel both of them !

Code: [Select]

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.

[bytemaster]

I made 2 short orders on bitBTC/BTSX market and I can't cancel both of them !

Code: [Select]

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.

[liondani]

I made 2 short orders on bitBTC/BTSX market and I can't cancel both of them !

Code: [Select]

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)

[38PTSWarrior]

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

[GaltReport]

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.

[bytemaster]

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.

[bytemaster]

This segfault occurs when quitting the GUI (after it has been open for a while).

Code: [Select]

[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.

[sfinder]

updating to RC2

help.chinese
chinese

[gyhy]

updating

[emski]

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:

Code: [Select]

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

[liondani]

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....

[luckybit]

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.

[speedy]

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.

[bytemaster]

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. 

[tonyk]

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

[Gentso1]

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

[tonyk]

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.

[Riverhead]

RC2 is working well as expected. It's nice seeing blocks coming through with multiple transactions.

[bytemaster]

I have asked DAC Sun to produce a Windows 64 bit version.  The crypto is 2x faster in 64 bit.

[tonyk]

Is win binary coming shortly, or my time is better spent upgrading linux to RC2 ?

Ok I see the win version is up.

[vikram]

RC2 released: https://github.com/dacsunlimited/bitsharesx/releases/tag/0.4.11-RC2

More market fixes so RC1 users still will have to upgrade.

[bitcoinerS]

Upgraded delegate node to 0.4.11-rc1 yesterday. Running well so far.

upgraded to 0.4.11-rc2.

[tonyk]

'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),

Code: [Select]

>> 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. 

[CalabiYau]

build and client running without issues so far. 

[bitder]

delegate.bitder updated to 0.4.11-RC1.  No problems so far.

Edit: updated to 0.4.11-RC2. No problems so far.

[bytemaster]

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.

[spartako]

active delegates spartako,spartako1,spartako2 updated to 0.4.11-RC1 without problem:

Code: [Select]

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"
}


[drekrob]

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.

[bernard]

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.

[tonyk]

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.

[dannotestein]

This segfault occurs when quitting the GUI (after it has been open for a while).

Code: [Select]

[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?

[Empirical1.1]

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 

[biophil]

Thanks tonyk and drltc for the explanations. I like it.

Sent from my SCH-S720C using Tapatalk 2

[theoretical]

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.

[tonyk]

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.

[ripplexiaoshan]

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?

[Riverhead]

Chain/Node server updated and running without issue. Linux GUI is running fine and even made  few trades  . 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.

[biophil]

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

[CLains]

Thanks for all the hard work gang.

[ionx]

This segfault occurs when quitting the GUI (after it has been open for a while).

Code: [Select]

[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 ?? ()


[tonyk]

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...

OK I see, 10 % sanity check.

[emski]

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.

[bytemaster]

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.   

[theoretical]

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!

[bytemaster]

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.

[emski]

Should seed nodes and delegates update to this ? (before official release I mean)

[bytemaster]

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.