Topic: A simpler Gateway built in to official client (Read 7446 times)

Eadeqa · « **on:** June 19, 2014, 04:12:57 am »

I think it's possible to create a more secure exchange by using Nxt AE and Nxt messaging system. If the communication between the server and users is done via Nxt blockchain with no frontend, the server will be immune from hackers as they won't even know the location/IP address of the server.

It would work like this:

(1) A user would request to generate depositing BTC address in the Nxt client by sending a message to asset issuer.
(2) A remote server (or servers) (whose location and IP would be unknown so can't be hacked) would see the request on the blockchain and generates an address for the user and send it back via blockchain (normal Nxt messaging transaction). The client on user side will only have to check if the message received came from asset issuer address.
(3) The user can then deposit BTC to that address, and the secret server would update the users "bitcoin balance" by sending bitcoin asset to the user.
(4) Those BTC can be traded with other users via asset exchange
(5) Since no one would know the IP address of the secret servers, the servers would be pretty safe from hackers. No weak frontend. No usernames, no passwords, no 2 factor authentication no https.

(6) BTC could be withdrawn by simply sending the asset back to asset issuer with withdrawal address in the comment (the client will check to make sure the withdrawal address has valid format).

This would work for ALL ALTcoins (not just BTC) and it would be simple to implement by just modifying the default JavaScript UI of Nxt, which is open source already.

Eadeqa · « **Reply #1 on:** June 19, 2014, 04:53:19 am »

Quote from: Eadeqa on June 19, 2014, 04:12:57 am

(2) A remote server (or servers) (whose location and IP is unknown so can't be hacked) sees the request on the blockchain and generate an address for the user and sends it back via blockchain (normal Nxt messaging transaction).

Ok, there is a risk here that someone will send fake BTC address.. The client will have to check to make sure the message originated from authentic asset issuer

jl777 · « **Reply #2 on:** June 19, 2014, 05:04:47 am »

Quote from: Eadeqa on June 19, 2014, 04:53:19 am

Quote from: Eadeqa on June 19, 2014, 04:12:57 am
(2) A remote server (or servers) (whose location and IP is unknown so can't be hacked) sees the request on the blockchain and generate an address for the user and sends it back via blockchain (normal Nxt messaging transaction).

Ok, there is a risk here that someone will send fake BTC address.. The client will have to check to make sure the message originated from authentic asset issuer

So you like a centralized gateway better than MGW because the IP address is hidden? Granted the MGW IP addresses are currently published, but they only talk to each other and firewalls will block any packets not from each other.

So I am confused why you like NAS gateway better? Certainly if it is integrated into the standard NAS wallet it is more convenient, but what prevents MGW from being part of standard wallet?

James

Eadeqa · « **Reply #3 on:** June 19, 2014, 05:13:51 am »

Quote from: jl777 on June 19, 2014, 05:04:47 am

So you like a centralized gateway better than MGW because the IP address is hidden? Granted the MGW IP addresses are currently published, but they only talk to each other and firewalls will block any packets not from each other.

I like it because it's much simpler from both developer and user perspective. It can be easily implemented for every altcoin on coinmarketcap.

It's not trustless but neither is our version. It's pretty secure from hackers though as they would not know the IP/location of the servers. It can be all automated with very quick withdrawals and deposits but yet remain very secure (close to 100% if servers are physically secure).

The party running such a service will have to be totally trustworthy.

I think Dgex should look into it, especially since they have their Offspring client

jl777 · « **Reply #4 on:** June 19, 2014, 05:24:40 am »

Quote from: Eadeqa on June 19, 2014, 05:13:51 am

Quote from: jl777 on June 19, 2014, 05:04:47 am
So you like a centralized gateway better than MGW because the IP address is hidden? Granted the MGW IP addresses are currently published, but they only talk to each other and firewalls will block any packets not from each other.

I like it because it's much simpler from both developer and user perspective. It can be easily implemented for every altcoin on coinmarketcap.

It's not trustless but neither is our version. It's pretty secure from hackers though as they would not know the IP/location of the servers. It can be all automated with very quick withdrawals and deposits but yet remain very secure (close to 100% if servers are physically secure).

The party running such a service will have to be totally trustworthy.

I think Dgex should look into it, especially since they have their Offspring client

Basically its MGW without the multisig and multiple servers, so yes much easier
If there were many coins that were worth supporting that didnt support multisig, maybe it would be worth doing

MGW to my knowledge is the least centralized gateway. I am surprised to hear that such things dont matter to you.

Eadeqa · « **Reply #5 on:** June 19, 2014, 05:29:14 am »

Quote from: jl777 on June 19, 2014, 05:24:40 am

MGW to my knowledge is the least centralized gateway. I am surprised to hear that such things dont matter to you.

There is nothing wrong with your MGW. But there could be more than one version from other parties, and I still think Dgex should look into implementing it in OffSpring. They can make money by having some withdrawal fees.

It will be far more secure than their web version, and I will like to see they implement something like top 50 coins, and it will be still easy to implement but yet secure

2Kool4Skewl · « **Reply #6 on:** June 19, 2014, 05:35:41 am »

Quote from: jl777 on June 19, 2014, 05:24:40 am

Quote from: Eadeqa on June 19, 2014, 05:13:51 am
Quote from: jl777 on June 19, 2014, 05:04:47 am
So you like a centralized gateway better than MGW because the IP address is hidden? Granted the MGW IP addresses are currently published, but they only talk to each other and firewalls will block any packets not from each other.

I like it because it's much simpler from both developer and user perspective. It can be easily implemented for every altcoin on coinmarketcap.

It's not trustless but neither is our version. It's pretty secure from hackers though as they would not know the IP/location of the servers. It can be all automated with very quick withdrawals and deposits but yet remain very secure (close to 100% if servers are physically secure).

The party running such a service will have to be totally trustworthy.

I think Dgex should look into it, especially since they have their Offspring client
Basically its MGW without the multisig and multiple servers, so yes much easier
If there were many coins that were worth supporting that didnt support multisig, maybe it would be worth doing

MGW to my knowledge is the least centralized gateway. I am surprised to hear that such things dont matter to you.

Exactly James. NAS's version doesn't have multisig therefore it isn't any better than current centralized exchanges.

NXT's MGW on the other hand is the most "trustless" solution available for an exchange / crypto-gateway and can be expanded later by adding more multisigs.

Eadeqa · « **Reply #7 on:** June 19, 2014, 05:40:11 am »

Quote from: 2Kool4Skewl on June 19, 2014, 05:35:41 am

Exactly James. NAS's version doesn't have multisig therefore it isn't any better than current centralized exchanges.
NXT's MGW on the other hand is the most "trustless" solution available for an exchange / crypto-gateway and can be expanded later by adding more multisigs.

MGW might be more "trustless", but it's not totally trustless like a blockchain.

The other version has benefits too: simplicity (both for users and developers), and security -- as the server location and IP would be unknown to hackers.

Quote

it isn't any better than current centralized exchanges.

It's better than centralized exchanges as it's more secure. There are no logins (username/passwords) to websites. No location and no IP of servers

jl777 · « **Reply #8 on:** June 19, 2014, 05:46:00 am »

Quote from: Eadeqa on June 19, 2014, 05:40:11 am

Quote from: 2Kool4Skewl on June 19, 2014, 05:35:41 am

Exactly James. NAS's version doesn't have multisig therefore it isn't any better than current centralized exchanges.
NXT's MGW on the other hand is the most "trustless" solution available for an exchange / crypto-gateway and can be expanded later by adding more multisigs.

MGW might be more "trustless", but it's not totally trustless like a blockchain.

The other version has benefits too: simplicity (both for users and developers), and security -- as the server location and IP would be unknown to hackers.

Quote
it isn't any better than current centralized exchanges.

It's better than centralized exchanges as it's more secure. There are logins to servers. No passwords. No location and IP of servers

I could simply not make the MGW IP addresses available. I had it in the JSON, but never actually used it.
...
I removed the ipaddr field that published the server's IP addr, so now nobody will know the IP of MGW production servers
but I am sure you still like NAS better

jl777 · « **Reply #9 on:** June 19, 2014, 05:48:51 am »

Quote from: Eadeqa on June 19, 2014, 05:29:14 am

Quote from: jl777 on June 19, 2014, 05:24:40 am
MGW to my knowledge is the least centralized gateway. I am surprised to hear that such things dont matter to you.

There is nothing wrong with your MGW. But there could be more than one version from other parties, and I still think Dgex should look into implementing it in OffSpring. They can make money by having some withdrawal fees.

It will be far more secure than their web version, and I will like to see they implement something like top 50 coins, and it will be still easy to implement but yet secure

I would be happy to work with anybody that wanted to implement a gateway for all the secondary altcoins
It wouldnt be too much work to strip out the multisig part of MGW
I just dont see MGW supporting the altcoin of the week, I prefer to support just the top volume coins

Eadeqa · « **Reply #10 on:** June 19, 2014, 05:50:49 am »

Quote from: jl777 on June 19, 2014, 05:46:00 am

I removed the ipaddr field that published the server's IP addr, so now nobody will know the IP of MGW production servers
but I am sure you still like NAS better

What's your problem? I said Dgex should look into implementing this version in OffSpring (NXT -- not NAS) as it's more secure than centralized exchange on a website with username and password. And it will be easier for users and could support all altcoins

Do you not like any competition? I am not asking you to trash your version

2Kool4Skewl · « **Reply #11 on:** June 19, 2014, 05:53:11 am »

Quote from: Eadeqa on June 19, 2014, 05:40:11 am

Quote from: 2Kool4Skewl on June 19, 2014, 05:35:41 am

Exactly James. NAS's version doesn't have multisig therefore it isn't any better than current centralized exchanges.
NXT's MGW on the other hand is the most "trustless" solution available for an exchange / crypto-gateway and can be expanded later by adding more multisigs.

MGW might be more "trustless", but it's not totally trustless like a blockchain.

I never said MGW was "totally trustless", but it IS the most "trustless" solution avaliable.

The only way I can think of to make a "totally trustless" crypto gateway would be to upload the MGW code into NxtAT.

jl777 · « **Reply #12 on:** June 19, 2014, 05:55:39 am »

Quote from: Eadeqa on June 19, 2014, 05:50:49 am

Quote from: jl777 on June 19, 2014, 05:46:00 am
I removed the ipaddr field that published the server's IP addr, so now nobody will know the IP of MGW production servers
but I am sure you still like NAS better

What's your problem? I said Dgex should look into implementing this version in OffSpring (NXT -- not NAS) as it's more secure than centralized exchange on a website with username and password. And it will be easier for users and could support all all altcoins

Do you not like any competition? I am not asking you to trash your version

My issue was your stated reason for preferring NAS over MGW was the availability of ipaddr in MGW. It does help security to remove that, so I thank you for the feedback. Integration into client is not really an MGW issue, it is a web GUI issue. longzai almost has the standard web GUI enhanced with MGW page, so to users it will be pretty easy to use.

I said I would be happy to work with dgex or anybody who wants to do a gateway for altcoins without multisig
I can make a stripped down version of MGW

Eadeqa · « **Reply #13 on:** June 19, 2014, 05:56:47 am »

Quote from: 2Kool4Skewl on June 19, 2014, 05:53:11 am

The only way I can think of to make a "totally trustless" crypto gateway would be to upload the MGW code into NxtAT.

NxtAT will not make it trustless as the reason it's not trustless has nothing to do with Nxt, but the three servers that will be run by third parties

jl777 · « **Reply #14 on:** June 19, 2014, 05:58:45 am »

Quote from: 2Kool4Skewl on June 19, 2014, 05:53:11 am

Quote from: Eadeqa on June 19, 2014, 05:40:11 am
Quote from: 2Kool4Skewl on June 19, 2014, 05:35:41 am

Exactly James. NAS's version doesn't have multisig therefore it isn't any better than current centralized exchanges.
NXT's MGW on the other hand is the most "trustless" solution available for an exchange / crypto-gateway and can be expanded later by adding more multisigs.

MGW might be more "trustless", but it's not totally trustless like a blockchain.

I never said MGW was "totally trustless", but it IS the most "trustless" solution avaliable.

The only way I can think of to make a "totally trustless" crypto gateway would be to upload the MGW code into NxtAT.

Not just MGW code, but bitcoind and any coin you want to support would also have to be in the NXTcore. paying per instruction would cost quite a bit and it would probably be way too slow. The only practical way would be to integrate bitcoinj into the NXTcore and port MGW code also, but the problem is that the acct passwords will be where? A gateway needs to keep the bitcoin wallet somewhere and if it is in the blockchain then anybody could decode it and cashout all the deposits.

I am just not sure if a blockchain gateway is possible...
So, until someone figures that out and implements it, MGW will be state of the art and most trustless gateway

James

2Kool4Skewl · « **Reply #15 on:** June 19, 2014, 05:59:10 am »

Quote from: Eadeqa on June 19, 2014, 05:56:47 am

Quote from: 2Kool4Skewl on June 19, 2014, 05:53:11 am
The only way I can think of to make a "totally trustless" crypto gateway would be to upload the MGW code into NxtAT.

NxtAT will not make it trustless as the reason it's not trustless has nothing to do with Nxt, but the three servers that will be run by third parties

You would have to upload the MGW code and have it executed on the NXT blockchain. Therefore it would not be run by servers, but by three separate scripts executing on the chain.

jl777 · « **Reply #16 on:** June 19, 2014, 06:00:23 am »

Quote from: 2Kool4Skewl on June 19, 2014, 05:59:10 am

Quote from: Eadeqa on June 19, 2014, 05:56:47 am
Quote from: 2Kool4Skewl on June 19, 2014, 05:53:11 am
The only way I can think of to make a "totally trustless" crypto gateway would be to upload the MGW code into NxtAT.

NxtAT will not make it trustless as the reason it's not trustless has nothing to do with Nxt, but the three servers that will be run by third parties

You would have to upload the MGW code and have it executed on the NXT blockchain. Therefore it would not be run by servers, but by three separate scripts executing on the chain.

where are the bitcoin wallets?

Eadeqa · « **Reply #17 on:** June 19, 2014, 06:02:04 am »

Quote from: jl777 on June 19, 2014, 05:55:39 am

My issue was your stated reason for preferring NAS over MGW was the availability of ipaddr in MGW.

No, that was not the reason. I liked the simplicity for users and developers. The IP issue was not regarding your version but compared to centralized exchanges with logics/passwords.

Quote

I can make a stripped down version of MGW

Good. Maybe Graviton will talk to OffSpring developer and you. It will be better than web exchange.

2Kool4Skewl · « **Reply #18 on:** June 19, 2014, 06:02:52 am »

Quote from: jl777 on June 19, 2014, 05:58:45 am

but the problem is that the acct passwords will be where? A gateway needs to keep the bitcoin wallet somewhere and if it is in the blockchain then anybody could decode it and cashout all the deposits.

That's true. Even if you encrypted the wallet and stored it on the blockchain, where would you keep the password? Interesting to think about. I can't currently think of a solution.

jl777 · « **Reply #19 on:** June 19, 2014, 06:03:51 am »

Quote from: Eadeqa on June 19, 2014, 06:02:04 am

Quote from: jl777 on June 19, 2014, 05:55:39 am
My issue was your stated reason for preferring NAS over MGW was the availability of ipaddr in MGW.

No, that was not the reason. I liked the simplicity for users and developers. The IP issue was not regarding your version but compared to centralized exchanges with logics/passwords.

Quote
I can make a stripped down version of MGW

Good. Maybe Graviton will talk to OffSpring developer and you. It will be better than web version.

regardless it turned out to be good feedback as a legacy JSON had MGW ipaddr in it
are there things I can do to make MGW simpler for users other than integrating it into standard GUI?

Eadeqa · « **Reply #20 on:** June 19, 2014, 07:05:53 am »

Quote from: jl777 on June 19, 2014, 06:03:51 am

are there things I can do to make MGW simpler for users other than integrating it into standard GUI?

I haven't yet tried it,but am I am trying now. What's the start up time with NXTservices_M08f? It's been something like an hour and it's scanning the blockchain?

I don't think this will work. In fact the user should not have to install anything on his computer. It should work with just GUI and NRS

jl777 · « **Reply #21 on:** June 19, 2014, 07:09:39 am »

Quote from: Eadeqa on June 19, 2014, 07:05:53 am

Quote from: jl777 on June 19, 2014, 06:03:51 am

are there things I can do to make MGW simpler for users other than integrating it into standard GUI?

I haven't yet tried it,but am I am trying now. What's the start up time with NXTservices_M08f? It's been something like an hour and it's scanning the blockchain?

I don't think this will work. In fact the user should not have to install anything on his computer. It should work with just GUI and NRS

I am working on speeding it up. There is also a libcurl wierdness and I have to put a couple millisecond delay that makes it 10 times slower. Hopefully someone can find that bug and most of the slowness issues will be solved

Eadeqa · « **Reply #22 on:** June 19, 2014, 07:14:57 am »

Quote from: jl777 on June 19, 2014, 07:09:39 am

I am working on speeding it up. There is also a libcurl wierdness and I have to put a couple millisecond delay that makes it 10 times slower. Hopefully someone can find that bug and most of the slowness issues will be solved

Is it possible to make it work with just GUI and NRS without the user installing anything? The user could generate BTC address by sending a request on NRS (messaging system) , and the remote server would returns the depositing address via Nxt messaging system.

jl777 · « **Reply #23 on:** June 19, 2014, 07:20:01 am »

Quote from: Eadeqa on June 19, 2014, 07:14:57 am

Quote from: jl777 on June 19, 2014, 07:09:39 am
I am working on speeding it up. There is also a libcurl wierdness and I have to put a couple millisecond delay that makes it 10 times slower. Hopefully someone can find that bug and most of the slowness issues will be solved

Is it possible to make it work with just GUI and NRS without the user installing anything? The user could generate BTC address by sending a request on NRS (messaging system) , and the remote server would returns the depositing address via Nxt messaging system.

Yes I think I can do that. I had been so concentrating on a peer verified gateway that I pushed all the MGW code (other than actual wallets and payments) into all the nodes.

Currently there is:
A) just NXT blockchain to track assets and AM's
B) updating MGW status without blockchain info (assets and AM's)
C) linkage to bitcoin-qt to get blockchain info, this recreates MGW internal state on each node at level C)

Now if you dont care about even B), then I can simply make a version that does A) without any history. The deposit address received would need to be stored locally so an AM isnt needed each time you run the GUI, but I think that is like storing the contact info locally.

When we have an actual GUI to store the deposit addresses, I can make a lean version real quick

James

P.S. Two great feedbacks within 1 hour! Great work. Thanks!!

Eadeqa · « **Reply #24 on:** June 19, 2014, 07:30:37 am »

Ok, then as far as I am concerned, I am only interested in GUI (preferably written in Javascript -- maybe even clone of Wesley client with extra options for gateway). From a user perspective, they should not have to deal with NXTservices at all. That should be server side code only (even totally closed source, I don't care). All the communications between the servers and users could be done via Nxt messaging system (like generating depositing address) and withdrawals could be done by sending asset back to to the issuer and including the withdrawal address in that transaction (the GUI client should check if the withdrawal address is valid BTC address before sending the transaction to catch user errors).

There is nothing more to do from user perspective.

jl777 · « **Reply #25 on:** June 19, 2014, 07:33:44 am »

Quote from: Eadeqa on June 19, 2014, 07:30:37 am

Ok, then as far as I am concerned, I am only interested in GUI (preferably written in Javascript -- maybe even clone of Wesley client with extra options for gateway). From a user perspective, they should not have to deal with NXTservices at all. That should be server side code only (even totally closed source, I don't care). All the communications between the servers and users could be done via Nxt messaging system (like generating depositing address) and withdrawals could be done by sending asset back to to the issuer.

Thats pretty much how it works now plus all the MGW state duplication and I can just disable that
I am hoping wesley can integrate the AM processing into the official GUI, but if not the longzai version can support the lite mode

Thanks again! I knew you would be helpful. You want some MGW assets? You have earned them

James

Eadeqa · « **Reply #26 on:** June 19, 2014, 07:41:55 am »

Quote

Thats pretty much how it works now plus all the MGW state duplication and I can just disable that
I am hoping wesley can integrate the AM processing into the official GUI, but if not the longzai version can support the lite mode

Since Wesley client is open source and free to use, it shouldn't be a problem to just clone it and release it with extra options for gateway. It should be easy to do for any Javascript developer (maybe even Wesley himself?) I doubt JL will agree to including it in official distribution due to centralization issue.

Quote

Thanks again! I knew you would be helpful. You want some MGW assets? You have earned them

Sure

Graviton · « **Reply #27 on:** June 19, 2014, 08:17:32 am »

Quote from: Eadeqa on June 19, 2014, 05:29:14 am

and I still think Dgex should look into implementing it in OffSpring.

Thanks Eadeqa for the trust! DGEX is working on such a system since a while. UI independent, full JSON driven interface with passthrough to AE.

Quote

It can be all automated with very quick withdrawals and deposits but yet remain very secure (close to 100% if servers are physically secure).

Close to 100% is far cry. Most of the hacks unfortunately occur at frontend software, middle layer, social engineering or a combination of these.

Eadeqa · « **Reply #28 on:** June 19, 2014, 08:23:44 am »

Quote from: Graviton on June 19, 2014, 08:17:32 am

Close to 100% is far cry. Most of the hacks unfortunately occur at frontend software, middle layer, social engineering or a combination of these.

This maybe true, but if everything (deposit addresses, withdrawal) go through Nxt blockchain, it will not be your error if a user loses his Nxt password

No logins/passwords (not https issues) and your server would have unknown IP

Graviton · « **Reply #29 on:** June 19, 2014, 08:41:00 am »

Quote from: Eadeqa on June 19, 2014, 08:23:44 am

and your server would have unknown IP

That's what we do since December. The frontend still has an IP and procedures that forward actions to the secret server. Manipulations can be carried out all the same no matter how many middle layers you have before the secret backend.

Quote

No logins/passwords (not https issues)

I see your point in simplifying the process up to a point of no user accounts. I have been thinking of this. I'll need to talk to Dirk about the blockchain things. He already figured out authentication can be done through blockchain messaging.

Eadeqa · « **Reply #30 on:** June 19, 2014, 08:46:28 am »

Quote from: Graviton on June 19, 2014, 08:41:00 am

That's what we do since December. The frontend still has an IP and procedures that forward actions to the secret server. Manipulations can be carried out all the same no matter how many middle layers you have before the secret backend.

It's not the same as the frontend knows (or talks to) secret server. If you do it via Nxt blockchain, there is no front end. The secret server only checks the blockchain and has no direct link to frontend.

Eadeqa · « **Reply #31 on:** June 19, 2014, 09:05:42 am »

Quote from: Graviton on June 19, 2014, 08:41:00 am

He already figured out authentication can be done through blockchain messaging.

By the way, I don't know what that means. All Nxt messages are already "authenticated" as they are signed just as all Nxt transactions. Changing anything in the message will invalidate the signature.

A Nxt user sends a message asking for deposit address. The secret server sees the message in the blockchain (no direct link to the user -- no front end). The server sends back depositing address via Nxt message. That address can't be changed as it's already signed (curve25519). It can even be encrypted (AES) The OffSpring client only have to check if the response was sent by asset issuer.

Graviton · « **Reply #32 on:** June 19, 2014, 09:10:23 am »

Quote from: Eadeqa on June 19, 2014, 09:05:42 am

By the way, I don't know what that means.

DGEX login authentication

The blockchain thing with non-accounts indeed removes most of the weak links, you're right about that.

rudeboi · « **Reply #33 on:** June 19, 2014, 09:58:10 pm »

I think most would want mgw in the official gui, however there are issues of doing this. The best approach I think would be addon support like xbmc.

If there wasn't any kind of official GUI support even by add on, then I like the idea of a clone of the wesley source with mgw support.

This then gives users the choice if they want mgw version at their own risk, I would expect most nxters to try, this would put pressure on adoption into the main gui.

In the same way it wouldn't stop other teams from producing more centralised add ons ie DGEX addon, let the user decide what they want to use.

valarmg · « **Reply #34 on:** June 19, 2014, 10:10:57 pm »

Quote from: rudeboi on June 19, 2014, 09:58:10 pm

I think most would want mgw in the official gui, however there are issues of doing this. The best approach I think would be addon support like xbmc.

If there wasn't any kind of official GUI support even by add on, then I like the idea of a clone of the wesley source with mgw support.

This then gives users the choice if they want mgw version at their own risk, I would expect most nxters to try, this would put pressure on adoption into the main gui.

In the same way it wouldn't stop other teams from producing more centralised add ons ie DGEX addon, let the user decide what they want to use.

Most likely the initial release of the MGW will be via a cloned client. However, ultimately, something like this could be the best solution. https://nxtforum.org/nxt-improvement-proposals/plugin-feature-to-nxt-client-(wesley's-ui)-proposal-thread

VanBreuk · « **Reply #35 on:** June 19, 2014, 10:25:51 pm »

Thanks for the feedback, keeping an eye on this. Some of the ideas mentioned can make some of the work I'm doing (i.e. NXTservices installers) completely unnecessary for MGW, and might change a lot of things in the user documentation. So maybe I will put some things on hold.

jl777 · « **Reply #36 on:** June 20, 2014, 02:38:58 am »

Quote from: VanBreuk on June 19, 2014, 10:25:51 pm

Thanks for the feedback, keeping an eye on this. Some of the ideas mentioned can make some of the work I'm doing (i.e. NXTservices installers) completely unnecessary for MGW, and might change a lot of things in the user documentation. So maybe I will put some things on hold.

There will be several levels of MGW clients

I will be defining a generic AM based gateway deposit address request and withdrawal "protocol" that can be used by any gateway, including MGW. The user just has to put in the gateway's NXT address and so the client will be gateway agnostic. At this level it has a very good chance of being adopted by the official GUI since it is just a way to configure which gateway you want to use. At this level all you would be able to do is to get a deposit address and do withdraws, but that is all most people would need to do. The big advantage is that there is no software to install and just one NXT address to put in.

The next level is what we currently have when you run NXTservices without linking up bitcoind (litecoind, etc). It will allow you to track the MGW tx and balances via AM's and do all the NXTservices calls that dont require bitcoind linkup.

The most advanced level is where you link up the bitcoind. This will allow you to fully reproduce MGW status, NXTsubatomic transactions and any other NXTservices functions that requires bitcoin blockchain. Mostly for advanced users or those that want to do NXTsubatomic trades.

So, we clearly need documentation of all these levels

James

P.S. For some reason, I am having problems concentrating. Will call it an early day today and hope to do better tomorrow

Eadeqa · « **Reply #37 on:** June 20, 2014, 05:08:04 am »

Quote from: jl777 on June 19, 2014, 07:20:01 am

The deposit address received would need to be stored locally so an AM isnt needed each time you run the GUI, but I think that is like storing the contact info locally.

Deposit address does not have to be stored locally as they are on the blockchain. Nothing on the blockchain is deleted, so the user will always see the same deposit address on various machines.

Eadeqa · « **Reply #38 on:** June 20, 2014, 06:50:16 am »

I updated my original post, as I think all exchanges should use Nxt blockchain

jl777 · « **Reply #39 on:** June 20, 2014, 08:47:13 am »

Quote from: Eadeqa on June 20, 2014, 05:08:04 am

Quote from: jl777 on June 19, 2014, 07:20:01 am

The deposit address received would need to be stored locally so an AM isnt needed each time you run the GUI, but I think that is like storing the contact info locally.

Deposit address does not have to be stored locally as they are on the blockchain. Nothing on the blockchain is deleted, so the user will always see the same deposit address on various machines.

So you are suggesting to rescan the blockchain on every login?
Otherwise how will the webGUI know what the deposit address is?

Eadeqa · « **Reply #40 on:** June 20, 2014, 05:29:21 pm »

Quote from: jl777 on June 20, 2014, 08:47:13 am

So you are suggesting to rescan the blockchain on every login?
Otherwise how will the webGUI know what the deposit address is?

UI already shows all your transactions and messages after every login. It will show the deposit address similarly.

jl777 · « **Reply #41 on:** June 20, 2014, 05:30:16 pm »

Quote from: Eadeqa on June 20, 2014, 05:29:21 pm

Quote from: jl777 on June 20, 2014, 08:47:13 am
So you are suggesting to rescan the blockchain on every login?
Otherwise how will the webGUI know what the deposit address is?

UI already shows all your transactions and messages after every login. It will show the deposit address similarly.

so doesnt this mean it is stored locally?

Eadeqa · « **Reply #42 on:** June 20, 2014, 05:31:46 pm »

Quote from: jl777 on June 20, 2014, 05:30:16 pm

so doesnt this mean it is stored locally?

It's on the blockchain just like your messages, transaction, balance, all blocked you forged etc. The UI shows all that info

jl777 · « **Reply #43 on:** June 20, 2014, 05:46:42 pm »

Quote from: Eadeqa on June 20, 2014, 05:31:46 pm

Quote from: jl777 on June 20, 2014, 05:30:16 pm
so doesnt this mean it is stored locally?

It's on the blockchain just like your messages, transaction, balance, all blocked you forged etc. The UI shows all that info

yes I am aware of that
are you saying the GUI rescans the blockchain everytime you login?
It sure seems to instantly show a lot of info, almost as if it was storing stuff locally.
do you know or are you assuming it rescans the blockchain?

Clearly storing locally or rescanning the blockchain are the options. If it can rescan the entire blockchain without a noticeable delay then that is better

Eadeqa · « **Reply #44 on:** June 20, 2014, 06:16:59 pm »

Quote from: jl777 on June 20, 2014, 05:46:42 pm

Quote from: Eadeqa on June 20, 2014, 05:31:46 pm
Quote from: jl777 on June 20, 2014, 05:30:16 pm
so doesnt this mean it is stored locally?

It's on the blockchain just like your messages, transaction, balance, all blocked you forged etc. The UI shows all that info
yes I am aware of that
are you saying the GUI rescans the blockchain everytime you login?
It sure seems to instantly show a lot of info, almost as if it was storing stuff locally.
do you know or are you assuming it rescans the blockchain?

Clearly storing locally or rescanning the blockchain are the options. If it can rescan the entire blockchain without a noticeable delay then that is better

Doesn't UI just use API calls to retrieve all that info? A message would be one of the transaction from user's account.

jl777 · « **Reply #45 on:** June 20, 2014, 06:25:59 pm »

Quote from: Eadeqa on June 20, 2014, 06:16:59 pm

Quote from: jl777 on June 20, 2014, 05:46:42 pm
Quote from: Eadeqa on June 20, 2014, 05:31:46 pm
Quote from: jl777 on June 20, 2014, 05:30:16 pm
so doesnt this mean it is stored locally?

It's on the blockchain just like your messages, transaction, balance, all blocked you forged etc. The UI shows all that info
yes I am aware of that
are you saying the GUI rescans the blockchain everytime you login?
It sure seems to instantly show a lot of info, almost as if it was storing stuff locally.
do you know or are you assuming it rescans the blockchain?

Clearly storing locally or rescanning the blockchain are the options. If it can rescan the entire blockchain without a noticeable delay then that is better

Doesn't UI just use API calls to retrieve all that info? A message would be one of the transaction from user's account.

sure, but which API calls. I am not aware of an API that says give me list of all AM's I have received. Would make things a lot simpler and maybe there is. A lot of new API calls get added without any real notice so sometimes I am pleasantly surprised with a new one

Unless this API call has been added, you need to find all the AM messages which are in a certain type of transaction, so that means API calls to get the block and then scan for the right transaction.

Now I am having all sorts of performance problems with libcurl. I can issue 20000+ per second, but if I go much faster than 500 per second, it starts sputtering.

So, this is why I suggested the deposit address be stored locally. Or somebody tell me how to get all AM's without rescanning. or how I can make 20000 curl requests per second without it gagging

James

Eadeqa · « **Reply #46 on:** June 20, 2014, 06:27:22 pm »

Quote from: jl777 on June 20, 2014, 06:25:59 pm

sure, but which API calls. I am not aware of an API that says give me list of all AM's I have received. Would make things a lot simpler and maybe there is. A lot of new API calls get added without any real notice so sometimes I am pleasantly surprised with a new one

Is there API call for list your transactions? AM is a transaction

valarmg · « **Reply #47 on:** June 20, 2014, 06:34:30 pm »

Quote from: Eadeqa on June 20, 2014, 06:27:22 pm

Quote from: jl777 on June 20, 2014, 06:25:59 pm
sure, but which API calls. I am not aware of an API that says give me list of all AM's I have received. Would make things a lot simpler and maybe there is. A lot of new API calls get added without any real notice so sometimes I am pleasantly surprised with a new one

Is there API call for list your transactions? AM is a transaction

I just checked this, and this seems to be true. getAccountTransactionIds includes AMs to that account.

jl777 · « **Reply #48 on:** June 20, 2014, 06:34:36 pm »

Quote from: Eadeqa on June 20, 2014, 06:27:22 pm

Quote from: jl777 on June 20, 2014, 06:25:59 pm
sure, but which API calls. I am not aware of an API that says give me list of all AM's I have received. Would make things a lot simpler and maybe there is. A lot of new API calls get added without any real notice so sometimes I am pleasantly surprised with a new one

Is there API call for list your transactions? AM is a transaction

yup! you are right
getAccountTransactionIds

That wasnt there when I looked for it last, but I need to do this for all accounts and since I scan blockchain anyway I never bothered to look for account specific txs

thanks, this will help in some cases

so you were right, no need to store locally if this gets all tx for an account.

James

P.S. do you know how to do lots of curl calls really fast without making things comatose?

Eadeqa · « **Reply #49 on:** July 16, 2014, 10:10:21 pm »

https://nxtforum.org/trading-exchanges/dgex-hacked-for-52-btc-1-2m-nxt/

I bet the above would not have not happened if we had an exchange that was based on blockchain

antanst · « **Reply #50 on:** July 17, 2014, 08:06:38 am »

We've got something in the works, and hopefully we'll announce a beta version of a gateway in the following weeks. It will be a separate project from nxtblocks.info. Stay tuned.

Eadeqa · « **Reply #51 on:** August 21, 2014, 05:07:17 am »

Quote from: antanst on July 17, 2014, 08:06:38 am

We've got something in the works, and hopefully we'll announce a beta version of a gateway in the following weeks. It will be a separate project from nxtblocks.info. Stay tuned.

A month later .. still nothing?

antanst · « **Reply #52 on:** August 21, 2014, 08:42:37 am »

Quote from: Eadeqa on August 21, 2014, 05:07:17 am

Quote from: antanst on July 17, 2014, 08:06:38 am
We've got something in the works, and hopefully we'll announce a beta version of a gateway in the following weeks. It will be a separate project from nxtblocks.info. Stay tuned.

A month later .. still nothing?

Nothing indeed. The nxtblocks asset sales were far slower that we expected, which means that we had to reprioritize a bit. We are still developing the gateway, but it's not ready yet.

The fact that NRS again has breaking API changes and new incompatibilities doesn't help as well.

News:

Author Topic: A simpler Gateway built in to official client (Read 7446 times)