如题，今天发现好多人，都退选了，
是否可以有退选的提醒呢？
现在是要时不时的去关注

已经进行过注册节点、更新节点、投票提息等操作，在交易记录中不显示记录。

节点：feilun

问题描述错误，不存在问题。

未注册节点的钱包地址，在该页面显示为候选节点。

版本：v0.9.9
提交节点：Bit Cat

背景：因为节点的 peer count 很低，所以在命令行里添加了参数：--in-peers=200

日志中频繁出现以下报错：

WARN Received extra substream after having already one open in backwards-compatibility mode with PeerId("QmbxgbthEh2Qm72M32VYjVxwgz6Dm6ryZ5UQk3d9hJ6eRp")

此问题在plokadot v0.4.3 中并不会出现。

补充：还有其它的报错

Banning PeerId("QmS8Gi18TmDwLv7Yr5TYmH9vQc2ydRZ8nx7a79pemfguUF") because "Peer is on different chain (our genesis: 0x78be…87c7 theirs: 0xcd89…97b2)"
2019-04-27 12:09:31 Banning a node is a deprecated mechanism that should be removed」

提息或投票时 钱包经常不响应，F12看报错截图：

节点：feilun

Dockerfile:

FROM ubuntu:18.04

ARG VERSION=0.9.8

RUN apt update; apt install -y \
    wget \
    sysstat \
    libssl1.0.0 && \
    rm -rf /var/lib/apt/lists/*

RUN wget https://github.com/chainx-org/ChainX/releases/download/v${VERSION}/chainx-v${VERSION}-x86_64-unknown-linux-gnu.tgz && \
    tar -zxvf chainx-v${VERSION}-x86_64-unknown-linux-gnu.tgz -C /usr/local/bin && \
    rm -f chainx-v${VERSION}-x86_64-unknown-linux-gnu.tgz

EXPOSE 8087

bash:

docker build . -t chainx
docker run -d --restart=always -p 8087:8087 -v $(pwd)/data:/data chainx:latest chainx --key=`key` --validator-name=`validator-name` --name=`name` --base-path=/data --validator --chain=local --pruning archive --block-construction-execution=native --other-execution=native --ws-external

--key=key --validator-name=validator-name --name=name need to replace.

从一个老账户向一个新的账户（刚新增的）转账会发现待领取利息有很多，我测试过大概1000sdot 有70左右的待领取利息，BTC 也存在同样的问题，也会有很多待领取利息，老账户向老账户（已经有过充值挖矿的账户）转账不会出现，有时候利息会大于奖池的数量，导致领取失败，如果一直不领取，账户利息会随着奖池的变化而变化有时增长很快，有时减少很快
mengkeTest

在线钱包一直连接不上服务器，连接超时切换也总是尝试本地websocket 导致连接超时

HLT (原来是mengkeTest)

提现金额=总余额-手续费(0.0004)

提现金额已冻结，但手续费还是可用，可以在币币交易挂单等操作

问题：验证节点可以主动关联任意出块地址，导致无需跑物理节点即可行使验证节点权利
问题描述：
1）验证节点关联网络中不存在的出块地址，则验证节点的奖池会被罚没，最终自动退选，该逻辑正常；
2）验证节点可以关联网络中已存在的任意出块地址，尽管该出块地址已被其他验证节点关联；
3）随意注册验证节点，并关联网络中已被关联的出块地址后，虽然该节点出块数一直为0，但是奖池累计正常；
4）上述“伪验证节点”的漏块数也一直为0，这比正常跑物理节点的验证人更有优势，因为不会有罚款，且无硬件成本；
5）参考实例：STW、hashworld、BugHunter、chainxtester（均为STW节点持有）

提交节点：STW

https://live.blockcypher.com/btc-testnet/tx/a50b1fccee803707730176e7118154fc2ac85c413b7204b1a3d7bfadfbfcbc02/

使用bitx工具，btc充值绑定失败

tx:9982faaadae318d26f9a628292fbfc38ebd8c0fe01d147e315830f9f6afa5c4d

2019-04-13 06:29:56.660 INFO [runtime|xrml_xsystem] height:22401, blockproducer: 74725dad959ffc248a50c9ccc923f772e5df352bb2423616417c94777177876c (5EhPPKHk...)|name:Facebook

====================

stack backtrace:
0: substrate_panic_handler::set::{{closure}}::h6151f83348fe5cb3 (0x561b7cc7731f)
1: rust_panic_with_hook (0x561b7ce5e1e8)
at src/libstd/panicking.rs:478
2: std::panicking::begin_panic::ha17c276b68ef3911 (0x561b7ca37ad4)
3: <chainx_runtime::xexecutive::Executive<System, Block, Context, Payment, AllModules>>::execute_block::hf28d0b5901e8ead2 (0x561b7ca9ad52)
4: chainx_runtime::api::dispatch::hbd978dc53fe9f7c9 (0x561b7c9d0a52)
5: std::panicking::try::do_call::h7ae11b3d4cdfbdfb (0x561b7c45de11)
6: __rust_maybe_catch_panic (0x561b7ce64579)
at src/libpanic_unwind/lib.rs:87
7: substrate_executor::native_executor::safe_call::h13303d24dfa76ef7 (0x561b7c45daf2)
8: <std::thread::local::LocalKey>::with::hf324c8a2d7642d9b (0x561b7c45d516)
9: <chainx_executor::Executor as substrate_executor::native_executor::NativeExecutionDispatch>::dispatch::hffd4afadc7f37f13 (0x561b7c45ce7c)
10: <std::thread::local::LocalKey>::with::he29e68a370bece3e (0x561b7c18d316)
11: <substrate_state_machine::StateMachine<'a, H, B, T, O, Exec>>::execute_aux::h10a9eb4603a2b4ce (0x561b7bfd9ca2)
12: <substrate_state_machine::StateMachine<'a, H, B, T, O, Exec>>::execute_call_with_native_else_wasm_strategy::h01e29a7158eeac09 (0x561b7c0624b2)
13: <substrate_state_machine::StateMachine<'a, H, B, T, O, Exec>>::execute_using_consensus_failure_handler::hb71ec0f91bbf6eca (0x561b7c03ef11)
14: <substrate_client::call_executor::LocalCallExecutor<B, E> as substrate_client::call_executor::CallExecutor<Block, substrate_primitives::hasher::blake2::Blake2Hasher>>::call_at_state::h39de45a6d010cf78 (0x561b7c10cde1)
15: <substrate_client::client::Client<B, E, Block, RA>>::lock_import_and_run::{{closure}}::h576be5145f13c396 (0x561b7c30e2be)
16: <substrate_client::client::Client<B, E, Block, RA> as substrate_consensus_common::block_import::BlockImport>::import_block::h6e2b74ee4ad6ffc3 (0x561b7c2df371)
17: <substrate_finality_grandpa::import::GrandpaBlockImport<B, E, Block, RA, PRA> as substrate_consensus_common::block_import::BlockImport>::import_block::hbc25775dd83ec082 (0x561b7c1f36f2)
18: <substrate_consensus_common::import_queue::BlockImportWorker<B, V>>::import_a_batch_of_blocks::h6640ccd940ec190c (0x561b7bf6162b)
19: std::sys_common::backtrace::__rust_begin_short_backtrace::hc46b607889d60a21 (0x561b7c3f29fe)
20: std::panicking::try::do_call::hefc70362a4239358 (0x561b7bd9a87d)
21: __rust_maybe_catch_panic (0x561b7ce64579)
at src/libpanic_unwind/lib.rs:87
22: <F as alloc::boxed::FnBox>::call_box::hdf3f10eb1475be8f (0x561b7bdb599e)
23: call_once<(),()> (0x561b7ce638bd)
at /rustc/a9da8fc9c267c08cfdb8cf5b39da14f154d12939/src/liballoc/boxed.rs:759
start_thread
at src/libstd/sys_common/thread.rs:14
thread_start
at src/libstd/sys/unix/thread.rs:80
24: start_thread (0x7f32431526da)
25: __clone (0x7f3242c6388e)
26: (0x0)

Thread 'ImportQueueWorker' panicked at 'All extrinsics should have the correct nonce', runtime/src/xexecutive.rs:183

This is a bug. Please report it at:

    https://github.com/chainx-org/ChainX

运行持续报错，信息如下:

stack backtrace:
0: substrate_panic_handler::set::{{closure}}::h6151f83348fe5cb3 (0x564454d5031f)
1: rust_panic_with_hook (0x564454f371e8)
at src/libstd/panicking.rs:478
2: std::panicking::begin_panic::ha17c276b68ef3911 (0x564454b10ad4)
3: <chainx_runtime::xexecutive::Executive<System, Block, Context, Payment, AllModules>>::execute_block::hf28d0b5901e8ead2 (0x564454b73d52)
4: chainx_runtime::api::dispatch::hbd978dc53fe9f7c9 (0x564454aa9a52)
5: std::panicking::try::do_call::h7ae11b3d4cdfbdfb (0x564454536e11)
6: __rust_maybe_catch_panic (0x564454f3d579)
at src/libpanic_unwind/lib.rs:87
7: substrate_executor::native_executor::safe_call::h13303d24dfa76ef7 (0x564454536af2)
8: <std::thread::local::LocalKey>::with::hf324c8a2d7642d9b (0x564454536516)
9: <chainx_executor::Executor as substrate_executor::native_executor::NativeExecutionDispatch>::dispatch::hffd4afadc7f37f13 (0x564454535e7c)
10: <std::thread::local::LocalKey>::with::he29e68a370bece3e (0x564454266316)
11: <substrate_state_machine::StateMachine<'a, H, B, T, O, Exec>>::execute_aux::h10a9eb4603a2b4ce (0x5644540b2ca2)
12: <substrate_state_machine::StateMachine<'a, H, B, T, O, Exec>>::execute_call_with_native_else_wasm_strategy::h01e29a7158eeac09 (0x56445413b4b2)
13: <substrate_state_machine::StateMachine<'a, H, B, T, O, Exec>>::execute_using_consensus_failure_handler::hb71ec0f91bbf6eca (0x564454117f11)
14: <substrate_client::call_executor::LocalCallExecutor<B, E> as substrate_client::call_executor::CallExecutor<Block, substrate_primitives::hasher::blake2::Blake2Hasher>>::call_at_state::h39de45a6d010cf78 (0x5644541e5de1)
15: <substrate_client::client::Client<B, E, Block, RA>>::lock_import_and_run::{{closure}}::h576be5145f13c396 (0x5644543e72be)
16: <substrate_client::client::Client<B, E, Block, RA> as substrate_consensus_common::block_import::BlockImport>::import_block::h6e2b74ee4ad6ffc3 (0x5644543b8371)
17: <substrate_finality_grandpa::import::GrandpaBlockImport<B, E, Block, RA, PRA> as substrate_consensus_common::block_import::BlockImport>::import_block::hbc25775dd83ec082 (0x5644542cc6f2)
18: <substrate_consensus_common::import_queue::BlockImportWorker<B, V>>::import_a_batch_of_blocks::h6640ccd940ec190c (0x56445403a62b)
19: std::sys_common::backtrace::__rust_begin_short_backtrace::hc46b607889d60a21 (0x5644544cb9fe)
20: std::panicking::try::do_call::hefc70362a4239358 (0x564453e7387d)
21: __rust_maybe_catch_panic (0x564454f3d579)
at src/libpanic_unwind/lib.rs:87
22: <F as alloc::boxed::FnBox>::call_box::hdf3f10eb1475be8f (0x564453e8e99e)
23: call_once<(),()> (0x564454f3c8bd)
at /rustc/a9da8fc9c267c08cfdb8cf5b39da14f154d12939/src/liballoc/boxed.rs:759
start_thread
at src/libstd/sys_common/thread.rs:14
thread_start
at src/libstd/sys/unix/thread.rs:80
24: start_thread (0x7f197df1c6da)
25: __clone (0x7f197da2d88e)
26: (0x0)

Thread 'ImportQueueWorker' panicked at 'All extrinsics should have the correct nonce', runtime/src/xexecutive.rs:183

This is a bug. Please report it at:

    https://github.com/chainx-org/ChainX

2019-04-15 07:24:19.807 WARN Received extra substream after having already one open in backwards-compatibility mode with PeerId("QmZ1XaJAXKp88JUnNFJN6ihGVPreAGLpaeNThZuMDGfYj3")
2019-04-15 07:24:20.068 INFO [runtime|xrml_xsystem] height:110964, blockproducer: b1695b946241c43876d07d2a50dc7bd501ca5d7de52f44d1487c95fe8991880f (5G5KdXP2...)|name:zjb0807

The commit you have tagged for v0.9.8 is at c1ca876 but the binary you upload is at 78a8763. Please fix this as the commit will be wrong if I checkout with the tag. And I think you haven't pushed the commits to GH.

版本：v0.9.8
提交节点： Bit Cat

跑了2天多发现程序有几次就会被 退选 ，最后发现网络连接的节点数为0，没找到什么原因，最后重启chainx进程后问题解决。
感觉可能是一个程序关于网络连接处理bug。

我从一个帐户向另一个帐户转sdot，接收帐户的挖矿待领利息变得很多，应该是计算不正确

在线钱包不能投票签名，提息没有问题，应该是前端的bug

Please add support for the 'pruning' option.
This should allows for running the node in 'archive'-modus, which is a necessity for support on Polkascan.

1、钱包页面，投票选举页里的数据可以定时刷新，现在数据好像要手动刷新
2、有地方可以看到miss block 数量。

buildlinks report

version 0.9.9 chainx-multigsi-verify-script

index.js line 39 - 48

多签验证脚本的index.js中，在查询UTXO构造交易原文时，使用的逻辑是在utxo中找到一条满足金额的utxo，用它作为单一input构造交易。该逻辑在balance足够但utxo个体都偏小时，会误报没有足够的utxo。应该采用累加utxo判断amount，和允许多utxo作为input构造交易的模式。 考虑到多签验证脚本仅为学习和验证目的，该bug问题不大。但需要检查官方钱包的对应模块逻辑在处理提现申请时，是否也有该潜在问题。

HLT 验证节点已经开放 ws 服务和端口，但是在添加节点页面始终无法添加成功
这是验证节点的部分配置信息：

这是添加失败界面：

这是改成ws:// 后的失败界面

我在js 里面通过websocket 连接HLT 节点是正常的，可以连接上，所以我觉得这是BUG

节点：HLT

chainx.trade.putOrder 挂单接口挂买单成功，但卖单一直挂不成功。用同样的数量和价格在钱包界面下能挂成功
ExtError: Unable to initialise Enum with value Sale
at assert (/home/drun/node_modules/@polkadot/util/assert.js:47:9)
at OrderDirection.Enum (/home/drun/node_modules/@chainx/types/lib/codec/Enum.js:49:22)
at new OrderDirection (/home/drun/node_modules/@chainx/types/lib/OrderDirection.js:27:105)
at /home/drun/node_modules/@chainx/types/lib/codec/Struct.js:212:74
at Array.reduce ()
at Function.decodeStructFromObject (/home/drun/node_modules/@chainx/types/lib/codec/Struct.js:202:33)
at Function.decodeStruct (/home/drun/node_modules/@chainx/types/lib/codec/Struct.js:197:21)
at Struct (/home/drun/node_modules/@chainx/types/lib/codec/Struct.js:57:26)
at new Struct (/home/drun/node_modules/@chainx/types/lib/codec/Struct.js:237:107)
at /home/drun/node_modules/@chainx/types/lib/codec/Struct.js:217:78

测试环境：0.9.8
bug出现环境：chainx explorer
累计出块数错误，没有显示累计，而是本轮次最新累计值

在线钱包 点击添加账户无法添加，点击后显示也有问题

节点：HLT (原 mengkeTest)

反馈节点：buildlinks

版本: 0.9.9
运行服务器： Google Cloud **区 n1

运行一段时间后，出现稳定性问题。该问题似乎在上版本也存在，但这个版本又复现了。

Bug reporter: BitPortal

2019-04-26 03:32:49.430 INFO [runtime|xrml_xsystem] height:39320, blockproducer: 61b5932a5a0832b28c7f1fd67261e0c1e93da4239916472ad3aa2deb1193eb02 (5EGpSXhp...)|name:NodeSoleil

====================

stack backtrace:
   0: substrate_panic_handler::set::{{closure}}::h3ac648907d84f931 (0x55ba9bb55b0f)
   1: rust_panic_with_hook (0x55ba9bd413c8)
             at src/libstd/panicking.rs:478
   2: std::panicking::begin_panic::hd1b275492f3b6bff (0x55ba9b9414a4)
   3: chainx_runtime::xexecutive::Executive<System,Block,Context,Payment,AllModules>::execute_block::hef7cedd90dae9beb (0x55ba9b970962)
   4: chainx_runtime::api::dispatch::h16e2ba2969aa5372 (0x55ba9b8ba7a2)
   5: std::panicking::try::do_call::hc5e87824aef7d012 (0x55ba9b342c61)
   6: __rust_maybe_catch_panic (0x55ba9bd46df9)
             at src/libpanic_unwind/lib.rs:85
   7: substrate_executor::native_executor::safe_call::h7e5d22bee70f85d0 (0x55ba9b343372)
   8: std::thread::local::LocalKey<T>::with::haf73e46118f70b34 (0x55ba9b342d96)
   9: <chainx_executor::Executor as substrate_executor::native_executor::NativeExecutionDispatch>::dispatch::hc882303ccffa3fb4 (0x55ba9b3426bc)
  10: std::thread::local::LocalKey<T>::with::h0dd1d2b55861767a (0x55ba9b04b138)
  11: substrate_state_machine::StateMachine<H,B,T,O,Exec>::execute_aux::h64f140fd0296b8c1 (0x55ba9af1a2b2)
  12: substrate_state_machine::StateMachine<H,B,T,O,Exec>::execute_call_with_native_else_wasm_strategy::hf5f42670a3b53e01 (0x55ba9af9b962)
  13: substrate_state_machine::StateMachine<H,B,T,O,Exec>::execute_using_consensus_failure_handler::ha5195f7735f40328 (0x55ba9af77761)
  14: <substrate_client::call_executor::LocalCallExecutor<B,E> as substrate_client::call_executor::CallExecutor<Block,substrate_primitives::hasher::blake2::Blake2Hasher>>::call_at_state::h8ae1a6916df3ff99 (0x55ba9b0140b1)
  15: substrate_client::client::Client<B,E,Block,RA>::lock_import_and_run::{{closure}}::h38208b2ce9cae960 (0x55ba9b194f5e)
  16: <substrate_client::client::Client<B,E,Block,RA> as substrate_consensus_common::block_import::BlockImport<Block>>::import_block::hd74eacc942e5f3af (0x55ba9b1864d1)
  17: <substrate_finality_grandpa::import::GrandpaBlockImport<B,E,Block,RA,PRA> as substrate_consensus_common::block_import::BlockImport<Block>>::import_block::h5f29e85a2d8e9910 (0x55ba9b0f46e1)
  18: substrate_consensus_common::import_queue::BlockImportWorker<B,V>::import_a_batch_of_blocks::h66a89532c190eb6c (0x55ba9aeccd5d)
  19: std::sys_common::backtrace::__rust_begin_short_backtrace::ha2ba196ad89ca1d5 (0x55ba9b2fa2fe)
  20: std::panicking::try::do_call::h869436222e77f206 (0x55ba9ac93ffd)
  21: __rust_maybe_catch_panic (0x55ba9bd46df9)
             at src/libpanic_unwind/lib.rs:85
  22: core::ops::function::FnOnce::call_once{{vtable.shim}}::h81a8af19346b6d9a (0x55ba9b09bb92)
  23: call_once<(),FnOnce<()>> (0x55ba9bd2e7ee)
             at /rustc/70f130954d6fd36fe3e77f4b5b33e5af50489288/src/liballoc/boxed.rs:704
  24: call_once<(),alloc::boxed::Box<FnOnce<()>>> (0x55ba9bd4610f)
             at /rustc/70f130954d6fd36fe3e77f4b5b33e5af50489288/src/liballoc/boxed.rs:704
      start_thread
             at src/libstd/sys_common/thread.rs:13
      thread_start
             at src/libstd/sys/unix/thread.rs:79
  25: start_thread (0x7f90370646da)
  26: __clone (0x7f9036b7588e)
  27: <unknown> (0x0)

Thread 'ImportQueueWorker' panicked at 'All extrinsics should have the correct nonce', runtime/src/xexecutive.rs:183

This is a bug. Please report it at:

        https://github.com/chainx-org/ChainX

如图 投票大概10分钟 区块浏览器依旧没更新信息

节点：feilun

0.9.8测试网验证者节点在高度25951的位置产生问题。节点会重复打印如下日志：

stack backtrace:
   0: substrate_panic_handler::set::{{closure}}::h6151f83348fe5cb3 (0x564ac756131f)
   1: rust_panic_with_hook (0x564ac77481e8)
             at src/libstd/panicking.rs:478
   2: std::panicking::begin_panic::ha17c276b68ef3911 (0x564ac7321ad4)
   3: <chainx_runtime::xexecutive::Executive<System, Block, Context, Payment, AllModules>>::execute_block::hf28d0b5901e8ead2 (0x564ac7384ef7)
   4: chainx_runtime::api::dispatch::hbd978dc53fe9f7c9 (0x564ac72baa52)
   5: std::panicking::try::do_call::h7ae11b3d4cdfbdfb (0x564ac6d47e11)
   6: __rust_maybe_catch_panic (0x564ac774e579)
             at src/libpanic_unwind/lib.rs:87
   7: substrate_executor::native_executor::safe_call::h13303d24dfa76ef7 (0x564ac6d47af2)
   8: <std::thread::local::LocalKey<T>>::with::hf324c8a2d7642d9b (0x564ac6d47516)
   9: <chainx_executor::Executor as substrate_executor::native_executor::NativeExecutionDispatch>::dispatch::hffd4afadc7f37f13 (0x564ac6d46e7c)
  10: <std::thread::local::LocalKey<T>>::with::he29e68a370bece3e (0x564ac6a77316)
  11: <substrate_state_machine::StateMachine<'a, H, B, T, O, Exec>>::execute_aux::h10a9eb4603a2b4ce (0x564ac68c3ca2)
  12: <substrate_state_machine::StateMachine<'a, H, B, T, O, Exec>>::execute_call_with_native_else_wasm_strategy::h01e29a7158eeac09 (0x564ac694c4b2)
  13: <substrate_state_machine::StateMachine<'a, H, B, T, O, Exec>>::execute_using_consensus_failure_handler::hb71ec0f91bbf6eca (0x564ac6928f11)
  14: <substrate_client::call_executor::LocalCallExecutor<B, E> as substrate_client::call_executor::CallExecutor<Block, substrate_primitives::hasher::blake2::Blake2Hasher>>::call_at_state::h39de45a6d010cf78 (0x564ac69f6de1)
  15: <substrate_client::client::Client<B, E, Block, RA>>::lock_import_and_run::{{closure}}::h576be5145f13c396 (0x564ac6bf82be)
  16: <substrate_client::client::Client<B, E, Block, RA> as substrate_consensus_common::block_import::BlockImport<Block>>::import_block::h6e2b74ee4ad6ffc3 (0x564ac6bc9371)
  17: <substrate_finality_grandpa::import::GrandpaBlockImport<B, E, Block, RA, PRA> as substrate_consensus_common::block_import::BlockImport<Block>>::import_block::hbc25775dd83ec082 (0x564ac6add6f2)
  18: <substrate_consensus_common::import_queue::BlockImportWorker<B, V>>::import_a_batch_of_blocks::h6640ccd940ec190c (0x564ac684b62b)
  19: std::sys_common::backtrace::__rust_begin_short_backtrace::hc46b607889d60a21 (0x564ac6cdc9fe)
  20: std::panicking::try::do_call::hefc70362a4239358 (0x564ac668487d)
  21: __rust_maybe_catch_panic (0x564ac774e579)
             at src/libpanic_unwind/lib.rs:87
  22: <F as alloc::boxed::FnBox<A>>::call_box::hdf3f10eb1475be8f (0x564ac669f99e)
  23: call_once<(),()> (0x564ac774d8bd)
             at /rustc/a9da8fc9c267c08cfdb8cf5b39da14f154d12939/src/liballoc/boxed.rs:759
      start_thread
             at src/libstd/sys_common/thread.rs:14
      thread_start
             at src/libstd/sys/unix/thread.rs:80
  24: start_thread (0x7f120ca2d6da)
  25: __clone (0x7f120c53e88e)
  26: <unknown> (0x0)

Thread 'ImportQueueWorker' panicked at 'Storage root must match that calculated.', runtime/src/xexecutive.rs:265

This is a bug. Please report it at:

	https://github.com/chainx-org/ChainX

2019-04-13 09:32:19.557 INFO [runtime|xrml_xsystem] height:25951, blockproducer: 0b257ad398a034bec8e2020bf0d8f8102cdeb8a0ba21455e11d8df9a44636791 (5CKKWyrD...)|name:Amazon
Runtime: Cannot nominate if greater than your avaliable free balance.
Hash: given=64235d7dd78d74819d15055b1165b1bae7b7feeb88de41d7e1304795fbc669ef, expected=46c2a5652dd2c05a7ecd67c92b58a0839c47333d7f54d4d4a710fdca69ccf2ce

测试网版本: v0.9.9

1. 部分信托节点（DappPub和Keypool）节点详情页的信托设置里，看不到信托的对应链和冷热公钥。

提交节点：DappPub

buildlinks report

version 0.9.10

keystore目录中的那个文件名，记录的是出块账户的公钥，内容是一段助记词。实际使用该助记词恢复出来的账户地址，与使用公钥在区块浏览器里看到的地址不符，实测结果是区块浏览器里的地址有效。

版本：v0.9.9
提交节点：Bit Cat

在设置信息节点填写bitcoin的冷热公钥时提示：
设置信托报错

可能造成的原因：
是没有填写前缀0x，这个要加一个提示。

目前解冻冻结时间设置为0，但是撤销投票后，一直在解冻中未到账，一直后延，不知道准确的解冻时间，请核实。
节点:feilun

buildlinks report

version 0.9.9 在线钱包bug

更新节点信息时，url栏限制长度为2-12，不合理。通过sdk的chainx.stake.refresh接口，就没有此限制，且执行成功。

buildlinks report

version 0.9.9

1. 设置节点时，如果能设置多个节点，在前面节点失去连接后自动切换后面的节点，可以提高可靠性；
2. 因为自有全节点的rpc访问一般都会设置rpcusername和rpcuserpassword，是否要在设置节点时将这些安全参数一并填入；
3. 是否可以提供判定全节点链接状态的检查工具供信托节点运维进行日常检查；

====================

stack backtrace:
0: substrate_panic_handler::set::{{closure}}::h3bb2927286838192 (0x106894d50)
1: std::panicking::rust_panic_with_hook::he70bc64de1b70082 (0x106983c96)
2: std::panicking::begin_panic::h3263e3e577a17679 (0x106859424)
3: <slog_scope::NoGlobalLoggerSet as slog::Drain>::log::h3b8705de198b71fd (0x10685960b)
4: <substrate_service::Service>::new::{{closure}}::{{closure}}::{{closure}}::h78f90bae460e8e95 (0x105b97db5)
5: <std::thread::local::LocalKey>::with::hd58eebb8df7ec206 (0x105b71864)
6: <substrate_service::Service>::new::{{closure}}::{{closure}}::hf019d6767e3adb81 (0x105b9789e)
7: <substrate_telemetry::Connection<'a> as ws::handler::Handler>::on_open::h87c44b5165ac6337 (0x1067b829d)
8: <ws::connection::Connection>::read::h89e708cbbe455ae2 (0x106796c6d)
9: <ws::io::Handler>::run::hdeffd23333e3885b (0x1067afd35)
10: substrate_telemetry::init_telemetry::{{closure}}::hdb80b2dcf5789620 (0x1067bbbeb)
11: std::sys_common::backtrace::__rust_begin_short_backtrace::h62452878618c63ac (0x1067b8faf)
12: std::panicking::try::do_call::ha108186cc53eccfa (0x1067b90ff)
13: ___rust_maybe_catch_panic (0x106988dae)
14: <F as alloc::boxed::FnBox>::call_box::h903526b9e104b90a (0x1067c5904)
15: std::sys::unix::thread::Thread::new::thread_start::h71145ac911a9cde4 (0x10698834b)
16: __pthread_body (0x7fff6f6de304)
17: __pthread_start (0x7fff6f6e126e)

Thread '' panicked at 'slog-scope: No logger set. Use slog_scope::set_global_logger or slog_scope::scope.', /Users/xlc/.cargo/registry/src/github.com-1ecc6299db9ec823/slog-scope-4.1.1/lib.rs:123

This is a bug. Please report it at:

https://github.com/chainx-org/ChainX

充值成功到账后，不显示充值记录。

节点：feilun

问题：

1. 投票选举-更新节点模块-官网域名，官网域名2-12个字符不合理，一般情况后缀就占了4个；
2. 投票选举-更新节点模块-简介，简介栏尾部无法直接输入空格，只能光标回退到中间才能输入空格。

提交节点：STW

1、根据常用操作，计算手续费，当用户操作后可能造成后续操作手续费不足的情况，进行提示，避免用户因失误导致手续费不足。
2、增加节点退选提示（短信/邮件提示）；
3、提息，节点可以设置自己提息保留一定金额，以免恰好此时漏块导致节点退选；
4、前端：充值时选择节点没有说明用途，感觉像是冲值冲给了节点，建议增加“选择推荐节点”类似的说明字样；

节点：feilun

版本：v0.9.8
提交节点：Bit Cat

我们的服务器全部在国外，晚测试节点的时候掉线掉的严重，后来发现是国外没有节点的原因，建设添加国外节点以便连接区块。

经观察：充值挖矿待提息部分数值增长至一定程度后，会出现下降的情况，官方有解释为因充值稀释导致收益下降，现提出以下问题：
1、如果是因充值稀释，那么下降应该出现在充值发生的瞬间，但下降的情况一旦出现，就会持续线性降低，且为双资产待领利息均下降，直至进行一次提息或减没。
2、关于稀释会降低收益的逻辑，对于用户而言显示的收益，应为已经实现的收益，而充值造成的稀释应该是挖矿速度的降低，而非已经产生的收益的降低，即新充值的资产不应该获它充值之前的挖矿收益，所以也就不应该造成待领利息的降低。
3、是否是逻辑正确，但显示有问题？

节点：feilun

{ RpcError: [1012]: Transaction is temporarily banned
at RpcCoder.checkError (/home/drun/node_modules/@chainx/rpc-provider/lib/coder.js:121:15)
at RpcCoder.decodeResponse (/home/drun/node_modules/@chainx/rpc-provider/lib/coder.js:87:12)
at WsProvider.onSocketMessageResult (/home/drun/node_modules/@chainx/rpc-provider/lib/ws/index.js:120:34)
at W3CWebSocket.onmessage (/home/drun/node_modules/@chainx/rpc-provider/lib/ws/index.js:103:39)
at W3CWebSocket._dispatchEvent [as dispatchEvent] (/home/drun/node_modules/yaeti/lib/EventTarget.js:107:17)
at W3CWebSocket.onMessage (/home/drun/node_modules/websocket/lib/W3CWebSocket.js:234:14)
at WebSocketConnection. (/home/drun/node_modules/websocket/lib/W3CWebSocket.js:205:19)
at emitOne (events.js:116:13)
at WebSocketConnection.emit (events.js:211:7)
at WebSocketConnection.processFrame (/home/drun/node_modules/websocket/lib/WebSocketConnection.js:554:26)
name: 'RpcError',
message: '[1012]: Transaction is temporarily banned',
data:
{ code: 1012,
message: 'Transaction is temporarily banned',
data: undefined } }

buildlinks report

version 0.9.9

使用脚本下币币交易的pcx/btc合约对的限价买单，每次签名广播后，在广播状态，整个链卡住。多次测试，重现率接近100%。 相关脚本已发徐留成。

trade.getOrderPairs与trade.getQuotations信息不一致

by buildlinks节点

简述

getOrderPairs也会返回当前买一卖一档，getQuotations更是返回十档深度。
但是它们的买卖盘信息明显冲突。
而且在getQuotations的返回中，更是出现量为0的盘口，不合逻辑。

附详细信息：

块高161354, 节点状态正常，
trade.getOrderPairs()返回信息：

{ assets: 'PCX',
    averPrice: 56919116,
    buyOne: 56995200,
    currency: 'BTC',
    id: 0,
    lastPrice: 51813900,
    online: true,
    precision: 9,
    sellOne: 56995500,
    unitPrecision: 2,
    updateHeight: 137872 },

trade.getQuotations(0, 10)返回信息：

BTC/PCX deep:
{ buy: [ [ 51813900, 0 ] ], id: 0, piece: 10, sell: [] }

设置信托时候录入公钥时前段最好加个格式检查，如0x开头等格式。格式不对不能确定进行下一步并返回提示信息

问题：
1、挂单列表不准确，已经成交的挂单未及时消失，已挂单订单也未及时出现；
2、价格没有单位，不好理解，目前的展现形式很容易出错；
建议：增加一键撤单功能，多个挂单一次撤销，避免多次输入密码的麻烦；
提交节点：feilun

buildlinks report

version 0.9.9 币币交易模块

在用户有多笔挂单的情况下，现有接口只能一笔笔撤单，每次撤单都将消耗手续费。在挂单特别多的情况下，撤单非常不经济和繁琐。是否可以提供一个批量或全部单撤单的接口，省去大笔手续费，也能提高交易所效率。