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?
![Wink](https://bitcointalk.org/Smileys/default/wink.gif)
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