C-IPFS and BlockPay related: We are just finishing up the c-libp2p and c-ipfs-routing components this week (eliminating reliance on http, ssl and dns is no easy task) and will have the first formal Release of C-IPFS for Linux and Mac published here by friday, january 27th:
https://github.com/kenCode-de/c-ipfs/releases So, with Storage and Routing completed and the first formal public Release of C-IPFS by end of next week, we can finally begin on the "2.0" architecture for BlockPay 2.0 as well as the Smartcoins Wallet 2.0 by end of next week. The mobile wallet will get a new brand too, still tossing around different name ideas... Smarty, Cirrus, Toke, Chainz, ..if you have ideas for the rebranding of Smartcoins Wallet, let me know. It will support 7 different chains and their tokens/assets. It also has a new material design, better UI/UX. Anyway, let me know..
Routing commits:
https://github.com/kenCode-de/c-ipfs/commit/7d3418e9c715e70d86c81452639a5ef239a22f31 https://github.com/kenCode-de/c-libp2p/commit/3b301f823ad3993d25d92fdd3905bdb9b2409487 https://github.com/kenCode-de/c-libp2p/commit/e3fc5f640953ef23eb28ccffd086c05e2e7947c2 Since all of the Core components for 2.0 are near completion now, the upgrade procedure will not be that difficult, since the other libraries have already been published for you as well (like graphenej). Wallets developers should love that lib, it makes it insanely easy to make many different types of graphene-connected mobile wallets now for iOS, Android, Windows Phones, etc. I would love to see Jaxx add support for the Graphene chain now.....
Android Smartcoins Wallet and security audits: Security audits have been completed and incorporated into our new graphenej library:
https://github.com/kenCode-de/graphenej Smartcoins Wallet has been upgraded to the new architecture and has been published to google play. Lots of UI fixes (especially in the Transactions and Balances display) to come this week and will be published by end of next week as well.
During this process, we are also upgrading the architecture of BlockPay so that it runs a hell of a lot faster and stronger too. I have a debug apk you can play with if you like, but only bitUSD has been done so far. In the next few days I will publish it to google play once we have all the smartcoins working with this new lib (with direct DEx support in graphenej).
Upgrading the architecture of BlockPay to graphenej:
A huge waste of user's data transfer and battery usage was detected and fixed. This happened because even after the user leaves the app, the android system keeps its process running and its activities and resources are not automatically discarded, but instead kept around as the user might come back. The websocket connection to the witness node in this case was left open and receiving large amounts of data. This is also an issue that affected the Smartcoins Wallet so we fixed that as well.
Another outstanding issue with both apps is that once subscribed to events from the witness node, all sorts of events get broadcasted, essentially spamming the apps with unwanted notifications. This is is why this fix however important, is not reducing all the unused data transfer, just the unused data transfer that used to take place after the user left the app. Since apps can keep running in background for an unlimited amount of time, this was an important reduction of something that otherwise might have turned into an unbounded amount of traffic.
Of course this is not fixing the remaining issue yet with the unwanted notifications while the user is actively using the app, something that might be even more pronounced in the Smartcoins Wallet, since it might be consuming the limited 3G data transfer quota of the user. But in order to fully solve this problem, a modification in the witness code is required (it was not fully fixed in this old Issue:
https://github.com/cryptonomex/graphene/issues/540).
Some of the relevant work for this
Witness code update can be found at this commit: 3b081c428ec406de46e0f568484d8afeb91dd4d3
A new table called "balances" is used to keep track of the user's balances for every asset. The table is also dynamically updated from the notifications received via the websocket connection. Commit: 2f63eeb1d4b2cc417d1e81bfe00ba9cf6f90cdc7
The assets table has been updated in order to also track the information about the number of holders that each asset has. This is then used to filter the list of UIA and smartcoins, which was featuring a veeeery long list, including many inactive assets. The holders information is obtained from the cryptofresh API, but we now plan to request it directly from the witness node (commit: 5cd0c65d676274b51a88c37001700c8bbb6a5942) so that our software ultimately no longer relies on third parties.
A new table called "bridge_rates" is now used to keep track of not only the transfer rates between any two cryptos that the Bridge offers support for, but also the supported trading pairs. Commit: 706231122c0d2f0fba0938db20e0b8c40913962d
Aditional support for smartcoins and bitcoin input has been extended to all other cryptos supported by the bridge. The conversions can then be classified into 3 distinct categories:
- Bitshares assets (no need for a Bridge)
- Bridge-supported using a single conversion
- Bridge-supported using a 2-step conversion
Up till last week, we already had support for conversions 1 and 2. The third case is required because for some cryptocurrencies, there are no direct trading pairs with the user's desired smartcoin. For these cases, which amount to the large majority of pairs, we need to ask for an initial conversion to BTS, and only then convert that BTS into the desired smartcoin.
The ideal solution would be to just use the DEx for this second conversion, but since the graphenej library is currently lacking support for trade operations, we decided to just use the bridge a second time for now. In the short term however, the direct DEx support will be a priority. This work can be mostly found here: 66125491fb2eec6fb2df337666f8735b07512198
After a conversion has been initiated, the expected balance change is calculated and the app signals the success of the transaction only after the desired balance change has been detected. This verification was not being done before and thus it was very easy to scam the merchant by sending any amount of BTS. This has been fixed here: ec8e2d681ed3eeda4d481e68d07a39f6160fa347
A number of other bug fixes and small improvements have also been performed on the apps. An outstanding issue was also detected with the bitEUR conversion. Since the Blocktrades bridge doesn't support direct trading between BTS and bitEUR, the 2-step conversion strategy described above is not enough to obtain bitEUR. So for now the app is not supporting bitEUR as a final smartcoin because of this bridge limitation. This is another important reason to add the direct DEx support this coming week.
Stealth related: Regarding our new "trustless" setup algo, the original zcash multiparty trust setup was written in Rust. So, we are converting the Rust to C++ for direct graphene integration. The core functionality of this algo will be done in just a few more days, and then the interfaces and objects can be finished up this coming week for all of the UI connections. I also want this packaged up so that other graphene-based wallets can easily take advantage of Stealth, so modularity has been a high priority.
Automated Stealth transaction backups to c-ipfs can be started by end of next week too since the first formal Release of c-ipfs will be published then:
https://github.com/kenCode-de/c-ipfs/releases Additional work being performed:
Code cleanup, join split implementation, verification, proofs, libsnark integration, commits:
https://github.com/kenCode-de/graphene/commit/849c808ebabebd388641daf8abf75d7b37b78355 https://github.com/kenCode-de/graphene/commit/0983477201821f3856871e09202eb9f8130f4d5c https://github.com/kenCode-de/graphene/commit/0e70a69c87364107fb51818fb716fc00565097c5 Graphene-UI work can now resume on friday, january 27th so that Stealth actually looks nice too. A simple, logical UI/UX for this is imperative.
Alfredo Garcia, Bitshares Core Dev update: As I stated in the Worker Proposal, I will be posting updates on his work here each week too.
He is voted in now and his 6-month job technically starts on Monday, January 23rd.
I already got him rolling though on "get_asset_holders_count" and "get_all_assets_holder_count". This is a bolt-on for [member=7312]ElMato[/member] (Matias') asset api. It takes as parameter an asset id just as "get_asset_holders" original function created by him but it returns just an integer with the number of asset holders.
So, using it with wscat:
> {"id":1, "method":"call", "params":[2,"get_asset_holders_count",["1.3.0"]]}
< {"id":1,"result":0}
> {"id":1, "method":"call", "params":[2,"get_asset_holders_count",["1.3.0"]]}
< {"id":1,"result":1}
> {"id":1, "method":"call", "params":[2,"get_asset_holders_count",["1.3.0"]]}
< {"id":1,"result":2}
The first call returns 0 and there was no user created in the node, we had an additional window running with the client wallet. The second call is with user nathan created as the cookbook (
https://github.com/cryptonomex/graphene/wiki/CLI-Wallet-Cookbook) returns 1. The third call is with user nathan and following the cookbook there is an additional user called "my-account" where we transfer some of the nathan funds. This call returns 2. Nice and clean, minimal bytes transmitted.
By the way, the 7 chains that the mobile wallet will support will require me to add one more expert, so I'm getting him up to speed this week too. Our 2.0 apps are gonna seriously kick ass.
