New release 2.0.151209

[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