Author Topic: [ANN] BlockPay -Your favorite store can now accept any crypto thanx to Bitshares  (Read 99737 times)

0 Members and 1 Guest are viewing this topic.

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline kani

  • Full Member
  • ***
  • Posts: 56
    • View Profile
My opinions are my own

Turn up the H.E.A.T.

iHashFury

  • Guest

Offline Thom

No, it's two different use cases and UI's entirely. Echo will use all of the core components that we have been building, but also include voice, video, chat and things that the Smartcoins Wallet just doesn't need.

Got it.  In any event, cosmos is already a blockchain project and you probably don't want that confusion.  How about calling it Jupiter?

I like the name "Nebula", as in sprawling, or scattered over a broad area (not my idea BTW).
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline tbone

  • Hero Member
  • *****
  • Posts: 632
    • View Profile
  • BitShares: tbone2
No, it's two different use cases and UI's entirely. Echo will use all of the core components that we have been building, but also include voice, video, chat and things that the Smartcoins Wallet just doesn't need.

Got it.  In any event, cosmos is already a blockchain project and you probably don't want that confusion.  How about calling it Jupiter?   

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
No, it's two different use cases and UI's entirely. Echo will use all of the core components that we have been building, but also include voice, video, chat and things that the Smartcoins Wallet just doesn't need.
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline tbone

  • Hero Member
  • *****
  • Posts: 632
    • View Profile
  • BitShares: tbone2
hey @kenCode, I thought your plan was to combine all of the Smartcoins wallet functionality into Echo once you have the messaging piece worked out.  If that's the case, why not rename the SmartCoins wallet EchoPay and then later combine it with EchoChat?   To refine it further, maybe the app itself is called Echo, and EchoPay is the first feature, while EchoChat will be the next feature.

Just some ideas.



Offline 天籁

  • Hero Member
  • *****
  • Posts: 744
    • View Profile
« Last Edit: January 22, 2017, 02:06:05 am by 天籁 »

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
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..

call it cosmos

Actually, that's not bad.
Once we have a few more suggestions, I will tally up the votes and get the new app icon designed for it too.
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline fav

  • Hero Member
  • *****
  • Posts: 4278
  • No Pain, No Gain
    • View Profile
    • Follow Me!
  • BitShares: fav

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
Tons of updates this week!
https://github.com/kenCode-de?tab=repositories
 
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 @ElMato (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:
Code: [Select]
> {"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.
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
Tons of updates this week!
https://github.com/kenCode-de?tab=repositories
 
C-IPFS and BlockPay related:

On C-IPFS, need to fix the windows resolver, gcc for windows doesn't have libresolv. Next week we'll work on c-libp2p-peer and c-ipfs-routing, so we can finish up namesys/publisher and can launch the final Release. C-IPNS can resolve names, but not publish yet.
 
We got the first debug apk of BlockPay v1.5.0 packaged up yesterday, so final bug checking over this coming week before I launch it on gplay.

We should also have the fist formal Release of C-IPFS ready for public download by end of next week.
 
Android Smartcoins Wallet and security audits:

Smartcoins Wallet
An efficiency problem has been detected in the smartcoins wallet by analyzing the mechanism by which the app gets notified of account balance updates. It turns out the 'set_subscribe_callback' API call will get us subscribed to a feed of information that notifies us of many more events than we are asking for. Worst of all, is that these notifications do not stop when the user leaves the app, instead just keeps on running in the background consuming both network traffic and battery.

There seemed to be a mechanism in place to try to stop this notifications, but it wasn't working every time. Instead of trying to debug the existing code, we actually decided to perform call to the 'cancel_all_subscriptions' at the onPause life cycle callback of every activity of the app. This is not the best possible solution to the problem, because you still get a unsubscribe-subscribe pair of messages sent on every activity transition, but since the focus of this week was blockpay and considering that any other "better" solution could end up leaving situations where the feed is not canceled after the user leaves the app, it was decided to opt (for now) for the most simple but secure fix. So, after the BlockPay v1.5.0 launch next week, we will revisit this one and tighten the network usage down even more.

BlockPay
The same classes previously developed for smartcoins wallet and included in our graphenej lib that made possible to remove the dependency on the server components at the QR-code creation step when dealing with smartcoins. For bitcoin we still need to fetch the QR-code data from the bridge, which in this case is the blocktrades API. This work can be found at this commit bc2415bcb60aa09b50dad8f1e5877a55b67f1574.

Different methods have been tried in order to obtain an accurate exchange rate between smartcoins, but the one that finally worked best both in terms of speed and exchange data accuracy was to take the data from the witness feeds. With the conversion rate in place, it was possible to replace the calls that made the same thing to the shared components and create the same output classes in order to "fill the void" left by the removal of the server components.

In order to be able to display a list of smartcoins, the raw list of assets obtained from the witness had to be filtered. Telling a UIA from the rest is easy, since they lack a field (bitasset_data_id) that both smartcoins and prediction market tokens have. Now in order to be able to tell these two apart, a 'get_objects' API call had to be performed on each of the id's indicated by the 'bitasset_data_id' field. In the response object, the 'is_prediction_market' field was used in order to verify the specific class of a given witness-fed asset. With this in place it was possible to present the user with a list of only smartcoins. This processing was previously also being done in the server side by the server components, but the overhead of doing it in the mobile device is not so much since we just require 2 API calls and everything is stored locally for future use. The added support for the 'get_objects' API call has also been included in our new graphenej library. This work can be found at commit 01b8a6187bd83392cb4c99a0c4e37436f152afb5

The mechanism by which balance updates were being handled was broken, a new scheme of BalanceListener and BalanceNotifier was built using the existing infrastructure that receives the network notification feed. The app is now reacting to incoming transactions while in the activity displaying the QR-code to the user. And the same efficiency problem that was present in the smartcoins wallet was also affecting the blockpay app. But it was fixed as well. This work can be found in the following commit: d7a552bfcf7b6597251ce52e126ffc72e4a66299.

The marketcap data, that was previously obtained from the server components is now retrieved directly from the 3rd party API, we still need to use this response though.
 
Ideal situation here is that BlockPay will no longer rely on any third party api's whatsoever, and once 2.0 is built and launched, our apps won't even need to rely on http, ssl or dns anymore either, furthering the app security and endurance even further.
 
Stealth related:
 
Many improvements done to our new "trustless setup" algorithm, no viewable code on github yet, algorithm development only. Incremental merkle tree implementation and tests, https://github.com/kenCode-de/graphene/commit/c1b1d2c6e3a1d9a53efb53e277f4296cd274a7d8
 
Once I feel comfortable with the new algo, then we can resume the work on the UI and connect it to our graphene coding.
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
Still got a waterfall coming out of my nose and a massive headache, so I will briefly try to post some of last weeks progress:
 
C-IPFS and BlockPay related:
https://github.com/kenCode-de/c-ipfs/commit/9882c28743f8d1669e966afddfcbeb628d948c54
https://github.com/kenCode-de/c-ipfs/commit/61d0adc445445a7fbe689203915a544d7b695756
https://github.com/kenCode-de/c-ipfs/commit/4c330e29bef529f5de854b3ee54506d6253e82aa
https://github.com/kenCode-de/c-ipfs/commit/6448a35a72ee87a5f137d6f0b0e1030b357233b7
https://github.com/kenCode-de/c-ipfs/commit/3c3474eacd859cacc1050e6474500e23fc954f78
The upgrade of BlockPay to v1.5.0 (with graphenej) should be done, tested and posted to google play by friday the 20th.
 
Android Smartcoins Wallet and security audits:
The wallet is on google play (v1.5.7), but I still need to add some more UI tweaks to the transactions list, the way dates and equivvalue are displayed, etc. Those little things should all be done in a week or so and then a v1.5.8 will be published to google play.
 
Stealth related:
Finishing the "trustless" setup algo now so that Stealth Core is complete and we can resume work on the UI.
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat