Trust statistics seem off

[Dmole]

rm -r ~/.Tribler
apt install Tribler_7.1.0-exp2.deb
Tokens starts at 0 (seems like an easy way to game the system if there is any penalty for <0 )
Leave Tribler running for a bit with 0 Torrents, then observe;

• Given = 1.2GB
• Taken = 0.4GB
• Tokens = 0.8GB

... think about it

• Should Taken =0?
• If not should Given=Taken?
• even if there were some explanation for this (like some chunks are discarded as they were provided by another node first) that would mean that actively trying to contribute could have a net negative impact on ones tokens, making the feature counter productive.

Side note; please don't use the crazy date format (31-05-18), use date --iso-8601 (2018-05-31); sorting largest to smallest units is the only rational format.

[devos50]

@Dmole that's quite interesting! When not downloading anonymously, taken should instead always be zero. The easiest way to debug this, is to explore the blocks on the Tribler blockchain I guess. Could you please provide your database with blocks? You can find this in your Tribler state directory, specifically in ~/.Tribler/sqlite/trustchain.db. With this info, we might be able to figure out what happened 👍 (if you don't want to share this file publicly, you can also email it to me).

[Dmole]

One would hope with a fresh ~/.Tribler there would be nothing sensitive, but it's also kinda big so here is the tip;

du -sh ~/.Tribler/sqlite/trustchain.db | cut -f 1
17M

sqlite3 ~/.Tribler/sqlite/trustchain.db 'select count(*) from blocks;'
24442

sqlite3 ~/.Tribler/sqlite/trustchain.db 'select insert_time,sequence_number,link_sequence_number,tx from blocks limit 9;'
2018-05-31 21:31:55|17823|0|a4d4bdown7i733901310btotal_down12i1368913904318btotal_up13i15523933827842bup1i0
2018-05-31 21:31:55|1|17823|a4d4bdown1i010btotal_down1i08btotal_up7i73390132bup7i7339013
2018-05-31 21:31:55|1811|0|a4d4bdown9i13325219110btotal_down12i1362690080978btotal_up9i3689062682bup1i0
2018-05-31 21:31:55|2|0|a4d4bdown8i4441739710btotal_down8i444173978btotal_up7i73390132bup1i0
2018-05-31 21:31:55|3|1811|a4d4bdown1i010btotal_down8i444173978btotal_up9i1405912042bup9i133252191
2018-05-31 21:31:55|16100|2|a4d4bdown1i010btotal_down10i80832004978btotal_up13i13183900678272bup8i44417397
2018-05-31 21:31:55|1812|0|a4d4bdown9i13325718910btotal_down12i1364022652868btotal_up9i3689062682bup1i0
2018-05-31 21:31:55|4|1812|a4d4bdown1i010btotal_down8i444173978btotal_up9i2738483932bup9i133257189
2018-05-31 21:31:55|5|0|a4d4bdown8i4441906310btotal_down8i888364608btotal_up9i2738483932bup1i0

sqlite3 ~/.Tribler/sqlite/trustchain.db 'select insert_time,sequence_number,link_sequence_number,tx from blocks order by insert_time DESC limit 9;'
2018-06-01 03:48:32|38190|0|a4d4bdown8i8380765510btotal_down13i56710070460338btotal_up10i66588440642bup1i0
2018-06-01 03:48:32|646|38190|a4d4bdown1i010btotal_down11i743224141118btotal_up10i36672566122bup8i83807655
2018-06-01 03:48:32|38192|0|a4d4bdown8i8380765510btotal_down13i56711746613438btotal_up10i66588440642bup1i0
2018-06-01 03:48:32|650|38192|a4d4bdown1i010btotal_down11i743782858818btotal_up10i38348719222bup8i83807655
2018-06-01 03:47:06|12713|0|a4d4bdown8i7942235910btotal_down13J10468880665768btotal_up1i02bup1i0
2018-06-01 03:47:06|16642|12713|a4d4bdown1i010btotal_down12i2575518135218btotal_up13i19123838184642bup8i79422359
2018-06-01 03:47:06|12714|0|a4d4bdown8i8173285210btotal_down13J10469697994288btotal_up1i02bup1i0
2018-06-01 03:47:04|12712|0|a4d4bdown8i8057048110btotal_down13J10468086442178btotal_up1i02bup1i0
2018-06-01 03:47:04|16641|12712|a4d4bdown1i010btotal_down12i2575518135218btotal_up13i19123043961052bup8i80570481

and I emailed you the rest.

[Thomasedv]

I can add that i also end up in negative from only having one Torrent in a seeding state. I tested this by removing the .Tribler folder, and then starting tribler and adding an already downloaded torrent, and let it seed for some time. Of course, there is practically no demand for that torrent at all, so whatever activity is on it, it's not from actually seeding to others.

[devos50]

@Dmole @Thomasedv thank you for your help! I noticed this behaviour too when starting with a fresh Tribler instance. Next week I won't be at the university to work on it but I will try to investigate this as soon as I can when I'm back 👍

[devos50]

Related forum post: https://forum.tribler.org/t/uploads-and-downloads-are-miscalculated-tribler-7-1-0-exp2/4571

[Dmole]

2
History seems to disappear to, I built up a credit then downloaded something and only one day of data (no credit) was recorded...

3
v7.1.0-exp2 finds seeds faster but it's also quite crashy (I sent a few bug reports).

4
It seems impossible to have anonymity and -ve credits so Tribler should just not count anything below 0.

[devos50]

Thank you all for these reports! Fortunately, this should be relatively easy to debug since all blockchain records are public. This issue also makes it clear that we need a (very basic) blockchain explorer within the debug panel in order to debug it better.

We recently switched to a more sophisticated method of token payout so my first guess is that clients using the old method are communicating with clients that run a newer version. We have one more hard reset for the TrustChain structure in our pipeline (see #3572) so after that, this problem might be resolved.

[Dmole]

What I said was a possibility

actively trying to contribute could have a net negative impact on ones tokens, making the feature counter productive.

I have tested and confirmed to be a reality; since I first reported this I have just let Tribler run empty (0 torrents) and I got up to 1939 tokens then down to -10413 tokens...

[devos50]

This should be fixed in the upcoming experimental release. I will move this issue to the next milestone.

[Dmole]

It seems impossible to have anonymity and -ve credits so Tribler should just not count anything below 0.

The only way to make credits useful (unhackable) would be to make a history (of any sort) count for more than a weeks worth of seeding. (a fresh account should get less priority than a week old account with -1k points)
The UI would have to make this clear with
"seniority:5 weeks, credits: -1k = rank 4k"
vs
"seniority:5 minutes, credits: 1 = rank 1"

[qstokkink]

Overlap with #3731

[Dmole]

Technicaly this issue was first so not a duplicate.
Also there are 2 problems in this issue thread that are not mentioned in the other issue.
#tagMisuse

[devos50]

I reproduced this issue, by simply downloading a ~1.4GB file (Ubuntu).

My TrustChain statistics:

root@tribler-runner1:~# curl http://localhost:8085/trustchain/statistics | python -m json.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1361  100  1361    0     0  99183      0 --:--:-- --:--:-- --:--:--  102k
{
    "statistics": {
        "id": "4c69624e61434c504b3a4fc2982dbedbb7d847a427566af0724f12bb749106a32f579a947288bdaf7c5e887236f77b05642afc991554393c4dccc899faa1fa9062204f4d73fa44a4d78b",
        "latest_block": {
            "_transaction": "6134643462646f776e3969323239363835313336313062746f74616c5f646f776e31306936353933373833303234326275703169303862746f74616c5f7570316930",
            "down": 229685136,
            "hash": "c4570b66eb6f2804fe6c32beb87129ba6d7c7eaf99626df68d268c281568b1fe",
            "insert_time": "2018-10-02 10:13:51",
            "link_public_key": "4c69624e61434c504b3a3d9ced35fcc43906b27d6e3568a518b1e0d56571c83ca4715ddd8181e32ee811e0959a220f409f06456d1f0b5a4fa6079124a23715433ca64578d3911cc1d24e",
            "link_sequence_number": 0,
            "previous_hash": "4a45ca2a66b2ce3e35d00772d95270e7f56f410b130797b21e5de66ab39ff003",
            "public_key": "4c69624e61434c504b3a4fc2982dbedbb7d847a427566af0724f12bb749106a32f579a947288bdaf7c5e887236f77b05642afc991554393c4dccc899faa1fa9062204f4d73fa44a4d78b",
            "sequence_number": 36,
            "signature": "2fa8869aa0ffd8168f1c22d179803ce0eee984ccace6a77dae3fb8cf083dafac4e71d4723772d0cc26971f1cfcd778009a0b3010feff6d29fd09b3256ef01406",
            "timestamp": 1538475231438,
            "transaction": {
                "down": 229685136,
                "total_down": 6593783024,
                "total_up": 0,
                "up": 0
            },
            "type": "tribler_bandwidth",
            "up": 0
        },
        "peers_that_helped_pk": 8,
        "peers_that_pk_helped": 0,
        "total_blocks": 36,
        "total_down": 6593783024,
        "total_up": 0
    }
}

I paid around 6.5GB, for a 1.4GB file. There's definitely something wrong here. I will look into it.

[devos50]

What actually goes over the write, seems to be way lower:

"statistics": {
                "bytes_down": 1701791165,
                "bytes_up": 128424579,
                "diff_time": 1517.9209060668945,
                "num_down": 1390178,
                "num_up": 1343046
            }

So, around 1.58GB goes over the wire but we are doing payouts of 6+ GB... there's either something wrong with the payouts or byte accounting of circuits.

[devos50]

I adjusted the maximum number of circuits to be created for each download to one, which makes this issue easier to debug. It seems that that byte accounting of circuits is off, and this effect amplifies when we use more parallel circuits to download.

byes_down as reported by the circuit:

root@tribler-runner1:~# curl http://localhost:8085/debug/circuits | python -m json.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   184  100   184    0     0  24210      0 --:--:-- --:--:-- --:--:-- 26285
{
    "circuits": [
        {
            "bytes_down": 266833732,
            "bytes_up": 516,
            "created": 1538485831.260635,
            "goal_hops": 1,
            "hops": [
                {
                    "host": "37.48.77.232:35020"
                }
            ],
            "id": 3095613092,
            "state": "CLOSING"
        }
    ]
}

Actual data that went over the wire:

            "statistics": {
                "bytes_down": 139485921,
                "bytes_up": 11585823,
                "diff_time": 118.32790017127991,
                "num_down": 124441,
                "num_up": 119183
            }

So 266833732 bytes accounted vs 139485921 bytes sent...

[qstokkink]

These might be doing double accounting?

https://github.com/Tribler/py-ipv8/blob/master/ipv8/messaging/anonymization/community.py#L882
https://github.com/Tribler/py-ipv8/blob/25a6e65aeb569842beee67456ad0ea637e0c2b4f/ipv8/messaging/anonymization/community.py#L711

[devos50]

I fixed a part of the issue in Tribler/py-ipv8#315, but it seems that there is another bug where a single payout is sent twice to the other party. I will investigate this too.

[devos50]

Payouts are now accurate when using a single circuit to download a 1.5GB file:

Over the wire:

"statistics": {
                "bytes_down": 1690552461,
                "bytes_up": 132366281,
                "diff_time": 1942.5653347969055,
                "num_down": 1405838,
                "num_up": 1390456
            }

And we did a payout of 1.57GB 👍

[devos50]

Also confirmed to work when downloading with multiple hops 👍

[Dmole]

@devos50, you said

When not downloading anonymously, taken should instead always be zero.

But in 7.1.0-rc2 it still is not; I got a 12142 / 3863 MBytes ratio (with 0 torrents).

[Dmole]

I turned on credit mining but lost ~10GB of ratio/trust.
this bug should not be closed IMO.

[Thomasedv]

@Dmole I do believe that might be a result of the credit mining using credits to download the files first and thus you are losing the initial mount which may very well be 10 GB or more. The one time i used credit mining with the bug enable, i went very very quickly down in token balance. And if i remember correctly it was around 15-25 files at around half a GB in size each, for the community i chose to mine for. So at that time, i went at least 50-100 GB in negative.

After testing the recent release, i am finally in the positive from using normal seeding because it's not double/triple counted. And now i am counted normally for my downloads, and probably uploading too.

[synctext]

@Dmole
Sorry for losing that 10GB of credit. Correct I think, it's the initial download that is causing this. It should be smarter then that. Its overinvesting. We had 4 people on credit mining in past 5-ish years.
Proven very difficult to get a token economy going smoothly. Please bare with us..

[devos50]

Yes, it is most likely the initial download which is causing this. The credit mining algorithm first downloads the whole file and then seeds it to others. It's a naive but basic algorithm. We will improve the credit mining algorithm during the coming releases.

This issue however was meant for the double accounting bug when doing a regular download, which is fixed now.

[Dmole]

I made this bug report with the idea of getting statistics reasonable, but if you want to re-classify it as just a doubling bug I can make new bug reports for the other sub issues if that helps.

A token economy would be more likely to happen after the statistics and traid are reasonable (not yet).

[devos50]

If you notice that something is off, please create separate issues for it. This issue should have been made a bit more specific by us (i.e. by modifying the title to make it more specific), so we will keep that in mind.

A token economy would be more likely to happen after the statistics and traid are reasonable (not yet).

Building an operational token economy requires many iterations and testing. Now that downloading seems to work fine, fixing the token mining algorithm is becoming a more important issue. Also, explaining the process to the end-user in a clear manner is challenging, but we'll get there based on your feedback and the feedback of others 👍

Also, the market requires more polish, especially the user-interface part. Last months, I spent much time researching and implementing the decentralized algorithm for trading (and wrote an article about it). Getting it fully operational is the next step.

[Dmole]

5 years later and the Trust statistics are still untrustworthy, but at least hidden for the moment (again);

v7.12.1
The token balance is now hidden until the algorithm for calculating the balance is updated.