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

in cryptocurrency •  7 months ago

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.


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.

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:

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:


Stealth Transactions on the Bitshares platform

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

Due to the unreliability of their 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:
010 Create Stealth Account.png

Send from Public to Blinded:
020 Send Public to Blind.png

Confirm Public to Blinded:
030 Confirm Public to Blind.png

Public to Blinded shows in History:
040 Public to Blind in History.png

Public to Blinded shows on the blockchain:
050 Public to Blind in Blockchain.png

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 (, hopefully an animated round-trip video too.

Here is proof of that transaction on the main chain:

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.

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.

A few people from the Agorise telegram group ( 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:

As always, feel free to help audit our code:


Point Of Sale (POS) systems

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



Want to make an android app for the Bitshares platform? Try out our graphenej lib!
In dev:

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:


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 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!

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

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

Bring it on! I have a feeling @agorise is the most exciting project in cryptoland ;-) Upvoted, resteemed and all that. Grandma needs her stealth before christmas... ;-)


ya darn tootin' she does! ;)
thanx for the re-steem and upvote @funkit! <3

Thanks for the great update Ken :)

Exciting updates! Looking forward to trying out stealth. Keep up the excellent work!

I may not be active much but I'm following the improvements in "stealth" mode and I'm excited for the future. I may try to get more involved for any Turkish translation if you need and if I can have some free time, just keep it in mind. Cheers!


For sure, and thank you @xquad! :) We'll be having another Crowd-Voting contest soon for Translations so thanx again! :)

Good Job Ken. I can't wait for that carbon. lol Keep it up man.....

Any news about this? Is there an ETA on when all the relevant software will be publicly available, after proper vetting & testing ?

This will be huge for Bitshares. With proper confidential transactions, we must not lose the opportunity to educate the cryptopublic about bitUSD (vs USDT).


We post updates every few days in our telegram group:

Well done! Exciting times ahead.

Very cool developments. Highly rEsteemed ; )

Congratulations @agorise! You have completed some achievement on Steemit and have been rewarded with new badge(s) :

Award for the number of comments received

Click on any badge to view your own Board of Honor on SteemitBoard.
For more information about SteemitBoard, click here

If you no longer want to receive notifications, reply to this comment with the word STOP

By upvoting this notification, you can help all Steemit users. Learn how here!

Congratulations @agorise! You have completed some achievement on Steemit and have been rewarded with new badge(s) :

Award for the number of upvotes received

Click on any badge to view your own Board of Honor on SteemitBoard.
For more information about SteemitBoard, click here

If you no longer want to receive notifications, reply to this comment with the word STOP

By upvoting this notification, you can help all Steemit users. Learn how here!