Input data displaying odd information from Restful endpoint

[immartian]

(copied from Slack by @phiferd ):

http://orbiter.musicoin.org/tx/0xeb05f6b79c82c74e5c6e8167f4e00f8a6c44cb5f9365f01736da71cf850b98f5
orbiter.musicoin.org
Musicoin Block Explorer

[8:37]
then curl that same address:

curl -H "Content-Type: application/json" -X POST -d '{"addr":"0xeb05f6b79c82c74e5c6e8167f4e00f8a6c44cb5f9365f01736da71cf850b98f5","count": 10}' http://orbiter.musicoin.org/log

[8:37]
which gives

{"draw":null,"data":[{"_id":"5874cbfb89397bce4d58501b","transactionHash":"0xeb05f6b79c82c74e5c6e8167f4e00f8a6c44cb5f9365f01736da71cf850b98f5","__v":0,"action":{"value":"0xde0b6b3a7640000","to":"0x0697fdc2a44ec94fd9532711d1759dbf8effe55b","input":"0x","gas":2300,"from":"0xf751fd1140173550daaadcaaf64b3a6db6d9c4e6","callType":"0"},"blockHash":"0x5ef4c2453b0d7906100e5a230488b616b3ea86a9f3e2059a471dcb76330b3245","blockNumber":113042,"result":{"output":"0x","gasUsed":51},"subtraces":0,"traceAddress":["0"],"transactionPosition":1,"type":"call","timestamp":1484049382}],"recordsFiltered":55,"recordsTotal":55}

[8:39]
note "input":"0x" in the curl response and inputData: 0x93e84cd9 in the tx detail page

[immartian]

The InternalTx table may have some inconsistent data from listener program(it's another bug we should report, created in #10 ), but temporarily I switched to Transaction table to make it simply work.

[phiferd]

As I think more about this, I think it has to do with the internal transactions. When a PPP event occurs, the following happens.

1. Musicoin account (M) calls "ppp" method on the license contract (L), which is assigned a transaction id, Tx
2. The license contract distributes the payment to the contributors. In this case, just the artist. To do that it initiates a "send" transaction to the artist profile contract A.

Right now, I'm querying the history of the artist profile contract A and hoping to see calls to "ppp", but that's not right. The call to A is an internal transaction of Tx and will not have its own transaction. The "input" that is coming back from the API could be orbiter's (or parity's) representation of the internal transaction.

For now, I think I can actually work around this issue with the existing API. If you look at this example:

http://orbiter.musicoin.org/addr/0x0697fdc2a44ec94fd9532711d1759dbf8effe55b

In block 113042, you can see a transaction that shows a payment

{ from: 0xf751fd1140173550daaadcaaf64b3a6db6d9c4e6, to: 0x0697fdc2a44ec94fd9532711d1759dbf8effe55b}

where,
0xf751fd1140173550daaadcaaf64b3a6db6d9c4e6 = "Our Times" PPP contract
0x0697fdc2a44ec94fd9532711d1759dbf8effe55b = My artist profile contract

However, if you show the details of that transaction (http://orbiter.musicoin.org/tx/0xeb05f6b79c82c74e5c6e8167f4e00f8a6c44cb5f9365f01736da71cf850b98f5) you see:

from: 0xb560530ea7939a88093123af648f718f15e540cc (musicoin account)
to: 0xf751fd1140173550daaadcaaf64b3a6db6d9c4e6 (our times PPP contract
input: 0x93e84cd9 (ppp method)

So, the orbiter history API is doing the hard work of extracting the internal transactions and making sure they get grouped under the right transaction id. This means I can use it to pull a list of all the top-level transactions that ultimately send coins to the profile account, and then I can look up those transactions (locally) to see what they actually where and what type of action they were.

[immartian]

ok, I leave you to investigate first, so I can refer to fine tune orbiter presentation as well.

[immartian]

I'm now providing 2 entry point: /top and /low, maybe easier for you reuse?

query the top level of tx, related to PPP:

curl -H "Content-Type: application/json" -X POST -d '{"addr":"0x2f9b31db7388addbfc4fdde21cfef757e6138ae3","count": 20}' http://orbiger.musicoin.org/top

query the low level(internal tx) with distribution:

curl -H "Content-Type: application/json" -X POST -d '{"addr":"0x2f9b31db7388addbfc4fdde21cfef757e6138ae3","count": 20}' http://orbiter.musicoin.org/low

I'm not sure if they are matching what you meant above.

[immartian]

solved in #6 or seeing the implementation at Musicoin/core@68a42ed

we can close this issue as the quest has been addressed and all aspects achieved in both orbiter and musicoin catalog.