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

0 Members and 1 Guest are viewing this topic.

Offline lil_jay890

  • Hero Member
  • *****
  • Posts: 1197
    • View Profile
Ken, thank you for the updates.  What portion of time are you dedicating to the the wallet improvements vs stealth? I think the vast majority of your investors are more interested in stealth than in any other aspect of blockpay.

Maybe I am to only one, but most of the details you post in the updates fly over my head. I'm guessing that's the case for most investors as well.  What I would really like to know is an ETA on stealth, and if that ETA is more than a few months out, what can be done to expedite it.  Unless there is a pressing need to update the wallet in order to integrate stealth, I believe most resources should be dedicated to releasing stealth as soon as possible.

Also, I think investors should be updated on the business development side.  What happened with the coffee shop and large electronics company?  What about oodoo?

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
Any teaser pictures or more details on the transaction flow of stealth?

Nope, not yet. The screenshots that I posted in this thread are the only UI elements that you can look at right now, but until we get the Stealth api finished (see my most recent weekly update above) we cannot connect any more of the ui to the core. I don't want to waste any manhours on UI work that cannot be tested yet.
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline Brekyrself

  • Hero Member
  • *****
  • Posts: 512
    • View Profile
Any teaser pictures or more details on the transaction flow of stealth?

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
Smartcoins Wallet v1.5.10 released. This version includes UI fixes, tighter integration with the new graphenej library, some crash fixes, and better performance.
Known issues: You can receive UIA's, but not send them out yet. Will have that fixed in the next few days and release that in v1.5.11. I still have to clean up the eReceipts layout, and make the Transactions display work in real-time again. As always, never keep more funds in a wallet than you can afford to lose.
https://play.google.com/store/apps/details?id=de.bitsharesmunich.smartcoinswallet
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
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/231
ElMato 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/234

Graphene 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!
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline Brekyrself

  • Hero Member
  • *****
  • Posts: 512
    • View Profile
Keep up the great work.  I always look forward to Friday's updates!

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
BlockPay v1.5.5 released. Today we started cleaning up the Settings screen, making UI tweaks, and more UI tweaks to come early next week. Some crashes have been reported too so we are addressing those in this release and the last of them by early next week in the v1.5.6 release.
https://play.google.com/store/apps/details?id=de.bitsharesmunich.blockpay
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
 
BlockPay related:
 
This week's work was mainly focused on adding support for a wider range of currencies as input values. To be able to do this without relying on a 3rd party API it was required to ask the bitshares network about the witness-provided data regarding real-world currencies. The input currency support is consequently limited to those currencies that do have a smartcoin counterpart. The list now includes 14 currencies.
 
A lot of work has been invested in improving the handling of the conversions and making sure no unneeded exchange rate requests were being performed.
 
The currency and country selection have been decoupled from each other. This required both visible UI changes, and adjustments in the code behind the scenes. For the UI part we now have a separate spinner displaying the list of supported currencies displaying currency name, currency symbol and a small country flag.
 
It is now also possible to mark the "None" option when selecting the desired UIA for Loyalty Points. When this happens, the Loyalty Points "ratio" section gets deactivated. This feature has not yet been included in the latest release, but it is already published in the repo and we will probably release this on the app store this weekend.
 
Some minor UI adjustments like specifying the correct length of the PIN number and shading pending app features have been completed. At first the app used 6 digit PIN numbers, then we switched to 8, now the app supports 6-unlimited digits for added security.
 
Work regarding the storage of market cap data in the local database was also initiated. This will enable us not only to store this data in a proper way by taking advantage of the relational database, but bandwidth utilization will also be lowered since we'll be requiring less frequent updates.
 
C-IPFS related:
 
This week, we attempted to add the connectivity encryption to C-IPFS. It did not go as well as we had hoped.
 
We implemented the handshake, and the GO version (go-ipfs) is sending their side of the negotiation, but it is not listening to our response yet. We believe it is something small, but have yet to figure out what it is. So the goal today is to get two C versions to talk to each other.
 
Ephemeral encryption implemented:
https://github.com/kenCode-de/c-libp2p/commit/783855fe26a07c61a3ddab9b4fb3ad2b2db557f2
https://github.com/kenCode-de/c-libp2p/commit/f9ba2f6c0f5dbb878053bfa018a9f17098ea27df
https://github.com/kenCode-de/c-libp2p/commit/030b2b197d113ce1ea101d990ad625fb30206b82
 
Encryption negotiation:
https://github.com/kenCode-de/c-libp2p/commit/e1a29128b686c707d2e2bd0024a7895ae7554fe5
https://github.com/kenCode-de/c-libp2p/commit/be9f278ebf8a83e378d7aa3af0ce1077a866c19c
https://github.com/kenCode-de/c-libp2p/commit/773c980f1f1127d005a03d8eebf73d03bdca53c2
 
Testing and cleanup:
https://github.com/kenCode-de/c-libp2p/commit/c1620d1d8baad6c0d7245ad738defaf12728f40e
https://github.com/kenCode-de/c-libp2p/commit/e55f81490d3f63c23f6585cb2e362aad82ecd931
https://github.com/kenCode-de/c-libp2p/commit/910c07e9513ca0564454c2c285e788266de12b65
 
More commits:
https://github.com/kenCode-de/c-ipfs/commit/cd0993007717fa5efbc4d01bfba94112e93b7d76
https://github.com/kenCode-de/c-ipfs/commit/de6c4b24954a0e90bdde8e3be0fca1bc6f96c331
https://github.com/kenCode-de/c-ipfs/commit/0522bedd2a189092fbe169f32a16201cd1a23d5f
 
This coming week, we will finish the connectivity encryption, and all things going as planned, have our first formal public Release of C-IPFS for linux published by end of day today too. Mac, Win, Android and RasPI release should follow shortly thereafter.
 
Android Smartcoins Wallet:
 
Smartcoins Wallet v1.5.8 download is here:
https://play.google.com/store/apps/details?id=de.bitsharesmunich.smartcoinswallet
 
As mentioned before, we are now adding native support for Bitcoin, Litecoin, Dash, Dogecoin and Steem blockchains so that they can take advantage of the mobile wallet's Overdraft Protection (aka: Backup Asset), built-in coins Bridge, Loyalty Points, and eReceipts. These 5 additional chains will be integrated and Released (as probably v1.8.0) by May. Work done so far:
  • Created Seeds Accounts Database
  • Created Bitcoin Transaction Database
  • Create BIP39 seed
  • Create new Bitcoin Account
  • Load Bitcoin Account from DB
  • Import Bitcoin account from seed
  • Added cryptocoin core tables to SCWALL: seeds, general_accounts, general_orphan_keys, general_address, general_transactions, inputs_tx, outputs_tx
  • Added database queries to seeds and to general accounts
  • Added AccountSeed , class that permits seed exporting and importing
  • Added Seed Type BIP39 (Standrad Seed creation and importing)
  • Added Seed Type Brainkey (openledger)
  • Added General CryptoCoin Structure
  • Added Bitcoin Account, Manager, Address)
  • Changed the TabActivity to show the bitcoin balance (4)
  • Adding the fragment for no currency account (no bitcoin account)
  • Changed the mnemonic to add the master seed words to the end
  • Import 24 to 28 words (brainkey and bitcoin) and also the 12 to 16 words import (only brainkey)
  • Added Export new seeds (BIP39) and account to bin file
  • Added import new seeds (BIP39) and account from bin file
The work for the next week is:
  • Importing and exporting of private keys
  • Showing Bitcoin Balance
  • Showing Equivalent fiat Values
  • Follow BTC Transaction
  • Show Historical Balances
Getting the full nodes setup on the server this week, then:
  • Expand local database for contacts
  • Add new BTC/altcoin Contact
  • Share Contact Address
  • Import contacts
  • Create v10 QR Code support for reading eReceipt data, etc
We should have v1.5.9 ready by monday which includes many more ui fixes from the graphenej upgrade.
 
Stealth related:
 
More snark proof testing:
https://github.com/kenCode-de/graphene/commit/7007739e672f30e99b51e8e1875591689cbcea62
 
Snark gadget tests:
https://github.com/kenCode-de/graphene/commit/0318e5cb7b34da458a7a436c0a1bb3fc99fb69d8
 
We are expanding the api a bit this weekend so that the UI connections can be made properly. Once the api is to a point where I feel comfortable with it and we make the initial connections to the UI, then I will invite the community to start hammering on it with me, see if we can break it. That is a few weeks off yet, but I will post about it here as soon as I can. Everything is looking great and right on schedule so far though.
 
Alfredo Garcia, Bitshares Core Dev update:
 
Done:
 
asset api added 2 functions:
https://github.com/bitshares/bitshares-core/pull/226 merged
 
added list of assets created by account to get_full_accounts api function:
https://github.com/bitshares/bitshares-core/pull/229 merged
 
Remove "no subscription warning" - researched:
https://github.com/bitshares/bitshares-core/issues/174
Fixed in commit/a3cfa1055edb016d8d3b80258657862668f8598f#diff-37f216b941581cfd05361cdd1e765305
 
get_account_history in API-0 without login.
https://github.com/bitshares/bitshares-core/issues/105
This was resolved in PR from elmato (code referenced by xeroc):
https://github.com/bitshares/bitshares-core/pull/223 merged
 
full_accounts needs list of assets created by that account
https://github.com/bitshares/bitshares-core/issues/101
This was done and pull request is at:
https://github.com/bitshares/bitshares-core/pull/229 merged
 
full_accounts needs list of withdrawal permissions from and to that account
https://github.com/bitshares/bitshares-core/issues/230
https://github.com/bitshares/bitshares-core/pull/232 merged
 
Now in progress:
 
Websocket “spamming too much data” issue
https://github.com/cryptonomex/graphene/issues/540
Resolving here: https://github.com/bitshares/bitshares-core/issues/231
waiting on elmato and sigve contributions
 
Find a way to reduce the amount of bytes that are sent and/or received over the internet. EVERY byte counts. (remember my vending machine conversation).
spamming issue above must come first
 
support multiple transfer ops in a single transaction if possible. xeroc (on telegram) already coded this for the peerplays project, so will work with him and acquire that code.
 
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
 
Uninstall light client does not remove "personal info"
https://github.com/bitshares/bitshares-core/issues/227
 
It's nice to see all of these issues being knocked out so fast.
Anyway, expect to see another release of both the Smartcoins Wallet and BlockPay in the next day or two, LOTS of great stuff coming your way.
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
BlockPay v1.5.4 released. Loyalty Points calculations updated, more connectivity improvements, minor UI improvements:
https://play.google.com/store/apps/details?id=de.bitsharesmunich.blockpay
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
 
BlockPay related:
 
This week's work was mainly concentrated around one main task: which was to enable the sending of the final Loyalty Points to the customer. This feature is only available for mobile wallets that support the graphenej library (https://github.com/kenCode-de/graphenej), because from all other forms of payment (like the Jaxx wallet) we can't assess who the customer is so that we can send them any Loyalty Points (hint hint!).
 
Anyways, in order for us to be able to detect the customer identity, it was required to expand the incoming funds detection mechanism. As it was being done, the app would just look for objects of type "account_balance_object" (Object id 2.5.x) from the subscription feed. But this object of course, only informs us about the value update of a given user's balance. No meaningful information about the origin of those funds is provided. To obtain this information, it was required that we looked also for "transaction_object" (Object id 2.7.x).
 
While introducing support for this additional object, it became clear that we needed a way to perform a sort of selective parsing of the data coming from the subscription feed.
 
The idea here is that because the stream of subscription objects contain a whole range of different objects, many of which we might not be interested in, instead of wasting CPU resources parsing ALL of them, it would be better to just look at their specific object ids, and then decide whether or not to perform a full object deserialization. This way we would basically be performing a very minimal deserialization on all objects, and then decide whether or not perform a full deserialization depending on whether we have at least one listener registered.
 
Most of this code was added to our graphenej library and introduced into the BlockPay app. And the work regarding this specific feature can be found here:
https://github.com/kenCode-de/blockpay-s/commit/da95c58ea3338dbe1e02fc0f97ad9abb096dc692
 
After successfully detecting incoming transactions and identifying the customer's bts account, some calculations are needed in order to decide how much (n) of the selected Loyalty Points tokens that we need to send to the customer. Most of the code for this feature was already present, but some corner cases had to be taken into consideration. For example, resetting the Loyalty Points "ratio" (ie: send n OBITS to customer after they have spent at least $n) back to zero, if the merchant decides to change his desired Loyalty Points token. This avoids the possibility of sending the wrong amount of Loyalty Points tokens to the customer if the merchant was to make that change in the settings screen.
 
Finally, the graphenej transaction broadcasting mechanism was used in place of the old one that relied on server components. Bandwidth can be very expensive, so less trips to the server is a good thing. This work can be found here:
https://github.com/kenCode-de/blockpay-s/commit/f9488b30bad2b8536be0a3fd3fc9d7cea54e78d5
 
Also there was still some Loyalty Points UIA list-duplication issues that were solved here:
https://github.com/kenCode-de/blockpay-s/commit/cb127778bca4e81af14f96dad289d5378acece85
 
BTS was added as an entry to the "Desired Smartcoin" list here:
https://github.com/kenCode-de/blockpay-s/commit/923c257475030b095ced564f3f7f99ead623c492
 
A bug that displayed unsupported currencies was fixed here:
https://github.com/kenCode-de/blockpay-s/commit/11e9ff0912dc7760f01d3cf2666b2d1670fb362e
 
Also the initial work to add support for all fiat currencies that currently have an associated Smartcoin was started, but since it was not yet finished, I will publish its commits here next week.
 
Once the liquidity issues are solved and the Bridge fully supports it, we will be adding support for additional Smartcoins such as bitGBP, bitGold, bitSilver, bitMXN, etc soon too.
 
C-IPFS related:
 
C-IPFS is extremely important because it will serve as a Core for most of our apps, a more secure way of acquiring app assets, faster (and even offline) app asset downloading, as well as an automation mechanism for secure data backups. We made tons of great improvements this week that will see daylight by end of next week. We are now connecting to remote IPFS swarm peers, and beginning encryption negotiations. This step is crucial that it be right, as it simply won't work otherwise.
 
We found a few hiccups in a past merge of c-ipfs and c-libp2p so this has been fixed in this latest commit:
https://github.com/kenCode-de/c-ipfs/commit/be4bee3119e4746aa68064b9de73b2a0533450ab
 
We began the buildout of secio, which is the encrypted way that ipfs swarm peers talk to each other:
https://github.com/kenCode-de/c-libp2p/commit/6d9a9e0e70377f1a74515b2ac807cdb504eb32bf
https://github.com/kenCode-de/c-libp2p/commit/513b778561cf773eb541ecf2d95c1a43acaf01eb
https://github.com/kenCode-de/c-libp2p/commit/29e1a0c31b3a78a82058226b080f777dd6e3ed70
 
To make secio work, you first have to connect with multistream. So here is the multistream implementation:
https://github.com/kenCode-de/c-libp2p/commit/d091a29b193a654f3b18e44da7b11139f3b4fa26
https://github.com/kenCode-de/c-libp2p/commit/6b24f0685503649e011c70f1950b998a2210efbb
 
There were a few longstanding incompatibilities with the GO version and C version, due to the way the peer ID was generated. Some adjustments were made and now the C version handles keys just like the GO version:
https://github.com/kenCode-de/c-libp2p/commit/94566ade6989ad144e34072249a4dc64c104eaf7
https://github.com/kenCode-de/c-libp2p/commit/5666a8a2ef8cbd85911f063681cee35444f81307
https://github.com/kenCode-de/c-libp2p/commit/6d5f7410c6c55f4d131500bc2179bfcb07584b89
 
More c-ipfs and c-libp2p commits:
https://github.com/kenCode-de/c-ipfs/commit/2431aba246d52604ff8dce9848868cce910396db
https://github.com/kenCode-de/c-ipfs/commit/15352732596e6098b2c9d7adf6966d61efd677b5
 
Implemented off-line (incomplete, need to save in local db) routing, is the most basic routing protocol, it doesn't need to communicate with other nodes, but proves that just as in the Go implementation the same calls in other modules can be made without knowing which protocol the structure has, will also be used as a skeleton for all other protocols, and we will be able to use multiple protocols or just those that are loaded.
 
Next week we will finish up with the c-ipfs encryption and p2p connectivity features. The first formal public Release of C-IPFS will then be posted here:
https://github.com/kenCode-de/c-ipfs/releases
 
Android Smartcoins Wallet:
 
Smartcoins Wallet v1.5.8 was released today:
https://play.google.com/store/apps/details?id=de.bitsharesmunich.smartcoinswallet
  • This version includes UI fixes, tighter integration with the new graphenej library and better performance.
  • Added support to pt-BR and pt-PT as distinct versions of pt which involved not only change the xml strings, but also a similar treatment the app already does for Chinese variations at SettingActivity and Helper class.
  • Changed the PIN dialog to be auto-submitted.
  • Previous PIN was hardcoded to 6 digits. It is now 6 to "unlimited" digits. Next week we are also adding a 10sec timer, so that if you switch apps or something you should not have to retype your PIN again. I found that kind of annoying.
  • Currently all dialogs of the app needed a refactor, because it is important to do dialog dismiss when the Activity they belong to pause or stop. Otherwise this may cause a memory leak. So we have to keep track of which dialog is open when the app is closed for example, dismiss the dialogs, and show them again, if they were visible before the termination. Memory leaks suck, so we wanted to add this support before that could ever happen.
  • Minor Changes: updated EULA, fixed some variables syntax, updated app version to v1.5.8, updated the 3min "Auto-close" feature so that it is enabled by default (in v1.5.9), updated LTM and "Delete Contact" dialogs to remove weird whitespace, and also updated/fixed some language translations (english and portuguese)
Known issues: I still have to clean up the eReceipts layout, and make the Transactions display work in real-time again. Will fix those things over the next couple days and release another update as v1.5.9. As always, never keep more funds in a wallet than you can afford to lose.
 
The relevant commits and open source for this work are here:
https://github.com/kenCode-de/smartcoins-wallet
 
Stealth related:
 
Libsnark integration (for our new "trustless" setup algo) nearing completion:
https://github.com/kenCode-de/graphene/commit/efea55d15e0b6a5adbc3fe3764cba024c10d99c9
https://github.com/kenCode-de/libsnark/commit/69c380bfe7cc183b7e7eba580bb962dc3e2f90ee
 
Gadget and zero-knowledge proof fixes:
https://github.com/kenCode-de/graphene/commit/82166971f909860fd2adbc198280de42fb61ec90
 
By tuesday of this coming week we will begin the libsnark integration with bitshares-core (graphene) and then we can start the connections of the api to the UI work we have been doing. Stealth transactions are gonna really blow the doors off of the competition. A Bitshares Stealth transaction means "unknown" sent n "unknown" to "unknown". True privacy.
 
Alfredo Garcia, Bitshares Core Dev update:
 
Alfredo has been kicking butt on the github issues, adding the new streamlined asset count, and holders code, fixing the indentation issues with ElMato and nathan, and starting on the "websocket spamming too much data" issue that even bytemaster wanted to fix months ago. That old issue should be fixed by end of next week as well. That issue is a big one too, because if you ever want to use a graphene app over mobile, you could be stuck with consuming around 200K per block and bandwidth is very expensive so this one is marked as High Priority.
 
https://github.com/bitshares/bitshares-core/pull/226
https://github.com/bitshares/bitshares-core/pull/229
PR 229 solves issue 101: https://github.com/bitshares/bitshares-core/issues/101
 
Chris4210 has updated the roadmap for Alfredo too so that I can keep his mountain of work rolling and never stops. I see lots of great stuff coming to Bitshares again.
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline kenCode

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

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
BlockPay v1.5.2 released. More "Desired Smartcoin" choices being added, UI updates, Loyalty Points upgraded to the new graphenej library, more speed improvements. This version also includes all of the updates from our recent security audit. Since most of the underlying code has been upgraded now, it kind of messed up the UI a bit, so we are making it look nicer over the next few days and will release that update as v1.5.3.
https://play.google.com/store/apps/details?id=de.bitsharesmunich.blockpay
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
Smartcoins Wallet for Android v1.5.7 released. This version includes UI fixes, more accurate equivalent fiat values displayed under each asset quantity, tighter integration with the graphenej library and better performance. As always, never keep more funds in a wallet than you can afford to lose.
https://play.google.com/store/apps/details?id=de.bitsharesmunich.smartcoinswallet
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
 
BlockPay related:
 
BlockPay v1.5.1 has finally been published on the google play store, just got a bunch of UI work we want to do to it now and some other minor things that still need the graphenej integration (Loyalty Points for instance). Once Alfredo's latest graphene updates get committed by nathan, then BlockPay will run much faster and initial setup sync's up a lot faster then too.
 
We have totally removed all reliance on the cryptofresh api and wrote our own api's. I am not a fan of our apps having to rely on third-parties. Our recent security audits played a big part in this and have now all been upgraded successfully.
 
Today we are moving the Loyalty Points feature onto our new graphenej library, tomorrow we are adding direct DEx support, Sunday and Monday we are cleaning up the UI of the eReceipts, Tuesday and Wednesday we are moving the Transactions code onto graphenej as well and cleaning up the UI there, on Thursday we will start the redesign of the settings screen and initial app setup process so that merchant's can understand it better. As you add features to software, it can turn the UI into a cluster fuck so this redesign is imperative IMO.
 
I will try to upload BlockPay v1.5.2 for you guys by tomorrow (saturday) with some of the stuff mentioned above, especially UI work and the Loyalty Points feature.
 
C-IPFS related:
 
We're adding some features to the c-libp2p repo, and c-libp2p-routing at moment:
https://github.com/kenCode-de/c-libp2p/commit/ee6049804a86cf7f2f85bb0b96cb4e046e01328e
https://github.com/kenCode-de/c-libp2p/commit/6a30c46492101b164e91c8ff1f1ea923bc2135a1
https://github.com/kenCode-de/c-libp2p/commit/f2031179a962495836c453c02593dc2e924dca9e
https://github.com/kenCode-de/c-libp2p/commit/0ca303bb1c11695b6d965fac9a13723072309a4c
 
We also added code for message signing:
https://github.com/kenCode-de/c-libp2p/commit/9a7c494436c486498a8fc520cbe13f3a361f9e6c
https://github.com/kenCode-de/c-libp2p/commit/d13a47d7d5c997892ebf34b148a905824119addd
 
Need to complete the Kademlia DHT port, IPNS Publish feature, and implement Swarm so that we can implement the daemon for the Linux and Mac public Release which will be published as v1.0.0 in the next week or so here:
https://github.com/kenCode-de/c-ipfs/releases
 
Android Smartcoins Wallet:
 
All security audits have been completed and integrated successfully. Our new graphenej lib can be audited here too if you like:
https://github.com/kenCode-de/graphenej
 
This week we are doing more UI work, adding direct DEx support into graphenej, and working on the additional chain support.
 
Stealth related:
 
More testing completed of our new "trustless" algo, will reveal more of that for you guys and on our testnet soon. Proof and verification implementation,  libsnark gadgets for notes, commitments and joinsplit transaction work:
https://github.com/kenCode-de/graphene/commit/3159c26ee3511788ee0ffd5e1e2a6246dd18232f
 
Updated to the new bitshares-ui repo, added underlying functionality for wallets to be able to keep records of Stealth accounts. Not tested yet due to a bug in their latest bitshares-ui which doesn't allow account creation from LTM accounts.
 
Github work: https://github.com/kenCode-de/graphene-ui/tree/graphene-ui-dev-v3-BITSHARES_UPDATE
 
UI work has resumed and we will have more screenshots for you soon. Tonight we will begin the initial connections of the UI to graphene.
 
Alfredo Garcia, Bitshares Core Dev update:
 
As ordered, Alfredo began work on Monday, January 23rd. I got him rolling on outstanding github issues and graphene additions already:
 
1) Install and test asset api to the new bitshares-core (https://github.com/bitshares/bitshares-core/) project from the old cryptonomex (https://github.com/cryptonomex/graphene/) repo. They have differences that were addressed to make the asset api work and the first function get_asset_holders_count.
Pull request: https://github.com/bitshares/bitshares-core/pull/220
 
2) add new function get_all_asset_holders that returns a vector of assets_ids:holder count.
Commit: https://github.com/bitshares/bitshares-core/pull/220/commits/0316affea7219da51cae49d27a92d1f133f63834
 
3) corrected indents as per nathan request, changed counter loop function to use distance for efficiency.
Commits:
https://github.com/bitshares/bitshares-core/pull/220/commits/6a0f41ffc2be9fc1d9824cf98c17f4629484b534
https://github.com/bitshares/bitshares-core/pull/220/commits/b50bba13c8dddbe7879b7b5888341bcc1b7a506e
https://github.com/bitshares/bitshares-core/pull/220/commits/b6fbc97d3a172522533356b31c9e595e85116cf2
 
4) github issue: https://github.com/bitshares/bitshares-core/issues/105
Created a public function that does the same as get_account_history_public but can be called without authentication.
Commit: https://github.com/bitshares/bitshares-core/commit/7872a2f51b8fbeda0db5b6df737c78be764ee658
 
At least 3 more github Issues will be fixed and PR'd early next week along with updated bitshares-core (graphene) code which will fix the "websocket spamming too much data" issue once and for all. There have been quite a few requests for a mobile-friendly version of our DEx and better bandwidth utilization for all mobile clients and wallets. Right now, each block consumes about 200K of your data plan, so once Alfredo fixes that too, we no longer have to worry about data consumption.
 
Keep an eye on the google play store, I will post quite a few more updates for our apps this week.
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline Pheonike

How about Nebula.

Sent from my SM-N920T using Tapatalk