Tons of commits this week!
https://github.com/kenCode-de?tab=repositories BlockPay related: Man, BlockPay is getting a LOT of work done to it right now. The Settings screen, Thank You screen, Steem support, node hopping update, connectivity fixes, bandwidth utilization (fixed thanx to Alfredo, ElMato and Sigve), additional coin support from the Bridge, the Loyalty Points choices and display... anyway, you get the point.
We spent almost the entire week though getting the .bin file and brainkey (backups and imports) interoperable with the web wallet and light client wallets. This has not been easy as there were many differences that needed to be fixed and made to work with the mobile wallets and BlockPay. Anyway, the good news is that we just finished the bin and brainkey stuff late last night so it will be available in the BlockPay v1.5.6 release this week.
After some research, it was possible to identify the problem with the import feature at the decompression stage. After fixing an endianess incompatibility from the LZMA header fields and another problem with the correct slicing of the data, it was possible to sucessfully decompress the web wallet backup data from OpenLedger.
As it turns out, this data is stored as a JSON-formatted string, with the capability of storing multiple wallets. Some other classes were introduced in order to deserialize this JSON string into proper java objects and thus ease their manipulation.
Not all fields from this backup format were used though, especially the purpose of the "brainkey_pubkey" and "password_pubkey" were not completely clear. That didn't prevent the backup from being imported though. As similarly the lack of meaningful information from these fields in the backups created by the mobile app using the developed mechanism didn't prevent the file to be correctly processed and the account information loaded by the web wallet. Moreover the format used for the backup seems to be containing duplicated information and a few other apparent problems were detected with it. Some comments on these can be found in this forum thread:
https://bitsharestalk.org/index.php/topic,23798.0.html The work described above has now been completed and resides in the graphenej library for everyone to use, and thus is easily be incorporated into BlockPay, Smartcoins Wallet and all custom BlockPay Integrations. The commit that contains most of the work is:
https://github.com/kenCode-de/graphenej/commit/0b0d2516750de972ad10ad62247074b6d635dcac Also there was a nasty bug, introduced in one of the previous commits that made requests with indirect conversions (Like the ones from ETH to bitUSD for instance) to end up in an infinite loop. This was also solved in the commit above.
There was also the initial work of storing the market cap data into the local database instead of dynamically fetching it every time. This change however needs substantial code changes and since the cryptocurrencies already appear in a decreasing marketcap order, this improvement was not deemed of top priority as the others and was paused in order to finish other features and bug fixes like the ones described above.
BlockPay v1.5.6 will be released on google play this week so keep your eyes peeled!
C-IPFS related: This week we worked on many facets of C-IPFS and its connectivity with other nodes. Here's a rundown of the commits:
multiaddress:
We haven't touched that code in a long time, as we didn't need it until now. It needed cleanup and debugging.
https://github.com/kenCode-de/c-multiaddr/commit/d57e026fbf889e436a9b6f9bf6844725d0e642eb https://github.com/kenCode-de/c-multiaddr/commit/78ce39b0670493c47f22ae3e5c0de7094e7c1755 https://github.com/kenCode-de/c-multiaddr/commit/bb488f7e820d650c1606aaccbe5e92eb02bec32b https://github.com/kenCode-de/c-multiaddr/commit/cc8ff45cc13220b7c8897d3eb9f1cb161fd0ff25 https://github.com/kenCode-de/c-multiaddr/commit/9a9c5ea1c324e2aaeaba06fc17f47e929e550d71 https://github.com/kenCode-de/c-multiaddr/commit/29a68c8f557daef6dffe1b5cd00d9f292f1a03a2 https://github.com/kenCode-de/c-multiaddr/commit/f2d1a5aa83a7cdabf35b80c5a3dcd9d56970c2af libp2p:
Many things were touched as we approach the connectivity and file transfer pieces of C-IPFS. In order to be compatible with the GO version, and so as to not implement something that will be thrown away, we decided to move ahead with our implementation of Kademlia and DHT. Once completely implemented, this will allow for communication between hosts, and fulfill requests, even with the Go-IPFS implementation.
To get there, we need "dialers" that are intelligent about how to connect, as well as hide complexity from higher levels. We now have the beginnings of one of these dialers:
https://github.com/kenCode-de/c-libp2p/commit/466bfe3fa46b80a7343ed44e9b1f1213dcd5665f https://github.com/kenCode-de/c-libp2p/commit/81263fc1a2a9d0bcf081bcbe20f55af96cb92780 https://github.com/kenCode-de/c-libp2p/commit/5c08094548228f333edab77349390f38476cfc37 https://github.com/kenCode-de/c-libp2p/commit/ccc7ca3e8b2513d2de6c8bf8a667ea9413579e2d In addition, the Kademlia and DHT stuff needed to communicate using protobufs, so, this week we coded protobufs for records, peers, and messages:
https://github.com/kenCode-de/c-libp2p/commit/c29c5744b88f565eedb48bea1ad42eb011f80d4c https://github.com/kenCode-de/c-libp2p/commit/3aa0d89cb33c951a6d1132af1dfd450586867695 https://github.com/kenCode-de/c-libp2p/commit/897d257b3beae00319d7f1d048cec4b88d39b1ea https://github.com/kenCode-de/c-libp2p/commit/d985919f412ae4d06efbd7b71db377e68c9b8763 https://github.com/kenCode-de/c-libp2p/commit/28961aa592f72232004c95a4d2f15aaef3b67c15 https://github.com/kenCode-de/c-libp2p/commit/029e3d800f36f1c4476b0e1d26429069329947e1 https://github.com/kenCode-de/c-libp2p/commit/0a8f4767deb731937115481af8846fec0c918d82 DHT related commits this week:
https://github.com/kenCode-de/c-ipfs/commit/4cd4750f6fed6683771aef6883ac05136ca2bf17 https://github.com/kenCode-de/c-ipfs/commit/fbd862431c3b2b3832c55176f14c3698c7cdd5ac https://github.com/kenCode-de/c-libp2p/commit/35a9b4b73efd0ef62f3dc48254064843bc22ed1b Kademlia DHT work should be finished by this Sunday, then we just have to finish swarm support, then I will feel comfortable enough to release C-IPFS v1.0.0 and BlockPay 2.0 can begin, along with with the new Smartcoins Wallet 2.0 (codename: Carbon).
Android Smartcoins Wallet: Fixed a few little crashes that were happening, totally redesigned the way PIN numbers are handled (so they don't annoy the user so much), fixed the way fiat equivalent values appear and are calculated, fixed the scrolling issue on transactions. Lots of little UI fixes here and there too.
We are also adding support for WIF Key importing. Work on that began yesterday, and will be included in the v1.5.9 release on google play this week.
As you might already be aware, we are adding native support for the Bitcoin, Litecoin, Dash, Doge and Steem chains right now. We are creating a special library too (that can be ported to our web wallets and light client wallets) called multicoinsj that facilitates the common code for the BTC, LTC, Dash and Doge chains. That lib will be ready and open sourced of course in about 6 weeks on my github page.
Work done this week:
- Testing our Bitcoin full node server on our testnet
- Added api communication: GetTransactionByAddress, and Gettransactiondata
- Updated GIOTx info, change internal logic
- Update generalcoinAccount: added a way to get addresses
- Change the database to adapt to the new changes
- Using Retrofit and Gson for parsing and database names changes
- Added getter, put and modifier for GeneralCoinAddress, GeneratlTransasction, GIOTx
- Added GAP to the address calculated by the GeneralCoinAccount
- Added AccountWatcher to use Socket.Io for getting the new transaction event, this will save network and battery usage.
- Added Bitcoin balance in BalanceFragment
- Added Bitcoin transfer history to BalanceFragment
- Fixed some minor errors in updating the BalanceItems to evaluate the amounts received
This week we will tie in our EquivalentValue function too so that you can easily see what the fiat value is for any of the assets you hold (including BTC and altcoins).
The tasks for next week are:
- Follow a BTC Transaction
- Fixing the values on the historical info displayed
- Sending a Transaction
- Generate a QR Code
- Scanning a QR Code
If time allows, I'd also like to:
- Add support for Bitcoin and altcoin Contacts on the Contacts screen
- Add new Contact
- Share a Bitcoin or altcoin Contact
- Import existing Bitcoin and altcoin contacts
So, if things keep going the way they are right now, we should have Bitcoin support in the Smartcoins Wallet ready in the next week or so and this includes sending, receiving, backups, imports, Contacts and consulting balances. Then, it's on to the other 4 chains next..
Stealth related: Stealth will be unbeatable. There is really nothing else on Earth that can compare to this kind of privacy. This week we ran some more gadget tests, debugging of snark gadgets and fixed errors in input note gadgets as can be seen in this commit:
https://github.com/kenCode-de/graphene/commit/993460c819512d90e86cc2b0f48cf01727a8fdad Additional debugging of snark gadgets and fixed errors in output note gadgets too:
https://github.com/kenCode-de/graphene/commit/c157491f0f6f7f50d07feb719fc46b4571162de4 Lots of work on the cryptography this week. We found what appears to be 2 serious errors (including one that might reside in the zcash code). It's an inaccuracy in the restrictions format that allows you to use incorrect proofs, but I'm not sure it is really an error in their code, so just need a couple more days to investigate that further to be sure. The last error that we're debugging now is similar, checking proofs on the verifying side gives an error in some cases. We've added unit tests for it, the last test is failing right now, in the stealth_test.cpp file.
"faerie_gold" has been tested, and secured. It's one of the attacks that was investigated in 2015.
"r1cs" for those who are wondering, stands for "restrictions of the first order". It's the way we format restrictions for use in our libsnark library.
I have been asked what "gadgets" are. Gadgets are the classes that format restrictions for our libsnark lib. We have different restrictions for our transactions (for example inputs = outputs + fees, etc). Using different libsnark gadgets, we format these conditions in a special binary form, and create libsnark proofs for these conditions. They're almost like a special programming language for our objects.
The other serious error that we found was an error in the gadgets construction, for input notes and output notes. We should have this one fixed by mid next week too. We are having to rewrite quite a bit of the zcash implementation for bitshares-core (although to be fair they saved us a lot of time too, so Thank You zcash team).
We are also converting a lot of Rust code into C++ for direct use within bitshares-core (graphene) which will give us the best possible solution in our DPOS environment for our "trustless" setup algo.
This coming week, many more commits on github, algo creation time and testing, and initial steps towards an open source api as well for use in our other graphene based projects and products.
Alfredo Garcia, Bitshares Core Dev update: Alfredo is an animal! Multiple Pull Requests, commits and Issue contributions this week. Oh, remember the websocket "spamming too much data" Issue #231? Fixed! That was an Issue that even bytemaster admitted was high priority. Special shout out to ElMato and Sigve for helping us to fix and test this one too!
Also...
Replicated and fixed the "Uninstall light client does not remove 'personal info'" issue:
https://github.com/bitshares/bitshares-core/issues/227 (i closed it already)
PR:
https://github.com/bitshares/bitshares-ui/pull/82 - merged
Finishing the "spamming" issue:
https://github.com/bitshares/bitshares-core/issues/231ElMato is helping us to test this one with his use case and we should be able to close this one by Monday.
Testing the "No spam sub function" with ElMato's branch, with Sigve's changes and Alfredo's commit to make a new pull request here:
https://github.com/bitshares/bitshares-core/pull/234Graphene issues up next for this week:
"Don't print private keys in log on witness startup"
https://github.com/bitshares/bitshares-core/issues/93 "api call to obtain an account's trad history for a specific asset-pair"
https://github.com/bitshares/bitshares-core/issues/222 Also looking in to Witness node memory leaks and some minor bugs, and if time allows looking in to "multiple transfer ops in single transaction".
As always, I will post our updates to my github page and keep you guys in the loop here as much as I can. Please keep an eye on google play too since I will have a couple more Releases for you guys this week!
Show Posts
