Print

• Show the most recent posts.

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[VanBreuk]

Just a suggestion:

Why not create a lil web-based "dashboard" that displays the status of the MGW servers?  I hate waiting hours for an MGW withdrawal to go through, wondering if the servers are up or not. 

It would ALSO be nice to be able to get an "automated" status of a pending withdrawal -- saves posting to ask how the servers are doing.

So -- how are the servers doing? 

A status page/monitoring script for production servers is of course planned and has been requested repeatedly since they went online. I will be happy to see a simple feed like Starbuck Status Page for MGW production servers, because I have to wonder too if they are up or not Too bad I cannot do that myself and I have to wait for one of the production nodes to do it. Maybe this plea will help to progress to happen.

Thankfully the servers are scheduled to restart services every few hours, and if anything becomes stuck it won't stay stuck for long. But yes, you are absolutely right.

[mikesbmw]

Wouldn't it be a good idea to have a standard message on the MGW tab that says: transactions can take up to six hours to complete? (or any other time that is realistic)

[mikesbmw]

Hi, I sent 1 BTC to my mgwBTC address this morning, but after 23 bitcoin confirmations and 5 hours, the mgwBTC still hasn't been added to my deposit address: 3NnDx6RyDuwzCeExTGmQ3786NHtdmp5pqu

Could someone please have a look?

[VanBreuk]

Hi, I sent 1 BTC to my mgwBTC address this morning, but after 23 bitcoin confirmations and 5 hours, the mgwBTC still hasn't been added to my deposit address: 3NnDx6RyDuwzCeExTGmQ3786NHtdmp5pqu

Could someone please have a look?

Node 0 in production servers is behind, I've sent a message to the operator.

[mikesbmw]

Still no deposit.
What's going on guys?

[TwinWinNerD]

MGW really should have higher priority. Sute the other services will be nice, but because of this high uncertainty, I can't use MGW.

[CryptKeeper]

Just a suggestion:

Why not create a lil web-based "dashboard" that displays the status of the MGW servers?  I hate waiting hours for an MGW withdrawal to go through, wondering if the servers are up or not. 

It would ALSO be nice to be able to get an "automated" status of a pending withdrawal -- saves posting to ask how the servers are doing.

So -- how are the servers doing? 

A status page/monitoring script for production servers is of course planned and has been requested repeatedly since they went online. I will be happy to see a simple feed like Starbuck Status Page for MGW production servers, because I have to wonder too if they are up or not Too bad I cannot do that myself and I have to wait for one of the production nodes to do it. Maybe this plea will help to progress to happen.

Thankfully the servers are scheduled to restart services every few hours, and if anything becomes stuck it won't stay stuck for long. But yes, you are absolutely right.

In the meantime you could use a service like https://www.pingdom.com to get alerts if a server is down.

[mikesbmw]

After help from Frohike the mgwBTC has arrived!

Thanks Frohike! 

[VanBreuk]

MGW really should have higher priority. Sute the other services will be nice, but because of this high uncertainty, I can't use MGW.

I understand that delays of more than a few blockchain confirmations should not happen often. But I wouldn't like people to think that any delays that have happened were due to apathy or carelessness.

MGW is great tech but while its distributed/less-centralized/multiple operator structure has several big pros, it also can entail slower time responses when the service is being developed, as new features and changes are implemented. Updates and fixes need to be applied by three different agents, and a little bug in one server can partially hold the whole cluster service until the issue is spotted and fixed. Then again every fix makes the service more stable, but in the meantime, a user suffered a delay. And that little bug, otherwise easy to fix, could linger there for a few hours for the simple reason that the operator may have a full time job and may only able to intervene in the server a couple times a day.

And that can be just fine when everything is polished and triple checked, but now we are also in a transition period and the status of development servers also may affect production servers, since BTC are being transferred as users swap their old assets; as we leave dev servers behind, and operators iron details out, service progressively becomes more reliable. Monitoring will speed up reaction times by eliminating uncertainty. @Cryptkeeper - the monitoring tool has been in the to-do list for a while and I believe Frohike has made a good deal of progress, but I'll point operators to your suggestion so they can see if it's a good alternative.

Edit: After their feedback, Pingdom wouldn't cut it. MGW needs service monitoring, not server uptime monitoring. What they're working in is service level monitoring.

[Tosch110]

Hello, I am waiting for a mgwBTCD withdraw:

http://mynxt.info/blockexplorer/details.php?action=tx&tx=7381747177535994063

[jl777]

Hello, I am waiting for a mgwBTCD withdraw:

http://mynxt.info/blockexplorer/details.php?action=tx&tx=7381747177535994063

sorry, converting to DB MGW for BTCD
wanted to take the weekend off of debugging, so might be monday before its processed

[jl777]

I have done a realtime MGW deposit address creation
This can also be used for checking status of servers
Still need to do a test cycle and complete the withdraw side, but I envision DB MGW that will be "on-demand"
so, when you do a request, the servers will respond with status, pending deposits, withdraws, etc.

Still for withdraws, all three servers blockchains have to be in sync and the servers running, but being able to know the status from the user invoked remote SuperNET API command is the near future.

In order to shield the MGW server's IP addresses, we will need to go through an intermediary and that will require a "forward" and maybe even "inject" API I wrote about recently. I will be able to get these done in parallel with the test cycle though. No promises on exact dates, but the address generation and deposits working in the lab, withdraw coded about to be debugged

James

[Tosch110]

Hello, I am waiting for a mgwBTCD withdraw:

http://mynxt.info/blockexplorer/details.php?action=tx&tx=7381747177535994063

sorry, converting to DB MGW for BTCD
wanted to take the weekend off of debugging, so might be monday before its processed

ok, I am not in a hurry, just wanted to have some more for staking

[jl777]

I got the DB version ready to test, found a privkey dereference bug (if the source is a multisig addr, you need to use the key to the normal address that is part of the multisaddr and there is actually no multisig addr in any wallet) but other than that it is is calculating reasonable looking raw tx bytes. I just used the old method of MGW server <-> MGW server comms for the batch withdraw, as that is ~64KB in some cases and rather than write new code just for this, I felt it safer to just use the existing code ported into the new codebase.

Might have missed a few checks, but ready to test the withdraw and I do see three pending, along with a couple deposits. Of course, I have to fiddle with the servers to get them back in sync (there needs to be an up to data DB for the coin's blockchain)

Rather than mess with real money code at the end of the day, I will recharge and try to get the DB MGW for BTCD caught up tomorrow and if all goes well, tighten up the loose ends and get it ready for testing by others

James

[TallSmile]

Added BTC to my MGW deposit adress: 3GN9Yp5uTBHUoAxxVZ1WtAXxuexAa3BJev  but still have not received mgwBTC after one day of waiting.

[VanBreuk]

Added BTC to my MGW deposit adress: 3GN9Yp5uTBHUoAxxVZ1WtAXxuexAa3BJev  but still have not received mgwBTC after one day of waiting.

Reported to Frohike, server restarted and processing any pending transactions now so your mgwBTC should be there soon.

Apparently node 0 was refusing to automatically respawn the service periodically, apologies for the delay.

[jl777]

Well it has taken a while, but finally have all three servers in sync. It was hard to tell if there was a bug in the new code or something else. For most of it, it was just some silly stuff like not having the latest NRS so of course the new API in the latest NRS was having problems. After isolating the cause, I realised one of the servers wasnt the latest NRS.

Another one had the BTCD daemon stuck. Another had the NXT stuck. Also, things were just too slow with RAM maxxed out, so I finally stopped the dev MGW for BTC to be able to get results in less than 30 minutes on the BTCD side.

Throw in some messed up DB files, etc...

Anyway, about to clear out the pending deposits and then debug the withdraw code. It is looking pretty good, but sometimes just refuses to run?!

I cant wait till this is all done!

James

ever notice the long blocks are always when you are waiting for the next one?

[jl777]

The following command (after waiting enough LONG NXT blocks) identified pending deposits and then sent them out:

curl -k --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "SuperNET", "params": ["{\"requestType\":\"MGWdeposits\",\"specialNXT\":\"7117166754336896747\",\"actionflag\":\"1\",\"rescan\":\"1\",\"coin\":\"BTCD\",\"asset\":\"11060861818140490423\",\"NXT0\":\"423766016895692955\",\"NXT1\":\"12240549928875772593\",\"NXT2\":\"8279528579993996036\",\"exclude0\":\"7581814105672729429\",\"exclude1\":\"13434315136155299987\"}"]  }' -H 'content-type: text/plain;' https://127.0.0.1:7777/


[{"circulation":"7516.63010000","unspent":"7843.81565468","pendingdeposits":"298.09657278","transfers":[{"coinaddr":"bS1QVCA6UjGRBuvFyPYFZQeP1KXuy94MQ4","cointxid":"874b0dc71d882a9577eb489427c902ffb6d8c854bb3d82222f509f7546086251","coinblocknum":249493,"cointxind":2,"coinv":1,"depositid":"\"10415350677232054721\""}, {"coinaddr":"bWtsHmWGb7Lb5dWrSDUQ87vGB4H5qS7LqA","cointxid":"8b6c321eebcc844090294b7408f323b62a81c9e4359969b0195018a59ac396a6","coinblocknum":255691,"cointxind":2,"coinv":1,"depositid":"\"11560182692476625193\""}, {"coinaddr":"bWtsHmWGb7Lb5dWrSDUQ87vGB4H5qS7LqA","cointxid":"a7ae953236fba0b22f44f7a34caa31eb4c6cdea4cb44f6fc5bbc9ab1d3a742a6","coinblocknum":255978,"cointxind":2,"coinv":1,"depositid":"\"14753482159514090717\""}, {"coinaddr":"bWtsHmWGb7Lb5dWrSDUQ87vGB4H5qS7LqA","cointxid":"d76a8d1835959e9817240566fa47ee524ea6e7776676f1e5d14d337e06010bc1","coinblocknum":255993,"cointxind":2,"coinv":1,"depositid":"\"3818917506109742602\""}]}, {}]

Good thing its still morning, onto withdraws!

James

[jl777]

starting first test that has a chance of all three servers synchronizing the same multisig payment
actual payment is disabled, but unlike the old MGW, I can go from cold start to testing a withdraw in the time it takes NXT to do 5 blocks. Hopefully it will be less than the almost 1 hr of earlier

James

[jl777]

Not quite right...
I was trying to correlate the multisig address with the local address on each server, but due to all the different AM formats and versions, there was no single way to reconstruct this. I then tried "validateaddress" and that had all the raw data I need, so I can just use that to retrieve the keys, probably need to do it for the msigaddr, then iterate the list of normal addresses to find one I know the privkey for so I can use it to sign the rawtx.

So, that part that I though would be easy, turned out to be really messy and unclean, but now is back to easy again. Too bad I did just start with the validateaddress method. Just used to avoiding any extra bitcoin RPC calls as the more you make the more likely to run out of tcp sockets temporarily. since this is the rare case of signing a tx, it is of no matter to make some extra RPC calls.

one of the servers is being cranky and while the other two finish the sequence, this one is stuck on the withdraw checking of txids. Not sure what is wrong... They are all same, but different.

Anyway, the current approach of bruteforcing all known addresses and accounts is too bruteforce. I need to provide per user remote access and that will allow for much more surgical reprocessing of only what is needed. Hopefully that will work around the cranky server.

James

P.S. I will postpone processing the withdraws till tomorrow, things are a bit too early now. At least all the pending deposits are caught up