Again on the Tronscan Map..

And.. we are again back on the map! (14.09.2019 – 9 AM GMT+2)

How come we’ve disapeared?
Sadly.. in Romania, it seems that we are the only server (tron nodes) operators. There were some folks who ran the nodes but now ours are the only one. Once we dropped back to 10.. puf, the country was removed from the map.

Screenshot (before)

10 nodes before 14.09.2019

10 nodes before 14.09.2019 that were run by our SR Candidate

 

 

 

 

 

 

 

 

In order to address the issue I’ve deployed the 11th node. Now, all 11 that are shown on the maps belong to this SR Candidate (TronLabs Romania)

This is how it looks now

11 nodes Tronlabs Romania candidate

11 nodes after 14.09.2019 at 9 AM that belong to our SR candidate

[How-to] Convert Block level DB to ROCKS DB

This guide is intended for those who wish to convert from one DB format to another. The benefits are:
– You can use RocksDB as storage engine when you want to back up the database without the node application stopped,
– The Rocksdb engine has more tuning parameters for faster-synchronizing block and takes up less disk space when compared with the Block LevelDB.

Note:
You must only use one db engine (leveldb or rocksdb) throughout the life cycle of node because rocksdb’s data structure is incompatible with the leveldb’s. A convert tool is provided within Java-Tron to convert the leveldb data to rocksdb data and the usage of tool is described below. Please be aware that the conversion take time and the node is not syncing any blocks while this operation is ongoing.

1. First we need to clone the git and build it

git clone https://github.com/tronprotocol/java-tron
cd java-tron/
./gradlew build

Just wait until it’s built and tested. Go grab a cup of tee or a coffee.

2. Then we need to stop the node
3. Now we need to use this Java converter package (DBConvert.jar) to perform the conversion. It is located here: /java-tron/build/libs/

Sample syntax looks like this

java -jar build/libs/DBConvert.jar  your_database_dir/database  output-directory-dst/database

Example syntax looks like this

java -jar /home/userdir/java-tron/build/libs/DBConvert.jar /home/userdir/FullNode/output-directory/database /home/userdir/FullNode/output-directory2/database

According to tron documentation it should take about 10 hours to finish the conversion. Well on my node it took about 67800 seconds. This translates to 18.8 hours. The process is not CPU or Memory bound, both my CPU and Memory usage never exceeded 10% or the allocated resources.

Odyssey-v3.6.0 was released

On the 21st of June 2019 the latest Odyssey version 3.6 was released. This introduces new TVM instructions, API, protocol data check as well as optimizations.

New Features

  • #2070 Add create2 instruction for TVM, which returns a predictable contract address before deploy. TIP #26
  • #2069 Add bitwise shifting instructions for TVM to reduce energy consumption of shift. TIP #29
  • #2075 Add extcodehash instruction for TVM which returns the keccak256 hash of a contract’s code. TIP#30
  • #2125 Add triggerConstantContract API to support contracts which have no ABI. TIP #31
  • #2125 Add clearABI API including http and grpc, contract’s deployer can use this to clear his contract’s existed ABI. TIP #32
  • #2093 Add built-in message queue for event subscribe. TIP #28
  • #2047 Add protocol data check
  • #2154 Add the Permission_id field when returning the created transaction, compatible with multi-signature transactions

Changes

  • #2142 Support event subscription without abi
  • #2173 Optimize erengy deduction strategy in TVM when transfer 、sendor transferToken failed
  • #2141 Optimize the HTTP interface by adding the visible parameter to support the convenience type of addresses and strings, and add the AccountID related interface
  • #2182 Optimize http/grpc broadcast transaction interface
  • #2155 Optimize the process of block broadcasting
  • #2219 Fix the problem that the http interface parses the long type value for a long time.

Notices

  • Add built-in message queue config. See here
    use event.subscribe.native.useNativeQueue to control whether using built-in message queue . If true, use native message queue, else use event plugin.
    use event.subscribe.native.bindport to control bind port.
    use event.subscribe.native.sendqueuelength to control max length of send queue.
  • For smart contact without ABI (after clear ABI or deploy without ABI)
    If you want to call the constant method, you must use the triggerConstantContract interface instead of triggerContract . More details: TIP #31
    If you need event subscription, you need to subscribe to and upload ABI using version 3.6+. More details: tron-eventquery.md
    After clearABI, it is not possible to re-add ABI to the same contract address.
  • For create2 instruction
    If you want to use create2 to genertate a new address . More details: TIP #31
    After suicide, the storage of create2 addresses will be reset.
    If deployed on a normal address (created by transfer trx), the address will be modified to the contract address. The resources (bandwidth and energy) previously delegated to this address are cleared, and do not affect the unfreeze operation of the client.

Bucharest Blockchain and DPoS is safe !

A few days ago I received the following message via e-mail from the Meetup Site.

save_meetup

Save Bucharest Blockchain and DPoS

The Meetup group that I’ve attended and got inspired to run for TRON SR was going to disappear in a couple of days, if no one would step up and save it.
Knowing that it might be an issue with the payment or just some glitch, I told myself to be patient and wait for a couple of days. I’ve waited until the 2nd of March at 10 PM. No renewal and no one else stepped up so I had to act.

Now our Meetup group is safe. I plan to continue what Crypto Girls have started and help our community to succeed. I plan for both in person meetings as well as for virtual ones.

Stay tuned for more.. good things are coming our way.

Java-tron node, new Odyssey-3.5 released

Yesterday (28.02.2019) a new release (v. 3.5) became available.
https://github.com/tronprotocol/java-tron/releases/

New features:

  • Multiple signatures support and different permissions support in account
  • The upper limit of energy can be adjusted automatically by the current state of the network
  • Develop a new mechanism to listen event message from a queue

Changes:

  • Solved the Compatibility Problem between Backup and DUP_WITNESS
  • Optimize duplicate check of transaction, Increase processing speed
  • Transfertoken function security improvement
  • ADDRESS and ORIGIN instruction security improvements
  • Improve the partial UNKNOWN execution results of the smart contract to a more detailed error type
  • Log optimization improvements
  • Http interface improvements

 

Important:
You will need to update the config.conf:
https://github.com/tronprotocol/tron-deployment/blob/master/main_net_config.conf

Please complete your upgrade to the new version before next Tuesday (March 05, 2019), otherwise it will affect the synchronization of the node !

Romania – 10 Nodes online

Hello fellow Tron enthusiasts,

We did it ! As of this morning we have 10 Tron nodes online who are part of the Tron Main Net. This does translate to about 1% of the network. I am very proud to have put “Romania” officially on the Tronscan Nodes ranking map. This shows that we as a community SR, are all in !

Here are the screenshots:

10 Nodes Online on Tron MainNet 2nd of Febr. 2019

TronLabs Romania has 10 Nodes Online on Tron MainNet on 2nd of Febr. 2019

Tron Nodes Ranking 2nd of Febr. 2019

Tronscan Node Ranking shows 11 Nodes online. From this total number, 10 are ours (TronLabs Romania) and one belongs to another tron enthusiast.

If you want to help out, check our projects page and vote for us.

Case Study – The Missing TRX

A Reddit user found a Dapp called FomoSports and played it. He then saw that he was missing 80 TRX, that could not be justified in any way.

This is his address: TBhLhTP4Mscgj5gpMxfe6u1zsWQ3DzEGMi

How he explained it with his own words:
a) The deal is open a Tronlink wallet to receive 50 TRX to play, and after betting let person know to get another 100TRX.
b) My friend lost the 30TRX of the 50TRX then received another 100TRX. Then he played another 10×3 (30TRX) should have 90TRX left.
c) However, my friend told me that he only have 10TRX left in his Tronlink.

It is shown in these 3 screenshots below.

Transfers

 Transfers. 50+100 = 150 TRX

 

Transactions

Transactions. This is the SUM of the amounts +50 -20 -10 +100 -10 -10 -10 = 90

 

final amount

Final amount in the Tronlink Wallet = 10 TRX

 

This is what happened:

This is because of the energy fees.  The conversion values are listed below.

1 SUN = 0.000001 TRX
1 TRX = 1,000,000 SUN

Let’s break it down and look at the contract triggers on TronGrid.

Transaction 1: SUCCESSFUL(-20TRX) with Fee 2.869300 TRX

"energy_fee": 2869300

Transaction 2: SUCCESSFUL(-10TRX) with Fee 3.581450 TRX

"energy_fee": 3581450

Transaction 3: TIMED OUT with Fee 100TRX

"energy_fee": 100000000

Transaction 4: OUT OF ENERGY with Fee 3.549250 TRX

"energy_fee": 3549250

Transaction 5: OUT OF ENERGY with Fee 0TRX (no funds left)

"result": "OUT_OF_ENERGY"

Let’s sum it all up:
20 + 2.8693 + 10 + 3.58145 + 100 + 3.54925 = 140TRX

+10TRX still left in account = 150TRX (all accounted for)

The loss is mainly due to the 3rd contract trigger where the out of time exception occurred and this causes all the input energy to be spent as seen above. This seems very unfair because the actual running of said contract didn’t actually use that much energy (judging by the origin_energy_usage it should’ve been more like 4TRX charged).

The timed out with 100 TRX Fee was unexpected. This seems like a way for TRON to punish people for trying to run smart contracts that take too long to execute. Either that or it’s a bug in java-tron. You as a end user have no control over the smart contract and how it executes as it’s running on the Nodes of the super representatives.

Dapps/Project funding

Good morning fellow Tron enthusiasts !

As you know we have some exciting projects that we are working on and these need money. Historically speaking now with almost 174K votes we earn too less (12 TRX/day as total vote rewards) to fund the Dapp fund, so I thought how I can accelerate this a bit.

Screenshot from Tronstation

Vote rewards 18012019

Vote rewards 18.01.2019 (10:50 AM)

 

So how can we make the DAPP fund bigger ?

a) First contribution, of course, out of my own pocket.

The TronLabs Romania main SR account has 2000 Tron Power. This is because I’ve kept 2000 TRX frozen and have cast a vote for Cryptogirls till the end of year 2018. My first TRX that I ever received was 200 TRX (the bounty they promised) when I’ve attended their local meetup in Bucharest. When I later purchased my own in July, I’ve promised Irina that they will have 2000 Votes from me, till the end of the year. This promise I’ve kept till the 2nd of January 2019.

Since then, the same amount was used to vote for ourselves and according to what I’ve written above my plan is to pump this amount into the Dapp Fund as it’s first funding and to show that we are all in and need to lead by example. This is the HASH of the transfer. As details I’ve used “Project: TRLANY” (it can be used for any project).

b) though other contributions from fellow tron enthusiasts. If you wish to help, please donate into the Tron DAPP Development fundTXgbWCjqoM7QKSntXW9t1d9eoA3j9JUhCG and remember to add the Project ID Code into the Transaction Details so we can differentiate what it is for. Please check each Project page for more details.