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

[bahamapascal]

Me to, after 40+ hours waiting 

Thanks!

[Frohike]

Okay,

It all seems to run fine now. Sorry for the delay of things. If there are indeed problems, we'd like to hear from you. My server should now have processed all withdraws.

MGW should be smooth sailing from now on.

[cr7yp]

I deposited more than 4 BC now and I can not see the assets on my account :/

Transactions are:
ffe3d1abab430c00d5cabf0b3e464b18a007ac17c316e3082ba6db9054188507   2.91 BC
ecc67c29d394c74382572e0dd145f37bbd5554a8cd701fcde7a9fae61816482e   2.383 BC

I recieved the Doge. But I am still waiting for Blackcoin assets. 

Thanks for your reply. Hope the problem can be fixed soon.

Also still waiting for my Dogecoin and Blackcoin deposits 

Doge Tx: 7e787ae88f1e82382250982a9d0f6aa86d63429e8a4c84cd9f356e7cb168e5a1
BC Tx: ecc67c29d394c74382572e0dd145f37bbd5554a8cd701fcde7a9fae61816482e

I cannot find the outputs of the those transfers in the status page for Starbuck (cluster operating DOGE, BC and VIA), so the deposits arrived but they haven't been processed. Pointing here Starbuck operators so they can check and push the assets if necessary.

Your deposit was 2.2832 BC, and as you can see in the Multigateway UI, the minimum deposit for BC is 4.

Whenever you do another deposit to the same address and the total exceeds that minimum of 4, assets should be delivered.

[VanBreuk]

I deposited more than 4 BC now and I can not see the assets on my account :/

Transactions are:
ffe3d1abab430c00d5cabf0b3e464b18a007ac17c316e3082ba6db9054188507   2.91 BC
ecc67c29d394c74382572e0dd145f37bbd5554a8cd701fcde7a9fae61816482e   2.383 BC

Please see this post added afterwards - https://nxtforum.org/index.php?topic=4079.msg138691#msg138691

Turns out that in the current MGW build run by the two operating clusters, deposits below minimum are not credited. I did not know that change when I replied to the message you quote above.

As I found out, I changed website information and reported here - again, please don't do deposits below minimum because servers will not process them.

But I understand I gave you outdated information without knowing it was outdated, so I will send a message to MGW#1 operators so they send you 5.293 mgwBC (for the record, 0.12 USD).

Edit: 5.293 mgwBC sent to your account.

[_mr_e]

10 confirmations. No asset. https://blockchain.info/tx/f18ecd7c99a4862d196bd6bdac1a5feca7c4d987069d16ca6637f5300ea442be

[Peter2516]

mgwBTCD shows 'under maintenance' at http://multigateway.org/#sec_coins

Any idea how long? I have some BTCD in a wallet that I want to deposit

[kseistrup]

On November 29 I attempted a BTCD withdrawal:

Transaction 5323331527295977754:

Code: [Select]

Type:         Asset Transfer
Asset Name: mgwBTCD
Quantity: 4.95
Sender:         You
Recipient: NXT-JXRD-GKMR-WD9Y-83CK7
Public Message: {"redeem":"BTCD","withdrawaddr":"RFDpCG3ufe3SQqZpcLo61j2NT1CScWVj8X","InstantDEX":""}

I still haven't received the BTCD.  Any ETA?

[VanBreuk]

BTCD will be active in production servers once operators are ready. As soon as the three operators confirm they have the software running and configuration updated, we can quickly test basic operations and ask longzai for a SuperNET update that uses production servers for BTCD MGW. These last steps could take just two or three days.

However, since current SuperNET still aims to development servers for BTCD, deposits and withdraws requested so far have gone there. James can say when his testing work of the new database MGW build will allow to process pending requests.

[jl777]

On November 29 I attempted a BTCD withdrawal:

Transaction 5323331527295977754:

Code: [Select]

Type:         Asset Transfer
Asset Name: mgwBTCD
Quantity: 4.95
Sender:         You
Recipient: NXT-JXRD-GKMR-WD9Y-83CK7
Public Message: {"redeem":"BTCD","withdrawaddr":"RFDpCG3ufe3SQqZpcLo61j2NT1CScWVj8X","InstantDEX":""}

I still haven't received the BTCD.  Any ETA?

sorry for delay, I did not realize you were waiting on it. I sent it out manually: 47f4871f838fe5815547035d05eb54f62e373ccb5cc8ee97d5e26e6944416d5d

[kseistrup]

Transaction 5323331527295977754:

sorry for delay, I did not realize you were waiting on it. I sent it out manually: 47f4871f838fe5815547035d05eb54f62e373ccb5cc8ee97d5e26e6944416d5d

Received, thanks!

[jl777]

I think I got 5 hrs sleep in the last 50, but finally I have the DB MGW generating a valid withdraw, achieving consensus on all three MGW servers, properly exchanging (though quite inefficient for now), signing around and getting a valid "true" status.

After getting hit with a -22 error for using a spent output, at first I feared the DB was with bad data, but it was just due to some new code that I put in to improve things that totally broke the input selection. What I am doing now is including the smallest unspent into each withdraw. Since there is no additional cost to this, it will end up cleaning up one piece of dust at a time.

Now that all the pieces are in place, I thought through the deployment and the horror of the production server guys reaction to being exposed to the flood of traffic on the main SuperNET.

So I coded up a way to create a private supernet, which allows the usage of the SuperNET comms between the MGW servers and to be able to generate the deposit addresses offchain in near realtime, not to mention be able to get current status and even request to process pending deposit/withdraws.

Great!

Except, since they are on a separate private supernet, nobody will be able to communicate to them, realtime or no and would have to use the blockchain and I know how everybody loves waiting for their deposit addresses. Always seems a 10 minute block happens just when you are wanting the next block.

OK, so just publish the location of the production servers (IP and port). Hmmm. Now more complaints from the production guys, they seem to be picky about stuff like that.

So, I had to code up a way to bridge from the main SuperNET to the private supernet. Now any node can specify a bridgeipaddr/bridgeport and the MGW commands (later others) would be bridged to the private supernet. The return path is a bit klunky, but for now, just make another identical request to the bridge node and it will have  local copy, so can immediately return it.

How does this solve the issue of publishing the IP of the production servers? There does need to be a bridge node that everybody knows the location of, but it wont have to disclose the bridgeport. And firewalls on the MGW servers can be configured to only allow traffic from the bridge node.

With this, everyone can get near realtime deposit addresses, etc, but the MGW servers are off in their own private supernet with only the bridgenode allowed access. This way we can put in filters and spam detection in the bridgenode before it even gets to the other side. Of course the bridgenode can be DDOS (actually bandwidth flood against UDP), but the blockchain can always be used to get a deposit address the old fashioned way (well I just checked I didnt do this yet, not sure if it will be needed).

Now just have to debug it!

James

P.S. part of the debugging will be to get the pending mgwBTCD withdraws processed. I have been processing the deposits as they come in

[jl777]

Definitely getting tired...

I saw:

curl -k --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "SuperNET", "params": ["{\"requestType\":\"MGWdeposits\",\"actionflag\":\"-1\",\"handler\":\"mgw\",\"actionflag\":\"0\",\"specialNXT\":\"7117166754336896747\",\"rescan\":\"1\",\"coin\":\"BTCD\",\"asset\":\"11060861818140490423\",\"NXT0\":\"423766016895692955\",\"NXT1\":\"12240549928875772593\",\"NXT2\":\"8279528579993996036\",\"exclude0\":\"7581814105672729429\",\"exclude1\":\"13434315136155299987\",\"exclude2\":\"10694781281555936856\"}"]  }' -H 'content-type: text/plain;' https://127.0.0.1:4000/
{"circulation":"7996.95900000","unspent":"8026.04805468","pendingdeposits":"0.00000000","deposits":[],"redeems":[{"redeemtxid":"467556451624104852","destaddr":"RMMEUFFSEN7gtcMciBumAaSAJ1fZVYhdS1","amount":"99.70000000"}, {"redeemtxid":"11782007374754530178","destaddr":"RTyHH3kiiUsGSJ1D2MTRhgzktLXKAdQQg8","amount":"86.00000000"}],"withdraws":[{"redeemtxid":"467556451624104852","destaddr":"RMMGbxZdav3cRJmWScNVX6BJivn6BNbBE8","amount":"0.02010000"}, {"redeemtxid":"11782007374754530178","destaddr":"RMMEUFFSEN7gtcMciBumAaSAJ1fZVYhdS1","amount":"99.68990000"}],"batchsigned":"01000000fea58e540223af8a8e471848f15e68c5c48071972db19bf2b4aff843b282693e402980985102000000b500483045022100ffe9c2ca8a20308850381b07afcc31c06b668d201a6e2ace785c489171e1931f02200886a93962213b90f7ae3e936f12506ec08edbf7ea587a239b4abb20bf2c13bc014c69522102a74f604c082576eabca43c5e901b8afe93f3b1e2590d6e880cbfa0898c0444ea2103e1bb6ea9a2d3febeb0ebf22b954d3316b58a37fd315b51964beb2f151b0776472102a60e3b5ddabc1606383a225aab476fb7be66f87041c5bf6b2a0a2dcbe53a3aa253aeffffffff56a5b19aaada0496780b1fbce72f7647da5f940883da7ee5d5774f673c6703c401000000b500483045022100a1db56d5c30f0273244a4743fa6f3981efeebcf3e927dc7bc557255279b3935e02205e603777275d3533e42b6c64a7aba9104d8b055c6b2c527b3713f4ec6fe4d8fa014c695221035827b3c432eb5a528a21657d36a1b61dd85078a6ba5f328bed2d928c173a46c421024ae5e013fda966cf8544025534012156f84a40a5672a894c42e144b0664202502102acdb9c782d499de9b98e8b166fc22bd68895e2293cb49e4a2e071f1254d1a7aa53aeffffffff0490ab1e00000000001976a9148466f34f39c23547abf922d422e3e5322fdf156588ac30b73252020000001976a91484652b7f7000095ae0391302ce9e2d4449f709f688acb02c8a00020000001976a914cd073e0a5d4225f2577113400c3abf9ac1ad2cc488acdba94f930400000017a9140a45720c0a3e8cbb76dfbc789c4c73e77f681a308700000000","cointxid":"f4324147469f092768a59d4da0d575a6fcd507d03141484a9bb46f7c08da7e63","AMtxid":"10522040622539461566","crcs":[548618282, 548618282, 548618282],"numredeems":2,"pending_withdraw":"185.69990000"}

But I missed the "cointxid":"f4324147469f092768a59d4da0d575a6fcd507d03141484a9bb46f7c08da7e63","AMtxid":"10522040622539461566"

so I spent 2 hours trying to get the withdraw to work, but it couldnt find any withdraws to do. Since the AMtxid and cointxid is the signal that the withdraws were sent, that kind of makes sense.

So, at long last DG mgwBTCD is caught up. It is a horribly inefficient process as it is as there are some reliability issues with the UDP packets, but that is on my list next to address. Also, you have to run the command one server at a time and the third server that got the broadcasts of the other two has all the data needed to verify consensus and get the signatures.

I am just too tired to debug the bridge modes, so doing it all easy from a remote node is going to have to wait. But this data transfer reliability issue simply has to be fixed as it is causing bugs all throughout the system.

James

tldr: mgwBTCD is all caught up, plz post if you have a pending tx

[lemonhead]

Im waiting for my 2 withdrawals of mgwDoge

**done

[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

I am still waiting

so sorry for delay, I decided to deprecate the old MGW <-> MGW comms and use the SuperNET methods
but it didnt directly support oversized packets
and since UDP isnt guaranteed delivery, I needed to write a layer on top that emulate the TCP, as far as retry and I will put in a bit of congestion control.
With ~250 people in Slack, it is impacting my dev schedule a bit, but I just need to put in some tracking of pending transfers and SuperNET will get TCP like transfers, except it will be connectionless. I know not exactly TCP, I will probably do that some other day to add the connections concept, but Telepathy actually kind of does this...

so, once there is a reliable way to transmit the withdraw packet, then DB MGW just calls that, signs around and submits. I cant promise to eat my hat if I dont get it done today, but I promise to think about eating my hat.

James

Still the BTCD did not arrive... :-/

[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

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

I am still waiting

so sorry for delay, I decided to deprecate the old MGW <-> MGW comms and use the SuperNET methods
but it didnt directly support oversized packets
and since UDP isnt guaranteed delivery, I needed to write a layer on top that emulate the TCP, as far as retry and I will put in a bit of congestion control.
With ~250 people in Slack, it is impacting my dev schedule a bit, but I just need to put in some tracking of pending transfers and SuperNET will get TCP like transfers, except it will be connectionless. I know not exactly TCP, I will probably do that some other day to add the connections concept, but Telepathy actually kind of does this...

so, once there is a reliable way to transmit the withdraw packet, then DB MGW just calls that, signs around and submits. I cant promise to eat my hat if I dont get it done today, but I promise to think about eating my hat.

James

Still the BTCD did not arrive... :-/

I found a bug!
I will send out manually in a few hours

James

[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

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

I am still waiting

sent: 5493c33ab2bca40c3adb76c55d4d1bc9c7ea421feffacd0afc55b56f2d3961f0
sorry for delay. It did expose a bug though. thanks!

James

P.S. bug is fixed, but clearly need to test things quite thoroughly

[sepehr]

what is the status of production servers now?
Can I count on it for a fast transaction for my Asset holders?

[Tosch110]

Thanks James, received!

[jl777]

A day with no emergencies!
Finally made some progress with getting the UDP comms more stable. This is needed to get the MGW servers to sync up in a reasonable time, instead of the current process which requires being quite patient.

realiable comms are pretty important for, well for everything, so I expect to spend some time finally about this as the rest of SuperNET is pretty much there in test cases, but without reliable comms it is hard to tell if is is a bug due to unreliable comms or a real bug.

Anyway,  will daily monitor the mgwBTCD situation and try to stay current, so it is not ready for normal use, but will have dgex response times.

James

[jl777]

what is the status of production servers now?
Can I count on it for a fast transaction for my Asset holders?

I am seeing about 8 to 10 withdraws per day, so on average 3 hours, expected time to process a withdraw ~1.5 hours
however, I do see some withdraws within an hour from each other, so maybe the wait time is average of 30 minutes

James

P.S. Now I have no actual visibility into the production servers, but I can monitor payments to the marker address, which gets the txfees for every withdraw