Giter Club home page Giter Club logo

node's Introduction

Documentation | Guides | News

Twitter AGPL License Version Build Status Quality Gate Status

Credits Node

A node is a client-side application that is installed on the user equipment. The Node processes and stores transactions, executes and confirms smart contract rules requests processing from third-party systems and provides data when requested. Written on C++.

Version

Current node version 4.2.532.0

What is Credits Node?

Credits Node is the main module that provide an opportunity to run a node and participate in CREDITS blockhain network. The node performs processing and storage of transactions, execution and confirmation of the terms of smart contracts, processing requests from third-party systems, and provides data upon request. Each node on the network has the same functionality. The node consists of the following elements:

  • API
  • Desision-making module(Solver)
  • Storage(CSDB)
  • Transport protocol

Build dependencies

  • Boost 1.70 or newest static prebuild
  • Compiler with C++17 support
  • Cmake 3.11 or newest
  • Requirements fo building Apache Thrift
  • The building Berkeley DB distribution uses the Free Software Foundation's autoconf and libtool tools to build on UNIX platforms.
  • It is necessary to run in the terminal, which sets the environment variables for building a Visual Studio project For Windows:

    git clone https://github.com/CREDITSCOM/node.git
    cd node
    git submodule update --init --recursive
    mkdir build
    cd build
    cmake -DCMAKE_BUILD_TYPE=Release -A x64 ..
    cmake --build . --target ALL_BUILD --config Release

    If necessary, full step-by-step instruction for Windows:

    # Install cmake
    # After install you can try to run in command line version check:
    cmake --version
    # If installation was successful, the result will be like:
    cmake version 3.17.0-rc1
    # Install git, check the version the same way:
    git --version
    # and result result:
    git version 2.33.0.windows.2
    # Install Visual Studio, as result you can rut it
    # FLEX&BISON usually are installed automatically with Visual Studio and are not necessary to install yourself
    # DO NOT TRY TO INSTALL IT SEPARATELY IF IT ISN'T NECESSARY, IT CAN PREVENT YOU FROM CORRECT NODE BUILDING PROCESS
    # Check is made the same way by requesting Software version. System should give the correct answer.
    # Install boost from 1.68.0 to 1.72.0:
    wget -c $https://dl.bintray.com/boostorg/release/1.72.0/source/boost_1_72_0.tar.gz
    # or just load with your browser
    # unzip with any archiver, you prefer and go to directory:
    cd boost_1_72_0
    ./bootstrap.sh
    ./b2 --build-type=complete link=static threading=multi $runtime-link=static --layout=tagged install --prefix=../boost
    # do not forget to add BOOST_ROOT to your SYSTEM VARIABLES and set the value pointing your BOOST directory C:\boost\boost_1_72_0
    # Check it:
    echo %BOOST_ROOT%
    # Result: boost root variable value
    # and add the directories of boost-root and boost-libs to your SYSTEM PATHS like that:
    # C:\boost\boost_1_72_0
    # C:\boost\boost_1_72_0\stage\lib
    # Now you are ready to get node repository and build it:
    git clone https://github.com/CREDITSCOM/node.git
    cd node
    git submodule update --init --recursive
    mkdir build
    cd build
    cmake -DCMAKE_BUILD_TYPE=Release -A x64 ..
    cmake --build . --target ALL_BUILD --config Release

    For Linux:

    git clone https://github.com/CREDITSCOM/node.git
    cd node
    git submodule update --init --recursive
    mkdir build
    cd build
    cmake -DCMAKE_BUILD_TYPE=Release ..
    make -j4

    If necessary, full step-by-step instruction for Linux:

    Update repos and install required package

    sudo apt update
    apt upgrade -y
    sudo apt install build-essential libssl-dev autoconf -y
    sudo apt install flex bison libtool -y

    Create build directory

    mkdir csbuild
    d csbuild

    Update gcc g++ (there is no need to update in version of Ubuntu 20 and later)

    sudo apt install gcc-8 g++-8 -y
    sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-8 80 --slave /usr/bin/g++ g++ /usr/bin/g++-8 --slave /usr/bin/gcov gcov /usr/bin/gcov-8
    gcc --version
    gcc (Ubuntu 8.4.0-1ubuntu1~18.04) 8.4.0
    Copyright (C) 2018 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE

    Update cmake to latest version

    wget -c https://github.com/Kitware/CMake/releases/download/v3.17.0/cmake-3.17.0.tar.gz
    tar zxfv cmake-3.17.0.tar.gz
    cd cmake-3.17.0
    ./bootstrap
    make
    sudo make install
    cd ..

    Install boost

    wget -c $https://dl.bintray.com/boostorg/release/1.72.0/source/boost_1_72_0.tar.gz
    tar zxfv boost_1_72_0.tar.gz
    cd boost_1_72_0
    ./bootstrap.sh
    ./b2 --build-type=complete link=static threading=multi $runtime-link=static --layout=tagged install --prefix=../boost
    export PATH=~/csbuild/boost:$PATH
    export BOOST_ROOT=~/csbuild/boost
    cd ..

    Build node

    git clone https://github.com/CREDITSCOM/node.git
    cd node
    git submodule update --init --recursive
    mkdir build
    cd build
    cmake -DCMAKE_BUILD_TYPE=Release ..
    make -j2

    System requirements:

    Minimum system requirements:

    Operating system: Windows® 7 / Windows® 8 / Windows® 10 64-bit (with the last update package) Processor (CPU): with frequency of 1 GHz (or faster) with PAE, NX and SSE2 support; Memory (RAM): 8 Gb HDD: 600Gb Internet connection: 3 Mbit/s.

    Recommended system requirements:

    Operating system: Windows® 7 / Windows® 8 / Windows® 10 64-bit (with the last update package) Processor (CPU): Intel® Core ™ i3 or AMD Phenom ™ X3 8650 Memory (RAM): 8 Gb HDD: 3 Tb Internet connection: 5 Mbit/s.

    Contribution

    Thank you for considering to help out with the source code! We welcome contributions from anyone on the internet, and are grateful for even the smallest of fixes! If you'd like to contribute to Credits Node, please fork, fix, commit and send a pull request for the maintainers to review and merge into the main code base. If you wish to submit more complex changes though, please check up with the core devs first on our Developers portal and Contribution file to ensure those changes are in line with the general philosophy of the project and/or get some early feedback which can make both your efforts much lighter as well as our review and merge procedures quick and simple. Please make sure your contributions adhere to our coding guidelines:

    • Code must adhere to the Credits coding style
    • Pull requests need to be based on and opened against the master branch
    • Commit messages should be prefixed with the package(s) they modify

    Resources

    CREDITS Website

    Documentation

    Whitepaper

    Technical paper

    Developers portal

    Community links

    <

node's People

Contributors

0xaae avatar 13fredom13 avatar aldims avatar calendaric avatar cdmitry77 avatar darthvader312 avatar dmitry-yrtimd avatar instand avatar jcoder39 avatar kondrashovsv avatar ksv81 avatar sceptical-coder avatar sokolvano avatar stoner19 avatar sychevs avatar vshilkin avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

node's Issues

API:transactionsGet total_trxns_count always returns 0

Describe the bug
The transactionsGet API function always returns that the result is false. The total_trxns_count is set to 0, but I do get my requested transactions as well.

Found in the code that total_trxns_count is returned when MONITOR_NODE is defined, which probably isn't the case for the nodes provided.

Code -> https://github.com/CREDITSCOM/node/blob/master/api/src/apihandler.cpp line 471/473

Probably not really a bug, as it should work for the MONITOR_NODE. I think this should work on any node.

The second screenshot shows that the response from my own took over 10 minutes. That is somehow very, very slow compared to the WEB_WALLET_NODE.

Screenshots
image

image

Параметр "Decimal" у токенов

Describe the bug
при создании токена, если указать в параметре decimal (цифры после запятой) значение к примеру 6, а потом когда токен создался, отправить 0.0000001 этого токена или меньше, то монеты не отправятся, но появятся 2 транзакции где будет написано, что отправка прошла успешно.
To Reproduce
Создал токен TestToken(TT) вот его смарт "5RNJJ3WUos7VAGS7ehTURWSHUhjuowdee5KTMcjmBoVj" в графе decimal указал 6. После чего отправил 0.0000001 TT на адрес "Cs7Nb7DqqzLcR9qKM1fckjdxDPGvq9ddxdfaeAhZcDJc"
Отправка не прошла, с баланса монеты не ушли, но кошелек сообщил что монеты отправлены.
1 3
1
1,1
1,2

Credits Desktop Wallet can't be launched - OS Ubuntu 18.04

After starting the node, this new client can't connect to Credits blockchain. Besides the Credits Wallet GUI interface can Not be launched.

The following steps were performed:

  1. Oracle Java was installed from Linux Uprising Java PPA repository according to this:
    sudo add-apt-repository ppa:linuxuprising/java
    sudo apt update
    sudo apt install oracle-java11-installer
    sudo apt install oracle-java11-set-default

  2. The archive, Credits_Node_Linux_x64_ver_4.2.412.3_test.tar.gz, was downloaded from: https://developers.credits.com/en/Articles/Releases

  3. The node was launched by typing on the prompt: "./client"

  4. The Keys were generated by entering a password.

  5. The executor was launched also: java -jar contract-executor.jar

After launching the node, it should be able to connect to Credits blockchain and the GUI Desktop wallet should be launched. (I tried for TestNet and MainNet)

Please see the screenshot:
issue 2 mainNet

The current OS is Ubuntu 18.04 Bionic Beaver

Thank you in advace for the support!

Отображение токенов в кошельке и мониторе

Describe the bug
8 цифра после запятой не показывается у токенов не в мониторе не в кошельке при условии, что у тебя нету на счету хотя бы 0.0000001 (этого токена)
To Reproduce
Отправляем на аккаунт "Cs7Nb7DqqzLcR9qKM1fckjdxDPGvq9ddxdfaeAhZcDJc" на котором нету токенов 0.00000001 токена, транзакция проходит, но не в кошельке, не в мониторе этого 0,00000001 токена у получателя на балансе не видно. После чего отправляем на этот же аккаунт, 0.01 этого же токена, в кошельке и в мониторе у получателя будет 0.01000001 этого токена.
3,3
3
3,2
3,4
3,5

[BUG][CRITICAL] delay network with node clock time

I was remembering that some block timestamp were written with one of the TN time.
First I was not thinking it was a big issue, but if block timestamp is used as a proof for a transaction (for exemple patent) i was wondering what happen if I change date.

First I disabled NTP client, and change date D - 10days. It looks like I was not able to be TRUSTED anymore (I will need a try later)
Then I enabled NTP client and got exact date on my system and node become TRUSTED again.
Until now it looks good.

Afterwards I disabled again NTP client on system and set clock to tomorrow. Just after I checked monitor on Testnet, and chain is stuck. I can t be sure 100% this is due to my manipulation but probabilty looks high. See picture below : (now 18 minutes by the time I write this issue)

image

Please find my node logs here too :
may be start read them from this point : (block 1897259)
[2019-07-18 21:23:00.336920] [0x00007f4c352be700] [debug] NODE> Hash sent, round: 1897258.0, message: 2000000000000000527EE4A591EF6AEF38EA885B0ABF696C9E258F53E1734E9BB4D6D047F3C51FAF060670A789066C010000
[2019-07-18 21:23:01.116123] [0x00007f4c35abf700] [warning] strange: too many tasks 348
[2019-07-19 00:00:00.063620] [0x00007f4c35abf700] [warning] strange: too many tasks 217
[2019-07-19 00:00:00.065808] [0x00007f4c35abf700] [warning] strange: too many tasks 251
[2019-07-19 00:00:00.187054] [0x00007f4c352be700] [debug] NODE> next round table received, round: 1897259

later on I enabled again NTP

log_141.txt.gz

I was able to redo it at block #1898883 just going from now() to tomorrow 0h or block (#1901323) D+2
log_142.txt.gz

Optimize smart contracts storage in chain

The purpose is to keep nearly constant size of every contract in chain
The contract size in storage may increase due to data expand in its state and may become too large. Currently contract state is duplicated in chain every time when contract is executed. This leads to significant costs in disk space and seems to be inefficient.

The possible solution is to separate contract state storage from transactions
The idea is to store last state of every contract outside the chain and put in every execute transaction contract's state hash value

Test 2

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

  1. Go to '...'
  2. Click on '....'
  3. Scroll down to '....'
  4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

  • OS: [e.g. iOS]
  • Version [e.g. 22]

Smartphone (please complete the following information):

  • OS: [e.g. iOS8.1]
  • Version [e.g. 22]

Additional context
Add any other context about the problem here.

91% No rule to make target. Needed by 'client/client'

Tried to build the node on Ubuntu 18.04.

At 45% I received the following message:

[ 45%] Building CXX object cscrypto/CMakeFiles/cscrypto.dir/src/maincryptofunctions.cpp.o In file included from /home/*/csnode/node/cscrypto/include/cscrypto/memoryprotection.hpp:11:0, from /home/*/csnode/node/cscrypto/include/cscrypto/privatekey.hpp:5, from /home/*/csnode/node/cscrypto/include/cscrypto/maincryptofunctions.hpp:4, from /home/*/csnode/node/cscrypto/src/maincryptofunctions.cpp:1: /home/*/csnode/node/cscrypto/third-party/libsodium/src/libsodium/include/sodium.h:5:10: fatal error: sodium/version.h: No such file or directory #include "sodium/version.h" ^~~~~~~~~~~~~~~~~~ compilation terminated.

I did find a file in the above mentioned folder named sodium.h.in. Renaming that file did not work and caused the following error:

[ 45%] Building CXX object cscrypto/CMakeFiles/cscrypto.dir/src/maincryptofunctions.cpp.o In file included from /home/*/csnode/node/cscrypto/third-party/libsodium/src/libsodium/include/sodium.h:5:0, from /home/*/csnode/node/cscrypto/include/cscrypto/memoryprotection.hpp:11, from /home/*/csnode/node/cscrypto/include/cscrypto/privatekey.hpp:5, from /home/*/csnode/node/cscrypto/include/cscrypto/maincryptofunctions.hpp:4, from /home/*/csnode/node/cscrypto/src/maincryptofunctions.cpp:1: /home/*/csnode/node/cscrypto/third-party/libsodium/src/libsodium/include/sodium/version.h:11:1: error: stray ‘@’ in program @SODIUM_LIBRARY_MINIMAL_DEF@ ^ /home/*/csnode/node/cscrypto/third-party/libsodium/src/libsodium/include/sodium/version.h:11:28: error: stray ‘@’ in program @SODIUM_LIBRARY_MINIMAL_DEF@ ^ /home/*/csnode/node/cscrypto/third-party/libsodium/src/libsodium/include/sodium/version.h:11:2: error: ‘SODIUM_LIBRARY_MINIMAL_DEF’ does not name a type; did you mean ‘SODIUM_LIBRARY_VERSION_MAJOR’? @SODIUM_LIBRARY_MINIMAL_DEF@ ^~~~~~~~~~~~~~~~~~~~~~~~~~ SODIUM_LIBRARY_VERSION_MAJOR cscrypto/CMakeFiles/cscrypto.dir/build.make:62: recipe for target 'cscrypto/CMakeFiles/cscrypto.dir/src/maincryptofunctions.cpp.o' failed

Contract using payable function causes negative balances

Describe the bug
Upon starting my node (testnet v4.2.416) my logfile shows the following:
[2019-06-07 11:30:48.491091] [0x00007f37bb4057c0] [debug] Wallet with negative balance (-0.0077168) detected: 6100C7689D0446141532FF4FB1E0E8165ADCF1A104FDD1189E37459671584EE5 (7XfEfVkMxj78Y5N9PDHtkzcUuUWbnhJEyFrWH2U59N2Q) [2019-06-07 11:30:48.491117] [0x00007f37bb4057c0] [debug] Wallet with negative balance (-0.00257227) detected: 1F468EE473980EA87FA7E9BEB0D638475E8CB866DB6A7C3A153746C6E7BEF8E3 (3763MhjaHYvNXSR84CwcEBmD3dGyLSmbZqnrkaesV322) [2019-06-07 11:30:48.491129] [0x00007f37bb4057c0] [debug] Wallet with negative balance (-0.0102891) detected: 596C739032AB0D4AA0F2472C7B449521E015FBD357407D24168A0874A3F6D8BB (725Cc665HDxXdELakREL3efdpaNMdfXevkX27NgkUw3g)

Public keys:
7XfEfVkMxj78Y5N9PDHtkzcUuUWbnhJEyFrWH2U59N2Q
3763MhjaHYvNXSR84CwcEBmD3dGyLSmbZqnrkaesV322
725Cc665HDxXdELakREL3efdpaNMdfXevkX27NgkUw3g
are all smart contracts using public void payable.

According to the monitor the balance of those keys are 0, but my node shows otherwise (balance requested via WalletBalanceGet api function).

7XfEfVkMxj78Y5N9PDHtkzcUuUWbnhJEyFrWH2U59N2Q
image

3763MhjaHYvNXSR84CwcEBmD3dGyLSmbZqnrkaesV322
image

725Cc665HDxXdELakREL3efdpaNMdfXevkX27NgkUw3g
image

Some other strange behaviour regarding this is that the monitor shows 0.0 balance, and the web wallet node responds through the API with balance 0.0.

I tried two user nodes, and those nodes both return a negative value. Meaning that there is a difference in balances between nodes in this testnet.

Some balance needed for contract execution with 'NewState' set to true

Describe the bug
To request the current state of a contract it's possible to initiate a transaction and set the NewState parameter to true. Those transactions need to be signed by a valid keypair, but will not go into the consensus protocol if I'm not mistaken. That means that there is no fee that needs to be paid.

I experienced the following issue: while creating a transaction with an empty wallet and NewState set to true, the return message I receive mentions the following:
max fee is not enough, counted fee will be 0.000482

That message makes sense, only if I set NewState to false. As I don't have to pay any fee with this transaction it looks incorrect to me.

To Reproduce
Steps to reproduce the behavior:

  • Create new wallet, don't put any balance in it
  • Pick a random smart contract that contains some functions
  • Initiate a transaction to that contract with NewState set to true

Expected behavior
Returning the requested value instead of showing this error message.

Screenshots
image

Mainnet Linux Version 4.2.219 - Numeric keypad not working

When starting the latest 4.2.219 linux version of the node you cannot use the numeric keypad to enter your password.

I have tried with 2 differents vps nodes and from 3 computers to access those VPS.

In the print screen in attach you can see that on the right tmux panel the numeric keyboard is working well, but when you type your password who contain number, at the first number typed with the numeric keyboard the Node take it as a you have typed "ENTER" so it is related to the node only.

Regards,
Toki

2019-07-24 08_24_44-Window

Memory leak Linux Client node Testnet version 4.2.412.6

Describe the bug:

Used amount of memory used by Linux client is not stable/regular.

The amount of memory used by the client node is increasing little by little. After starting the node the memory level used is about 800mb, but after 19 hours as you can see in the attached log file, client use more than 7.5GB of memory. Which could crash / make unstable the system if the maximum available memory level available is reached.

The attached log file was generated with the following command that checks every minute the amount of memory used by the specified process:

watch -n 60 "pmap -x 5648 | grep total >> /home/credits/Clientmemory_20190516_0844PM.txt"

Where the number 5648 is the PID of the node client process

PID of the node client process is know by the following command:

ps -ef | grep client

The log file containing 1151 lines, which represents
1151 minutes or 19 hours and 11 minutes

Desktop (please complete the following information):

OS: Ubuntu 18.04
Version: Client node Testnet version 4.2.412.6

Clientmemory_20190527_0155PM.txt

Test 1

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

  1. Go to '...'
  2. Click on '....'
  3. Scroll down to '....'
  4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

  • OS: [e.g. iOS]
  • Version [e.g. 22]

Smartphone (please complete the following information):

  • OS: [e.g. iOS8.1]
  • Version [e.g. 22]

Additional context
Add any other context about the problem here.

[BUG][CRITICAL] Non-existent addresses

My English is not perfect, so for a better understanding of the problem, after the English description I posted the Russian version of this text because most of the developers are Russian

I decided not to supplement the previous report #45, but to create a new one to highlight the problem. There are many similar methods that allow you to stop the network

To Reproduce
Shut down the network again using a similar method that I described here #45. If you try to send a transaction to a nonexistent address, it will fail, the network will reject the transaction, or the wallet will not allow you to send it. but if you create a smart contract that sends the specified transaction addresses and specify a non-existent address, then after we send coins to this smart contract, the network stops. this way is even easier than the one I described here #45, you do not even need to specify in the smart contract many other smart contracts for which many transactions will be sent. it is enough to specify only 1 or several non-existent addresses. in this case, I have specified 27 times the non-existent address "chtozapizdec", although I am sure that it was enough to specify 1 time this address and the effect would be the same.
11
22

снова выключил сеть, с помощью похожего способа, который я описывал здесь #45. Если попытаться отправить транзакцию на несуществующий адрес, то этого сделать не удастся, сеть отклонит такую транзакцию, либо ее не даст отправить кошелек. но если создать смарт контракт, который пересылает указанным адресам транзакции и указать там несуществующий адрес, то, после того как мы отправим на этот смарт контракт монеты, сеть останавливается. этот способ даже легче чем тот который я описывал тут #45, даже не нужно указывать в смарт контракте много других смарт контрактов на которые будет отправлены много транзакций. достаточно указать всего 1 или несколько несуществующих адресов. в данном случае я указал 27 раз несуществующий адрес "chtozapizdec", хотя я уверен, что достаточно было указать 1 раз этот адрес и эффект был бы тот же.

Current smart contracts are not suitable for a large number of players who play at the same time

My English is not perfect, so for a better understanding of the problem, after the English description I posted the Russian version of this text because most of the developers are Russian

Describe the bug
Current smart contracts are not suitable for a large number of players who play at the same time

To Reproduce
I can't show it in testnet network, for the reason that testnet behaves inadequately.
It doesn't respond to my requests, then does it after 2 minutes. So I'll show it in the dappsnet network The example in application egyptslot.
Same problem in all networks
Suppose that in egypetslot(or any other app) plays at the same 10 people. Traffic 10 transactions per second. all bets that will be in the same block will be with the same outcome. Let's say 10 transactions(bets) from different accounts fall into one block. The network will give a block in which there will be either 10 or 20 transactions(depending on whether there was a win or not)
All 10 accounts will either receive the same winnings or lose. Example: I placed 3 bets at the same time from different accounts. They fell into one block and all three accounts received the same win or lose. In this case, all 3 bets that hit one block got a win of 4cs. Here is the hash block where there were 3 transactions(rates) from different accounts in one block
"34ef00682698feda01233add1cecca471441d4deaf00c2c52ac55b30199a3912"
1
As a result, these bets that were in the same block received the same winnings for 4cs. here's the hash
"5ef308db3d5e29dba860560f67c7a3c48798a50de27e44e9836e1818c5a667cc".
2
Here is another example. All bets that were in one block received a win of 8 cs.
Безымянный
Безымянный2
And this always happens. If there are 50 transactions (bets) in one block. Then these 50 bets will either win the same amount at the same time or lose. What can this lead to?
With a large number of bets in one application, all players will either win the same amount at the same time or lose massively at the same time. All bets will have the same outcome for everyone. No randomness. It will be unprofitable for developers of casinos and other decentralized applications. Because in one moment may occur such a situation that all accounts whose transactions have been in the same block, will have to pay out large winnings. For example X10. Developers will suffer great losses

Не могу показать это в сети тестнет, по той причине, что тестнет ведёт себя неадекватно. Он то не отвечает на мои запросы, то делает это спустя 2 минуты. Поэтому я покажу это в сети дапснет. На примере приложения egyptslot. Та же самая проблема есть в сети тестнет, либо любой другой
Предположим что в egypetslot(либо в любое другое приложение) играет одновременно 10 человек. Трафик 10 транзакций в секунду. все ставки, которые окажутся в одном блоке будут с одним и тем же исходом. Допустим попадает в один блок 10 транзакций(ставок) с разных аккаунтов. Сеть выдаст в ответ блок в котором будет либо 10 либо 20 транзакций(в зависимости от того был выигрыш или нет)
Все 10 аккаунтов получат либо одинаковые выигрыши, либо проиграют. Пример: Я делал 3 ставки одновременно с разных аккаунтов. Они попадали в один блок и все эти три аккаунта получали одинаковый выигрыш, либо проигрывали. В данном случае все 3 ставки что попали в один блок получили выигрыш 4cs. Вот хеш блока где было 3 транзакции(ставки) с разных аккаунтов в одном блоке
34ef00682698feda01233add1cecca471441d4deaf00c2c52ac55b30199a3912
В итоге эти ставки которые оказались в одном блоке получили одинаковые выигрыши по 4cs. вот хеш
5ef308db3d5e29dba860560f67c7a3c48798a50de27e44e9836e1818c5a667cc
И так происходит всегда. Если в одном блоке окажется 50 транзакций (ставок). То эти 50 ставок либо одновременно выиграют одну и ту же сумму, либо проиграют. К чему это может привести?
При большом количестве ставок в одном приложении, все игроки будут либо одновременно выигрывать одинаковые суммы, либо массово одновременно проигрывать. У всех ставок будут одинаковые исходы. Никакого рандома. Это будет невыгодно разработчикам казино и других децентрализованных приложений. Потому что в один момент может произойти такая ситуация, что всем аккаунтам чьи транзакции попали в один блок, придётся выплачивать большие выигрыши. К примеру х10. Разработчики понесут большие потери

Node compilation issue with Ubuntu18.04

Describe the bug
I tried to compile node from ubuntu but I didn t manage to get it work and I got the following result :

node/build$ cmake -DCMAKE_BUILD_TYPE=Release -A x86_64 ..
CMake Error in CMakeLists.txt:
  Generator
    Unix Makefiles
  does not support platform specification, but platform
    x64
  was specified.
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!

My dependencies
liboost installed are 1.65 + 1.68
dpkg -l | grep libboost

ii  libboost-date-time1.65.1:amd64        1.65.1+dfsg-0ubuntu5                        amd64        set of date-time libraries based on generic programming concepts
ii  libboost-filesystem1.65.1:amd64       1.65.1+dfsg-0ubuntu5                        amd64        filesystem operations (portable paths, iteration over directories, etc) in C++
ii  libboost-iostreams1.65.1:amd64        1.65.1+dfsg-0ubuntu5                        amd64        Boost.Iostreams Library
ii  libboost-locale1.65.1:amd64           1.65.1+dfsg-0ubuntu5                        amd64        C++ facilities for localization
ii  libboost-system1.65.1:amd64           1.65.1+dfsg-0ubuntu5                        amd64        Operating system (e.g. diagnostics support) library
ii  libboost-thread1.65.1:amd64           1.65.1+dfsg-0ubuntu5                        amd64        portable C++ multi-threading
ii  libboost1.68                          1.68-0~8~ubuntu18.04.1                      amd64        Boost C++ Libraries
ii  libboost1.68-dev                      1.68-0~8~ubuntu18.04.1                      amd64        Boost C++ Libraries development files

g++ --version
g++ (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0

gcc --version
gcc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0

Desktop (please complete the following information):

  • Linux ubuntu 18.04

Безлимитный "Decimal"

Describe the bug
можно создать токен со значением decimal 150 (цифры после запятой) и отправить токен со 150 знаками после запятой (к примеру 0,999...9)

To Reproduce
Создал токен "ST" в графе Decimal указал 150. токен создался. После чего сделал отправку этого токена со 150 знаками после запятой (0.999...9), это число не помещается в мониторе, транзакция спокойно проходит. Задумывалось, что максимальное количество цифр после запятой у токенов может быть 18, однако создать можно токен и со 150 цифрами после запятой. тоже самое кстати и с названием токена. можно дать токену бесконечно длинное название.
1
1,2

Node Encryption explanations

When we start a node (Linux or windows, we have the possibility to encrypt the key. ( Option 1 recommended)

I have 2 questions related to the encryption ( see print screen below)

  1. How can we use the Phrase on 24 words generated in case losing both public and private key.
  2. How can we use the the option "to use file file press F"

A word of explanations is really needed to allow us to update the vps/linux/installation guide.

Best regards,

Toki1975

2019-06-07_112222
v2-how-to-run-a-credits-node-on-a-pc-or-on-a-linux-vps.pdf

Some few nodes received stop request at same time

Describe the bug
Some few nodes experiments a stop request from network.
You will find logs :
nodes that received stop request are log_stop_XX.txt
i also add my node log that didn t stop at this same time to help analysis : log_OK_micmac-XX

From reading logs I see that here were grey list nodes I guess these ones (even one that seems to be team one in Latvia : AfgYdKaqHT5JqAyr6RWvnSfwCuCfuZ2rKeQPCXUY2ETr

here the wallet list I get with a fast look on log some other may exists :

5Jhpp7Ls51YD6Qcz9eQnXuEEagTW5XPCgSLdZDPX2Y1k
FLSmS5ni1PJannGCV5VZWNd1cKmEnom8uGduers6AMcB
AfgYdKaqHT5JqAyr6RWvnSfwCuCfuZ2rKeQPCXUY2ETr
J3G93yYGfMKvuyZLhsuZwmP2AYUjGu7VBcpjAeWVNXjU

These node stoped but i didn t get them from grey list :

B78Sfa6YLUD8LbHwXxQ9TqjNqchtb5SNyscd3HT9g4pa
AH5D8Ria7NxwbD75o83tNGm3DcumrFxTYPaLXQeHoBiH

logs of nodes that stoped
log_stop_mobile_53.zip
log_stop_bert_63.txt.tar.gz

log of node that continued to run
log_OK_micmac_88.txt.tar.gz

Linux Gui launcher needed.

Many Linux users are faced with the problem of running the node, wallet, executor via the command line interface.

It would be healthy to create a launcher that would do:

  1. single launcher for all Linux / Windows
  2. launch all modules with one button
  3. displaying the output of the modules all in one launcher window
  4. stop all modules with one button
  5. installing and updating the client using the launcher
  6. start / stop or reset the selected module
  7. install java
  8. opening configurator from launcher

Decimal for tokens

Describe the bug
When you create a token, if you specify a value in the decimal parameter for example 5, and then when the token is created, send 0.000001 of this token or less, the tokens will not be sent, but there will be 2 transactions where it will be written that the sending was successful

To Reproduce
Created a SWAP token(SWP) here is his smart contract "C2e5NyvG4cLaZYN5uqPmuVNuZLbgcdgapknmfzifvjiyj". in graph decimal pointed out 5. After that, sent 0.000001 SWP to address "7qk4vxgdqQGZJGVPk746X135DGTXTBrk52aadzmrskxk"
The sending did not pass, the tokens were not debited from the balance, but the wallet and the monitor reported that the tokens were sent
2
2,2
2,3
2,4

Minor bugs in default token contract

Describe the bug
The default token contract that is being used with the web wallet contains some minor bugs. Should be pretty easy to fix, but the default token contract needs some revision.

Thanks to Steffen in tech chat for pointing this issue out as well.

What currently needs to be done is the correct use of 'totalCoins' (TotalSupply). Upon deploying a token contract, the entire supply will be added to the public key of the contract owner. That means that the contract address does not contain any of that just created token.

When someone tries to burn some tokens, the burn function is called and defined as follows in the default token contract:

public boolean burn(String amount) {
        contractIsNotFrozen();
        BigDecimal decimalAmount = toBigDecimal(amount);
        if (!initiator.equals(owner))
            throw new RuntimeException("can not burn tokens! The wallet " + initiator + " is not owner");
        if (totalCoins.compareTo(decimalAmount) < 0) totalCoins = ZERO.setScale(decimal, ROUND_DOWN);
        else totalCoins = totalCoins.subtract(decimalAmount);
        return true;
    }

This function allows only the owner of the contract to use this function. Next to that, when 'burning' tokens, only the 'totalCoins' is being reduced. 'totalCoins' is equal to the total supply on the monitor. There are no tokens actually being burned, as nothing gets subtracted from an account.

With the current burn function it's actually possible to enter an amount below zero. This way you can even increase the totalCoins / total supply.

I suggest the following as a solution for this function.

public boolean burn(String amount) {
        contractIsNotFrozen();
        BigDecimal decimalAmount = toBigDecimal(amount);
        BigDecimal sourceBalance = getTokensBalance(initiator);
        if(decimalAmount.compareTo(ZERO) < 0) {
            throw new IllegalArgumentException("the amount cannot be negative");
        }
        if (sourceBalance.compareTo(decimalAmount) < 0) {
            throw new RuntimeException("the wallet " + initiator + " doesn't have enough tokens to burn");
        }
            totalCoins = totalCoins.subtract(decimalAmount);
            balances.put(initiator, sourceBalance.subtract(decimalAmount));
        return true;
    }

In my opinion anyone should be able to burn a token they possess. It's the users own responsibility when they burn tokens.

The code above checks if the entered amount is below zero. If so, it throws an error. After that, the entered amount is being checked against the actual balance of the token. When someone tries to burn more tokens than they possess, it throw another error. That causes these transactions to fail.

When it passes both checks, the 'totalCoins' is reduced. Next to that, the burned tokens get subtracted from the account that executed this transaction, causing them to actually being 'burned'.

totalCoins is currently also being used in the public void payable() function. Might need to be checked as well.

To Reproduce

  • Deploy a token contract through web wallet
  • Try to burn tokens through the burn function
  • Verify that total supply changes, but the amount of tokens in your wallet does not change.

Баланс аккаунта не соответствует транзакциям на этом аккаунте

Describe the bug
если отправляешь монеты Credits(CS) на любой смарт контракт с недостаточной комиссией, то монеты сначала уходят с твоего баланса, но примерно через 1.5-3 минуты (в зависимости от скорости генерации новых блоков) возвращаются обратно, при этом в мониторе не указано, что эти монеты вернулись обратно на адрес отправителя. и монитор из за этого показывает не правильный баланс у аккаунта, так как в истории транзакций, эти транзакции которые впоследствии зафейлились, остаются в мониторе. В следствии чего баланс аккаунта не соответствует тем транзакциям, которые у него были. Я понимаю, что транзакции не могут пропасть из базы данных и все что попало в базу данных, остается там навечно. но если эти транзакции в последствии отменились, они должны быть помечены соответственным образом в мониторе, иначе получается то, что я опишу ниже

To Reproduce
Отправил на аккаунт "FpiqgDfVP8AmvQXDQe7bussP2ewpip2jsGcPdy7oyGwF" 10 CS, после чего сделал первую исходящую транзакцию 9.9 CS на смарт контракт токена, указав при этом недостаточную комиссию для перевода 0.0005 CS, транзакция естественно зафейлилась и монеты вернулись обратно на кошелек. После чего я повторил ту же самую операцию, еще 4 раза. В итоге для "простого прохожего" это будет выглядеть так, что аккаунт "FpiqgDfVP8AmvQXDQe7bussP2ewpip2jsGcPdy7oyGwF" получил 10 CS, а отправил больше 43 CS.
1

Остановка любого смарт контракта в сети

Describe the bug
Есть способ парализовать работу абсолютно любого смарт контракта в сети. Смарт контракт перестает отвечать на запросы любого пользователя (будь то смарт игрового приложения, либо любой другой, неважно). Если брать в пример геймблинг приложение, то игрок будет делать ставку, отправляя смарт контракту монеты Credits, но смарт ему отвечать никак не будет, более того отправленные монеты будут находиться в подвешенном состоянии, их не сможет принять смарт контракт и получить обратно свои монеты пользователю тоже не удастся (монеты зависают в воздухе)

To Reproduce
Steps to reproduce the behavior:
По правилам это нужно делать в сети тестнет, но там нету этого приложения, поэтому делаем это на примере приложения Dice в сети дапс нет (эта дыра есть и в майннете или любой другой сети Credits доступной на данный момент)
И так дапс нет, приложение DICE. Открываем веб кошелек (ну либо с десктопа можно сделать тоже самое) формируем транзакцию, вводим в адрес получателя смарт контракт этого приложения "AtPvLHpqrcrioixZWxCNkAGLRdZuh9mJaqKVtEzhaqLs", в поле сумма можно вбить любую сумму, 0.1-0.000...1 cs, в поле комиссия, меняем стандартную комиссию 0.1CS которую нам предлагает веб кошелек, на 0.0005CS, нажимаем отправить. смарт контракт не сможет принять эти монеты, потому что мы указали слишком маленькую комиссию для перевода. в это время никто не сможет пользоваться приложением, оно просто не будет отвечать никакому пользователю, пока не зафейлится отправка монет с недостаточной комиссией(это время варьируется в зависимости от скорости создания новых блоков, от 1.5 минут до 4 и больше) таким образом можно заблокировать работу всех смарт контрактов в сети. причем злоумышленник получит свои отправленные монеты назад, его расходы это только комиссия за перевод 0.00043cs. данную процедуру можно проделывать сколько угодно раз, хоть со всеми смарт контрактами в сети одновременно в течении целого дня. никто все это время не сможет пользоваться никаким смарт контрактом в сети Credits. можно навечно заблокировать работу любого смарта. по моим подсчетам с помощью этого способа, чтобы заблочить 1 смарт популярного приложения в сети Credits на целый день, злоумышленнику понадобится всего $0.72 довольно бюджетненько) почему $0.72? фейлится транзакция с недостаточной комиссией в течении 1.5 минут и это в самом быстром варианте, когда скорость создания новых блоков примерно 2 блока в секунду. (если скорость создания блоков медленнее, то транзакция будет фейлится дольше). возьмем за основу показатель в 2 минуты. При условии что комиссия в сети cs будет находиться на уровне $0.001, то злоумышленнику понадобится всего $0.03 чтобы заблокировать работу смарт контракта на один час и $0.72 для блокировки на 24 часа, то бишь сутки. после того как я проделал данную процедуру на приложении DICE, то оно поломалось) сначала на кошелек, с которого я делал эту процедуру, перестали приходить выигрыши вообще, хотя в истории транзакций, было видно как будто мне приходили монеты. но на самом деле на баланс они не зачислялись, хотя играя на других аккаунтах такой проблемы не было. потом спустя пару часов, выигрыши стали приходить, но с одним но. теперь после каждой игры в DICE с тебя снимают 0.1 CS. допустим ставишь ты 1 монету на коэффициент 2, если твоя ставка сыграла, то в истории транзакции видно, как смарт контракт отправил тебе 2 монеты. вот только на баланс тебе зачисляется не 2cs, а 1.9cs. я удивлен что никто, из тех кто тестировал это приложение не заметил этого. Как мы видим на скрине, была сделана ставка 1CS на коэффициент 2, ставка сыграла, смарт контракт выплатил мне 2 монеты, но на балансе почему то 5.8996689453125cs, хотя должно быть 5.9996689453125cs. 0.1cs просто испарились, они не зачислились, хотя смарт вроде как нам выплатил нашу положенную сумму, судя по истории транзакций. в случае проигрыша тоже самое, с тебя снимают лишние 0.1cs. это происходит абсолютно на любом аккаунте.
Тем же самым способом можно парализовать передачу любого токена в сети, хоть всех сразу. отправляем на смарт контракт токена 0.000...1cs, выставляем комиссию 0.0005cs и после этого отправка этого токена, в отношении которого мы совершили данное действие будет невозможна. все транзакции с этим токеном хоть 10, хоть 20, хоть 50 штук будут висеть в статусе пендинг, пока не зафейлится передача монет Credits с недостаточной комиссией. При желании как я уже сказал, можно навечно парализовать передачу всех токенов и работу всех приложений в сети Credits. все что для этого нужно, написать бота(ну либо делать все это вручную), который каждые 1.5-2 минуты будет отправлять на смарт контракты токенов или любых приложений монеты Сredits с недостаточной комиссией. стоимость такой атаки на 1 смарт контракт в день будет составлять всего $0.72.

Апдейт: Баг с исчезающими 0.1cs как я понял уже пофиксили, по крайней мере сейчас мне не удается его повторить.
1
2

[Smarcontract feature] smartcontract as initiator or new variable fromContract for token transfer

Is your feature request related to a problem? Please describe.
First of all thank you angelesmanzo for you feedback on #22. I suggest to continue our discussion here as we are going away from initial subject.
ERC-233 answer perfectly to my first concern to not use 2 transactions to do one transfer. I hope you will go this way.

I read your answear but it looks like business logic is written in token smartcontract ?
I will try to explain a bit more the idea I wish to implement :
I create a smartcontract for token , let s call is "token contract"
Then I dynamically create new contract for each bet i want to create : call it "bet contract"

The idea is :
I create bet contract that contain the token address to be able to call token transfer through invokeExternalContract.
So in bet method (in bet contract) I do business logic and then call a approve / transferFrom to send token to smartcontract address.
After some time (can be hours and better can be away), smartcontract close bets and then compute winners. When done it need automatically pay all winners.

Describe the solution you'd like
To pay all winners automatically i think we can have two ways :
1 / Add a new property in token contract like :
private Map<String, String> approvedContract; //<OwnerOfBetContract, BetContractAddress

then when I create a new bet contract I call also in token contract call this new method : public void approveBetContract(String betContract) {
Object[] params = new Object[] { };
String newBetOwnerContract = (String) invokeExternalContract(betContract, "getOwner", params);
approvedContract.put(newBetOwnerContract, betContract);
}

Now I need to update either transfer or transferFrom code to allow also this new approvedContract map when token transfer is called
This way here i have a second list of approved address that I could call automatically from a cron in my 3rd party program with bet contract owner address right ? This way i can do automatic payment instead of asking to each user to create transactions to get funds back. Looks better for automation ?

The problem I see here is that initiator wallet have 0 Token, this is the smartcontract who get token so I guess I only can use and adapt transferFrom method ?

Describe alternatives you've considered (seems better to me)
I think with automation, we could add a new variable in com/credits/scap/v0/SmartContract.java.
This could be the smartContractCaller and create a new method transferFromSmartContract that would check smartContractCaller instead of initiator. (If fees payment are required, they can be checked from smartContractCaller owner address).
This way may be later on we could create Cron inside smartcontract that automatically will be able to do payements.

Use invokeExternalContract to do a token transfer

Describe the bug
I created a smartcontract to act as escrow for betting.
I do this :

 Object[] params = new Object[] { owner, amount };
 System.out.println("send token to "+owner+", "+amount);

 Object result = invokeExternalContract("GcqTxR4qjHfzmcYGaMeGi7T1fPf414oKzfTjUjAFKuPB", "transfer", params);

Also smartcontract was deployed with these options :
@UsingContract(address = "GcqTxR4qjHfzmcYGaMeGi7T1fPf414oKzfTjUjAFKuPB", method = "transfer") in smartcontract before the method i use to call invokeExternalContract

also tried at deployment and execution from client side to specify usedSmartContractsByte with GcqTxR4qjHfzmcYGaMeGi7T1fPf414oKzfTjUjAFKuPB .
used like this in client code :

SmartContractInvocationData scData = new SmartContractInvocationData(smartContractDeployData, method,
					params, usedSmartContractsByte, false);

When I try this method I had :
com.credits.client.node.exception.NodeClientException: Credits Node error: state is empty!

from node smartcontract executor issue seems to be located there :
https://github.com/CREDITSCOM/ewa/blob/master/sc-api/src/main/java/com/credits/scapi/v0/SmartContract.java#L94
smart contract "GcqTxR4qjHfzmcYGaMeGi7T1fPf414oKzfTjUjAFKuPB" can't be modify

        if (!usedContract.getContractData().isStateCanModify() && !Arrays.equals(
            usedContract.getContractData().getContractState(),
            returnValue.newContractState)) {
            throw new ContractExecutorException("smart contract \"" + contractAddress + "\" can't be modify");
}

I didn t manage to get the error on my node but with previous version I remember the problem seems to be located there :

To Reproduce
Here is the initiator wallet I used :
https://monitor.credits.com/testnet-r4_2/account/Eyh6ZBiM9D9yyLDwFG7nqAwgm8fFfJn7NauZ6bQxsufn#

here is the smartcontract :
https://monitor.credits.com/testnet-r4_2/Contract/5LKBpWvcDXYi4QK9xpx9Mraibj6hqgoai9R6m2Hn1qV3

** Additional question **
Can we transfer token to a smartcontract address ? If so, how can we initiate token transfer token from this same smartcontract as it can t be initiator ?

SmartContract : update state with parallel execution

Describe the bug
When called and modified by many initiator at same time, the state of smartcontract may not be updated correctly.

check these transactions:
https://monitor.credits.com/testnet-r4_2/transaction/29bc23183a8ce88d41ca2548070f5636cf34a482c831d0842dafb4412017e5f7.1

https://monitor.credits.com/testnet-r4_2/transaction/39988bdcf246072a9bcb5a3fdb4d8a1084d3b8b62ae8810dbcb77f478ee5e1e7.1

To Reproduce
I created a smartcontract there, this is just a call counter.
https://monitor.credits.com/testnet-r4_2/Contract/5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP

I created a client that call same smartcontract from 3 initiators address from 3 differents threads.
Then I loop N times to check if all return value are OK. For some times returned values where all uniq but for some few call state and call result was the same for two initators. That means that the counter do not work properly.

Here is my client log :

16-06-2019 21:06:08.672  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 37 : Success 7C29000000005ABA249D3F2E8EDE4BA73129D1F31E93F1D6FB6E988E5842D6F6F8161BA6B0854824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:61>
16-06-2019 21:06:08.672  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:06:08.708  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:06:08.708  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:06:08.718  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:06:10.225  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 36 : Success 280000000000223A02FFD91ED99BFB42613F0CF780BF046481D6ED58CD8A7F66FECC2536847C4824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:60>
16-06-2019 21:06:10.226  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:06:10.290  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:06:10.290  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:06:10.294  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:06:11.853  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 38 : Success 722900000000A83154187EF6A74929E8F2DA9CC5AE90AEB2F65873CDFCB4E5CABCA92647481A4824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:59>
16-06-2019 21:06:11.853  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:06:11.881  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:06:11.881  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:06:11.885  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:06:18.774  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 37 : Success 7D29000000005ABA249D3F2E8EDE4BA73129D1F31E93F1D6FB6E988E5842D6F6F8161BA6B0854824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:62>
16-06-2019 21:06:18.774  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:06:18.825  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:06:18.825  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:06:18.829  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:06:23.640  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 36 : Success 290000000000223A02FFD91ED99BFB42613F0CF780BF046481D6ED58CD8A7F66FECC2536847C4824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:63>
16-06-2019 21:06:23.640  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:06:23.665  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:06:23.665  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:06:23.669  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:06:36.340  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 38 : Success 732900000000A83154187EF6A74929E8F2DA9CC5AE90AEB2F65873CDFCB4E5CABCA92647481A4824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:64>
16-06-2019 21:06:36.340  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:06:36.368  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:06:36.368  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:06:36.372  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:06:40.609  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 37 : Success 7E29000000005ABA249D3F2E8EDE4BA73129D1F31E93F1D6FB6E988E5842D6F6F8161BA6B0854824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:65>
16-06-2019 21:06:40.610  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:06:40.640  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:06:40.640  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:06:40.657  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:06:45.931  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 36 : Success 2A0000000000223A02FFD91ED99BFB42613F0CF780BF046481D6ED58CD8A7F66FECC2536847C4824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:66>
16-06-2019 21:06:45.931  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:06:45.976  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:06:45.976  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:06:45.979  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:06:52.009  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 38 : Success 742900000000A83154187EF6A74929E8F2DA9CC5AE90AEB2F65873CDFCB4E5CABCA92647481A4824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:67>
16-06-2019 21:06:52.009  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:06:52.032  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:06:52.032  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:06:52.036  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:06:57.515  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 37 : Success 7F29000000005ABA249D3F2E8EDE4BA73129D1F31E93F1D6FB6E988E5842D6F6F8161BA6B0854824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:67>
16-06-2019 21:06:57.516  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:06:57.557  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:06:57.558  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:06:57.562  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:07:00.813  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 36 : Success 2B0000000000223A02FFD91ED99BFB42613F0CF780BF046481D6ED58CD8A7F66FECC2536847C4824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:68>
16-06-2019 21:07:00.814  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:07:00.835  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:07:00.835  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:07:00.839  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:07:05.951  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 38 : Success 752900000000A83154187EF6A74929E8F2DA9CC5AE90AEB2F65873CDFCB4E5CABCA92647481A4824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:68>
16-06-2019 21:07:05.951  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:07:05.987  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:07:05.987  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:07:05.990  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:07:10.472  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 37 : Success 8029000000005ABA249D3F2E8EDE4BA73129D1F31E93F1D6FB6E988E5842D6F6F8161BA6B0854824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:69>
16-06-2019 21:07:10.472  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:07:10.504  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:07:10.504  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:07:10.511  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:07:14.726  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 36 : Success 2C0000000000223A02FFD91ED99BFB42613F0CF780BF046481D6ED58CD8A7F66FECC2536847C4824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:69>
16-06-2019 21:07:14.727  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:07:14.749  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:07:14.750  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:07:14.754  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:07:20.145  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 38 : Success 762900000000A83154187EF6A74929E8F2DA9CC5AE90AEB2F65873CDFCB4E5CABCA92647481A4824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:70>
16-06-2019 21:07:20.145  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:07:20.175  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:07:20.175  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:07:20.178  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:07:23.683  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 37 : Success 8129000000005ABA249D3F2E8EDE4BA73129D1F31E93F1D6FB6E988E5842D6F6F8161BA6B0854824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:70>
16-06-2019 21:07:23.683  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:07:23.704  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:07:23.704  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:07:23.707  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:07:29.490  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 36 : Success 2D0000000000223A02FFD91ED99BFB42613F0CF780BF046481D6ED58CD8A7F66FECC2536847C4824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:71>
16-06-2019 21:07:29.490  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:07:29.519  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:07:29.519  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:07:29.522  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:07:32.757  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 38 : Success 772900000000A83154187EF6A74929E8F2DA9CC5AE90AEB2F65873CDFCB4E5CABCA92647481A4824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:72>
16-06-2019 21:07:32.757  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:07:32.787  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:07:32.787  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:07:32.790  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:07:38.032  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 37 : Success 8229000000005ABA249D3F2E8EDE4BA73129D1F31E93F1D6FB6E988E5842D6F6F8161BA6B0854824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:73>
16-06-2019 21:07:38.033  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:07:38.059  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:07:38.059  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:07:38.065  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:07:42.118  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 36 : Success 2E0000000000223A02FFD91ED99BFB42613F0CF780BF046481D6ED58CD8A7F66FECC2536847C4824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:73>
16-06-2019 21:07:42.118  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:07:42.142  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:07:42.142  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:07:42.148  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:07:46.777  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 38 : Success 782900000000A83154187EF6A74929E8F2DA9CC5AE90AEB2F65873CDFCB4E5CABCA92647481A4824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:74>
16-06-2019 21:07:46.777  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:07:46.800  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:07:46.801  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:07:46.803  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:07:49.738  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 37 : Success 8329000000005ABA249D3F2E8EDE4BA73129D1F31E93F1D6FB6E988E5842D6F6F8161BA6B0854824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:74>
16-06-2019 21:07:49.738  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:07:49.763  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:07:49.763  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:07:49.767  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:07:57.953  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 36 : Success 2F0000000000223A02FFD91ED99BFB42613F0CF780BF046481D6ED58CD8A7F66FECC2536847C4824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:75>
16-06-2019 21:07:57.953  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:07:57.992  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:07:57.992  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:07:57.996  o.c.l.l.DoSendSmartContractThread.doSend - send transaction
16-06-2019 21:08:06.129  o.c.l.l.DoSendSmartContractThread.doSend - Thread : 38 : Success 792900000000A83154187EF6A74929E8F2DA9CC5AE90AEB2F65873CDFCB4E5CABCA92647481A4824E36BACA0FA7C179BE15F031357E37A3E83490393E624E59F4A6400352E46000000000000000000000000FF4F0101440300000B00010000000A696E63436F756E7465720F00020C000000000F00030B00000000020004000C00050B0001000000FA696D706F727420636F6D2E637265646974732E73636170692E616E6E6F746174696F6E732E2A3B0A696D706F727420636F6D2E637265646974732E73636170692E76302E2A3B0A0A7075626C696320636C61737320546573743120657874656E647320536D617274436F6E7472616374207B0A207072697661746520496E746567657220636F756E7465723B0A207075626C69632054657374312829207B0A20636F756E7465723D303B0A207D0A200A207075626C696320537472696E6720696E63436F756E7465722829207B0A20636F756E7465722B2B3B0A2072657475726E20636F756E7465722E746F537472696E6728293B0A207D0A7D0F00020C000000010B00010000000554657374310B0002000001EFCAFEBABE0000003700200A000700120A0013001409000600150A001300160A00130017070018070019010007636F756E7465720100134C6A6176612F6C616E672F496E74656765723B0100063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501000A696E63436F756E74657201001428294C6A6176612F6C616E672F537472696E673B01000A536F7572636546696C6501000A54657374312E6A6176610C000A000B07001A0C001B001C0C000800090C001D001E0C001F000F0100055465737431010022636F6D2F637265646974732F73636170692F76302F536D617274436F6E74726163740100116A6176612F6C616E672F496E746567657201000776616C75654F660100162849294C6A6176612F6C616E672F496E74656765723B010008696E7456616C7565010003282949010008746F537472696E6700210006000700000001000200080009000000020001000A000B0001000C0000002D000200010000000D2AB700012A03B80002B50003B100000001000D0000000E00030000000600040007000C00080001000E000F0001000C0000003D00030003000000212AB400034C2A2AB40003B600040460B800025AB500034D2B572AB40003B60005B000000001000D0000000A00020000000B0019000C00010010000000020011000B000300000000080004000000000000
Result from smartcontract : <Variant v_string:75>
16-06-2019 21:08:06.129  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - ---> address = 5rcykeiGiP7V2tjxqFCoduG6qvpbr8hUsgwLafeL9EXP
16-06-2019 21:08:06.172  c.c.c.n.util.NodeClientUtils.logApiResponse - <--- resultCode = 0; resultMessage = Success
16-06-2019 21:08:06.173  c.c.c.n.s.NodeApiServiceImpl.getSmartContract - <--- smart contract hashState = 
16-06-2019 21:08:06.179  o.c.l.l.DoSendSmartContractThread.doSend - send transaction

we can see duplicate results with lines containg (Result from smartcontract) : 67, 68,69 ,70,73,74,75

Expected behavior
Concurent access policy should be added here ?

Testnet v4.2.420 - frequent lost of communication to signal server

Last two days my node experienced problems with connection to signal server
after 1-2 hours of proper work. It happened several times
during this times and always terminating client.exe (Ctrl+C) and
restarting the node helped to bring proper work back.
Maybe I'm wrong but I fill it is associated with extensive execution of smart contracts
causing problems in testnet network. Probably another tester was trying to reproduce
another bug with smart contracts. Now I see smart contracts are executed
quite seldom and my node is working for few hours without problems.
I did a ping to signal server during these problems with following results:
time=27ms
TTL=116
0% loss

System: Windows 10 Pro

Please find log file from my node attached

log_1.txt

Node-client on Ubuntu 16.04 can Not be started/launched

An issue was gotten when I was trying to start/launch a new node-client (desktop version for Linux).

Here the steps performed for installing:

  1. OS Ubuntu-16.04.6-desktop-amd64 image was installed
  2. Oracle Java 11 was installed from PPA repository
  3. Client version for Linux was downloaded from credits site: https://credits.com/Content/file_users/Credits_Node_linux_x64_ver_4.2.412.3_test.tar.gz
  4. Tar file was unziped in Desktop directory.

Afterward, the client should be launched, the new public key should be created and the node should establish connection to tesnet credits blockchain. However, the following error is showed on the prompt (please see screenshot):

issue

Additional comment: It seems that some dependencies/packages are missing and should be included/installed for Ubuntu: libstdc++6 and libc6.

The same issue is gotten by launching the desktop client for credits blockchain MainNet

Big thanks for support!

Angeles

Mainnet Version 4.2.219 - Sync Issue / Endpoint adress too big 28

Hello,

I have currently two Linux Vps who are syncronising from scratch the Mainnet DB.
Version is Linux Mainet 4.2.219 provided by Vladimir yesterday evening.

The sync goes well but i have constantly a message on both VPS in the sync panel:

"Endpoint adress too big 28"

Here's a printscreen in attach of the message and also a details of my 2VPS

If you need any log files or details, please let me know.

Best regards,

Toki

2019-07-23 09_25_30-credits@vmi264333_ ~
2019-07-23 10_55_19

Error Node on Linux

Hi
same errors after i selected "q" to exit or after choosing "p" then i pressed "enter" instead of password
Sans titre 2

[v417] SmartContract execution => Credits Node error: Transaction in progress

Describe the bug
I tried to reproduce issue #27 with parameter to force smartcontract execution in config.ini.
Chain was resolving around 10 blocks / 20 sec as initial conditions.
The first 6 exections were ok but after I got 4 error like this :

com.credits.client.node.exception.NodeClientException: Credits Node error: Transaction in progress
	at com.credits.client.node.util.NodeClientUtils.processApiResponse(NodeClientUtils.java:31)
	at com.credits.client.node.service.NodeApiServiceImpl.callTransactionFlow(NodeApiServiceImpl.java:211)
	at com.credits.client.node.service.NodeApiServiceImpl.smartContractTransactionFlow(NodeApiServiceImpl.java:179)
	at org.credits.load.loadtest.DoSendSmartContractThread.doSend(DoSendSmartContractThread.java:161)
	at org.credits.load.loadtest.DoSendSmartContractThread.run(DoSendSmartContractThread.java:58)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)

please find logs in attached files
log_TxInProgress.tar.gz

(my program is based on latest wallet-destop.jar v417)

Running 2 consensus node with same (50k) wallet

OPEN QUESTION
I did a test with two nodes using same wallet for staking. The result is both node work and get trusted. But they get TRUSTED for always same blocks and same trusted [number]. So obviously only one trust count each time.

It looks ok if we agree that having 2 nodes running do not give 2 more chance to have one of these 2 nodes selected for consensus ?

Additional context

here an exemple og log in each node :
[2019-05-27 20:15:02.505822] [0x00007feced629700] [info] ============================== R-2'662'425.0 TRUSTED [3] ==============================
[2019-05-27 20:15:02.505827] [0x00007feced629700] [debug] Node key FD370D1F5B3E3535052A90A6D47F68F890252AFFB2736384AF45ADA1D80DA960

and
[2019-05-27 20:15:02.525672] [0x00007f3c798ff700] [info] ============================== R-2'662'425.0 TRUSTED [3] ==============================
[2019-05-27 20:15:02.525689] [0x00007f3c798ff700] [debug] Node key FD370D1F5B3E3535052A90A6D47F68F890252AFFB2736384AF45ADA1D80DA960

выход за пределы массива

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:
использовать limit на максисмум и ненулевой offset

Expected behavior
ничего хорошего

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):
любая

Smartphone (please complete the following information):
любой

Additional context

node/api/src/apihandler.cpp

Lines 508 to 510 in 9dfff31

if (limit > transactionsCount)
limit = transactionsCount; // лимит уменьшается до реального количества // транзакций которые можно отдать
for (int64_t index = offset; index < (offset + limit); ++index) {

эти вещи code analyzer схватывает вроди. в msvc team edition он был

One minute between these 2 blocks

we finished test and chain is slow. here is some log with no transactions over network
[2019-05-15 23:33:37.023910] [0x00007f14af928700] [debug] Normal: nothing to do with transactions packet in this state
[2019-05-15 23:33:37.023925] [0x00007f14af928700] [debug] TRANSPORT> POSTPHONED finished, round 2398489
[2019-05-15 23:34:22.480128] [0x00007f14af928700] [debug] TRANSPORT> Got SS Last Block: 2398488
[2019-05-15 23:34:26.502397] [0x00007f14af928700] [warning] -----------------------------------------------------------
[2019-05-15 23:34:26.502491] [0x00007f14af928700] [warning] NODE> BigBang #2398489: last written #2398488, current #2398489
[2019-05-15 23:34:26.502546] [0x00007f14af928700] [warning] -----------------------------------------------------------

here one minute between these 2 blocks

Memory leak Linux Client node Testnet version 4.2.412.4

Describe the bug
Used amount of memory used by Linux client is not stable/regular.

The amount of memory used by the client node is increasing little by little. After starting the node the memory level used is about 800mb, but after a few days as you can see in the attached log file, client use more than 3GB of memory. Which could crash / make unstable the system if the maximum available memory level available is reached.

The attached log file was generated with the following command that checks every minute the amount of memory used by the specified process:

watch -n 60 "pmap -x 5648 | grep total >> /home/credits/Clientmemory_20190516_0844PM.txt"

Where the number 5648 is the PID of the node client process

PID of the node client process is know by the following command:

ps -ef | grep client

The log file containing 8613 lines, which represents
8613 minutes or 5 days, 23 hours and 33 minutes.

Desktop (please complete the following information):

  • OS: Ubuntu
  • Version: 18.04

ClientMemory_20190517_0720PM.txt

Stop any smart contract on the network

Describe the bug
There is a way to paralyze the work of absolutely any smart contract in the network. Smart contract stops responding to requests of any user (whether it is a smart contract of the game application or any other, it does not matter). If we take the example of gambling application, the player will bet by sending a smart contract Credits coins, but the smart contract will not respond to him, moreover, the sent coins will be in limbo. Smart contract will not be able to get these coins and get back their coins to the user will also fail (coins hang in the air)

To Reproduce
Сreate a transaction. enter the address of any smart contract, in the amount field, enter any value 0-0.000...1 cs, then enter in the commission 0.0005 cs and click send transaction. smart contract will not be able to accept these coins, because we have indicated too little сommission for the transfer. at this time, no one will be able to use the application, it simply will not respond to any user until the sending of coins with insufficient commission is canceled(this time varies depending on the speed of creating new blocks, from 1.5 minutes to 4 or more) so you can block the operation of all smart contracts in the network
this procedure can be done as many times as you want, even with all smart contracts on the network at the same time during the whole day. no one will be able to use any smart contract in the Credits network all this time. you can permanently block the operation of any smart contract. according to my calculations with this method to block 1 smart contract of the popular application in the Credits network for the whole day, the attacker will need only $0.72) why $0.72? transactions with insufficient commission are rejected within 1.5 minutes and this is the fastest option, when the speed of creating new blocks is about 2 blocks per second. (if the block creation speed is slower, the transaction will be rejected longer). take as a basis of 2 minutes. Provided that the commission in the cs network will be at $0.001, the attacker will need only $0.03 to block the operation of the smart contract for one hour and $0.72 to block for 24 hours
In the same way, you can paralyze the transaction of any token in the network. sent to the smart contract of token 0-0.000...1cs, set a commission of 0.0005 cs and then the transaction of this token, in respect of which we have committed this action will be impossible. all transactions with this token will be in the pending status until the Credits coin transaction with insufficient commission is rejected. If desired, as I said, you can permanently paralyze the transfer of all tokens and the operation of all applications in the Credits network. all you need to do is write a bot(or do it all manually), which is every 1.5-2 minutes will send credits coins to smart contracts with insufficient commission. the cost of such an attack on 1 smart contract per day will be only $0.72.
2

[BUG][CRITICAL] Transfer of created tokens above 4 digits fails

Describe the bug
When transferring tokens on CS blockchain any amount from 4 digits or higher will fail despite paying credits transfer fee and having a sufficient token balance
Only transactions up to the amount of 999 are succesfull, higher will fail

This was done with created Dutch BBQ Token on mainnet which was created by the default token smartcontract. This all was done via the iOS app.

To Reproduce
Mainnet

Steps to reproduce the behavior:

  1. Go to ios app
  2. initiate token transfer with the amount of one thousend BBQ tokens or more
    3.Transaction will fail
    4.fee is deducted from balance
    5.receiving party gets notification of zero tokens received (Transaction history, fee is zero
    receiving party
    )
    6.Monitor shows failed token transactions

Expected behavior
transfer of tokens to receiving party

Screenshots
added above

Additional context
https://monitor.credits.com/CreditsNetwork/account/3ABKJowm9aqPKkYMLcxjHdtH5SkicQhV2zuf2nGK6qMi

Difference in total fee (network node list) and actual received fee

Describe the bug
It's possible to view the total fee received by a node on the network node list page. The fees displayed on this page are a bit off compared to what's received in the wallet.

This bug is present in tesnet 4.2.417.

To Reproduce
Steps to reproduce the behavior:

  • Check any node on the network nodes pages to see the 'total fee' according to that page.
  • Check the wallet balance, subtract the initial transaction. Amounts should be the same, which is not.

Screenshot
As an example:
image
image

Build failure: thrift Haskell library

The Haskell library for Thrift fails to build due to the following error

src/Thrift/Transport/Handle.hs:34:1: error:
    Could not find module ‘Network’
    Use -v to see a list of the files searched for.
   |
34 | import Network
   | ^^^^^^^^^^^^^^

This is because in the Network module was deprecated in network-2.7 and removed in network-3.0. However, the cabal file for it specifies it needs network > 2.6.

I realize this is a third-party module. Is the Thrift Haskell library necessary for the functioning of the CREDITSCOM node, though? If not, is there an easy way of disabling it?

This is on Arch Linux using GHC 8.6.5.

Self build client can not connect to signal server.

Describe the bug
Managed to build the node from the code available on github. Upon starting the node it tries to connect to the signal server, but nothing happens with that. I simply replaced the client file with the client file I built, so that the config.ini should work.

Something I noticed is that the client file is about 15% of the file provided on the developers portal. See the image below.
image

The entire build folder is about the size of the client file provided by the Credits team. Am I missing any command to finish the build?

I've attached two files cmake and make as that was the output of running those commands.
cmake.log
make.log

To Reproduce
I've used the steps provided in the readme.MD to build the node.

git clone https://github.com/CREDITSCOM/node.git
cd node
git submodule update --init --recursive
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make -j4

Desktop (please complete the following information):

  • OS: Ubuntu
  • Version 18.04.2 LTS (GNU/Linux 4.15.0-50-generic x86_64)

Current smart contracts are not suitable for a large number of players playing at the same time

My English is not perfect, so for a better understanding of the problem, after the English description I posted the Russian version of this text because most of the developers are Russian

Describe the bug
Current smart contracts are not suitable for a large number of players playing at the same time
To Reproduce
I can't show it in a network testnet, for the reason that testnet behaves inadequately. He then does not respond to my requests, then does it after 2 minutes. So I'll show it in the network dapsnet. The example in application egyptslot. The same problem is in the network testnet, or any other
Suppose that in egypetslot(or any other app) plays at the same 10 people. Traffic 10 transactions per second. all bets that will be in the same block will be with the same outcome. Let's say 10 transactions(bets) from different accounts fall into one block. The network will give a block in which there will be either 10 or 20 transactions(depending on whether there was a win or not)
All 10 accounts will either receive the same winnings or lose. Example: I placed 3 bets at the same time from different accounts. They fell into one block and all three accounts received the same win or lose. In this case, all 3 bets that hit one block got a win of 4cs. Here is the hash block where there were 3 transactions(bets) from different accounts in one block
34ef00682698feda01233add1cecca471441d4deaf00c2c52ac55b30199a3912
1
As a result, these bets that were in the same block received the same winnings for 4cs. here's the hash
5ef308db3d5e29dba860560f67c7a3c48798a50de27e44e9836e1818c5a667cc.
2
Here is another example. All bets that were in one block received a win of 8 cs.
Безымянный
Безымянный2
And this always happens. If there are 50 transactions (bets) in one block. Then these 50 bets will either win the same amount at the same time or lose. What can this lead to?
With a large number of bets in one application, all players will either win the same amount at the same time or lose massively at the same time. All bets will have the same outcome for everyone. No randomness. It will be unprofitable for developers of casinos and other decentralized applications. Because in one moment may occur such a situation that all accounts whose transactions have been in the same block, will have to pay out large winnings. For example X10. Developers will suffer great losses

Не могу показать это в сети тестнет, по той причине, что тестнет ведёт себя неадекватно. Он то не отвечает на мои запросы, то делает это спустя 2 минуты. Поэтому я покажу это в сети дапснет. На примере приложения egyptslot. Та же самая проблема есть в сети тестнет, либо любой другой
Предположим что в egypetslot(либо в любое другое приложение) играет одновременно 10 человек. Трафик 10 транзакций в секунду. все ставки, которые окажутся в одном блоке будут с одним и тем же исходом. Допустим попадает в один блок 10 транзакций(ставок) с разных аккаунтов. Сеть выдаст в ответ блок в котором будет либо 10 либо 20 транзакций(в зависимости от того был выигрыш или нет)
Все 10 аккаунтов получат либо одинаковые выигрыши, либо проиграют. Пример: Я делал 3 ставки одновременно с разных аккаунтов. Они попадали в один блок и все эти три аккаунта получали одинаковый выигрышь, либо проигрывали. В данном случае все 3 ставки что попали в один блок получили выигрышь 4cs. Вот хеш блока где было 3 транзакции(ставки) с разных аккаунтов в одном блоке
34ef00682698feda01233add1cecca471441d4deaf00c2c52ac55b30199a3912
В итоге эти ставки которые оказались в одном блоке получили одинаковые выигрыши по 4cs. вот хеш
5ef308db3d5e29dba860560f67c7a3c48798a50de27e44e9836e1818c5a667cc
И так происходит всегда. Если в одном блоке окажется 50 транзакций (ставок). То эти 50 ставок либо одновременно выиграют одну и ту же сумму, либо проиграют. К чему это может привести?
При большом количестве ставок в одном приложении, все игроки будут либо одновременно выигрывать одинаковые суммы, либо массово одновременно проигрывать. У всех ставок будут одинаковые исходы. Никакого рандома. Это будет невыгодно разработчикам казино и других децентрализованных приложений. Потому что в один момент может произойти такая ситуация, что всем аккаунтам чьи транзакции попали в один блок, придётся выплачивать большие выигрыши. К примеру х10. Разработчики понесут большие потери

use client wallet to remotely validate a node

Is your feature request related to a problem? Please describe.
Many Credits followers will use some VPS to run their node.
Also, storing keys even encrypted can be a problem of confidence with VPS operators as admin may access to vm if not well protected. Also, even for home nodes, running a system 24h/24 can bring security issues.
So I do not know if this idea is doable, but your feedback could be interesting for me to read.

Describe the solution you'd like
1 / Generate from a client a new wallet (cscrypto, desktop or whatever)
2/ push only public key to the node
3/ start the node, node will connect to blockchain but can not participate to consensus until it s verified with a message signed by private key
4/ From client (with desktop wallet for exemple) ask node to sign a phrase
5/ Node generate a phrase to sign and send it back to client wallet
6/ Client wallet sign with local private key the phrase and send it to node
7/ node/chain verify signature and activate node if signature is ok

Testnet v4.2.420 - problematic nodes

Today since few hours my node frequently losing synchronization because of two nodes:
37.203.33.37
89.111.33.168

In my CMD window I frequently see:

"Got registration request...",
"Confirming registration..."

Seldom I see

"Stop resopnding..."

They causing my node is losing synchronization and have to sync itself to 100% frequently

My actual public IP:
178.43.74.197

My public key:
xXxYdjzrX6Hs4GeQHYL55KkttAUjKrMfc5TKUVueEgk

net: invalid input packet!!!!!!!!! [ version 4.2.412.4]

Describe the bug
I have two nodes on testnet.
One at personal home second is a contabo vps.
Home computer never had problem since one week. The vps goes after some times (days) with spamming screen with only this message I think I got it 3 times in this node :

net: invalid input packet!!!!!!!!!
net: invalid input packet!!!!!!!!!
net: invalid input packet!!!!!!!!!
net: invalid input packet!!!!!!!!!
net: invalid input packet!!!!!!!!!

All my log file just contain this message. I don t have other info than this one.

Screenshots
Looks also at log generated very fast + look gap between 71 and 80 and also datetime of all files. Only few seconds have been waited between these two ls commands :

credits@vmi247779:~/testnet/log$ ls -lrt
total 655336
-rw-rw-r-- 1 credits credits 52428791 May 19 19:39 log_8675.txt
-rw-rw-r-- 1 credits credits 52428776 May 19 19:39 log_8676.txt
-rw-rw-r-- 1 credits credits 52428791 May 19 19:39 log_8677.txt
-rw-rw-r-- 1 credits credits 52428776 May 19 19:39 log_8678.txt
-rw-rw-r-- 1 credits credits 26967285 May 19 19:39 log_8679.txt
-rw-rw-r-- 1 credits credits 52428791 May 20 22:07 log_8567.txt
-rw-rw-r-- 1 credits credits 52428776 May 20 22:07 log_8568.txt
-rw-rw-r-- 1 credits credits 52428791 May 20 22:07 log_8569.txt
-rw-rw-r-- 1 credits credits 52428792 May 20 22:07 log_8570.txt
-rw-rw-r-- 1 credits credits  5704874 May 20 22:07 log_8571.txt
-rw-rw-r-- 1 credits credits 52428714 May 23 20:21 log_8280.txt
-rw-rw-r-- 1 credits credits 52428776 May 23 20:21 log_8281.txt
-rw-rw-r-- 1 credits credits 52428791 May 23 20:21 log_8282.txt
-rw-rw-r-- 1 credits credits 52428776 May 23 20:21 log_8283.txt
-rw-rw-r-- 1 credits credits  9244344 May 23 20:21 log_8284.txt
credits@vmi247779:~/testnet/log$ ls -lrt
total 646380
-rw-rw-r-- 1 credits credits 52428791 May 19 19:39 log_8675.txt
-rw-rw-r-- 1 credits credits 52428776 May 19 19:39 log_8676.txt
-rw-rw-r-- 1 credits credits 52428791 May 19 19:39 log_8677.txt
-rw-rw-r-- 1 credits credits 52428776 May 19 19:39 log_8678.txt
-rw-rw-r-- 1 credits credits 26967285 May 19 19:39 log_8679.txt
-rw-rw-r-- 1 credits credits 52428791 May 20 22:07 log_8567.txt
-rw-rw-r-- 1 credits credits 52428776 May 20 22:07 log_8568.txt
-rw-rw-r-- 1 credits credits 52428791 May 20 22:07 log_8569.txt
-rw-rw-r-- 1 credits credits 52428792 May 20 22:07 log_8570.txt
-rw-rw-r-- 1 credits credits  5704874 May 20 22:07 log_8571.txt
-rw-rw-r-- 1 credits credits 52428776 May 23 20:21 log_8283.txt
-rw-rw-r-- 1 credits credits 52428791 May 23 20:21 log_8284.txt
-rw-rw-r-- 1 credits credits 52428776 May 23 20:21 log_8285.txt
-rw-rw-r-- 1 credits credits 52428791 May 23 20:21 log_8286.txt
-rw-rw-r-- 1 credits credits    70748 May 23 20:21 log_8287.txt

Desktop (please complete the following information):

  • ubuntu 18.04
  • Version 4.2.412.4

Full network shutdown

My English is not perfect, so for a better understanding of the problem, after the English description I posted the Russian version of this text because most of the developers are Russian

Describe the bug
Full network shutdown

To Reproduce

Created a smart contract that sends 10-15 transactions to the addresses of other seventeen(17) smart contracts. 10-15 transactions are sent to each of the 17 smart contracts. A total of 236 transactions and 17 recipients. This smart contract "DSR5wLzZsLJMx5gVAqUAiSBV8CjCbUsjvexdxdbxmqfz"
1111
After I created this smart contract, I sent 1 CS to it, this smart contract sent 236 transactions to the addresses of other 17 smart contracts. Then I sent 1CS to the smart contract which was in the list of these 17 smart contracts. After that, the network began to create 1 block in 1-2 minutes and ignore the transactions that I tried to send in the future. in this mode, the network "worked" for 25 minutes and created 22 blocks in 25 minutes. Then she stopped completely.
555
Создал смарт контракт который отправляет на адреса других семнадцати смарт контрактов 10-15 транзакций. На каждый из 17 смарт контрактов отправляется 10-15 транзакций. Всего 236 транзакций и 17 получателей. Вот этот смарт контракт "DSR5wLzZsLJMx5gVAqUAiSBV8CjCbUsjvEXdxDbxMQFz"
После того как я создал этот смарт контракт, я отправил на него 1 CS, этот смарт контракт разослал на адреса других семнадцати смарт контрактов 236 транзакций. Затем я отправил 1CS на смарт контракт который был в списке этих 17 смарт контрактов. После чего сеть стала создавать 1 блок за 1-2 минуты и игнорировать транзакции которые я пытался отправить в дальнейшем. в таком режиме сеть "работала" в течении 25 минут и создала за 25 минут 22 блока. После чего она полностью остановилась.

Token balances not being updated on monitor & web wallet

Bug in summary
Calling the transfer or transferFrom function indirectly causes token balances not to update properly on both monitor & web wallet. These token transactions are also not visible as transactions on the monitor.

Describe the bug (extended version)
Token balances do not update on both monitor and web wallet when the transfer or transferFrom function is not called directly.

When I transfer a token in a regular way (for example via web wallet) the following shows on the monitor:
image

As an extension to the basic contract, which still contains some other issues I've mentioned before (#11) I created a function where I can import token balances from a specific token in case I'd like to upgrade my token contract. This function clears the balance hashmap, sets all tokens to the contractAddress and starts transferring them to the wallets I import.

public void importBalances(String importBal) {
 if (!initiator.equals(owner)) {
 throw new RuntimeException("The wallet " + initiator + " is not owner");
 }
 balances.clear(); // Clear old hashmap as we're replacing balances with this import method

 balances.put(contractAddress, totalCoins); // set all tokens to contract address

 importBal = importBal.replaceAll("\\s+","");
 String[] newBalances = importBal.split(",");
 for (int i=0;i<newBalances.length;i++) {
 String newValue = newBalances[i];
 String[] keyValue = newValue.split("=");
 transferFrom(contractAddress, keyValue[0], keyValue[1]);
 }
 }

This function does what it needs to do, but the transaction I create shows up like this:
image

The string I imported via this function is as follows and should send tokens to two wallets:
33JWxAMxXzMmuuAoBZwAfc3qHP6xp1WTimoFqkdVFUwk=995, 7tiMoADn9VJfP3xEf58BAUj85mJuGmfqTyN86JeCk9TA=5

The hashmap does get updated in the background, but token balances are not updated on both monitor and web wallet. There are also no visible transactions of these two 'internal' transactions.

The contract address shows only 1 address as holder: https://monitor.credits.com/testnet-r4_2/Token/CcyY5NypSAVMGNoyQMYKeSZzZJP8jqjzwqTPvdByfXHc

image

When I use the balanceOf function for the other wallet, the correct amount is returned. This contract execution is also visible in the url mentioned above.

As far as I know the same issue happens when calling the transfer or transferFrom function from another contract using invokeExternalContract.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.