Topic: mgw - page 4. (Read 3794 times)

Ok, anyone capable of this? Guys?

Somebody on the team needs to recreate the doge client demo using just the AM data structure. Most of the code is just a hardcoded parser for API JSON return strings. I bet someone can make an equivalent program in much fewer lines of python or any other language using hansson JSON lib.

Could you please specify that?

As long as you can understand that is the most important.
The client software I wrote should be simple enough to port to whatever other language. I think the first step is for someone who is not me to be able to write programs that create gateway AM

James

i have read all James'  posts, many are full of invention.
6 years ago ,i coded a small program with object-c in linux, now use delphi in windows. In China you know  a few people use linux/unix.
Because i am not familiar with PHP in web design, i think  i can help comment on core and make some test tool.
btw, my english is very fool.

Maybe, but I already have access to ~180 servers, at least for now, to setup a real environment. Not sure if we need anything more elaborate, especially with our limited personnel.

Thank you for your input!

@jl777 can we use such a tool?

It's not clear for me exactly what is all about, my area is networking, so hopefully I can help on that field.. Well you can fairly simulate a large network at very low cost. To Networking prototyping, it is desired to have Flexibility, Scalability, Low-Cost and Realism then basically you can have a networks simulators  like ndnSIM, OMNeT++ , opnet but their are mathematical models. You can also have testbeds (expensive, they are experimental infrastructures that provide real resources for test and pilot scenarios eg.: Geni, Planetlab) and finally emulators just like testbeds,  they are realistic because they run real code (applications,  OS  kernel,  etc).   

To emulate that network above I would suggest then ..

The Common Open Research Emulator (CORE) it has a nice gui, network tools, etc and have a documentation
http://www.nrl.navy.mil/itd/ncs/products/core   

I am technically not fit to help here, but I will take over the organizational stuff. Just let me know what is needed so you can focus on coding.

Could the others please also drop a line about your understandings of what James wrote in his post above?

heya! ironing out last f***img wrinkles from AE client, but I'm alert!

 

https://bitcointalksearch.org/topic/m.5500225

http://arstechnica.com/security/2014/03/critical-crypto-bug-leaves-linux-hundreds-of-apps-open-to-eavesdropping/

The above describe real world security fails. Critical that we make sure no such thing ever happens.

the problem is that protocols of gen1 coins are pretty complicated, leaving lots of room for errors:

https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list
https://en.bitcoin.it/wiki/Raw_Transactions

I am designing things to minimize changes needed to add support for another BTC (or even LTC) fork. However, since I am utilizing some advanced features, it is not clear which coins actually support what is needed. One major task that really is the thing that creates the most value is to simply install the daemon for as many coins as possible (in order of importance) and make sure it supports the required low level functions. A desktop with a few terabytes and good bandwidth is all that is needed.

Once we have someone that has dozens of daemons to test things with, we will need to make some small tools for him to be able to easily test if the required functions are there. It took me a while to figure out how to properly create 2 of 3 multisig accts, not to mention just making a rawtransaction. Whoever signs up for being the tool maker, I will PM the reference src needed to get started.

Ultimately, we will have the following topology:


We are currently working on the code for the three gateway servers. All relevant transactions will leave a record in blockchain using AM. So, we need somebody to monitor all the relevant AM's and create a "block explorer" equivalent. This will allow not only us to debug things, but it will create the transparency needed for a trustless system. Whoever signs up to do the website for this, I will PM the internal AM codes. For now, I will assume that Evil Bob wont be able to directly communicate with the gateway servers as they will only accept connections from the 100 guardians.

This means all inputs to the gateways are via AM. At first, I had a lot of client visible calls, but in the interest of simplicity, I reduced to down to just 2 for sending data to gateway and 1 for receiving data back:

#define GET_COINDEPOSIT_ADDRESS 'g'
#define BIND_DEPOSIT_ADDRESS 'b'
#define SET_COINWITHDRAW_ADDRESS 'w'

I expanded GET_COINDEPOSIT_ADDRESS to include the ability to set the withdraw address, so SET_COINWITHDRAW_ADDRESS is only needed to change the withdraw address, but for most people this will be rare. The most common use case is that the client software sends a GET_COINDEPOSIT_ADDRESS with their acct # and withdraw address. They then poll all the AM's for a BIND_DEPOSIT_ADDRESS AM to find out what their deposit address is.

After the wallet addresses are linked to account, everything is designed to be transparent. just send coin to the deposit address and it appears in the AE. just transfer from AE to original issuer (or gateway ID) and it appears in the coin wallet. I tried to achieve Apple level usability so as long as the GUI makes the address binding process as simple as the balance/finance pages on the centralized exchanges, nobody should get confused.

I had to put in a workaround due to the fact that assets do not have fractions at this point. Not sure if this will ever change, so any deposit that isnt a round number will get issued milliALT (or microBTC) for the fraction. I am hoping that assets will support fractions, so this is just a temporary workaround. When we can denominate AE bids in terms of other assets, we will be able to put in a bid of .001 ALT for 1 milliALT and this would allow people to easily convert their millis (and micros) to the full unit asset.

Now the ability to set the withdraw address is definitely an attack vector. Imagine if someone is able to change the wallet address where your withdrawals go to. We need to make sure we identify all attack vectors and really pound on the system to make sure we are not vulnerable. I think looking at the prior security incidents we can create a list of potential attack vectors and a test plan based on them. I need somebody to take charge of this as I will have blind spots on attack vectors on my design. I imagine we will need to use test programs that create AM's en masse to make sure Evil Bob wont succeed.

Finally, if anybody can figure out how to add an optional "comment" field to the transferAsset API http://wiki.nxtcrypto.org/wiki/Nxt_API#Transfer_asset I will be able to implement a AE level atomic exchange between any two assets. It will require a private prearranged trade, but for large direct exchanges I dont think this is a barrier. As soon as the gateway is secure, assets are basically 1:1 for the real thing.

I am not familiar with everyone's skill set, so I am hoping that you will all self select tasks from the list and we can coordinate and clarify things on this thread.

a) massive installs and tests of bitcoin forks
b) tool maker
c) transaction explorer
d) attack vectors and Evil Bob attack programs
e) adding "comment" support to core

James

P.S. doing a dogecoind -reindex took a long time, but the unconfirming tx is gone and all three are in sync, so we now have a functional trio ready for testing. I havent verified https://github.com/jl777/multigateway/blob/master/get_dogeaddr.c is up to date, so maybe someone can do that?

oldnbold's summary: https://bitcointalksearch.org/topic/m.5526665

James