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

2 months ago
53 in cryptocurrency

Welcome to The Agorise Report!

agorist-flag.png

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.

hr.png

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

hr.png

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:
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 (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

hr.png

Point Of Sale (POS) systems

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

hr.png

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

hr.png

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

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:  trending
53
  ·  2 months ago

gettin there..:
https://cryptofresh.com/tx/7ee7106cc4bbe6e47fcb59236c7ff3dc798d514e

==========
update Sat, Nov 4, 2017:
OK, got fee schedule figured out. Fee amounts AND structure differ on main chain: On main chain you pay per OUTPUT. On testnet you pay per INPUT. Weird. Very weird.
https://cryptofresh.com/b/21501698

==========
update Sun, Nov 5, 2017:

ROUND TRIP:
Public to Blinded:
42.54933 BTS = win-the-agora to (@)nothingtoseehere
https://cryptofresh.com/b/21503991
Blinded to Blinded:
32.54933 BTS = (@)nothingtoseehere to (@)justme
https://cryptofresh.com/b/21504115
Blinded to Public:
20.00000 BTS = (@)justme to win-the-agora
https://cryptofresh.com/b/21504227
Round trip consumed ~25 BTS in fees.

FYI:
The "stealth-buyback" account (https://cryptofresh.com/u/stealth-buyback) is already buying up STEALTH tokens off the top of the order book. Buys occur every hour with the fees accumulated during the time period. Fees from Op-codes 39, 40, and 41 (to-blinded, blinded-to-blinded, and from-blinded) pay into the fee accumulator. The top few transactions you see here are from the fees we paid in our test transactions last night.

Public to Blinded:
060 Public to Blind.png

Public to Blinded (Confirmed):
065 Public to Blind Confirmed.png

Blinded to Blinded:
070 Blind to Blind.png

Blinded to Blinded (Confirmed):
075 Blind to Blind Confirmed.png

Blinded to Public:
080 Blind to Public.png

Blinded to Public (Confirmed):
085 Blind to Public Confirmed.png

==========
update Mon, Nov 6, 2017:

So, what's left for the completion of the Stealth Transactions feature on the Bitshares platform?

Asset sent, metadata, and also the recipient's pseudonymous "asking address" is still revealed in Blinded transactions (and the receipts too if they're sent unsecured). We'll hide that data as well, and fairly soon. The major remaining problem it appears, is how to get away from the need to transmit (and backup) receipts altogether, so that everything is seamless, and one single brain-wallet or mnemonic seed is ALL that is needed for a user to backup their accounts. Monero has solved this problem (although perhaps not without the “cost” of having to run a full node in order to discover your incoming transactions). So we need still to understand how they did it, and improve upon it. We’ve got some ideas, but we're not ready to present them until the range proof stuff is done first (see OP above).

There will also be a fair amount of work in getting things “production ready”. There’s a fair amount of “need to fix this later” code in the codebase right now to get us as quickly as possible to a prototype release. That WILL need to be addressed before we can be confident that some little code snippet that we used because “it worked at the moment” won’t come back and bite somebody’s balance.

Maybe somebody could run a Worker Proposal for us to pay a professional 3rd party Cyber Security Auditing Firm to sign off on our beta and final releases..?? - due diligence first! make sure of course that they have no connections to government funding or other backdoor'ing motives.

·
64
  ·  2 months ago

Thx for this update Ken.

Your comment above confirms a convo I had with a guy who was asking about how the "buyback" works for FBAs. I told him that FBAs don't use a buyback scheme, that the fees collected from stealth transactions are paid ONLY to holders of the STEALTH token. 60% of the stealth transaction fee goes to STEALTH token holders. He said the buyback was documented on Cryptofresh. I flatly said if so it's wrong. Is it? Is that statement (A Fee Backed Asset that will be bought back with 60% of all fees from stealth or confidential transfers.) correct? I don't believe it is, unless the approach for FBA has changed.

The whole reason for FBA is to provide a recurring stream of value to those who create new features. It's their work, they should receive value for it as long as people continue to use that feature. FBA tokens (such as STEALTH) are the distribution mechanism for 60% of the transaction fees collected for using the feature. The FBA creator also holds all of the FBA tokens initially and can distribute those tokens to anyone. They represent who will get a cut of the transaction fees after the FBA feature is successfully deployed and used.

For BitShares stealth, the original STEALTH token holder / FBA creator was onceuponatime. He distributed STEALTH tokens to Daniel Larimer, Ken Silver, myself and perhaps a few others. Kencode sold a bunch to chris4210. Ownership has changed hands of these tokens many times. I still hold all 20000 of the STEALTH tokens onceuponatime sent me for my participation on the stealth management team, which won't exist until the stealth feature is operational.

That's the FBA scheme as I understand it. It doesn't make sense to buy back STEALTH tokens, as doing so will stop the recurring stream of value to the one who previously owned them, which is contrary to the recurring value stream FBAs were designed to provide.

Now I don't know when this buyback mechanism was introduced to stealth, but it wasn't involved in the FBA approach I recall reading about on the bitsharestalk forum or discussed with onceuponatime or kencode. What is the purpose of this buyback? Are buyback & STEALTH transaction fees being conflated? Could we get clarification about this buyback, what it's for, what is being bought back (presumably not STEALTH tokens, as they are the source of recurring value). Has buyback arisen to replace BlockPay token in some way?

·
·
69
  ·  2 months ago

Hey Thom, that's a great point. Maybe @dantheman @dan could chime in here to help clarify this for us?

We @Agorise think it works by putting constant buy pressure on the market. There's no actual "distribution" after that. But the price of STEALTH tokens are pushed upwards because there is ALWAYS a buyer for it, as long as there are people making Stealth transactions and paying the fees.

The buyback account appears to be an automaton account. Nobody has the keys for it, nobody can control it, as far as we can see. Its only job is to buy STEALTH tokens. 60% of all the Stealth transaction fees go into the buyback account via an “accumulator”, and once every hour the account spends its entire balance to buy as much STEALTH as it can with its accumulated BTS.

So the BTS doesn’t really appear to get "distributed" per se. Rather it goes to buying STEALTH off the top of the order book. The fact that it is doing this can be verified by looking at the buyback account’s history. This "buy pressure" results in a higher STEALTH token price and increases the value of the STEALTH token for everybody.

(Our remaining question tho is: what happens to the STEALTH that the stealth-buyback account purchases? Is it burned? Is it redistributed over the current holders of STEALTH tokens? Is it held and available to fund future Stealth development? Our impression thus far is that it is "locked" in the buyback account, presumably forever. Not technically burned, but effectively so, since no human has control of that buyback account. In fact, the current STEALTH balance of stealth-buyback appears to be the sum total of all STEALTH that the buyback account has ever purchased off the market. If this is how it works, it effectively makes STEALTH a deflationary currency, and this puts upward pressure on the price).

·
·
·
60
  ·  2 months ago

Interesting. Sounds like STEALTH will end if the system ever buys back all tokens remaining. :)

·
·
·
·
53
  ·  2 months ago

No, that's not quite how it works.
In Thom's comment above he said:

I flatly said if so it's wrong. Is it? Is that statement (A Fee Backed Asset that will be bought back with 60% of all fees from stealth or confidential transfers.) correct? I don't believe it is, unless the approach for FBA has changed.

The buy-back IS happening since Cryptonomex coded the FBA that way. There are accumulator objects that you can query through the websocket API. They are objects 2.16.0, 2.16.1, and 2.16.2. They accumulate ALL fees from op-codes 39, 40, and 41 (to-blinded, blinded-to-blinded, and from-blinded). Once every maintenance cycle (approx. every hour), 60% of these fees go “virtually” to account stealth-buyback, which will buy off the top of the order book however much it can with the fees. This exerts upwards price pressure. The buyback account has owner and control public keys for which no private keys exist, thus no one “controls” the buyback account. So far as we know, it can ONLY do what the protocol requires it to do, which is to buy STEALTH tokens.

Separately from the 60% to stealth-buyback, another 20% goes to account stealth-mgmt, which is controlled by the top five STEALTH token holders. Presumably, this 20% could be used to fund future developments or improvements to the STEALTH protocol.

Thom also stated above:

It doesn't make sense to buy back STEALTH tokens, as doing so will stop the recurring stream of value to the one who previously owned them, which is contrary to the recurring value stream FBAs were designed to provide.

The buyback account only buys off the order book. If there are no asks on the order book, the buyback account will simply accumulate fees until there is an ask on the order book. Thus, it could never buy back ALL the STEALTH, nor will it ever buy back from people who aren’t wishing to sell.

SOURCE for this info: The "ROUND TRIP" test transactions we did a couple days ago. We observed the accumulator objects and buyback accounts, and inspected the virtual transactions where the buyback occurred. The public keys for buyback account were also queried to demonstrate that they are “burn keys” for which no private keys could plausibly exist. The specs for this process are probably documented somewhere, but what’s written here is from direct observation.

What we seem to have with FBA's is a deflationary asset for which there will (probably) ALWAYS be an eager buyer in the marketplace, so long as Stealth transactions are occurring on the network.

The TX fees are used by the buyback account to buy off the order book. Thus, those fees go to satisfying the highest ask order on the book. The seller whose STEALTH are sold in this manner is the recipient of the fees. (but note: he’s not getting anything "special" by this.. the buyback account buys at market price, same as anybody else. As a result of which, the price of STEALTH is edged upwards, just the same as if a real buyer had come in and bought the same quantity of tokens, and this increases the value of the STEALTH tokens for everyone).

There is no dividend stream, that we can see, anywhere. Nor could there be, since the fees are spent buying off the order book.

NOTE: This is what we’ve SEEN happening on the blockchain. If there is a spec out there somewhere that says "This is all supposed to CHANGE at some point (ie: when Stealth is full-on Stealth and not just Blinded), we've not encountered it. Nor do we think there is wisdom in it, necessarily, with regulators potentially taking an interest in something that looks like a "dividend" program.

(note: we're referring to the 60% buyback here. The other 20% that goes to the management account... that is spendable by the management account. But that's not quite equivalent to an "individual" getting a dividend stream. That's more like a "trust" receiving that revenue stream. And presumably they are obligated to spend it for the benefit of the ecosystem, though not sure if this is spelled out anywhere).

If nobody’s selling, or even trickle-selling.. the fees will indeed just accumulate until there is a seller. In fact, in block 20135695, when onceuponatime placed the first sell order, he took the whole fee pot that had accumulated over two years or whatever it was (3170 BTS). This will probably never happen again though, as there will essentially always be somebody who’s selling.

·
·
·
·
·
64
  ·  2 months ago

Well, sounds like BlockPay is not the only token that has changed its' color. If the code works the way you describe, and I have no reason to doubt you, then it was coded differently than the discussions I was party to.

It does make sense about the regulator's view tho, but we're talking 2 years ago before all this turmoil over ICOs and exchanges. We were smarter than most crypto projects and understood the Howie test, even back then (to some degree at least, but crypto application of SEC laws are STILL indeterminate), but there is zero doubt in my mind FBAs were discussed as a recurring stream of value provided to holders of the STEALTH token, and that has been my understanding the entire time. Somewhere along the way BM changed the implementation and that wasn't communicated.

If STEALTH tokens are bought back how do people realize that stream? Rather than the STEALTH tokens representing a recurring stream of value, it now appears owning STEALTH tokens as a means of providing future value (for example for elderly retirees), it is a not a recurring stream at all.

·
·
·
·
·
·
53
  ·  2 months ago

Yeah, we're not too happy about this discovery either.

We were under the impression that we would get paid in BTS from the fees from the Stealth transactions. Now we find that we will have to put the tokens on the market and sell some. Granted, the STEALTH tokens appear to be deflationary so that's very good news, and an appreciating asset (like bitSilver or Steem) is a very good thing in our opinion. Speaking of Blockpay, these owner-less tokens remove the need to trust a human too, which is a major plus.

Supposedly someone could just write a little sell-bot to trickle-sell the tokens or something, having the same effect as an income.

From a regulatory standpoint though, we can see why he might have changed that, but we were really hoping for a steady income from that asset which is why we agreed to finish the coding for it.

·
·
·
·
·
·
·
64
  ·  2 months ago

How much value the STEALTH tokens represent is even more indeterminate than it was before recognizing this buyback approach.

They no longer hold the same value proposition that was originally discussed for FBAs. The original, primary investor in the BitShares STEALTH feature was @onceuponatime, who was expecting a recurring stream based on the number of STEALTH UIA tokens he held, not on the proceeds from the sale of those tokens.

·
·
·
·
·
60
  ·  2 months ago

Sounds good. Thanks for taking time to reply. I appreciate that.

60
  ·  2 months ago

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... ;-)

·
53
  ·  2 months ago

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

57
  ·  2 months ago

Thanks for the great update Ken :)

40
  ·  2 months ago

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

34
  ·  2 months ago

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!

·
53
  ·  2 months ago

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

60
  ·  2 months ago

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

63
  ·  2 months ago

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).

·
53
  ·  2 months ago

We post updates every few days in our telegram group:
http://t.me/Agorise

25
  ·  2 months ago

Great job!

42
  ·  2 months ago

Well done! Exciting times ahead.

61
  ·  2 months ago

Very cool developments. Highly rEsteemed ; )

60
  ·  2 months ago

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!

60
  ·  2 months ago

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!