Author Topic: DVS Light Wallet for Mac Open Beta  (Read 33006 times)

0 Members and 1 Guest are viewing this topic.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
I helped Nathan fix that bug earlier today.

 +5% This? I think that fix also explains why the withdraw was unnecessarily split into 2 DVS and 8 DVS rather than a single 10 DVS.

So what command should I use to properly (non-TITAN) send funds to a light wallet account with memo and sender info working?

Offline bytemaster

I note that if you used transfer_to_address, memos will *not* be sent, as it's impossible to send a memo without a public key (and transfer_to_address doesn't use a key; only an address) so it's expected behavior that the recipient won't have the memo.

Oh, okay. Is there a way to send a non-TITAN (since I presume the light wallet has no way right now of knowing about received funds via TITAN) to an account rather than an address from the full client? I basically want to send some DVS to arhag-light, have the sending client grab the public key of arhag-light from the blockchain, use it as the address to send funds to (so the light wallet is aware of the funds received), and use the one-time key included with the transaction and the public key of arhag-light to derive the shared secret that encrypts the memo and sender information.

Are you reporting that the light wallet listed an incorrect balance, or an incorrect transaction display?

The main issue I was reporting is that a transfer initiated in the light wallet from arhag-light to another account (arhag) causes the full client holding the keys to that arhag account to believe (at least according to the transaction history) that it was the one that sent the funds rather than the one that received the funds.

I helped Nathan fix that bug earlier today.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
I note that if you used transfer_to_address, memos will *not* be sent, as it's impossible to send a memo without a public key (and transfer_to_address doesn't use a key; only an address) so it's expected behavior that the recipient won't have the memo.

Oh, okay. Is there a way to send a non-TITAN (since I presume the light wallet has no way right now of knowing about received funds via TITAN) to an account rather than an address from the full client? I basically want to send some DVS to arhag-light, have the sending client grab the public key of arhag-light from the blockchain, use it as the address to send funds to (so the light wallet is aware of the funds received), and use the one-time key included with the transaction and the public key of arhag-light to derive the shared secret that encrypts the memo and sender information.

Are you reporting that the light wallet listed an incorrect balance, or an incorrect transaction display?

The main issue I was reporting is that a transfer initiated in the light wallet from arhag-light to another account (arhag) causes the full client holding the keys to that arhag account to believe (at least according to the transaction history) that it was the one that sent the funds rather than the one that received the funds.
« Last Edit: February 02, 2015, 10:57:38 pm by arhag »

Offline modprobe

Builds for android are technically possible, but no one has any idea how to build fc for android, so that's a non-starter for now. Someday I'll look into it further.

Unfortunately, robohash.org has taken to giving unreliable results for their hashes. The Qt wallet even shows different images for the same thing on different pages. This is not our bug.

@arhag: I'm not entirely sure what all issues you're describing... I note that if you used transfer_to_address, memos will *not* be sent, as it's impossible to send a memo without a public key (and transfer_to_address doesn't use a key; only an address) so it's expected behavior that the recipient won't have the memo. Are you reporting that the light wallet listed an incorrect balance, or an incorrect transaction display?

Offline cn-members

  • Sr. Member
  • ****
  • Posts: 365
    • View Profile
I found the robohash is different on qt-wallet and light-wallet:




any suggestions?
BTS中文区发言人公共账号,帮助社区有效沟通与交流。
Chinese Community Spokesman Account,to help the effective communication between Chinese and other members of the community.We're not translators to do regular translations , but will help with vital ones as we see fit and available at that time.

Offline cn-members

  • Sr. Member
  • ****
  • Posts: 365
    • View Profile
Build the window version by vs2013 is success.
But i try to build the android version by windows and looks like it can't be done.
I use the qt for android(windows) and need to build the boost by mingw, and the lib boost_context can't build on windows by mingw, any idea?


I think i figure out how to build the boost_context, will try it later.

guide please? I never get to know how to use VS, but certainly I want to build the Windows version. Thanks

不知道你是到哪一步卡住了,假设你已经能能用vs编译命令行的钱包,如果不行的话看BUILD_WIN32.md文件。

编译轻钱包另外用到了库qml-extras和qml-material,qt开发包Qt 5.4.0 for Windows 32-bit (VS 2013, OpenGL) ,Qt 5.4.0 for Android (Windows 32-bit),可以在http://www.qt.io/download-open-source/#section-3下载。

Qt5.4或5.3版本应该都可以,用qt5.4 for android其实只是用来编译qml-extras和qml-material,用Qt 5.4.0 for Windows 32-bit (MinGW 4.9.1)也可以。
编译qml-extras和qml-material一样,都用命令行设置环境变量后用mingw编译。假设qt for android安装在d:/qt/qtAndroid
Code: [Select]
set PATH=D:\Qt\qtAndroid\5.4\mingw491_32\bin;D:\Qt\qtAndroid\Tools\mingw491_32\bin;%PATH%;
qmake
mingw32-make.exe
mingw32-make.exe check
mingw32-make.exe install
编译成功后D:\Qt\qtAndroid\5.4\mingw491_32\qml目录下就会有material,拷贝material到Qt for Window目录下D:\Qt\Qt5.4.0\5.4\msvc2013_opengl\qml。我觉着ubuntu下编译出来的material应该也可以直接拷贝过来用。


在能编译命令行钱包的基础上添加环境变量,设置vs使用的qt库目录
CMAKE_PREFIX_PATH D:\Qt\Qt5.3.0\5.3\msvc2013
添加编译轻钱包
INCLUDE_LIGHT_WALLET TRUE

这样就行了。

多謝 我再試試看
BTS中文区发言人公共账号,帮助社区有效沟通与交流。
Chinese Community Spokesman Account,to help the effective communication between Chinese and other members of the community.We're not translators to do regular translations , but will help with vital ones as we see fit and available at that time.

Offline cgafeng

Build the window version by vs2013 is success.
But i try to build the android version by windows and looks like it can't be done.
I use the qt for android(windows) and need to build the boost by mingw, and the lib boost_context can't build on windows by mingw, any idea?


I think i figure out how to build the boost_context, will try it later.

guide please? I never get to know how to use VS, but certainly I want to build the Windows version. Thanks

不知道你是到哪一步卡住了,假设你已经能能用vs编译命令行的钱包,如果不行的话看BUILD_WIN32.md文件。

编译轻钱包另外用到了库qml-extras和qml-material,qt开发包Qt 5.4.0 for Windows 32-bit (VS 2013, OpenGL) ,Qt 5.4.0 for Android (Windows 32-bit),可以在http://www.qt.io/download-open-source/#section-3下载。

Qt5.4或5.3版本应该都可以,用qt5.4 for android其实只是用来编译qml-extras和qml-material,用Qt 5.4.0 for Windows 32-bit (MinGW 4.9.1)也可以。
编译qml-extras和qml-material一样,都用命令行设置环境变量后用mingw编译。假设qt for android安装在d:/qt/qtAndroid
Code: [Select]
set PATH=D:\Qt\qtAndroid\5.4\mingw491_32\bin;D:\Qt\qtAndroid\Tools\mingw491_32\bin;%PATH%;
qmake
mingw32-make.exe
mingw32-make.exe check
mingw32-make.exe install
编译成功后D:\Qt\qtAndroid\5.4\mingw491_32\qml目录下就会有material,拷贝material到Qt for Window目录下D:\Qt\Qt5.4.0\5.4\msvc2013_opengl\qml。我觉着ubuntu下编译出来的material应该也可以直接拷贝过来用。


在能编译命令行钱包的基础上添加环境变量,设置vs使用的qt库目录
CMAKE_PREFIX_PATH D:\Qt\Qt5.3.0\5.3\msvc2013
添加编译轻钱包
INCLUDE_LIGHT_WALLET TRUE

这样就行了。
BTC:1EYwcZ9cYVj6C9LMLafdcjK9wicVMDV376

Offline cn-members

  • Sr. Member
  • ****
  • Posts: 365
    • View Profile
Build the window version by vs2013 is success.
But i try to build the android version by windows and looks like it can't be done.
I use the qt for android(windows) and need to build the boost by mingw, and the lib boost_context can't build on windows by mingw, any idea?


I think i figure out how to build the boost_context, will try it later.

guide please? I never get to know how to use VS, but certainly I want to build the Windows version. Thanks
BTS中文区发言人公共账号,帮助社区有效沟通与交流。
Chinese Community Spokesman Account,to help the effective communication between Chinese and other members of the community.We're not translators to do regular translations , but will help with vital ones as we see fit and available at that time.

Offline cgafeng

Build the window version by vs2013 is success.
But i try to build the android version by windows and looks like it can't be done.
I use the qt for android(windows) and need to build the boost by mingw, and the lib boost_context can't build on windows by mingw, any idea?


I think i figure out how to build the boost_context, will try it later.
« Last Edit: February 02, 2015, 07:06:26 am by cgafeng »
BTC:1EYwcZ9cYVj6C9LMLafdcjK9wicVMDV376

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
By the way, I am pretty sure I have heard this bug discussed before, but I'll mention it here since it happened while interacting with the light wallet.

I used the full client's wallet_transfer_to_address  command to transfer 10 DVS from my arhag account to the active key of my arhag-light account (DVS6AryKFGdYZRJmmT2HaSZcRcuv1Q6VvQjbWgfnGodWrUqriM8Uz). I received the 10 DVS in my arhag-light account within the light wallet.  I then used the light wallet to send 8 DVS back to arhag (which reduced my arhag-light balance to 0 since 1 DVS was the transaction fee and 1 DVS was sent as a fee to Nathan's light wallet server).

Both transactions were noted by the light wallet and the full client. However:
  • The light wallet was not able to identify the sender (arhag) or the memo I provided in the transaction that paid arhag-light 10 DVS.
  • As currently expected, the transaction sending 10 DVS to arhag-light was sent to UNKNOWN from the perspective of the full client (since I used wallet_transfer_to_address).
  • The full client thinks the transaction sending 8 DVS from arhag-light to arhag is a transaction in which arhag sent 8 DVS to arhag-light! As a result it mistakenly deducts 9 DVS from the balance column (as reported by "wallet_account_transaction history arhag") when it should instead add 8 DVS. What is even more bizarre is that in the GUI wallet, not only does it do the same reversal mistake, but it then reports that the balance after that transaction is -1.00 DVS! However, if I do the math manually based on what I remember of my transactions, the actual balance reported both in the summary balance for my account within the GUI and through the wallet_account_balance command are correct.

A portion of the output of "wallet_account_transaction_history arhag" from the full client:
Code: [Select]
TIMESTAMP           BLOCK     FROM                TO                  AMOUNT                  MEMO                                        BALANCE                 FEE                 ID     
==============================================================================================================================================================================================
...
2015-01-24T23:57:20 155748    arhag               UNKNOWN             100.00000 DVS           To: DVS2AgMj...                             (X)          DVS        1.00000 DVS         0162871b
2015-02-01T06:36:02 213806    arhag               UNKNOWN             10.00000 DVS            test                                        (X - 11)     DVS        1.00000 DVS         a95dc4a1
2015-02-01T06:39:00 213823    arhag               arhag-light         8.00000 DVS             testing                                     (X - 11 - 9) DVS        1.00000 DVS         cf9aa5c6
Obviously, I have modified the balance fields for the tiniest bit of privacy from lazy people (if you really want to know the value of X, you can get it from the blockchain with a little bit of work), but you should get the idea of what is going on from the mathematical expressions.

The transaction history has another problem as well. The value of X as reported by the transaction history is 1 DVS larger than it should be. This discrepancy can be noticed by comparing the account balance, which reports the correct (X - 11 + 7) DVS, to the account balance I would calculate if I were to simply correct transaction cf9aa5c6 in the transaction history, which would give me an account balance of (X - 11 + 8 ). The reason for this discrepancy is because the transaction history is missing my one (and only) vote_all transaction which cost me a 1 DVS fee. It used to be there, but somehow during this process (I upgraded clients a lot) it lost it.
« Last Edit: February 01, 2015, 11:40:07 pm by arhag »

Offline clayop

  • Hero Member
  • *****
  • Posts: 2033
    • View Profile
    • Bitshares Korea
  • BitShares: clayop
For the windows users, I'm hoping to get my hands on a windows dev box tomorrow, so hopefully I'll get something together for you. Thanks for being patient!

Looking forward to it. Thanks!
Bitshares Korea - http://www.bitshares.kr
Vote for me and see Korean Bitshares community grows
delegate-clayop

Offline modprobe

@fluxer: I agree with you, and I'd like to see such solutions deployed. The issues aren't insurmountable, but they need consideration, and I welcome new ideas on how to solve them (why waste time implementing one bad solution if someone else can think of a better one?). Right now I'm the only one running a light server because it's under heavy development (you think delegates have to upgrade a lot? Ha!) and I need to be able to debug and redeploy rapidly. Once I've got a relatively stable solution (which is, of course, the point of this beta -- to figure out what needs to be changed to sustain a reliable solution) then I'll be looking into multi-server models. Eventually, I'll make it configurable.

Still, the model of paying a centralized party to provide immediate, accurate information is a reasonable one, particularly when I deploy mobile apps where all matters of internet traffic are much more expensive (in time and money).

@cn-members: Thank you very much for taking the time to detail out those instructions. I'll add those to a README on GitHub soon.

@arhag: I'm glad you got it working! Yes, I do develop against 5.4. I think 5.3 would work, but you'll have to turn back the version numbers in the import statements until it works, and doing that might break something which depends on the later version. I haven't researched exactly when all the features I need were added, so I just use the latest version available at the time of writing.


Is anyone else still having trouble building? For the rest of you, do you have any comments or problems you've experienced?

For the windows users, I'm hoping to get my hands on a windows dev box tomorrow, so hopefully I'll get something together for you. Thanks for being patient!

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Nice job on those build instructions cn-members. I'll post my (slightly different) guide on how to build the light wallet (as well as the CLI client, web wallet, and Qt client) on Ubuntu 14.04 x64. This guide can be used if you want to install Qt directly from its creators rather than relying on a PPA. Please note that I haven't actually tried these exact instructions on a fresh install, but they were reconstructed from memory based on various things I tried. So, let me know if it actually works for you.

Initial setup stage:
0) Set up a working directory in which everything will be done and install all pre-requisites from repositories:
Code: [Select]
~$ mkdir BitShares && cd BitShares
~/BitShares$ sudo apt-get install cmake git libreadline-dev uuid-dev g++ libdb++-dev libdb-dev zip libssl-dev openssl build-essential python-dev autotools-dev libicu-dev libbz2-dev libboost-dev libboost-all-dev npm nodejs-legacy
~/BitShares$ sudo npm install -g lineman

1) Install Qt 5.4:
Code: [Select]
~/BitShares$ wget http://download.qt-project.org/official_releases/qt/5.4/5.4.0/qt-opensource-linux-x64-5.4.0.run
~/BitShares$ sha256sum qt-opensource-linux-x64-5.4.0.run
Verify that the SHA-256 hash of the executable is correct by comparing to the hash listed here. Although, the website's current SSL security practices are pretty disappointing.   
Then run the installer to install Qt 5.4 in a system-wide location:
Code: [Select]
~/BitShares$ chmod +x qt-opensource-linux-x64-5.4.0.run
~/BitShares$ sudo ./qt-opensource-linux-x64-5.4.0.run
Then follow the GUI and install in "/opt/Qt5.4.0".

2) Install qml-extras and qml-material into the Qt5.4.0 folder:
Code: [Select]
~/BitShares$ git clone https://github.com/papyros/qml-extras.git
~/BitShares$ mkdir qml-extras-build && cd qml-extras-build
~/BitShares/qml-extras-build$ /opt/Qt5.4.0/5.4/gcc_64/bin/qmake ../qml-extras
~/BitShares/qml-extras-build$ make && make check
Make sure all the tests pass.
Code: [Select]
~/BitShares/qml-extras-build$ sudo make install
~/BitShares/qml-extras-build$ cd ..
~/BitShares$ git clone https://github.com/nathanhourt/qml-material.git
~/BitShares$ mkdir qml-material-build %% cd qml-material-build
~/BitShares/qml-material-build$ /opt/Qt5.4.0/5.4/gcc_64/bin/qmake ../qml-material
~/BitShares/qml-material-build$ make && make check
Make sure all the tests pass.
Code: [Select]
~/BitShares/qml-material-build$ sudo make install
~/BitShares/qml-material-build$ cd ..

3) Initial setup of DevShares:
Code: [Select]
~/BitShares$ rm -rf bitshares # Remove any prior bitshares folder
~/BitShares$ git clone https://github.com/BitShares/bitshares.git
~/BitShares$ cd bitshares
~/BitShares/bitshares$ git submodule init && git submodule update
~/BitShares/bitshares$ cd programs/web_wallet
~/BitSharesbitshares/programs/web_wallet$ npm install
~/BitSharesbitshares/programs/web_wallet$ cd ../../../


Building DevShares from scratch:
If this is the first time building DevShares, or you want to build an update of it from scratch, you must first do the following additional setup before compiling. If you think you can get away with a quick recompilation after some minor changes, skip to "Recompiling Devhares after minor changes".

4) Build from scratch:
Code: [Select]
~/BitShares$ cd bitshares
~/BitShares/bitshares$ git pull
~/BitShares/bitshares$ git checkout devshares
~/BitShares/bitshares$ git submodule update
~/BitShares/bitshares$ cd ..
~/BitShares$ rm -rf devshares-build  # Remove any prior devshares-build folder
~/BitShares$ mkdir devshares-build && cd devshares-build
~/BitShares/devshares-build$ cmake -DINCLUDE_QT_WALLET=ON -DINCLUDE_LIGHT_WALLET=ON -DCMAKE_PREFIX_PATH=/opt/Qt5.4.0/5.4/gcc_64/ ../bitshares/
~/BitShares/devshares-build$ make forcebuildweb
~/BitShares/devshares-build$ make
~/BitShares/devshares-build$ cd ..

The Qt client will be located in "~/BitShares/devshares-build/programs/qt_wallet/bin/DevShares". The light wallet will be located in "~/BitShares/devshares-build/programs/light_wallet/LightWallet". The CLI client will be located in "~/BitShares/devshares-build/programs/client/devshares_client". The CLI client can be run with the "--server" flag to run the backend of the web wallet (make sure to first set up the RPC parameters in the config.json file appropriately). The web wallet can be run from the "~/BitShares/bitshares/programs/web_wallet" folder using "npm start" and then accessed from the browser using http://localhost:8000/.


Recompiling DevShares after minor changes (assuming updating HEAD of same branch):
5) Get latest sources and recompile:
Code: [Select]
~/BitShares$ cd bitshares
~/BitShares/bitshares$ git pull && git checkout devshares && git submodule update && cd ../devshares-build
~/BitShares/devshares-build$ make forcebuildweb # Only needed if web_wallet code changed
~/BitShares/devshares-build$ make

If there are any problems from this quick recompilation procedure, then go back and do it properly with step 4, and if that has problems then go back to step 3.
« Last Edit: February 01, 2015, 10:38:29 pm by arhag »

Offline cn-members

  • Sr. Member
  • ****
  • Posts: 365
    • View Profile
Finally I get it worked on ubuntu 14.04:


this is how I did it:
1. Install qt5.4 from PPA
Code: [Select]
add-apt-repository ppa:beineri/opt-qt54-trusty
apt-get update
apt-get install qt54-meta-full

2. set variables
Code: [Select]
export QTDIR=/opt/qt54/
export PATH=$QTDIR/bin:$PATH   
export MANPATH=$QTDIR/man:$MANPATH   
export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH 

you can use:
Code: [Select]
qmake -vto check if the version is correct

3. build qml-extra & qml-material
Code: [Select]
git clone https://github.com/papyros/qml-extras
cd qml-extras
qmake
make
make check
sudo make install
cd ..

Code: [Select]
git clone https://github.com/nathanhourt/qml-material
cd qml-material
qmake
make
make check
sudo make install
cd ..

4. final thing: compile dvs-light wallet
Code: [Select]
git clone https://github.com/BitShares/bitshares
cd bitshares
git checkout devshares
git submodule init
git submodule update
cmake -DINCLUDE_LIGHT_WALLET=ON CMakeLists.txt
make

and the process is in
bitshares/programs/light_wallet/LightWallet
BTS中文区发言人公共账号,帮助社区有效沟通与交流。
Chinese Community Spokesman Account,to help the effective communication between Chinese and other members of the community.We're not translators to do regular translations , but will help with vital ones as we see fit and available at that time.

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
Hi, fluxer. Thanks for the thoughts. I would like to move to a multiple server model, but this does have some difficulties. One is performance (I've got to wait for N servers to respond instead of 1), and another is fragility (if I use 2 servers and they give different results... now what?) as well as ambiguity (If I query three servers and two never respond... now what?), as well as economics (each light server charges a fee for propagating transactions; if I have N lightservers, I have to pay N fees?). I haven't taken the time to come up with good answers to these questions, so the current version only supports one server. If we can come up with a good design, though, I'll be happy to implement a multiple server architecture.

As to the issue of delegates hosting servers, it's a great idea, but the light wallet has no way of knowing who the delegates are nor what they've published in their accounts. The light wallet would then need to trust a lightserver to give it accurate information about the delegates, which defeats the purpose.

My idea is to have a few initial 'seed' servers when you first download the client. There ideally should be more than 2, to avoid that problem you stated, as well as to be sufficiently distributed so to mitigate risk of server hacks / attacks. Once there is consensus of the initial seed servers as to who the delegates are and what their servers are, the delegates' servers are then added to the trusted servers list. From there, the data of the delegates' servers are compared against each other for authenticity, and any discrepancies can either be ignored if a very low percent (probably usually due to software malfunction rather than malicious intent), or if under a certain threshold can issue a warning to the user, much like the current system in the full client with the delegate participation rate. Since each delegate is paid (at the bare minimum) to run a server anyway, it should remain economical to have them set this up at no additional charge.

To address your points specifically,

One is performance (I've got to wait for N servers to respond instead of 1),

You might not need to wait for all servers to respond, as long as the number that do are above a threshold, and as long as you rotate through the servers you have (to not trust one source more than others). This is much much better than trusting a central entity that can be hacked or DDoS'd easily.

and another is fragility (if I use 2 servers and they give different results... now what?)

If you only have two results and they are different, you need more results, or you stop transactions. This would indicate that something is wrong, and the user should be glad their client checked more than once source before trusting the faulty one (whichever one that may be).

as well as ambiguity (If I query three servers and two never respond... now what?),

Related to answer above. You set a threshold, and if this threshold is not met, you either warn the user or stop transactions.

as well as economics (each light server charges a fee for propagating transactions; if I have N lightservers, I have to pay N fees?).

If delegates are hosting lightservers, then this problem is solved. You would just need a handful of 'seed' lightservers, which I suspect certain trusted patrons would run for free.

As to the issue of delegates hosting servers, it's a great idea, but the light wallet has no way of knowing who the delegates are nor what they've published in their accounts. The light wallet would then need to trust a lightserver to give it accurate information about the delegates, which defeats the purpose.

Answered in various ways throughout this post.


EDIT: Added "at no additional charge" to the end of my first paragraph to clarify.
« Last Edit: February 01, 2015, 02:39:12 pm by fluxer555 »