musicoin / orbiter Goto Github PK

Will pop up a quick page when the service is under maintenance, popping up a notice instead of services.

Hello, some days ago I made a transfer from my musicoin desktop wallet v0.7 to cryptopia, the transaction failed and discount my balance and appears in the blockchain but it is still not reflected in my cryptopia balance, please help me. Thank you.

hash 0xedc70bc87be01fd1b179d448a9b07ecc13690caa0a7d0f2dfeee8f5a51a52903
blockNumber 1714362
Time 2018-01-03 02:42:41 -0400 (1 day, 6 hours ago)
from 0xe5af300b582cc6d02d4d16c93d8d8b3dd206e5b9
to 0x5e41d1feae03a37b37af13dfe1aa38c2d0daeaf2
value 1092
gas used 21000/940000
gasPrice 20000000000
nonce 4
Input Data 0x

Transaction Link https://orbiter.musicoin.org/tx/0xedc70bc87be01fd1b179d448a9b07ecc13690caa0a7d0f2dfeee8f5a51a52903

Address page does not list mined blocks and uncles. It only lists ordinary transactions.

"I set it up to send my account 0.1 mc as a fixed payment, then the remainder split equally between my (test) profile, your profile, and brian's profile. Brian's balance shows as "117.3" musicoin, yours shows as 23.3, and mine shows as 544.4 (since I got an extra 0.1). So, I think it's working, but orbiter might be missing some details", via @phiferd

http://orbiter.musicoin.org/tx/0x9d158e105220544229a23c953793ee2b2e14cc61367602691363bd137609c9fe

What's happening? Could please anyone from the team help?
There is 0 connection shown in the below link.
https://www.cryptopia.co.nz/CoinInfo/?coin=MUSIC&view=settings

So is there someone working on it? What to do?
Help would be appreciated.
My transaction hash:
0x62a061e91238fa19dcdba95eb102e119cf1874dd98c62b98c285109c99f1ba9c

Hi. I notice you guys ripped off the ethereum classic block explorer. Please reference the original repo. Thanks.

http://github.com/ethereumproject/explorer

When there's contract is created by a wallet address, the destination should display the contract address. Currently it displayed nothing, which is confused to user:

Listen.js would abort with the follow breakpoint:

Internal tx: {"jsonrpc":"2.0","result":[{"action":{"callType":"call","from":"0xb560530ea7939a88093123af648f718f15e540cc","gas":"0xd9f8","input":"0x6049a45d000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000c000000000000000000000000000000000000000000000000000000000000001200000000000000000000000000000000000000000000000000000000000000180000000000000000000000000000000000000000000000000000000000000000344616e00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000035697066733a2f2f516d53386e34524b61744577745559356273754e6259385436514c47764156766a76663232733453753352394e5600000000000000000000000000000000000000000000000000000000000000000000000000000000000035697066733a2f2f516d5139336f52577338426f61684658734d6f4c347a346961424b62737a686e5359547977634a55524b46526a5400000000000000000000000000000000000000000000000000000000000000000000000000000000000035697066733a2f2f516d4e77667a737359544c4a646452415351503637344177446356544d647258334a39727763386351554d7a4c550000000000000000000000","to":"0x0697fdc2a44ec94fd9532711d1759dbf8effe55b","value":"0x0"},"blockHash":"0x26096674f6f4a21ce60987942660ab3aa1ad32a85603454a1e1c4c1bcc2be3b7","blockNumber":12947,"error":"Out of gas","subtraces":0,"traceAddress":[],"transactionHash":"0x1a71ef0f7d4c86548d92f388042caf1139aa50071666aa3701e46c96da7a13ca","transactionPosition":0,"type":"call"},{"action":{"callType":"call","from":"0x15b64d20202475b2ef8c8544e743f36eafe7507c","gas":"0x10d88","input":"0x","to":"0x008d4c913ca41f1f8d73b43d8fa536da423f1fb4","value":"0x4563918244f40000"},"blockHash":"0x26096674f6f4a21ce60987942660ab3aa1ad32a85603454a1e1c4c1bcc2be3b7","blockNumber":12947,"result":{"gasUsed":"0x0","output":"0x"},"subtraces":0,"traceAddress":[],"transactionHash":"0x8c36ac228ec3503878bd329bc11551bf2a70b4067322b8311d134fb855e877b7","transactionPosition":1,"type":"call"}],"id":12947}

/home/im/lab/musicoin/orbiter/tools/listen.js:122
if (j.result.call)
^

TypeError: Cannot read property 'call' of undefined
at IncomingMessage. (/home/im/lab/musicoin/orbiter/tools/listen.js:122:25)
at emitNone (events.js:91:20)
at IncomingMessage.emit (events.js:185:7)
at endReadableNT (_stream_readable.js:974:12)
at _combinedTickCallback (internal/process/next_tick.js:74:11)
at process._tickCallback (internal/process/next_tick.js:98:9)

Although it seems didn't affect orbiter in remote(protected by forever process), it's a potential data integrity issue.

When there's a new contract was created on chain, supposely the transaction page should have the contract information together with owner information, but right now it's blank.

http://orbiter.musicoin.org/tx/0xe97328dfe6fcb0d83e3a694fc702007cca5412390ebd759405371c9c8cbe7cd4

This tx http://orbiter.musicoin.org/tx/0x951eaebfba79a0b195525260108dfe3811cc3308cd9f330751a894be31738588

was actually conducted 100MC from the "from" address, to "to", the result is correct, but the display is not so.

Hi.

All blocks shown on orbiter are at least 8 hours old, URL links to view them are not working (https://orbiter.musicoin.org/block/1228958) err 404.

It's very abnormal today after seeing a popup error from orbiter DB, but unfortunately I didn't capture the screen that moment but further presentation of data indicated it's a terrible error, either on database capacity or the listening process met some unresolvable issue.
I'm trying to roll back to early version to see it helps.

Amount: 1067.67461057 MUSIC
To: 0x083131d4387101ff0582c0fbd541172b3b4a3a7b
Requested At: 01/11/2018 19:41
From: 47.158.102.216

Help

Hi all,
I made a deposit to Cryptopia of MUSICs and it has not yet arrived.
I have tested the wallet address and the explorer keeps loading some info forever. And have no more clues.
Info of tx is this:

Address: 0xbb7b4f230220be7bd21ed2026bee864c8415f140
TxId: 0x42ce85d6f1f2839f0fd16303ffe1034793d71f2319dcc5358f82a01205d14815

The block list suppose to be refreshing by itself every 15sec.

The backend catch.js seems much slower these days to sync up the DB once there are more transactions happened on chain. So the frontend seems vastly dragged. We can reduce the interval between writing each record, but probably it can cause DB panic we can't predict, will try to experiment and improve.

There's no correct display in this page
http://orbiter.musicoin.org/addr/0x37abae253cc0a30b7c6599534ff7ab325ab74c6d

even the tx http://orbiter.musicoin.org/tx/0x277322760b9c3545201e57f1d30c0a5b0c75dd345218d10349245266c934094c can be traced in the tx page.

the txns number is forever displaying wrongly with each block. There's no such information yet in database, should be scraped from blockchain first.

To echo the PPP contract concept, there should be some internal transactions be breakdown within a tx. Like how Etherscan's view.

Will look into some refs to dig into, e.g. http://hypernephelist.com/2016/06/21/a-simple-smart-contract-ui-web3.html

By selecting 'All' transactions, I can only get one latest transaction.

Without any signals, the orbiter site at http://orbiter.musicoin.org was suddenly redirected from browser(FF, Chrome), and can't resolve.

We didn't put SSL before, so should add it to the service, but the reason is really not perceivable as it worked all time along.

e.g. http://orbiter.musicoin.org/tx/0x6033e88f1a08088775968975fd2eb77c6f6bcfd894c95a7e9013b6d7fa25be6b

it shows Gas and price, but not resolved final gasused (1929219 as @phiferd said) , should be investigated.

It's old issue, but found relevant today when setting up a new chain and running Parity to support Orbiter. However, because the "--tracing on" flag was not set, the Orbiter database can't record those internal tx, so the address page can't show any TXs because it was actually showing internal tx on current orbiter implementation. We still should differentiate tx and internal tx in further improvement.

The listener won't continue to work even after Parity restart after some interruptions. The program seems still running but not listening to the previous RPC and returning any data. Maybe a testing of the syncing is necessary, wonder if https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethissyncing helps.

refer to #9 , need further investigation into listen.js , obviously retrieving tx.input is not matching those in general information from Transaction table.

some transactions, like this one http://orbiter.musicoin.org/tx/0xd73fb4bbb13d15c0b553d00cf37d7eadabe9597189a4f5cbde52fdcc22bb8db9

being displayed as failed (because gas and gasused equal to each other),but seems it's not a failed tx from blockchain, we should investigate it and see what's the solution for this presentation.

The reason here is the argument been discussed in community http://ethereum.stackexchange.com/questions/1179/how-to-know-if-a-transaction-went-through-or-not-out-of-gas we should try to get more status from tx, instead of just compare gas and gasused.

A more detailed ref here: a good ref here: http://ethereum.stackexchange.com/questions/6002/transaction-status

e.g. http://orbiter.musicoin.org/addr/0x6a3087972bbda4d73b6519597d6aae9a2d7aa7d2 this address should have over 254 tx but only showing one page with ":(" at the end. Yet to investigate.

• https://orbiter.musicoin.org/home

I'm curious why, if it does not support the fork, shouldn't it be stuck on 1200000?

Is it running an old RMC version? Make sure fork num is 1200001!

Did you consider running Parity nightly as backend?

(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

Open: https://orbiter.musicoin.org/addr/0x6946871a9507bb7596ff3258e054e8d795493eae

actual result: Can't check an address' balance - Please wait while the transaction history loads... - shows forever
expected: the balance of the address shows

Later versions of parity will require the fork info for block 1462 -

"params": {
"accountStartNonce": "0x0",
"maximumExtraDataSize": "0x20",
"minGasLimit": "0x1388",
"networkID": 7762959,
"forkBlock": 1462,
"forkCanonHash": "0xa5e88ad9e34d113e264e307bc27e8471452c8fc13780324bb3abb96fd0558343",
"eip98Transition": "0x7fffffffffffff"
},

The fast growing chain always drop and misplace information into database which should be corrected by a program later, so there should be a patrol program trying to outlook the database and match the final result from blockchain.

The address page will show records of transactions but there are wrong information still haunting:

1. Wrong transaction age:
   

2. Repeated records
   

http://orbiter.musicoin.org/tx/0xb8849a00645367b087ff721a9e09a92ccc8dd3a1109c179cb8bcc0410e9fe94d

I believe this transaction failed due to an exception. However, in orbiter is appears to have succeeded. I suspect that an additional check is needed to see if the gasUsed == gas. Maybe this can be addressed when #4 is addressed, since both require gasUsed information (which is only in the receipt).

(and don't get me started on how stupid it is to check if gasUsed==gas to see if there is a failure, or how it is actually possible that gasUsed == gas when everything went fine)

So as a noob to ubuntu I whish there was some guide as I am stuck
on ubuntu 16.04 using parity
installed parity...

$wget https://raw.githubusercontent.com/Musicoin/orbiter/master/mc.json
$ parity --chain mc.json
Could not load specification file at mc.json: Permission denied (os error 13)

~/work/parity$ ls -lsha mc.json
4.0K -rw-rw-r-- 1 2.7K Sep 20 12:58 mc.json

Hi all, yesterday I made a deposit to Cryptopia of 28.xxx MUSICs and it has not yet arrived.

I have tested the wallet address and the explorer keeps loading some info forever. And have no more clues.

Info of tx is this:

Address: 0x33919fb747f70f51b188ec17e0c10809d5a63bf0
TxId: 0xafcc2ad2b971f4ea887e3223be16a93f812ca71271afc9bbab07badd418440db

Thanks!

once the network disconnected, listener.js would halt as well without indicating errors. There could be timeout handling failure, will have a new branch to investigate.

Some internal tx, since didn't get fetched from tracing switch from new Parity, seems didn't register in the database.

The reason is known but it take ages to re-sync because the stateDB needs that.

openethereum/parity-ethereum#6386

according to bitcoin community: The hashrate can be calculated from the expected rate of finding a block (144 a day), the actual rate of finding a block and the current difficulty.

expected_blocks = 144
difficulty = 11187257.461361 # this is on May 22nd 2013
blocks_found = 155 # Also May 22nd 2013
hash_rate = (blocks_found/expected_blocks*difficulty * 2**32 / 600)

But still, have no simple way to calculate musicoin blockchain, yet to explore.