New release 2.0.151209

[monsterer]

I'm getting weird errors trying to send transactions in the latest build - help would be appreciated:

https://bitsharestalk.org/index.php/topic,20683.0.html

[abit]

in.abit updated to v2.0.151216b.

[wackou]

wackou updated to v2.0.121516b

[bytemaster]

I'm running the original 2.0 Light Client I don't want to keep updating every week. Will my original 2.o Light Client be fine to run and will my 2.0 coins still work if I send them from my original 2.0 client to an exchange?

The nice thing about light clients is that you don't have to update them if they currently work for you. 

[Marketorder]

I'm running the original 2.0 Light Client I don't want to keep updating every week. Will my original 2.o Light Client be fine to run and will my 2.0 coins still work if I send them from my original 2.0 client to an exchange?

[cube]

bitcube updated. All nodes updated to v2.0.121516b

[Thom]

Verbaltech2: all seed nodes and witness updated to v2.0.121516b

[sudo]

why BitShares2-light &BitShares-2.0.151215-x64-cli-tools.exe  can't  support 32bit windows?

[rnglab]

Building 16b now: https://github.com/bitshares/bitshares-2/releases/tag/v2.0.151216b

https://bitsharestalk.org/index.php/topic,19040.msg266736.html#msg266736

[abit]

This should now be fixed on the BitShares branch.  I'm replaying in Debug mode now, I'll tag a release as soon as I make sure it finishes.

Thanks. Noticed the new release 2.0.151216b. Building.

[abit]

Witness in.abit updated to v2.0.151215, and running/testing v2.0.151216 with a backup node, will switch over after some hours.

[theoretical]

This should now be fixed on the BitShares branch.  I'm replaying in Debug mode now, I'll tag a release as soon as I make sure it finishes.

[abit]

Those who are suffering from crashes are operating in debug mode.  We will have a update for this crash shortly.  In the meantime, running in release mode should fix your problem.

Thanks.
I'm now confirming that Release mode works.
BTW Release node is much faster than Debug mode.

Code: [Select]

1855071ms th_a       db_management.cpp:96          reindex              ] Done reindexing, elapsed time: 202.13984400000001074 sec


[bytemaster]

Those who are suffering from crashes are operating in debug mode.  We will have a update for this crash shortly.  In the meantime, running in release mode should fix your problem.

[clayop]

Same error here, updated from 2.0.151209

Code: [Select]

3023762ms th_a       db_block.cpp:274              push_proposal        ] removing failed operation from applied_ops: {"id":"0.0.0","op":[31,{"fee":{"amount":2000000,"asset_id":"1.3.0"},"new_param
eters":{"current_fees":{"parameters":[[0,{"fee":2000000,"price_per_kbyte":1000000}],[1,{"fee":500000}],[2,{"fee":0}],[3,{"fee":2000000}],[4,{}],[5,{"basic_fee":500000,"premium_fee":200000000,"pric
e_per_kbyte":100000}],[6,{"fee":2000000,"price_per_kbyte":100000}],[7,{"fee":300000}],[8,{"membership_annual_fee":200000000,"membership_lifetime_fee":1000000000}],[9,{"fee":50000000}],[10,{"symbol
3":"50000000000","symbol4":"30000000000","long_symbol":500000000,"price_per_kbyte":10}],[11,{"fee":50000000,"price_per_kbyte":10}],[12,{"fee":50000000}],[13,{"fee":50000000}],[14,{"fee":2000000,"p
rice_per_kbyte":100000}],[15,{"fee":2000000}],[16,{"fee":100000}],[17,{"fee":10000000}],[18,{"fee":50000000}],[19,{"fee":100000}],[20,{"fee":500000000}],[21,{"fee":2000000}],[22,{"fee":2000000,"pr
ice_per_kbyte":10}],[23,{"fee":100000,"price_per_kbyte":10}],[24,{"fee":100000}],[25,{"fee":100000}],[26,{"fee":2000000}],[27,{"fee":0,"price_per_kbyte":10}],[28,{"fee":500000000}],[29,{"fee":1000
00}],[30,{"fee":100000}],[31,{"fee":2000000}],[32,{"fee":500000000}],[33,{"fee":100000}],[34,{"fee":100000}],[35,{"fee":100000,"price_per_kbyte":10}],[36,{"fee":2000000}],[37,{}],[38,{"fee":500000
,"price_per_kbyte":10}],[39,{"fee":500000,"price_per_output":500000}]],"scale":10000},"block_interval":3,"maintenance_interval":3600,"maintenance_skip_slots":3,"committee_proposal_review_period":3
600,"maximum_transaction_size":98304,"maximum_block_size":2097152,"maximum_time_until_expiration":86400,"maximum_proposal_lifetime":2419200,"maximum_asset_whitelist_authorities":10,"maximum_asset_
feed_publishers":10,"maximum_witness_count":1001,"maximum_committee_count":1001,"maximum_authority_membership":10,"reserve_percent_of_fee":2000,"network_percent_of_fee":2000,"lifetime_referrer_per
cent_of_fee":3000,"cashback_vesting_period_seconds":7776000,"cashback_vesting_threshold":10000000,"count_non_member_votes":true,"allow_non_member_whitelists":false,"witness_pay_per_block":150000,"
worker_budget_per_day":"50000000000","max_predicate_opcode":1,"fee_liquidation_threshold":10000000,"accounts_per_fee_scale":1000,"account_fee_scale_bitshifts":4,"max_authority_depth":2,"extensions
":[]}}],"result":[0,{}],"block_num":29382,"trx_in_block":0,"op_in_trx":1,"virtual_op":42699}
3023763ms th_a       db_block.cpp:282              push_proposal        ] e
3023765ms th_a       db_update.cpp:180             clear_expired_propos ] Failed to apply proposed transaction on its expiration. Deleting it.
{"id":"1.10.1","expiration_time":"2015-10-14T15:29:00","review_period_time":"2015-10-14T14:29:00","proposed_transaction":{"ref_block_num":0,"ref_block_prefix":0,"expiration":"2015-10-14T15:29:00",
"operations":[[31,{"fee":{"amount":2000000,"asset_id":"1.3.0"},"new_parameters":{"current_fees":{"parameters":[[0,{"fee":2000000,"price_per_kbyte":1000000}],[1,{"fee":500000}],[2,{"fee":0}],[3,{"f
ee":2000000}],[4,{}],[5,{"basic_fee":500000,"premium_fee":200000000,"price_per_kbyte":100000}],[6,{"fee":2000000,"price_per_kbyte":100000}],[7,{"fee":300000}],[8,{"membership_annual_fee":200000000
,"membership_lifetime_fee":1000000000}],[9,{"fee":50000000}],[10,{"symbol3":"50000000000","symbol4":"30000000000","long_symbol":500000000,"price_per_kbyte":10}],[11,{"fee":50000000,"price_per_kbyt
e":10}],[12,{"fee":50000000}],[13,{"fee":50000000}],[14,{"fee":2000000,"price_per_kbyte":100000}],[15,{"fee":2000000}],[16,{"fee":100000}],[17,{"fee":10000000}],[18,{"fee":50000000}],[19,{"fee":10
0000}],[20,{"fee":500000000}],[21,{"fee":2000000}],[22,{"fee":2000000,"price_per_kbyte":10}],[23,{"fee":100000,"price_per_kbyte":10}],[24,{"fee":100000}],[25,{"fee":100000}],[26,{"fee":2000000}],[
27,{"fee":0,"price_per_kbyte":10}],[28,{"fee":500000000}],[29,{"fee":100000}],[30,{"fee":100000}],[31,{"fee":2000000}],[32,{"fee":500000000}],[33,{"fee":100000}],[34,{"fee":100000}],[35,{"fee":100
000,"price_per_kbyte":10}],[36,{"fee":2000000}],[37,{}],[38,{"fee":500000,"price_per_kbyte":10}],[39,{"fee":500000,"price_per_output":500000}]],"scale":10000},"block_interval":3,"maintenance_inter
val":3600,"maintenance_skip_slots":3,"committee_proposal_review_period":3600,"maximum_transaction_size":98304,"maximum_block_size":2097152,"maximum_time_until_expiration":86400,"maximum_proposal_l
ifetime":2419200,"maximum_asset_whitelist_authorities":10,"maximum_asset_feed_publishers":10,"maximum_witness_count":1001,"maximum_committee_count":1001,"maximum_authority_membership":10,"reserve_
percent_of_fee":2000,"network_percent_of_fee":2000,"lifetime_referrer_percent_of_fee":3000,"cashback_vesting_period_seconds":7776000,"cashback_vesting_threshold":10000000,"count_non_member_votes":
true,"allow_non_member_whitelists":false,"witness_pay_per_block":150000,"worker_budget_per_day":"50000000000","max_predicate_opcode":1,"fee_liquidation_threshold":10000000,"accounts_per_fee_scale"
:1000,"account_fee_scale_bitshifts":4,"max_authority_depth":2,"extensions":[]}}]],"extensions":[]},"required_active_approvals":["1.2.0"],"available_active_approvals":["1.2.90743","1.2.90744","1.2.
90745","1.2.90746","1.2.90747","1.2.90748","1.2.90749","1.2.90750","1.2.90751","1.2.90752"],"required_owner_approvals":[],"available_owner_approvals":[],"available_key_approvals":[]}
10 assert_exception: Assert Exception
itr->get_balance() >= -delta: Insufficient Balance: committee-account's balance of 0 BTS is less than required 20 BTS
    {"a":"committee-account","b":"0 BTS","r":"20 BTS"}
    th_a  db_balance.cpp:70 adjust_balance
    {"account":"1.2.0","delta":{"amount":-2000000,"asset_id":"1.3.0"}}
    th_a  db_balance.cpp:76 adjust_balance
    {}
    th_a  evaluator.cpp:46 start_evaluate
    {}
    th_a  db_block.cpp:645 apply_operation
    {"proposal":{"id":"1.10.1","expiration_time":"2015-10-14T15:29:00","review_period_time":"2015-10-14T14:29:00","proposed_transaction":{"ref_block_num":0,"ref_block_prefix":0,"expiration":"2015-
10-14T15:29:00","operations":[[31,{"fee":{"amount":2000000,"asset_id":"1.3.0"},"new_parameters":{"current_fees":{"parameters":[[0,{"fee":2000000,"price_per_kbyte":1000000}],[1,{"fee":500000}],[2,{
"fee":0}],[3,{"fee":2000000}],[4,{}],[5,{"basic_fee":500000,"premium_fee":200000000,"price_per_kbyte":100000}],[6,{"fee":2000000,"price_per_kbyte":100000}],[7,{"fee":300000}],[8,{"membership_annua
l_fee":200000000,"membership_lifetime_fee":1000000000}],[9,{"fee":50000000}],[10,{"symbol3":"50000000000","symbol4":"30000000000","long_symbol":500000000,"price_per_kbyte":10}],[11,{"fee":50000000
,"price_per_kbyte":10}],[12,{"fee":50000000}],[13,{"fee":50000000}],[14,{"fee":2000000,"price_per_kbyte":100000}],[15,{"fee":2000000}],[16,{"fee":100000}],[17,{"fee":10000000}],[18,{"fee":50000000
}],[19,{"fee":100000}],[20,{"fee":500000000}],[21,{"fee":2000000}],[22,{"fee":2000000,"price_per_kbyte":10}],[23,{"fee":100000,"price_per_kbyte":10}],[24,{"fee":100000}],[25,{"fee":100000}],[26,{"fee":2000000}],[27,{"fee":0,"price_per_kbyte":10}],[28,{"fee":500000000}],[29,{"fee":100000}],[30,{"fee":100000}],[31,{"fee":2000000}],[32,{"fee":500000000}],[33,{"fee":100000}],[34,{"fee":100000}],[35,{"fee":100000,"price_per_kbyte":10}],[36,{"fee":2000000}],[37,{}],[38,{"fee":500000,"price_per_kbyte":10}],[39,{"fee":500000,"price_per_output":500000}]],"scale":10000},"block_interval":3,"maintenance_interval":3600,"maintenance_skip_slots":3,"committee_proposal_review_period":3600,"maximum_transaction_size":98304,"maximum_block_size":2097152,"maximum_time_until_expiration":86400,"maximum_proposal_lifetime":2419200,"maximum_asset_whitelist_authorities":10,"maximum_asset_feed_publishers":10,"maximum_witness_count":1001,"maximum_committee_count":1001,"maximum_authority_membership":10,"reserve_percent_of_fee":2000,"network_percent_of_fee":2000,"lifetime_referrer_percent_of_fee":3000,"cashback_vesting_period_seconds":7776000,"cashback_vesting_threshold":10000000,"count_non_member_votes":true,"allow_non_member_whitelists":false,"witness_pay_per_block":150000,"worker_budget_per_day":"50000000000","max_predicate_opcode":1,"fee_liquidation_threshold":10000000,"accounts_per_fee_scale":1000,"account_fee_scale_bitshifts":4,"max_authority_depth":2,"extensions":[]}}]],"extensions":[]},"required_active_approvals":["1.2.0"],"available_active_approvals":["1.2.90743","1.2.90744","1.2.90745","1.2.90746","1.2.90747","1.2.90748","1.2.90749","1.2.90750","1.2.90751","1.2.90752"],"required_owner_approvals":[],"available_owner_approvals":[],"available_key_approvals":[]}}
    th_a  db_block.cpp:288 push_proposal
3023769ms th_a       account_history_plugin.cpp:86 update_account_histo ] removing failed operation with ID: 1.11.11199
witness_node: /home/clayop/bitshares-2/libraries/fc/include/fc/optional.hpp:202: const T* fc::optional<T>::operator->() const [with T = graphene::chain::operation_history_object]: Assertion `_valid' failed.
Aborted (core dumped)

[abit]

@bytemaster @theoretical  v2.0.151216 is unable to start with parameter --replay-blockchain on my node. I'm upgrading from v2.0.151215.
Program received signal SIGABRT, Aborted.
Logs are attached below.
Will try again.

//UPDATE: still doesn't work with a backup blockchain folder which produced by v2.0.151209. Trying with --resync-blockchain.

//UPDATE2: resync failed.

Any idea?
Ubuntu 14.04.3 LTS x86_64, build with boost_1_57_0 and -DCMAKE_BUILD_TYPE=Debug

Code: [Select]

2291830ms th_a       db_block.cpp:282              push_proposal        ] e
2291831ms th_a       db_update.cpp:180             clear_expired_propos ] Failed to apply proposed transaction on its expiration. Dele
ting it.
{"id":"1.10.1","expiration_time":"2015-10-14T15:29:00","review_period_time":"2015-10-14T14:29:00","proposed_transaction":{"ref_block_n
um":0,"ref_block_prefix":0,"expiration":"2015-10-14T15:29:00","operations":[[31,{"fee":{"amount":2000000,"asset_id":"1.3.0"},"new_para
meters":{"current_fees":{"parameters":[[0,{"fee":2000000,"price_per_kbyte":1000000}],[1,{"fee":500000}],[2,{"fee":0}],[3,{"fee":200000
0}],[4,{}],[5,{"basic_fee":500000,"premium_fee":200000000,"price_per_kbyte":100000}],[6,{"fee":2000000,"price_per_kbyte":100000}],[7,{
"fee":300000}],[8,{"membership_annual_fee":200000000,"membership_lifetime_fee":1000000000}],[9,{"fee":50000000}],[10,{"symbol3":"50000
000000","symbol4":"30000000000","long_symbol":500000000,"price_per_kbyte":10}],[11,{"fee":50000000,"price_per_kbyte":10}],[12,{"fee":5
0000000}],[13,{"fee":50000000}],[14,{"fee":2000000,"price_per_kbyte":100000}],[15,{"fee":2000000}],[16,{"fee":100000}],[17,{"fee":1000
0000}],[18,{"fee":50000000}],[19,{"fee":100000}],[20,{"fee":500000000}],[21,{"fee":2000000}],[22,{"fee":2000000,"price_per_kbyte":10}]
,[23,{"fee":100000,"price_per_kbyte":10}],[24,{"fee":100000}],[25,{"fee":100000}],[26,{"fee":2000000}],[27,{"fee":0,"price_per_kbyte":
10}],[28,{"fee":500000000}],[29,{"fee":100000}],[30,{"fee":100000}],[31,{"fee":2000000}],[32,{"fee":500000000}],[33,{"fee":100000}],[3
4,{"fee":100000}],[35,{"fee":100000,"price_per_kbyte":10}],[36,{"fee":2000000}],[37,{}],[38,{"fee":500000,"price_per_kbyte":10}],[39,{
"fee":500000,"price_per_output":500000}]],"scale":10000},"block_interval":3,"maintenance_interval":3600,"maintenance_skip_slots":3,"co
mmittee_proposal_review_period":3600,"maximum_transaction_size":98304,"maximum_block_size":2097152,"maximum_time_until_expiration":864
00,"maximum_proposal_lifetime":2419200,"maximum_asset_whitelist_authorities":10,"maximum_asset_feed_publishers":10,"maximum_witness_co
unt":1001,"maximum_committee_count":1001,"maximum_authority_membership":10,"reserve_percent_of_fee":2000,"network_percent_of_fee":2000
,"lifetime_referrer_percent_of_fee":3000,"cashback_vesting_period_seconds":7776000,"cashback_vesting_threshold":10000000,"count_non_me
mber_votes":true,"allow_non_member_whitelists":false,"witness_pay_per_block":150000,"worker_budget_per_day":"50000000000","max_predica
te_opcode":1,"fee_liquidation_threshold":10000000,"accounts_per_fee_scale":1000,"account_fee_scale_bitshifts":4,"max_authority_depth":
2,"extensions":[]}}]],"extensions":[]},"required_active_approvals":["1.2.0"],"available_active_approvals":["1.2.90743","1.2.90744","1.
2.90745","1.2.90746","1.2.90747","1.2.90748","1.2.90749","1.2.90750","1.2.90751","1.2.90752"],"required_owner_approvals":[],"available
_owner_approvals":[],"available_key_approvals":[]}
10 assert_exception: Assert Exception
itr->get_balance() >= -delta: Insufficient Balance: committee-account's balance of 0 BTS is less than required 20 BTS
    {"a":"committee-account","b":"0 BTS","r":"20 BTS"}
    th_a  db_balance.cpp:70 adjust_balance

    {"account":"1.2.0","delta":{"amount":-2000000,"asset_id":"1.3.0"}}
    th_a  db_balance.cpp:76 adjust_balance

    {}
    th_a  evaluator.cpp:46 start_evaluate

    {}
    th_a  db_block.cpp:645 apply_operation

    {"proposal":{"id":"1.10.1","expiration_time":"2015-10-14T15:29:00","review_period_time":"2015-10-14T14:29:00","proposed_transactio
n":{"ref_block_num":0,"ref_block_prefix":0,"expiration":"2015-10-14T15:29:00","operations":[[31,{"fee":{"amount":2000000,"asset_id":"1
.3.0"},"new_parameters":{"current_fees":{"parameters":[[0,{"fee":2000000,"price_per_kbyte":1000000}],[1,{"fee":500000}],[2,{"fee":0}],
[3,{"fee":2000000}],[4,{}],[5,{"basic_fee":500000,"premium_fee":200000000,"price_per_kbyte":100000}],[6,{"fee":2000000,"price_per_kbyt
e":100000}],[7,{"fee":300000}],[8,{"membership_annual_fee":200000000,"membership_lifetime_fee":1000000000}],[9,{"fee":50000000}],[10,{
"symbol3":"50000000000","symbol4":"30000000000","long_symbol":500000000,"price_per_kbyte":10}],[11,{"fee":50000000,"price_per_kbyte":1
0}],[12,{"fee":50000000}],[13,{"fee":50000000}],[14,{"fee":2000000,"price_per_kbyte":100000}],[15,{"fee":2000000}],[16,{"fee":100000}]
,[17,{"fee":10000000}],[18,{"fee":50000000}],[19,{"fee":100000}],[20,{"fee":500000000}],[21,{"fee":2000000}],[22,{"fee":2000000,"price
_per_kbyte":10}],[23,{"fee":100000,"price_per_kbyte":10}],[24,{"fee":100000}],[25,{"fee":100000}],[26,{"fee":2000000}],[27,{"fee":0,"p
rice_per_kbyte":10}],[28,{"fee":500000000}],[29,{"fee":100000}],[30,{"fee":100000}],[31,{"fee":2000000}],[32,{"fee":500000000}],[33,{"
fee":100000}],[34,{"fee":100000}],[35,{"fee":100000,"price_per_kbyte":10}],[36,{"fee":2000000}],[37,{}],[38,{"fee":500000,"price_per_k
byte":10}],[39,{"fee":500000,"price_per_output":500000}]],"scale":10000},"block_interval":3,"maintenance_interval":3600,"maintenance_s
kip_slots":3,"committee_proposal_review_period":3600,"maximum_transaction_size":98304,"maximum_block_size":2097152,"maximum_time_until
_expiration":86400,"maximum_proposal_lifetime":2419200,"maximum_asset_whitelist_authorities":10,"maximum_asset_feed_publishers":10,"ma
ximum_witness_count":1001,"maximum_committee_count":1001,"maximum_authority_membership":10,"reserve_percent_of_fee":2000,"network_perc
ent_of_fee":2000,"lifetime_referrer_percent_of_fee":3000,"cashback_vesting_period_seconds":7776000,"cashback_vesting_threshold":100000
00,"count_non_member_votes":true,"allow_non_member_whitelists":false,"witness_pay_per_block":150000,"worker_budget_per_day":"500000000
00","max_predicate_opcode":1,"fee_liquidation_threshold":10000000,"accounts_per_fee_scale":1000,"account_fee_scale_bitshifts":4,"max_a
uthority_depth":2,"extensions":[]}}]],"extensions":[]},"required_active_approvals":["1.2.0"],"available_active_approvals":["1.2.90743"
,"1.2.90744","1.2.90745","1.2.90746","1.2.90747","1.2.90748","1.2.90749","1.2.90750","1.2.90751","1.2.90752"],"required_owner_approval
s":[],"available_owner_approvals":[],"available_key_approvals":[]}}
    th_a  db_block.cpp:288 push_proposal
2291832ms th_a       account_history_plugin.cpp:86 update_account_histo ] removing failed operation with ID: 1.11.11199
witness_node: /app/bts/bts2-2.0.151216/libraries/fc/include/fc/optional.hpp:202: const T* fc::optional<T>::operator->() const [with T
= graphene::chain::operation_history_object]: Assertion `_valid' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff6c01cc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.

(gdb) bt
#0  0x00007ffff6c01cc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff6c050d8 in __GI_abort () at abort.c:89
#2  0x00007ffff6bfab86 in __assert_fail_base (fmt=0x7ffff6d4b830 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
    assertion=assertion@entry=0x2c4195e "_valid",
    file=file@entry=0x2c41920 "/app/bts/bts2-2.0.151216/libraries/fc/include/fc/optional.hpp", line=line@entry=202,
    function=function@entry=0x2c42320 <fc::optional<graphene::chain::operation_history_object>::operator->() const::__PRETTY_FUNCTION__> "const T* fc::optional<T>::operator->() const [with T = graphene::chain::operation_history_object]") at assert.c:92
#3  0x00007ffff6bfac32 in __GI___assert_fail (assertion=0x2c4195e "_valid",
    file=0x2c41920 "/app/bts/bts2-2.0.151216/libraries/fc/include/fc/optional.hpp", line=202,
    function=0x2c42320 <fc::optional<graphene::chain::operation_history_object>::operator->() const::__PRETTY_FUNCTION__> "const T* fc::optional<T>::operator->() const [with T = graphene::chain::operation_history_object]") at assert.c:101
#4  0x00000000024246ca in fc::optional<graphene::chain::operation_history_object>::operator-> (this=0x7fffef039010)
    at /app/bts/bts2-2.0.151216/libraries/fc/include/fc/optional.hpp:202
#5  0x0000000002421155 in graphene::market_history::detail::market_history_plugin_impl::update_market_histories (this=0x59a1960,
    b=...) at /app/bts/bts2-2.0.151216/libraries/plugins/market_history/market_history_plugin.cpp:221
#6  0x000000000242142c in graphene::market_history::market_history_plugin::__lambda11::operator() (__closure=0x599df50, b=...)
    at /app/bts/bts2-2.0.151216/libraries/plugins/market_history/market_history_plugin.cpp:261
#7  0x0000000002422513 in boost::detail::function::void_function_obj_invoker1<graphene::market_history::market_history_plugin::plugin_initialize(const boost::program_options::variables_map&)::__lambda11, void, const graphene::chain::signed_block&>::invoke(boost::detail::function::function_buffer &, const graphene::chain::signed_block &) (function_obj_ptr=..., a0=...)
    at /app/boost_1_57_0.bin/include/boost/function/function_template.hpp:153
#8  0x00000000024e7225 in boost::function1<void, graphene::chain::signed_block const&>::operator() (this=0x599df48, a0=...)
    at /app/boost_1_57_0.bin/include/boost/function/function_template.hpp:767
#9  0x00000000024e672d in boost::signals2::detail::call_with_tuple_args<boost::signals2::detail::void_type>::m_invoke<boost::function<
void (graphene::chain::signed_block const&)>, 0u, graphene::chain::signed_block const&>(void*, boost::function<void (graphene::chain::signed_block const&)>&, boost::signals2::detail::unsigned_meta_array<0u>, std::tuple<graphene::chain::signed_block const&>) const (
    this=0x7fffffffb4af, func=..., args=...) at /app/boost_1_57_0.bin/include/boost/signals2/detail/variadic_slot_invoker.hpp:92
#10 0x00000000024e5968 in boost::signals2::detail::call_with_tuple_args<boost::signals2::detail::void_type>::operator()<boost::functio
n<void (graphene::chain::signed_block const&)>, graphene::chain::signed_block const&, 1ul>(boost::function<void (graphene::chain::sign
ed_block const&)>&, std::tuple<graphene::chain::signed_block const&>, mpl_::size_t<1ul>) const (this=0x7fffffffb4af, func=...,
    args=...) at /app/boost_1_57_0.bin/include/boost/signals2/detail/variadic_slot_invoker.hpp:81
#11 0x00000000024e3a17 in boost::signals2::detail::variadic_slot_invoker<boost::signals2::detail::void_type, graphene::chain::signed_b


[pc]

Witness cyrano updated.

[rnglab]

By the way my primary node is now running with 2.0.151209 and backup node is with 2.0.151215. I'm able to switch in a few seconds but won't switch so soon.

Same for witness rnglab

[abit]

By the way my primary node is now running with 2.0.151209 and backup node is with 2.0.151215. I'm able to switch in a few seconds but won't switch so soon.

//Update: my primary node updated to 2.0.151215 and testing 2.151216 in a backup node.

[taoljj]

delegate.taolje updated
v2.0.151215

[cube]

bitcube updated to  v2.0.151215. All nodes updated.

[abit]

I've just upgraded and all tx id changed? anyone can confirm?

For example tx id was 1.11.13306 , now it is changed to 1.11.13305.

My system rely on this tx id, as the result i get a lot of duplicate deposits recently, and forced to roll back our bts deposits.

I assume this tx id is not reliable for identifying a transaction? Are we doing it wrong?

Thank you

That would a completely critical failure - @bytemaster, @xeroc can you confirm

confirmed ..
There was a security issue that has been fixed now that resulted in a change in opIDs ..
it's unfortunate but necessary .. It could definitely have been communicated better.

As an alternative for a unique identifier I would recommend the transaction HASH which is given by get_block and can be derived from any signed transaction by using the cli_wallet's call "get_transaction_id" ... it has the form of a transaction id in bitcoin and will NEVER change because it is signed by the user and a change in the transaction would invalidate the signature of the user

Which version introduced this issue? Imo if it's 2.0.151215 we may postpone this update.

[pc]

1. How soon?
2. Will that be another required (for witnesses) update?

[theoretical]

We're aware of the operation history renumbering issue and a patch which will restore the old numbering should be available soon.

[Thom]

verbaltech2 has updated all seed nodes and the witness.

[ngkong]

Wow. Just wow. So, all the unique id's which exchanges have been diligently filing and storing are now worthless? Or worse still after exchanges upgrade they can be subject to double spends against users deposits since the the original deposit txid is now totally different?

The amount of affected operation IDs is (as per my understanding) limited to only a few hours worth of transactions .. definitely not all of them ..

definitely not "only a few hours worth of transactions"

in my case: 

oldest tx: 1.11.13306 (dated  16-Oct-15) changed to  1.11.13305
latest tx:  1.11.356893 (dated  21-Nov-15 ) changed to  1.11.356892

we got no deposit after 21-Nov-15

[monsterer]

Wow. Just wow. So, all the unique id's which exchanges have been diligently filing and storing are now worthless? Or worse still after exchanges upgrade they can be subject to double spends against users deposits since the the original deposit txid is now totally different?

The amount of affected operation IDs is (as per my understanding) limited to only a few hours worth of transactions .. definitely not all of them ..

This really needs clarifying as it is critical for all exchanges processing transactions. All exchanges must be notified of the recommend course of action to prevent double crediting users.

[xeroc]

Wow. Just wow. So, all the unique id's which exchanges have been diligently filing and storing are now worthless? Or worse still after exchanges upgrade they can be subject to double spends against users deposits since the the original deposit txid is now totally different?

The amount of affected operation IDs is (as per my understanding) limited to only a few hours worth of transactions .. definitely not all of them ..

[monsterer]

confirmed ..
There was a security issue that has been fixed now that resulted in a change in opIDs ..
it's unfortunate but necessary .. It could definitely have been communicated better.

As an alternative for a unique identifier I would recommend the transaction HASH which is given by get_block and can be derived from any signed transaction by using the cli_wallet's call "get_transaction_id" ... it has the form of a transaction id in bitcoin and will NEVER change because it is signed by the user and a change in the transaction would invalidate the signature of the user

Wow. Just wow. So, all the unique id's which exchanges have been diligently filing and storing are now worthless? Or worse still after exchanges upgrade they can be subject to double spends against users deposits since the the original deposit txid is now totally different?

[xeroc]

I've just upgraded and all tx id changed? anyone can confirm?

For example tx id was 1.11.13306 , now it is changed to 1.11.13305.

My system rely on this tx id, as the result i get a lot of duplicate deposits recently, and forced to roll back our bts deposits.

I assume this tx id is not reliable for identifying a transaction? Are we doing it wrong?

Thank you

That would a completely critical failure - @bytemaster, @xeroc can you confirm

confirmed ..
There was a security issue that has been fixed now that resulted in a change in opIDs ..
it's unfortunate but necessary .. It could definitely have been communicated better.

As an alternative for a unique identifier I would recommend the transaction HASH which is given by get_block and can be derived from any signed transaction by using the cli_wallet's call "get_transaction_id" ... it has the form of a transaction id in bitcoin and will NEVER change because it is signed by the user and a change in the transaction would invalidate the signature of the user

[clayop]

delegate-clayop is updated to v2.0.151215

[Bhuz]

Or since all the blocks are produced by witnesses and they have updated, they will be the ones "handling" the fork and everyone will be automatically stay in the right chain?

This

[monsterer]

I've just upgraded and all tx id changed? anyone can confirm?

For example tx id was 1.11.13306 , now it is changed to 1.11.13305.

My system rely on this tx id, as the result i get a lot of duplicate deposits recently, and forced to roll back our bts deposits.

I assume this tx id is not reliable for identifying a transaction? Are we doing it wrong?

Thank you

That would a completely critical failure - @bytemaster, @xeroc can you confirm

[ngkong]

I've just upgraded and all tx id changed? anyone can confirm?

For example tx id was 1.11.13306 , now it is changed to 1.11.13305.

My system rely on this tx id, as the result i get a lot of duplicate deposits recently, and forced to roll back our bts deposits.

I assume this tx id is not reliable for identifying a transaction? Are we doing it wrong?

Thank you

[spartako]

spartako updated to v2.0.151215

[Akado]

Shouldn't it be a release version for the light client users too since there will be a hardfork today? All I see is the cli_tools.exe which I think is for whoever is running the CLI like witnesses?

Or since all the blocks are produced by witnesses and they have updated, they will be the ones "handling" the fork and everyone will be automatically stay in the right chain?

[Harvey]

harvey-xts updated
v2.0.151215

[BunkerChainLabs-DataSecurityNode]

datasecuritynode updated to v2.0.151215

[abit]

@theoretical @cass Another URGENT update released?
https://github.com/bitshares/bitshares-2/releases/tag/v2.0.151215

"All full nodes will need to upgrade to this release by Thu 2015-12-17 at 19:00 UTC", it's just one day after the coming hard-fork introduced by v2.0.151209.

[taoljj]

witness delegate.taolje updated

[sudo]

BitShares-2.0.151209-x64-cli-tools.exe

why no 32bit?

[Samupaha]

Cleanup

- Remove unsupported full_web_node and light_client #457

Files seem to be still included.

[alt]

witness delegate.baozi updated
but why can't get the new api?

Code: [Select]

locked >>> propose_builder_transaction2
propose_builder_transaction2
10 assert_exception: Assert Exception
itr != _by_name.end(): no method with name 'propose_builder_transaction2'


[pc]

Witness cyrano updated

[ffwong]

witness dragonball updated
Waiting for more votes to serve the net.

[iHashFury]

Witness,  seed and feed nodes are up-to-date .

Have all exchanges been informed?

[Thom]

Witness and seeds are now updated.

[rnglab]

witness rnglab updated

[wackou]

witness wackou updated

[abit]

Upgrading... Replaying takes about an hour on my machine :p

Update: Done. Now working on backup node and emergency node.

Update2: All nodes have been upgraded.

in.abit upgraded.

Code: [Select]

1106609ms th_a       db_management.cpp:96          reindex              ] Done reindexing, elapsed time: 1914.41913500000009662 sec
(Debug build)

[BunkerChainLabs-DataSecurityNode]

Witness datasecuritynode updated

Latest pricefeed fixes also updated.

[ElMato]

ElMato updated

[clayop]

Is there going to be a full node Windows CLI wallet with this release to replace the one from November 11th?

Also curious about this.

[Xeldal]

Is there going to be a full node Windows CLI wallet with this release to replace the one from November 11th?

[Tuck Fheman]

I'm not complaining, but simply point out what I think is a fact.

We're leaving 98.652% of the Community out when the updates have no binaries included. 

[lafona]

witness delegate-1.lafona updated

[spartako]

witness spartako updated

[Bhuz]

witness bhuz already upgraded

[cube]

Witness bitcube updated.  All nodes updated.

[BunkerChainLabs-DataSecurityNode]

A few witnesses have mentioned that they have replayed after upgrading, while the documentation states that reindexing will be required.

Replaying and reindexing are the same thing.

I'm used to thinking of it as "reindexing" because that's what Bitcoin and BTS 0.x called it, so I'll often say "reindexing" when I'm talking / typing on autopilot.  But "replaying" is the more "official" term used by Graphene and probably better describes what's actually happening (especially because Graphene has a ton more state than Bitcoin to support the markets, etc.)

Thanks for the clarification. I had it stuck in my head that there were both options but it must have been a throwback to 1.0 I was thinking about.

We are upgrading now and will be done by this afternoon.

[theoretical]

A few witnesses have mentioned that they have replayed after upgrading, while the documentation states that reindexing will be required.

Replaying and reindexing are the same thing.

I'm used to thinking of it as "reindexing" because that's what Bitcoin and BTS 0.x called it, so I'll often say "reindexing" when I'm talking / typing on autopilot.  But "replaying" is the more "official" term used by Graphene and probably better describes what's actually happening (especially because Graphene has a ton more state than Bitcoin to support the markets, etc.)

[Bhuz]

I recommend all witnesses upgrade ASAP because we also fixed a security vulnerability that could temporarily take down any witness that has not upgraded.

Is this related? https://bitsharestalk.org/index.php/topic,20486.0.html

[bytemaster]

I recommend all witnesses upgrade ASAP because we also fixed a security vulnerability that could temporarily take down any witness that has not upgraded. 

[Bhuz]

afaik it is the same thing

[BunkerChainLabs-DataSecurityNode]

A few witnesses have mentioned that they have replayed after upgrading, while the documentation states that reindexing will be required.

Can @theoretical confirm that replaying after the upgrade will suffice?

[abit]

Upgrading... Replaying takes about an hour on my machine :p

Sounds not so good.. 

[abit]

A link to this should be posted in the witness status thread, https://bitsharestalk.org/index.php/topic,19040.15.html -- the thread is read-only to me, so I would appreciate if @bytemaster or a mod could post there.

Thanks.
So the "BitShares Upgrade Announcements" post won't be used any more?
https://bitsharestalk.org/index.php/topic,7067.0.html

[sudo]

would it support 32bit os in future?

[Tuck Fheman]

compiling

Since someone else took all the credit for my greatest meme ever, I'm bringing it back just for you!

[twitter]

compiling ...........

done ... updated ...........


witness ( bue )  updated

[clayop]

Upgrading... Replaying takes about an hour on my machine :p

Update: Done. Now working on backup node and emergency node.

Update2: All nodes have been upgraded.

[dichalcog3nid3]

Magnificent news! I have compiled new code and re-played chain successfully!

[cass]

https://bitsharestalk.org/index.php/topic,19040.msg264882.html#msg264882

done

[xeroc]

Very nice .. looking forward to see #445 in action

[theoretical]

A link to this should be posted in the witness status thread, https://bitsharestalk.org/index.php/topic,19040.15.html -- the thread is read-only to me, so I would appreciate if @bytemaster or a mod could post there.

[theoretical]

New release 2.0.151209 at https://github.com/bitshares/bitshares-2/releases

Re-indexing will be required.  Hardfork takes effect at 2015-12-16 at 18:00 UTC.

This release incorporates numerous improvements and fixes.

List of changes
---------------

Market mechanics changes

- Refund order fee on cancellation #445
- Prevent margin call from executing unless feed < call #436

Improvements

- Several API calls added by community members (wackou, Scott Howard) #339
- Add propose_builder_transaction2 RPC

Bugfixes

- Fix referral reward percentages #449 #453 #455
- Improve wallet fee handling #434 #435
- Minor improvements to Javascript integration #439
- Unit testing improvements / bugfixes #413 #437

Cleanup

- Remove unsupported full_web_node and light_client #457

Hardfork #445 changes how we handle the fee paid to create a limit order.  Order objects will now have a deferred_fee field.  For orders created before the hardfork time, fees will be routed as currently and the field will be initialized to 0 to maintain compatibility.  For orders created after the hardfork time, the field will be initialized to the fee.  If the order is cancelled, the fee will be refunded to the order object owner.  If the order is matched, the fee will be routed normally.

Hardfork #436 ensures that you cannot be margin called if the feed says you have sufficient collateral.

This hardfork also retroactively corrects two bugs affecting the referral program.  First, the wallet incorrectly sets the referral percentage, resulting in most accounts referral balances being 1% of
what they should be.  In addition, annual memberships were not being handled correctly.

To ensure that the new code and old code do not split the network, we recommend vesting balance withdrawals should continue to be frozen until the hardfork date passes.