The Agorise Report : C-IPFS, Stealth and Blinded Transactions, POS Systems, Mobile Wallets, graphenej...

Welcome to The Agorise Report!

Anarchy itself literally means "without Rulers". It does not mean "no rules", or chaos. Agorists work to bring about a society of voluntary human-interactions by way of the Non-Aggression Principle (NAP), Peaceful Parenting and counter-economics. Agorism embraces free-market alternatives, rendering governments and the use of force obsolete.

This week has been intense, a few of our Dev teams are finishing up their projects and are merging their code with the master code for 7 (yes, seven) different products being launched this year and next. C-IPFS for Stealth, App and website decentralization, graphenej for the mobile wallets and POS systems, and a new testnet for hacking on all of these products amongst other things.

C-IPFS

Node Identities, Protobuf and Yamux work done this week. Lots of testing, leak plugs and Issue fixes done. The API client mode was returning an empty response from the server, found the cause and fixed it, after that we are changing the method of communication to be the same used by Go-IPFS and then we realized that this removed a huge limitation that was communication between our client and our server using the API with large volumes of binary data, but GO was still closing the connection with timeout. Fixed.
https://github.com/Agorise/c-libp2p/commit/7564a4b089f9d205beafddf550d7a51bf519658a
https://github.com/Agorise/c-ipfs/commit/4e556221bd8fe56a9a0b8f69e0b7d9ed41082170
https://github.com/Agorise/c-ipfs/commit/ae6fe6dc29a2f971d1c208d63afac9a5ad2679ec
https://github.com/Agorise/c-libp2p/commit/a91e8407707b2fbeaf6bce40365708402f51d883

A lot more work was done this week on GO compatibility, and we made good progress. Our C version is now connecting using a new, layered approach, and is more like the GO version. Adding additional protocols are now easier.

Here are the commits to the “yamux” branch of c-libp2p:
https://github.com/Agorise/c-libp2p/commit/746682ebef3e413e003c578522125fdc150094dc
https://github.com/Agorise/c-libp2p/commit/65194c06eee35034c140ad57794b7ca6acfb8c9a
https://github.com/Agorise/c-libp2p/commit/5e1cdac4cf2586d80ac9495cd50f4c53462b46bc
https://github.com/Agorise/c-libp2p/commit/9200e0f09c2206d8e0db7236f41a4e6e537c3910

In the coming week, we'll continue to work on GO compatibility and help the other Agorise Dev Teams with App and website integrations. Yamux protocol should be done by end of next week, and then will need to implement just a few other protocols to make the existing GO version happy to connect to one of our C nodes.

Most of our apps and websites are being decentralized with C-IPFS, not just Stealth, so getting this foundation built properly will enable all kinds of projects out there (besides ours) to decentralize fully. No more gov/ISP censorship!

To Follow and audit our code:
https://github.com/Agorise?tab=repositories

Stealth Transactions on the Bitshares platform

Our goal: "unknown" sent n "unknown" to "unknown"

Due to the unreliability of their bitshares.eu testnet, we have invested in our own this week. By tonight or tomorrow we should have the faucet running for it as well, and then we can finally give out the URL so that people can get on there and start hacking on it with us.

The UI and UX for Stealth and Blinded transactions is now done/beta, BUT, the recent release of the new Bitshares UI (you'll see it in your web wallet and downloadable light client wallets) moved some stuff around, so we are now taking a couple of extra days to make the same layout adjustments at our end. It does look awesome though, so no biggie, these changes are much praised. :)

Some of our test transactions going through...

Create a Stealth account:

Send from Public to Blinded:

Confirm Public to Blinded:

Public to Blinded shows in History:

Public to Blinded shows on the blockchain:

The above images demonstrate Public to Blinded, which is not nearly as exciting as Public—>Blind—>Blind—>Public. (but we'll have the rest soon. It works, we just need to tweak the fee calculation later today). Will upload more of these screen grabs to our telegram group this week (https://t.me/Agorise), hopefully an animated round-trip video too.

Here is proof of that transaction on the main chain:
https://cryptofresh.com/b/21487444

Once Range Proofs are done, we'll be able to complete the full feature-set of Stealth, using Confidential Assets and hiding every possible bit of data possible with today's available crypto technologies. We'll also design a short presentation then to show Stealth in action.

Some additional Stealth and Blinded Transactions work done this week:

• Completion of database (DB) security and most importantly, synchronization.
• The Stealth DB, including your private key, coins etc get LOCKED as well, currently using your normal password + SHA-3 + AES (easy to shift from one encryption/hash to another too in case of changes.)
• Completion of LOCAL backups: You can now backup an entire Stealth wallet, or a single account as you choose.
• Additional note: you can shift these accounts from any public wallet to another, so if say you had multiple Bitshares-UI wallets, you can now shift the Stealth accounts from one to the other. You can shift one account to another, or you can shift the entire Stealth wallet to another.

This also adds the possibility of you creating a file you send to someone instead of actually making a transfer. However, this is not as reliable as you both would have access to those funds so it is only useful in a very few scenarios.

• Single account backup functionality implemented in right-click menu of Stealth accounts. Stealth gives you so many options, we felt it best to put the grouped features into a right-click context menu which really helps to keep the UI clean of stuff that you won't use very often. Grandma-friendly, remember? ;)
• Visual bi-functional screen for either one Stealth account, or an entire Stealth wallet backup.
• Fixed a bug that caused doubling of accounts, and strangely or rather coincidentally enough, another that sometimes did the same if you stressed the UI with fast commands, on IndexedDB's side.
  https://github.com/Agorise/bitshares-ui/commit/c50413f16d81590cd4d50115a85e56e863c7c881

Range Proofs, RPC calls and API update:

• This is a “glue” commit (link below) between the UI and database layers and our underlying Stealth code. Particularly, this commit addresses “coin handling” before and after a send transaction. Since Blinded/Stealth use a Bitcoin-like UTXO model rather than the account model used by regular Bitshares accounts, a “blinded balance” is really a collection of “coins” that have been received (and communicated via “receipts”). For a Blinded-send to happen, a selection of received coins adequate to cover the amount (plus fees) must be assembled, and becomes the “inputs” to the transaction. After the transaction, those inputs are consumed and the corresponding “coins” in the Blinded balance must be marked as spent, reducing the remaining balance. If any of the “outputs” from the transaction are back to ourselves, (ie: a “change” coin representing the excess of the assembled inputs over the send amount plus fees), then those outputs must be recognized, processed, and added back into the Blinded balance. This commit addresses these “coin handling” processes.
• Remainder of the week was spent on range proofs: researching / tracing / analyzing the C++ code in the cli wallet for range commits and planning the Javascript implementation.
• Range proofs are needed for transactions involving multiple outputs. In other words, if an output will generate “change,” then a range proof is needed to prove that both outputs are positive valued (without revealing the output amounts). This is a fraud-prevention measure that the network uses to make sure that counterfeit coins aren’t produced and “cloaked” by balancing with a negative valued output.
• The Javascript implementation of range proofs is currently in-development and not yet activated in the code. For the time being, transactions that result in a change coin will be rejected by the network (they will fail the range proof check). However, transactions where the amounts are chosen so that there will be no change coin WILL be accepted by the network. The trick is to ensure that the transaction amount plus fees (0.001 TEST base fee plus 5.0 TEST per input) is exactly equal to the summed value of the “coins” assembled to make the transaction. Log messages to the Javascript console annotate the coin-selection process and the change amount in order to facilitate testing.
  https://github.com/Agorise/bitshares-ui/commit/fd0f5095170d8d9011016aefbbd944cba662b9d5

A few people from the Agorise telegram group (https://t.me/Agorise) are helping us to write-up the BSIP for Stealth so that our code can be understood, audited and eventually merged with the master Bitshares branch. If you'd like to see our progress on the Stealth BSIP, please visit the Agorise channel on Flock:
https://bitshares.flock.com

As always, feel free to help audit our code:
https://github.com/Agorise?tab=repositories

Point Of Sale (POS) systems

All work for the POS systems this week were done in the graphenej library below..

graphenej

Want to make an android app for the Bitshares platform? Try out our graphenej lib!
In dev: https://github.com/Agorise/graphenej/tree/develop
Main: https://github.com/Agorise/graphenej/

The first improvement was motivated by the fact that the PaymentHandler class in our POS system needs to obtain an updated copy of the order book. In order to do so we have to query the full node and obtain a current version of the order book between the core asset (BTS) and the user's (in this case the merchant) desired output asset, which would usually be a Smartcoin like bitUSD or bitEUR.

Now, the POS app already contacts the full node in order to obtain all sorts of network information, but every time it does, it uses a new connection. Only on specific instances, like when publishing a signed transaction, the same connection is used in order to send and receive several messages. This is a poor architecture, and was only introduced in our old Smartcoins Wallet (android) and in order to save development time while avoiding to use a poorly constructed message broker that that app initially had.

With the aim to unify all connections to any app that makes use of our graphenej library, a new class called NodeConnection was introduced to it a while back. The idea is that this class should receive a list of full node URLs, and with this information maintain a stable connection with any of the nodes. Remember when we invented the "Node-Hopping" schema? Anyway, in case of an error, this class should be able to retry to establish a connection with the next node in the list. This feature was only partially implemented in this class, and was now finished along with some tests here.

After this, some new error reports were filed on the memo de-serialization functionality of the graphenej library. But before that problem could be tackled directly, some structural issues with the test suite that made their use very impractical had to be introduced. The problem was that the test cases were dependent on some environment variables in order to obtain the private keys used to encrypt/decrypt memo data. This was done initially in order to avoid having to publicly release private keys in order to perform some tests. Now with the tests finally working, it was possible to reproduce the reported error and fix it. The problem was actually solved initially but reintroduced in our last changes to the Memo class, by virtue of the restoration of the long data type as the holder for the memo's nonce data. This time it was solved by replacing the long primitive by a BigInteger instance here:
https://github.com/Agorise/graphenej/commit/fc91f7366c39ea43193fcc5bcbd66f983e796990
https://github.com/Agorise/graphenej/commit/0192728bd5b3e7a3549fabf5b6abef07835b6252
https://github.com/Agorise/graphenej/commit/3d4b2719bb1d4726ad318f5d7fa4c70953f5417b

Mobile wallets

Hiring a qualified Dev for the animation work has not been an easy task. Luckily, Steemit helped us to get the word out there and it looks as if we found our guru.

The core code for "Carbon" is mostly done. We used the new Android Architecture Components (AAC) exclusively for this wallet and the responsiveness, abstractions and flexibility of AAC have been phenomenal. The animations are being coded up now (fiiiinally). We hope to have a Beta 1 release ready for download before Christmas this year. For the huge list of features, be sure to view our d.tube or YT channels.

Well, gonna end this Agorise Report here, gotta get back to work now. If you want to try out any of our pre-releases, participate in giveaways, or play around on our testnet, be sure to...

Please Follow and Share our blog! :)

Questions? Join us on Telegram for live chats too!
https://t.me/Agorise

Peace, Love, and Agorism.
-the Dev teams @ Agorise