questionSolved!Sorry for the traffic, and possibly confusion
- but this weird case was seemingly simply my "test" ...
whether I have understood the concepts,
i.e. if I can really trust the output of my
assetparser.py software.
I would have never expected what turned out to be the explanation in the end,
but hey - the most important thing is: We found it! And that the code can be trusted.
Thank you MaWo, for looking into this with me.
I would like to gift you some symbolic amount of my soon-to-be-launched asset for your help, PM me! The background story is easy to tell:
I wrote an assetparser.py to prepare
my own assetlaunch - by studying at the other assets.
Analyzing the output, I stumbled over a strange data artifact:
The "real marketcap" (definition of that new observable is in my
soon-to-be-published study)
... of one of the HZ assets became
zero. How is that possible, as the asset had already been traded?
So I dug deeper, and asked around in many places.
nxtforum,
here, slack.
On the basis of the easily available data, there was no sufficient explanation:
... so he has sold 990,000.00 assets,
In my world, he should have 9,010,000.00 assets left:
balanceQNT = 1000000000 - 90000000 - 8900000 - 100000 = 901000000
but his account shows that he still
(or again?) has
balanceQNT = 1000000000 of this asset
http://localhost:7776/nhz?requestType=getAccount&account=14690932713833726002... assetBalances: [2]0: {balanceQNT: "1000000000" asset: "9159194210388607784" ... Where is the flaw in my thinking?
But now ... I found the explanation!
The key was the
(or again?)
above.
However, the necessary data for checking my suspicion was a bit tricky to get,
because
HZ is still lacking the useful
getAssetTransfers&asset= (Nxt) function.
So tonight I created this
Workaround for getAssetTransfers&asset=It's actually only partly an answer, because it specifically emulates an
getAssetTransfers&account= but it works like this:
-> download
getAccountTransactionIds&account=14690932713833726002 --> list of 310
txIds--> then download all 310 transactions with
getTransaction&transaction=--> in the results, select by
----> only:
type==2 "Colored coins" subtype==1 "Asset transfer"----> only:
attachment.asset==9159194210388607784
For our mystery puzzle, that resulted in these two "Asset transfer" transactions:
http://localhost:7776/nhz?requestType=getTransaction&transaction=5347234624369137696quantityQNT: "1000000" sender: "14690932713833726002" timestamp: 15894761
= transfer from issuer to someone
http://localhost:7776/nhz?requestType=getTransaction&transaction=16730081599467904714quantityQNT: "100000000" recipient: "14690932713833726002" timestamp: 28783039
= transfer TO issuer from someone
(... and along the way, I spotted something essential of the overall architecture
just now: The assetId is simply the transactionId of the TX in which the asset
was issued: getTransaction ~ getAsset = cleverly constructed! Me likes!)So the final picture is this now:balanceQNT =
1000000000 # issuance
- 1000000 # transfer from issuer
- 90000000 - 8900000 - 100000 # trades
+ 100000000 # transfer to issuer
= 1000000000 - 1000000 - 90000000 - 8900000 - 100000 + 100000000
= 1000000000 # equals the original issuance amount
So:
The issuer has all his issued assets ... back in his account.
Who would have thought that?
If you like to read such nerd adventures, then consider to tip the author for this one -->
http://altsheets.ddns.net/give HZ: NHZ-Q675-SGBG-LQ43-D38L6 NXT: NXT-CMKU-ZQYK-V6CD-9UHF4 BTC: 1Ek9McNmXwQgDnkzE9J6pjCPWEiihhL83n
