BitShares Forum
Main => General Discussion => Topic started by: kenCode on May 31, 2016, 07:04:27 pm
-
[ANN] BlockPay - The App that allows any Business to accept any Crypto-currency at Zero Cost
Integrated completely with your favorite store's Point Of Sale system
Looking for somewhere to spend your Ether? Your Bitcoin, Dash or Steem..?
Over the last few weeks we have been coding yet another mobile wallet, this one is named Smartcoins Wallet. It is native android so it runs extremely fast.
In this video, the Smartcoins Wallet is on the left, and on the right one of our POS systems has been installed on an old phone...
https://youtu.be/IyIWxm6pVD0?list=PLjbx3qSmDe7RYkRMIEuFyYyG7_vvKgou0
The merchant charges you a specific amount, you scan the QR code (we will put the new scanner in there next week) with your wallet, the merchant receives the currency that they want and you got to spend the crypto that you wanted to spend (Smartcoins/BTS/SBD/BTC/ETH/LTC, etc) and in a few seconds the merchant can automatically reward you with loyalty points (tradeable on the open exchange or can be traded in upon your next visit at that merchant for discounts).
Of course the wallets and Bitshares blockchain also support Overdraft Protection, 3 second blocks, 100,000+ transactions per second, eReceipts (the QR code (or NFC) sends a small pdf file to your phone), unlimited altcoins and other assets, automated accounting and full rewards card (loyalty points) features.
BlockPay (the Smartcoins POS api/apps) can be integrated with nearly any existing POS system that you find at a grocery, retail, petrol, vending machines, restaurant or other business.
We still have a lot of UI/UX work to do and need to add just a few more features, but over the next few weeks I hope to have those finished as well. As usual, everything is open source, works with most crypto wallets (Mycelium, Jaxx, etc), and will be posted on github once we're happy with it.
more info --please Upvote! Thank You :)
https://steemit.com/crypto-news/@kenCode/ann-blockpos--the-app-that-allows-any-business-to-accept-any-crypto-currency-at-zero
https://steemit.com/crypto-news/@kenCode/smartcoins-pos-the-free-way-for-companies-to-accept-crypto-currencies
https://steemit.com/crypto-news/@kenCode/all-cryptocurrency-mobile-wallets-should-have-these-features
edit: The name of the app is now BlockPay
https://steemit.com/bitcoin/@kenCode/blockpay-being-rolled-out-in-de-fi-is-ru-tu-cn-ca-and-us-so-far
-
Thanks for the update. Finally a pos solution for merchants!
-
Thanx, and please retweet! :)
https://twitter.com/kenCode_de/status/737725421240897536
-
It is native android so it runs extremely fast.
Is it native Android connected to the hosted wallet infrastructure of the OpenLedger server?
If so, does it mean you've ported the whole client-side JavaScript code-base to native Android?
-
Do you negotiate with any of merchants to use this?
-
It is native android so it runs extremely fast.
Is it native Android connected to the hosted wallet infrastructure of the OpenLedger server?
If so, does it mean you've ported the whole client-side JavaScript code-base to native Android?
Ported, no. This has been written from scratch. You guys can see the code in a few weeks when I upload everything to github for forking etc :)
-
Do you negotiate with any of merchants to use this?
One better. There are Agents that pre-install many different pos systems onto hardware before shipping said hardware to merchants. The software that those manufacturers pre-install include packages like SAP, Shopify, Quickbooks POS and many more. By working with them we will be able to reach many more.
-
you guys need a map too. you know, where stores can show that they accept currency
-
For something like this, I would have expected a bigger more prominent well planned out launch across media outlets etc.
If it was me, I'd delete this thread, and re-announce with a "major" cross-media announce when the scan feature is ready and after the system has gone through a quiet, private, beta test with some actual retailers who would like to be part of the news release.
-
It is native android so it runs extremely fast.
Is it native Android connected to the hosted wallet infrastructure of the OpenLedger server?
If so, does it mean you've ported the whole client-side JavaScript code-base to native Android?
Ported, no. This has been written from scratch. You guys can see the code in a few weeks when I upload everything to github for forking etc :)
+5%
It's really amazing how efficient you are.
-
Amazing! Any other direction? No just moooooooooooooooonnnnn bts please give me a.mooooooooon time 8)
-
Fantastic stuff.
So if there are no fees, how do you make an income off the service?
-
Awesome job @kenCode
-
you guys need a map too. you know, where stores can show that they accept currency
we did the signs in 44 languages too:
https://bitsharestalk.org/index.php/topic,21754.0.html
plus, BlockPOS is having it's own little logo designed right now, something small like the Cirrus, Star and other networks that you see on the back of your debit cards. I want BlockPOS to be thought of as a network in the same way. if the merchant or vending machine etc accepts crypto, you will see the BlockPOS logo.
For something like this, I would have expected a bigger more prominent well planned out launch across media outlets etc.
If it was me, I'd delete this thread, and re-announce with a "major" cross-media announce when the scan feature is ready and after the system has gone through a quiet, private, beta test with some actual retailers who would like to be part of the news release.
Our funds are very limited at the moment, but if we secure an investor then "bigger" is exactly what we will do. I will integrate with at least 10 different POS systems and have mass market media hit around the world all at the same time. Make BlockPOS something that all merchants have heard of and know they need.
Fantastic stuff.
So if there are no fees, how do you make an income off the service?
Thank you MrJeans :)
The small network fee is charged to the user, not the merchant:
https://steemit.com/crypto-news/@kenCode/smartcoins-pos-the-free-way-for-companies-to-accept-crypto-currencies
Amazing! Any other direction? No just moooooooooooooooonnnnn bts please give me a.mooooooooon time 8)
Thank you bitsharesbrazil :)
Yes, Chris and Ridrigo are out there marketing us (personal, and phone meetings) so that we can ramp this up asap. With a little money I can start integrations of 5 to 10 at a time since the libraries are all coded now. As always I will keep you guys informed of our progress, we need your help too, word of mouth is everything.
Awesome job @kenCode
Thank you cylonmaker2053 :)
+5% It's really amazing how efficient you are.
Thank you jakub :)
-
It's worth a shot to put together a clear cut worker proposal with achievable goals. We might be able to get everyone on board with this as you have shown an actual product with REAL WORLD potential. This is huge.
-
hell yeah, ill vote for it
-
It's worth a shot to put together a clear cut worker proposal with achievable goals. We might be able to get everyone on board with this as you have shown an actual product with REAL WORLD potential. This is huge.
@kenCode , if you've managed to create a native Android library that handles private keys in a secure manner - IMO this alone is worth a worker proposal.
-
There is a way you can support this and share in the profits generated...
Buy the OPENPOS token on the dex
-
There is a way you can support this and share in the profits generated...
Buy the OPENPOS token on the dex
Bingo, this will help us fund further development and marketing by @Chris4210 and @Rodrigo10
Just PM Chris if you can place a larger order and he can cut you a deal I'm sure.
OPENPOS holders get to share in the rewards from the transactions at the POS systems, so in my opinion if you're not looking at it you will be missing out on the opp of a lifetime, seriously, this is huge guys. The meetings that we have had with major players over the last couple weeks is going to kick our development into overdrive and you will be able to finally see what I am really capable of.
-
There is a way you can support this and share in the profits generated...
Buy the OPENPOS token on the dex
Bingo, this will help us fund further development and marketing by @Chris4210 and @Rodrigo10
Just PM Chris if you can place a larger order and he can cut you a deal I'm sure.
OPENPOS holders get to share in the rewards from the transactions at the POS systems, so in my opinion if you're not looking at it you will be missing out on the opp of a lifetime, seriously, this is huge guys. The meetings that we have had with major players over the last couple weeks is going to kick our development into overdrive and you will be able to finally see what I am really capable of.
I think the reason the price of OPENPOS is low is because there hasn't been any buybacks yet since the software is just finishing up. Once the first couple buy backs start, that should inspire more confidence from investors. If what Ken is saying goes through, I'm guessing many of us will be very happy with our investment.
-
There is a way you can support this and share in the profits generated...
Buy the OPENPOS token on the dex
Bingo, this will help us fund further development and marketing by @Chris4210 and @Rodrigo10
Just PM Chris if you can place a larger order and he can cut you a deal I'm sure.
OPENPOS holders get to share in the rewards from the transactions at the POS systems, so in my opinion if you're not looking at it you will be missing out on the opp of a lifetime, seriously, this is huge guys. The meetings that we have had with major players over the last couple weeks is going to kick our development into overdrive and you will be able to finally see what I am really capable of.
I think the reason the price of OPENPOS is low is because there haven't been any buybacks yet since the software is just finishing up. Once the first couple buy backs start, that should inspire more confidence from investors. If what Ken is saying goes through, I'm guessing many of us will be very happy with our investment.
Don´t worry, we are hustling hard here. We just bought the first full demo equipment (POS station, tablet plus software) to demonstrate our product to merchants. We will produce some short video tutorials as soon as the hardware arrives and show how to use the system. A bigger ANN will follow shortly after.
-
Fantastic stuff.
So if there are no fees, how do you make an income off the service?
Thank you MrJeans :)
The small network fee is charged to the user, not the merchant:
https://steemit.com/crypto-news/@kenCode/smartcoins-pos-the-free-way-for-companies-to-accept-crypto-currencies
[/quote]
Makes sense.
This would be really great in Zimbabwe, where the local currency has defaulted and people use up to 13 other currencies. 4 official currencies. If people could pay in whichever currency they want and the merchant accept in the currency they want...
-
yo great news!
getgemz is dissolved i think
https://bitcointalk.org/index.php?topic=1470864.0;all
why dont we buy their IOS app and then release it with a slight "rebrand"
I don't know how they got Apple to approve their app, its just too bad it sucks compared to Ken's
What is their IOS intellectual property worth to us ?
-
Left to right..
Chris, me, Rodrigo, JP and Martin at yesterday's investor conference here in Munich..
(https://ipfs.pics/ipfs/QmSo4rufug5dFuSXUaELBo4TU8KNHNk19LqfCjcUcw1Kon)
edit: (Leopold was holding the camera)
-
Chris, me, Rodrigo, JP and Martin at yesterday's investor conference here in Munich..
edit: (Leopold was holding the camera)
Awesome! What was the investor conference about exactly? What was the audience? Did you guys make a pitch for Bitshares?
-
Chris, me, Rodrigo, JP and Martin at yesterday's investor conference here in Munich..
edit: (Leopold was holding the camera)
Awesome! What was the investor conference about exactly? What was the audience? Did you guys make a pitch for Bitshares?
We are now going to secure some more funds for marketing Bitshares, BlockPOS, Stealth, Graphene-IPFS, ECHO and a slew of other projects we are doing. I think 8 different VC firms showed up yesterday from around the world.
The BitShares Munich team is growing fast, lots of amazing talent with us now. They will take a stake in our private projects just like OPENPOS holders get, but it is worth it to me since we are now ready to unleash a few of our products to the public. We need to push the marketing HARD now and dominate the crypto space. Everyone will know about Graphene soon.
If you haven't started a Meetup group in your local town yet, NOW is the time!!!
https://secure.meetup.com/create/
-
Chris, me, Rodrigo, JP and Martin at yesterday's investor conference here in Munich..
edit: (Leopold was holding the camera)
Awesome! What was the investor conference about exactly? What was the audience? Did you guys make a pitch for Bitshares?
We are now going to secure some more funds for marketing Bitshares, BlockPOS, Stealth, Graphene-IPFS, ECHO and a slew of other projects we are doing. I think 8 different VC firms showed up yesterday from around the world.
The BitShares Munich team is growing fast, lots of amazing talent with us now. They will take a stake in our private projects just like OPENPOS holders get, but it is worth it to me since we are now ready to unleash a few of our products to the public. We need to push the marketing HARD now and dominate the crypto space. Everyone will know about Graphene soon.
If you haven't started a Meetup group in your local town yet, NOW is the time!!!
https://secure.meetup.com/create/
Sounds like things are going well and moving fast Ken.
Couple questions I have, who are "they" that will be taking a stake in your private projects? Are the VC's or new team members? How will they be taking a stake, by investing in OPENPOS? Are these private projects still part of the OPENPOS investment?
-
Chris, me, Rodrigo, JP and Martin at yesterday's investor conference here in Munich..
edit: (Leopold was holding the camera)
Awesome! What was the investor conference about exactly? What was the audience? Did you guys make a pitch for Bitshares?
We are now going to secure some more funds for marketing Bitshares, BlockPOS, Stealth, Graphene-IPFS, ECHO and a slew of other projects we are doing. I think 8 different VC firms showed up yesterday from around the world.
The BitShares Munich team is growing fast, lots of amazing talent with us now. They will take a stake in our private projects just like OPENPOS holders get, but it is worth it to me since we are now ready to unleash a few of our products to the public. We need to push the marketing HARD now and dominate the crypto space. Everyone will know about Graphene soon.
If you haven't started a Meetup group in your local town yet, NOW is the time!!!
https://secure.meetup.com/create/
Sounds like things are going well and moving fast Ken.
Couple questions I have, who are "they" that will be taking a stake in your private projects? Are the VC's or new team members? How will they be taking a stake, by investing in OPENPOS? Are these private projects still part of the OPENPOS investment?
Thanx @lil_jay890
Originally, we were just going to build a wallet and integrate with Odoo, but I managed to build 4 products instead of 2. :)
I think with all of the products that we are launching, systems that we are integrating with, things that we are bolting on to Bitshares and so on that we need to raise substantial capital and actually go public. It only makes sense to give OPENPOS holders a bigger stake than we had originally planned because without you guys we never would have been able to create these first four products (BitShares Wallet, Smartcoins POS for Odoo, standalone POS (runs on any android device), and now the Smartcoins Wallet (native android). I don't want to just market to individual stores or chains, I want to market Bitshares and our products to the world now. We're ready. Bitshares is ready.
So, the VC's we have been talking to (at least 60% of them so far, various meetings over the last month) are absolutely stoked about what we have built, are currently building and our vision for future products and BlockPOS integrations. They would not have come all the way here to Munich to see us unless they saw value.
Right now, it's just Chris (CEO), Rodrigo (CMO) and I. We must keep our overhead as low as possible. We need to raise about $25K to last us for the next 3 months until the paperwork goes thru and we get the first deposit, so if you guys can donate more to the OPENPOS token that would be MUCH appreciated (as you can see, our bitshares-munich account is just about empty now). We still have to order a couple more tablets and counter mounts (these things are $300 each), plus have a couple professional videos produced, design and print localized marketing materials and ads, legal work, get ready for two huge upcoming trade fairs (need booth equipment, handouts, ads, promotional items, etc) and pay my Devs for a few more features that I want added to the BlockPOS systems and the new Smartcoins Wallet before I give them to the public. The VC's have also told us that their marketing departments will push this hard too. They know the decision-makers at Billion dollar retail, vending, gas and grocery chains so this launch is massive, we just need to survive the next couple months until we get the first deposit from them.
The VC's want a chunk of ECHO Industries UG (our German company). One of the VC's might even be able to get us traded on the London Stock Exchange.
I think OPENPOS holders are ultimately going to get a stake in our company too, but we need to get legal on that (as we can afford it) so that the tokens can be tied to the regular company shares in some way. I am not the finance guy, @Chris4210 handles all of that, but leave him alone for now please, he is swamped with spreadsheets and meetings and until we know more, this is about all I can share right now as I don't know how it will be handed out yet either.
So, if that doesn't get you fired up about the OPENPOS token I don't know what will. PLEASE contact @Chris4210 if you'd like OPENPOS as well, this is your last chance.
-
fyi, I have posted a few articles on steemit in hopes of raising awareness and some steem dollars to help us through the next few months, please take a look and Upvote if ya can :)
https://steemit.com/@kenCode
edit: sorry about the broken steemit link
-
Chris, me, Rodrigo, JP and Martin at yesterday's investor conference here in Munich..
edit: (Leopold was holding the camera)
Awesome! What was the investor conference about exactly? What was the audience? Did you guys make a pitch for Bitshares?
We are now going to secure some more funds for marketing Bitshares, BlockPOS, Stealth, Graphene-IPFS, ECHO and a slew of other projects we are doing. I think 8 different VC firms showed up yesterday from around the world.
The BitShares Munich team is growing fast, lots of amazing talent with us now. They will take a stake in our private projects just like OPENPOS holders get, but it is worth it to me since we are now ready to unleash a few of our products to the public. We need to push the marketing HARD now and dominate the crypto space. Everyone will know about Graphene soon.
If you haven't started a Meetup group in your local town yet, NOW is the time!!!
https://secure.meetup.com/create/
Sounds like things are going well and moving fast Ken.
Couple questions I have, who are "they" that will be taking a stake in your private projects? Are the VC's or new team members? How will they be taking a stake, by investing in OPENPOS? Are these private projects still part of the OPENPOS investment?
Thanx @lil_jay890
Originally, we were just going to build a wallet and integrate with Odoo, but I managed to build 4 products instead of 2. :)
I think with all of the products that we are launching, systems that we are integrating with, things that we are bolting on to Bitshares and so on that we need to raise substantial capital and actually go public. It only makes sense to give OPENPOS holders a bigger stake than we had originally planned because without you guys we never would have been able to create these first four products (BitShares Wallet, Smartcoins POS for Odoo, standalone POS (runs on any android device), and now the Smartcoins Wallet (native android). I don't want to just market to individual stores or chains, I want to market Bitshares and our products to the world now. We're ready. Bitshares is ready.
So, the VC's we have been talking to (at least 60% of them so far, various meetings over the last month) are absolutely stoked about what we have built, are currently building and our vision for future products and BlockPOS integrations. They would not have come all the way here to Munich to see us unless they saw value.
Right now, it's just Chris (CEO), Rodrigo (CMO) and I. We must keep our overhead as low as possible. We need to raise about $25K to last us for the next 3 months until the paperwork goes thru and we get the first deposit, so if you guys can donate more to the OPENPOS token that would be MUCH appreciated (as you can see, our bitshares-munich account is just about empty now). We still have to order a couple more tablets and counter mounts (these things are $300 each), plus have a couple professional videos produced, design and print localized marketing materials and ads, legal work, get ready for two huge upcoming trade fairs (need booth equipment, handouts, ads, promotional items, etc) and pay my Devs for a few more features that I want added to the BlockPOS systems and the new Smartcoins Wallet before I give them to the public. The VC's have also told us that their marketing departments will push this hard too. They know the decision-makers at Billion dollar retail, vending, gas and grocery chains so this launch is massive, we just need to survive the next couple months until we get the first deposit from them.
The VC's want a chunk of ECHO Industries UG (our German company). One of the VC's might even be able to get us traded on the London Stock Exchange.
I think OPENPOS holders are ultimately going to get a stake in our company too, but we need to get legal on that (as we can afford it) so that the tokens can be tied to the regular company shares in some way. I am not the finance guy, @Chris4210 handles all of that, but leave him alone for now please, he is swamped with spreadsheets and meetings and until we know more, this is about all I can share right now as I don't know how it will be handed out yet either.
So, if that doesn't get you fired up about the OPENPOS token I don't know what will. PLEASE contact @Chris4210 if you'd like OPENPOS as well, this is your last chance.
Thank you for the summation Ken. Some sort of prospectus that we could hand out and point investors to would be very helpful. This would take a lot of the initial unkowns out of the equation.
I'm a large holder in OPENPOS and from what I can tell we will be getting 50% of all fee's from the POS terminals. I'm assuming Echo will be keeping the other 50%. Getting a stake in the company is definitely an added incentive to accumulate OPENPOS. Referring to OPENPOS as "donations" though is going to be a turn off for many people. I know there is probably some legal reason for this, but it puts doubt in the back of an investors mind that Echo has an easy out to stop all buybacks of OPENPOS and keep 100% for themselves. I'm not saying you guys would do that, but bitshares holders have been bitten by this several times before.
All in all the project seems to be going good, and some enhanced clarity of and some more promotion should see the OPENPOS token grow
-
Thank you for the summation Ken. Some sort of prospectus that we could hand out and point investors to would be very helpful. This would take a lot of the initial unkowns out of the equation.
I'm a large holder in OPENPOS and from what I can tell we will be getting 50% of all fee's from the POS terminals. I'm assuming Echo will be keeping the other 50%. Getting a stake in the company is definitely an added incentive to accumulate OPENPOS. Referring to OPENPOS as "donations" though is going to be a turn off for many people. I know there is probably some legal reason for this, but it puts doubt in the back of an investors mind that Echo has an easy out to stop all buybacks of OPENPOS and keep 100% for themselves. I'm not saying you guys would do that, but bitshares holders have been bitten by this several times before.
All in all the project seems to be going good, and some enhanced clarity of and some more promotion should see the OPENPOS token grow
Yeah, we have to be careful with the terms that we use as we cannot give legal or financial advice. If an Odoo system charges 0.9% per transaction then OPENPOS holders get 0.6% of that which is actually higher than the 50% you mentioned.
As I/we know more and can get the legal stuff done, Chris will be posting that financial data here. We can't afford it just yet, but over the next couple months when the vc deposit is made then we will have the money to get that new stuff written up and published here asap.
Without the OPENPOS token, we never would have made it this far, so thank you to all who have it! Thank you to all who are helping us to launch into this next phase, it's time to Market these products now and develop many more.
As usual, I will keep posting updates here to the forum, youtube videos, and now to steemit.com as well..
-
at the DAHO.am Developer Conference today.. :)
https://steemit.com/crypto-news/@kenCode/bitshares-munich-now-at-daho-am-developer-conference
ps: sorry about the broken steemit link..
-
I've been looking into OPENPOS, sounds like an interesting UIA, the only concern I have is that the option "override_authority: ISSUER MAY TRANSFER ASSET BACK TO HIMSELF" flag is enabled - does this not mean you can recall all OPENPOS from holders in the future? :-\
-
I've been looking into OPENPOS, sounds like an interesting UIA, the only concern I have is that the option "override_authority: ISSUER MAY TRANSFER ASSET BACK TO HIMSELF" flag is enabled - does this not mean you can recall all OPENPOS from holders in the future? :-\
CCEDK/Openledger is the creator of the OPENPOS token and I have full faith in him that he would not do such a thing. He also has a good reputation here in the Bitshares community. Just let @Chris4210 know if you're interested and thank you!
-
I've been looking into OPENPOS, sounds like an interesting UIA, the only concern I have is that the option "override_authority: ISSUER MAY TRANSFER ASSET BACK TO HIMSELF" flag is enabled - does this not mean you can recall all OPENPOS from holders in the future? :-\
That is a general risk with UIA. Such a move would need a solid reason by the issuer himself. However, all historic balances can be recovered via the blockchain and a UIA pull should not affect any future payouts.
Please send me a pm if you would like to buy more OPENPOS. We only have a couple left.
-
Looking forward to trying this at my establishment.
-
Today we added "Employee Tracking" to BlockPOS so that Employees can just use their Bitshares account name to login to the POS with, be able to process sales, returns, refunds and exchanges (and the merchant can see which employee screwed the customer over). I have also made it so that Employees of the company can login with just their PIN or now a Draw Pattern (but Employees must now at least have a Bitshares account name registered on the blockchain).
These features are also being added to the new Smartcoins Wallet and POS systems, starting on Monday morning:
https://steemit.com/bitshares/@kenCode/smartcoins-wallet-v1-2-
-
Today we added "Employee Tracking" to BlockPOS so that Employees can just use their Bitshares account name to login to the POS with, be able to process sales, returns, refunds and exchanges (and the merchant can see which employee screwed the customer over). I have also made it so that Employees of the company can login with just their PIN or now a Draw Pattern (but Employees must now at least have a Bitshares account name registered on the blockchain).
These features are also being added to the new Smartcoins Wallet and POS systems, starting on Monday morning:
https://steemit.com/bitshares/@kenCode/smartcoins-wallet-v1-2-
Ken, you and your team are very encouraging and bring great value to this endeavor. Keep up the good work.
Cheers.
-
One suggestion for mobile wallet: notification service. Let user select types of notifications he wants to receive about his account, such as trade happened, funds received etc...
-
Ken, you and your team are very encouraging and bring great value to this endeavor. Keep up the good work.
Thank you @Louis :)
-
One suggestion for mobile wallet: notification service. Let user select types of notifications he wants to receive about his account, such as trade happened, funds received etc...
+5% +5%
Right now, when funds are received the wallet will sound the homer simpson "woohoo" and animate a couple things on the home screen, but you don't hear that if the wallet is closed. What I could do is have some sort of tsr running, as a wallet add-on that just checks for incoming funds, kinda like the gmail notifier. I will look into that. As for trades, that is a bit more than I want to add to this wallet. This wallet I just want to keep it simple and focused. In the future I might do a mobile wallet specialized for traders too.
-
Today we added "Employee Tracking" to BlockPOS so that Employees can just use their Bitshares account name to login to the POS with, be able to process sales, returns, refunds and exchanges (and the merchant can see which employee screwed the customer over). I have also made it so that Employees of the company can login with just their PIN or now a Draw Pattern (but Employees must now at least have a Bitshares account name registered on the blockchain).
These features are also being added to the new Smartcoins Wallet and POS systems, starting on Monday morning:
https://steemit.com/bitshares/@kenCode/smartcoins-wallet-v1-2-
Will the source codes be available? I like to compile one and try it.
-
Today we added "Employee Tracking" to BlockPOS so that Employees can just use their Bitshares account name to login to the POS with, be able to process sales, returns, refunds and exchanges (and the merchant can see which employee screwed the customer over). I have also made it so that Employees of the company can login with just their PIN or now a Draw Pattern (but Employees must now at least have a Bitshares account name registered on the blockchain).
These features are also being added to the new Smartcoins Wallet and POS systems, starting on Monday morning:
https://steemit.com/bitshares/@kenCode/smartcoins-wallet-v1-2-
Will the source codes be available? I like to compile one and try it.
As always I post to my github page /kenCode-de so when I am happy with the first version enough to release it on google play then watch my github. I will probably post the apk to IPFS as well :)
-
Please Upvote my latest work on the Smartcoins Wallet
https://steemit.com/crypto-news/@kenCode/smartcoins-wallet-roadmap
Thank youuuu! :)
-
[ANN] BlockPOS - The App that allows any Business to accept any Crypto-currency at Zero Cost
Integrated completely with your favorite store's Point Of Sale system
Looking for somewhere to spend your Ether? Your Bitcoin, Dash or Steem..?
Over the last few weeks we have been coding yet another mobile wallet, this one is named Smartcoins Wallet. It is native android so it runs extremely fast.
In this video, the Smartcoins Wallet is on the left, and on the right one of our POS systems has been installed on an old phone...
https://youtu.be/IyIWxm6pVD0?list=PLjbx3qSmDe7RYkRMIEuFyYyG7_vvKgou0
The merchant charges you a specific amount, you scan the QR code (we will put the new scanner in there next week) with your wallet, the merchant receives the currency that they want and you got to spend the crypto that you wanted to spend (Smartcoins/BTS/SBD/BTC/ETH/LTC, etc) and in a few seconds the merchant can automatically reward you with loyalty points (tradeable on the open exchange or can be traded in upon your next visit at that merchant for discounts).
Of course the wallets and Bitshares blockchain also support Overdraft Protection, 3 second blocks, 100,000+ transactions per second, eReceipts (the QR code (or NFC) sends a small pdf file to your phone), unlimited altcoins and other assets, automated accounting and full rewards card (loyalty points) features.
BlockPOS (the Smartcoins POS api/apps) can be integrated with nearly any existing POS system that you find at a grocery, retail, petrol, vending machines, restaurant or other business.
We still have a lot of UI/UX work to do and need to add just a few more features, but over the next few weeks I hope to have those finished as well. As usual, everything is open source, works with most crypto wallets (Mycelium, Jaxx, etc), and will be posted on github once we're happy with it.
more info --please Upvote! Thank You :)
https://steemit.com/crypto-news/@kenCode/ann-blockpos--the-app-that-allows-any-business-to-accept-any-crypto-currency-at-zero
https://steemit.com/crypto-news/@kenCode/smartcoins-pos-the-free-way-for-companies-to-accept-crypto-currencies
https://steemit.com/crypto-news/@kenCode/all-cryptocurrency-mobile-wallets-should-have-these-features
Sent from my iPhone using Tapatalk
-
This is amazing I look forward to using!
Sent from my iPhone using Tapatalk
-
Please Upvote my latest work on the Smartcoins Wallet
https://steemit.com/crypto-news/@kenCode/smartcoins-wallet-roadmap
Thank youuuu! :)
This link does not work.
-
fyi, I have posted a few articles on steemit in hopes of raising awareness and some steem dollars to help us through the next few months, please take a look and Upvote if ya can :)
https://steemit.com/@kenCode
edit: sorry about the broken steemit link
The @ symbol will throw it off every time. Copy and paste it. The @ is tagging kencode.
-
BlockPOS now on TV, and being promoted by a major European Bank :)
if you can, retweet please https://twitter.com/kenCode_de/status/743054533027368960
-
Anyone in the Munich area?
Please join us at our next Meetup to try out the new Smartcoins Wallet, BlockPOS "S" and more!
http://www.meetup.com/BitShares-Munich/events/231835372/
-
at night I will share all around :D if you could make a post in steemit is easier to promote too but not a problem. congratulations. :D
-
at night I will share all around :D if you could make a post in steemit is easier to promote too but not a problem. congratulations. :D
First public demo of the new Smartcoins Wallet and BlockPOS
https://steemit.com/crypto-news/@kenCode/first-public-demo-of-the-new-smartcoins-wallet-and-blockpos
-
+5%
-
We should be finished with the UI/UX update in BlockPOS for Odoo either tonight or tomorrow and will publish it to the odoo app store asap. We're just waiting on the new BlockPOS logo now from the designer (hopefully tonight). Anyway, got another video posted to the playlist showing the update:
https://www.youtube.com/watch?v=I6ZHa7o4nvA
-
This is huge.
-
awesome job @kenCode and team! I'd be really interested to hear about the first vendor who uses the payment app...
-
Thanx guys :)
Fyi, I uploaded another Smartcoins Wallet video today to our YT playlist.
(https://ipfs.pics/ipfs/QmRQaxgsLjJXFU2BYeVBSDJ9rmkCetEbE8oSyp89QgNkVD)
Please copy/paste this link into your browser to view it:
https://steemit.com/crypto-news/@kenCode/smartcoins-wallet-v1-0-1--upgrading-an-account-to-ltm-
edit: grrrrr this forum kills all steemit links. it even changes the kencode to kenCode GRRRR
-
Excellent well done!!
-
your link didnt work for me, but I went to steem n found the video, n its pretty cool ken...pretty good job.
-
Hey,
On my android device, I only have the tabs 'balances' and 'contacts'; both 'finder' and 'exchange' are greyed out, are they unavailable at the moment?
How do we use assets other than bts/usd/cny/eur?
edit: I've got version 1.0.5?
Thanks :)
-
Excellent well done!!
Thanx betax :)
pretty cool ken...pretty good job.
Thanx bitsharesbrazil :)
Hey,
On my android device, I only have the tabs 'balances' and 'contacts'; both 'finder' and 'exchange' are greyed out, are they unavailable at the moment?
How do we use assets other than bts/usd/cny/eur?
edit: I've got version 1.0.5?
Thanks :)
Yes, on that older BitShares Wallet we have ceased development for the time being. That wallet runs way too slow for my taste since we had to use apache cordova and phonegap (way too much system overhead). It supports all of Bitshares' Smartcoins and UIA's. It runs on a huge array of devices too since it is just javascript in a chrome wrapper. The new Smartcoins Wallet however, runs much faster, I wanted to create one that people are not annoyed with.
-
More images and video of BlockPay (used to be called BlockPOS) in action:
https://steemit.com/bitcoin/@kenCode/blockpay-being-rolled-out-in-de-fi-is-ru-tu-cn-ca-and-us-so-far
(dang steemit links, you must copy/paste the link and lowercase the username in it)
-
Great work as usual Ken, when can we test the new Android SmartWallet? :)
-
Great work as usual Ken, when can we test the new Android SmartWallet? :)
Thanx maemon :)
I was hoping to upload it to google play today, but i found a couple of little ui things that are just bugging me, so give us another day please. I think by eod monday i will be happy and will upload it to google play then.
-
Any update Ken? :)
-
Any update Ken? :)
It's on google play now, just awaiting their approval.
I'll announce it on steemit the moment it's published:
https://steemit.com/@kenCode
-
Its up! Testing it right now, everything is so much faster. GRATZ!
BTW, is it possible to generate a barcode to recieve other assets beside the default (AUD, BTC, BTS, CHF, EUR, GOLD, HKD, KRW, MXN, SGD, SILVER, TRY) assets.
For example, if I open a coffee shop, and I want to be able to issue and recieve my own reward points as payment etc?
thanks.
-
Its up! Testing it right now, everything is so much faster. GRATZ!
BTW, is it possible to generate a barcode to recieve other assets beside the default (AUD, BTC, BTS, CHF, EUR, GOLD, HKD, KRW, MXN, SGD, SILVER, TRY) assets.
For example, if I open a coffee shop, and I want to be able to issue and recieve my own reward points as payment etc?
thanks.
thanx :) please do NOT mention it to the public yet. on receive screen tap icon in bottom left corner to request specific amount or assets. lots of translation work to do before I want the masses to download it
-
hmm I've tried that, but i can only choose from a few pre-selected asset rather than other User Issued Asset as well.
Also, when I try to send my UIA, it says "No Internet Connection" Everything works fine when Im sending Bitshares though.
(https://drive.google.com/file/d/0ByUqIwz6FS4kVVJRMjN0V1Y4bXdMVm1VTkZ2UlNlVlZFRFE0/view?usp=sharing)
-
ull also notice that balances and transactions load slow as hell. this is wss latency so we need to fundraiser so we can get faster nodes up
-
Hopefully I can help you a little with the fundraising. I'll pm you the details!
-
Hopefully I can help you a little with the fundraising. I'll pm you the details!
Wow! That would be much appreciated, we really need it. There is one more version that I want to develop for BlockPay too before I release that to the public. Once I am happy with that then I'll get that app uploaded to google play as well in the next few weeks.
Thank you @maemon !
Please pm @Chris4210 (the BitShares Munich CEO/CFO) if you would like to invest. I know he still has some OPENPOS tokens left too... :)
-
BlockPay demo with Smartcoins Wallet
Please retweet and Upvote the steemit post there too if ya could, MUCH appreciated :)
https://twitter.com/kenCode_de/status/751467181796421632
-
Very impressive, Ken!
-
Very impressive, Ken!
Thank you tbone :)
-
BlockPay for Odoo - demo and proof of concept with Smartcoins Wallet
Please retweet:
https://twitter.com/kenCode_de/status/752860987179622400
Please Upvote and Share:
https://steemit.com/bitcoin/@kenCode/blockpay-for-odoo-demo-with-smartcoins-wallet
-
Our first attempt at a promo video for BlockPay here:
https://www.youtube.com/watch?v=bcuVSjR6gkk
Steemit Upvotes and Shares are MUCH appreciated:
https://steemit.com/steem/@kenCode/ann-blockpay-point-of-sale-system-for-all-digital-currencies
-
Looks fantastic KenCode. I'm based in the UK now and I was wondering if ambassadors here could be useful.
-
Looks fantastic KenCode. I'm based in the UK now and I was wondering if ambassadors here could be useful.
Ya know, I don't think there is an Ambassador in UK yet.
@Chris4210 @Rodrigo10 Can you guys confirm?
Can you please drop Rodrigo an email? This way he can email you back about the details (he does not use this forum much).
His email: rodrigo@bitshares-munich.de
Also, I did a post on steemit about this:
https://steemit.com/crypto-news/@kenCode/here-s-another-5-reasons-to-get-blockpay-out-there
Thanx so much KenMonkey, I hope you join the team! I know Rodrigo had mentioned that we have BlockPay Ambassadors in like over 30 countries now, so welcome! :)
ken
-
Looks fantastic KenCode. I'm based in the UK now and I was wondering if ambassadors here could be useful.
Ya know, I don't think there is an Ambassador in UK yet.
@Chris4210 @Rodrigo10 Can you guys confirm?
Can you please drop Rodrigo an email? This way he can email you back about the details (he does not use this forum much).
His email: rodrigo@bitshares-munich.de
Also, I did a post on steemit about this:
https://steemit.com/crypto-news/@kenCode/here-s-another-5-reasons-to-get-blockpay-out-there
Thanx so much KenMonkey, I hope you join the team! I know Rodrigo had mentioned that we have BlockPay Ambassadors in like over 30 countries now, so welcome! :)
ken
Sweet! Yeah, the British love their fintech I'm sure many are willing to embrace. I've been chatting to a few people here about cryptocurrency and a lot of businesses seem open to the idea.
-
The BitShares Munich CEO speaks on camera...
https://steemit.com/crypto-news/@kenCode/blockpay-here-is-the-blockpay-ceo
Please retweet:
https://twitter.com/kenCode_de/status/759069242675388416
-
The Dash community is the first to start advertising our BlockPay systems:
https://cointelegraph.com/news/dash-accepted-here-blockpay-pos-system-integrates-with-dash
-
The Dash community is the first to start advertising our BlockPay systems:
https://cointelegraph.com/news/dash-accepted-here-blockpay-pos-system-integrates-with-dash
+5%
-
Fiiiiiiiinally!!
[ANN] Smartcoins Wallet v1.0.5 released; multiple currencies, Loyalty Points, 3sec transactions, 44 languages, overdraft protection, eReceipts...
https://steemit.com/crypto-news/@kenCode/ann-smartcoins-wallet-v1-0-5-released-multiple-currencies-loyalty-points-3sec-transactions-44-languages-overdraft-protection
-
@karnal
Smartcoins Wallet v1.0.5 released on F-Droid:
https://f-droid.org/repository/browse/?fdfilter=smartcoins&fdid=de.bitsharesmunich.smartcoinswallet
-
@karnal
Smartcoins Wallet v1.0.5 released on F-Droid:
https://f-droid.org/repository/browse/?fdfilter=smartcoins&fdid=de.bitsharesmunich.smartcoinswallet
@kenCode
Awesome!!
I wish I had better news, but I installed the app, and when creating an account, a red X with a circle around it is all that ever happens.. I waited about 10 mins before giving up.
I am proxying through Tor (it's me, after all) - does the wallet connect to any endpoints "protected" by the horrid cloudflare? That will break functionality, as cloudflare throws a captcha, and the app has no clue .. happens with the default configuration for copay and greenaddress, for instance ..
-
If the blockchain can't sync, then you're sol. Sorry, wish I had better news. That little red x down there means that your phone is unable to connect to one of the Bitshares public nodes. Also, Android 5.0 (Lollipop) or higher is recommended.
-
If the blockchain can't sync, then you're sol. Sorry, wish I had better news. That little red x down there means that your phone is unable to connect to one of the Bitshares public nodes. Also, Android 5.0 (Lollipop) or higher is recommended.
The wallet talks TCP right ?
-
BlockPay promoted on The Merkle:
http://themerkle.com/blockpay-offers-cryptocurrency-and-traditional-ecommerce-solutions-at-zero-cost/
- disqus comments much appreciated... :)
-
I am so sick of hearing about Plutus.
The risks with Plutus far outweigh my ability to describe them all.
These plutus fanatics have no idea what they are in for. Worse yet, they refuse to even look at all the things that BlockPay and the graphene chain have to offer. They set their mind on one and ignore the rest, bashing us, wtf
Can you guys PLEASE upvote my reply to him where I mention "NFC is cool"...
https://steemit.com/crypto-news/@kenCode/ann-the-blockpay-pre-ico-and-the-four-ways-you-can-get-a-piece-of-it-usd
-
BlockPay pre-ICO detailed on Bitcoin.com News!
https://twitter.com/kenCode_de/status/769113484223184896
Please retweet, and/or leave nice Disqus comments to Jamie's article:
https://news.bitcoin.com/blockpay-businesses-zero-cost/
-
you guys remember all the problems I had with Apple? (trying to get the Smartcoins Wallet approved, over a month, 30+ Appeals to their decision too, what a f*kn nightmare)
even Mycelium got denied by Apple, it doesn't get any more mainstream, or larger market cap than that right now.
well, Apple is at it again:
https://news.bitcoin.com/apple-tells-jaxx-remove-dashpay/
these people make me sick.
how in the hell am i going to get BlockPay "S" for iOS approved? or ECHO?
-
That's.. absurd.
-
jaxx got dumped too. sounds like a desperate move from Apple, but whatever. Let them lose even more market share
-
Apple be like.. fake bitcoin wallets that steal users funds, no problem! approve them by the dozen, no review!
...
private cryptocurrencies to fight big brother: NO!
-
HEADS UP!
Only about 36 hours left of the BlockPay pre-ICO :o
https://blockpay.ch/newsroom/investor-relations/
or: https://www.ccedk.com/ico/blockpay
(https://s32.postimg.io/8eddtbnlx/Block_POS_Android6.png)
-
Upvote needed:
CoinTelegraph: http://disq.us/p/1bzc60y
and on steemit please:
https://steemit.com/crypto-news/@kenCode/blockpay-is-now-active-on-coinmarketcap-com-if-you-re-into-that-sort-of-thing
-
Please leave 5-Stars for BlockPay if you get a sec:
https://play.google.com/store/apps/details?id=de.bitsharesmunich.blockpay
-
BlockPay excitement is building...
http://bitcoinist.net/bitshares-munich-pre-ico/
http://thedashtimes.com/2016/09/18/bitshares-munich-launches-successful-13-day-pre-ico/
http://www.econotimes.com/BitShares-Munich-Launches-Successful-13-Day-Pre-ICO-307533
http://www.newsbtc.com/2016/09/19/blockpay-s-now-available-on-android/
https://medium.com/@b_64902/blockpay-s-now-available-on-android-21157e5755dc#.qh6bl5in1
-
RE: Building IPFS and IPNS support directly into "BlockPay Libs" engine.
We are working on a proof of concept right now (to be done by friday of next week) where IPFS is fully integrated and completely decentralizes BlockPay as well so that it is unstoppable. "BlockPay API" will use this new Libs engine for integration with other apps, websites, etc.
BlockPay has been modularized in a way that allows us to use shared components across all versions of BlockPay across all kinds of systems and Integrations that we do (such as Odoo, SAP, ticket machines, etc etc). IPFS is now being added which further decentralizes BlockPay components and makes upgrades much faster over time and easier. If for example, App Stores decide to ban crypto apps or modules, or ISP’s decide to block “unapproved” crypto, IPFS has solved these problems as well since the files which run BlockPay and access to the BlockPay app will no longer require an App Store’s approval, http or even DNS.
Please find today's progress update below:
Task-1: "Create basic Android app for POC."
Status: "Done"
Task-2: "Implementation of IPNS/IPFS in Android app."
Status: "In-progress"
Task-21: "Research on development of non-http android IPFS library."
Status: "In-progress"
- We started researching IPFS libraries for android and found that almost all the libraries are using IPFS http api to get files.
- The libraries we investigated are: js-ipfs-api, go-ipfs, py-ipfs-api, js-ipfs, go-ipfs-api.
- We worked on somehow running IPFS daemon on android devices.
- We found a library that was doing something similar to it, however it was in kotlen language instead of java.
- We created a basic android app and tried to create IPFS daemon in it.
- We were able to create the daemon successfully, and are now working to grab the app files from it.
Next friday I will be ready to post more videos of the latest POC.
We are breaking new ground with IPFS here, this essentially makes BlockPay unstoppable and rock-solid, so when the tyrants start clamping down on crypto and crypto apps, BlockPay will still prevail.
-
BlockPay now at all Augustiner biergartens and Wirtshaus am Bavariapark:
(https://ipfs.pics/ipfs/QmdCoZFZrbP6pA6496NXMFaPk92jNZkBFh16RUeKW3va9W)
Next comes their restaurant chain! :)
-
BlockPay now at all Augustiner biergartens and Wirtshaus am Bavariapark:
(https://ipfs.pics/ipfs/QmdCoZFZrbP6pA6496NXMFaPk92jNZkBFh16RUeKW3va9W)
Next comes their restaurant chain! :)
FANTASTIC Kencode. +5% +5% +5%
-
BlockPay laying down on the job..
(https://ipfs.pics/ipfs/QmPR5sAHC28v7GhT1mCjZMACwguMb7uKisHnMncE7bKw4w)
-
BlockPay, beer and yummy fun... 8)
https://steemit.com/crypto-news/@kenCode/blockpay-beer-and-yummy-fun
-
BlockPay - Day 2 of 4 at Oktoberfest and Bits & Pretzels events (some very sexy photos)
https://steemit.com/crypto-news/@kenCode/blockpay-day-2-of-4-at-oktoberfest-and-bits-and-pretzels-events
edit: a better link: http://steem.link/Rh3PC
Erik Voorhees (Shapeshift), @Chris4210 @kenCode and more:
(https://ipfs.pics/ipfs/QmNd6TnbYyYMGD9ugddYBtaeGTJsjza1LpSKiKAqPHxBJ4)
-
Update on BlockPay IPFS integration...
Task-8: "File which handles the coin logos, coin name, details about the coin, etc."
Status: "Done"
Task-5: "File which handles sending/receiving loyalty points and UIA tokens"
Status: "In-progress"
Task-12: "File which handles all css or stylization standards, color codes, font weight and sizes, etc."
Status: "In-progress"
- We started fetching images from IPFS as we were storing logos as base64 encoded strings in our json files.
- Due to base64 encoded strings files became too large and IPFS daemon was unable to fetch.
- we decided to put logos as separate png files and their names in the corresponding json files.
- This approach reduced the file size as well as time taken by IPFS to download.
- We stored the image files in android as IPFS was sending the content of image file.
-
BlockPay - Day 2 of 4 at Oktoberfest and Bits & Pretzels events (some very sexy photos)
https://steemit.com/crypto-news/@kenCode/blockpay-day-2-of-4-at-oktoberfest-and-bits-and-pretzels-events
edit: a better link: http://steem.link/Rh3PC
Erik Voorhees (Shapeshift), @Chris4210 @kenCode and more:
(https://ipfs.pics/ipfs/QmNd6TnbYyYMGD9ugddYBtaeGTJsjza1LpSKiKAqPHxBJ4)
We had a fun night with the local Blockchain community and some great international guest!! Thank you all for coming over to Wirtshaus am Bavariapark! +5%
-
Thanks for the continued updates. Your project has great potential.
-
Our IPFS proof of concept is 90% complete.
Here is a really boring video we did today showing how we interact with IPFS:
https://www.youtube.com/watch?v=PiMcZW1sux0 (roughly 6min long)
-
BlockPay just went live on coincap (http://coincap.io/BLOCKPAY)! I like the coincap UI better than CMC. Now if we can just get BlockPay listed on Blocktrades too... (I'm workin on it)
-
Thanks for the progress reports and the news about coincap.io is great! I just snatched up some more blockpay shares and I'm sure that I've joined a winning team!
-
Our new Engine (for BlockPay, Smartcoins Wallet, Echo and beyond)...
http://steem.link/pMJgn
-
I have some more good news, the Smartcoins Wallet will have full support for real Bitcoins, Dash and Steem soon (3 more chains). So, with just one mobile wallet, you will be able to hold the coins and assets from 4 different blockchains. I have a meeting on wednesday and thursday of next week about that to finalize who is doing which parts (it has to work with our new IPFS based BlockPay Core and BlockPay Engine). If all goes well, we will have that release of the wallet ready by Christmas.
Also, it looks as if we may be moving the BlockPay Core to C instead of Java, as this has helped us to port BlockPay Integrated to more hardware (such as the vending machines and gas pumps projects I mentioned earlier). The new Core and Engine should be ready for you by Christmas as well.
-
As of tomorrow at noon, we will start adding the support for the Dash, Bitcoin and Steem blockchains to the Smartcoins Wallet. This way, the users of those coins can use our wallet if they like to get the benefits from BlockPay such as Loyalty Points, eReceipts, and of course to start getting familiar with Smartcoins at the same time. Those communities are really missing out right now since they don't have mobile wallets that support all that stuff. i have 3 part-time guys working to add those 3 extra chains as fast as possible.
As of today, I broke out the different parts of our new BlockPay Core and BlockPay Engine IPFS-related stuff into 7 different repos:
https://github.com/kenCode-de?tab=repositories
so, as of Wednesday the 2nd, next week, you will start seeing our commits there. i have 3 full-time guys, and 8 part-time guys working on those repos. The new BlockPay Core relies on them to be able to load up the new BlockPay Engine from IPFS for the specific platform or device that BlockPay is installed onto, such as windows, mac, linux, vending machines, raspi's, etc.
as of thursday of this week (tomorrow) we will start the integration of Stealth with the Bitshares platform and if all goes well we should have most of it ready for testing by Christmas. I have 2 full-time guys, and 1 part-time guy on our Stealth team.
all of these things that we are coding right now are needed for the Echo app as well and I have 5 more guys on standby waiting for those components so we are knocking this out as fast as possible.
the new 1-step setup for BlockPay by the way is frign awesome, I think you guys will really like it.
keep an eye on my github, steemit blog, and right here in this thread for more updates to come...
-
@kenCode you are one of the last hope for bts to succeed. Thank you very much +5% +5% +5%
-
@kenCode you are one of the last hope for bts to succeed. Thank you very much +5% +5% +5%
there's nothing out there that can beat our platform in speed, scalability and features. why more businesses aren't building on it is beyond me.
-
Such awesome news!
-
Such awesome news!
Unfortunately the market doesn't think so... huge dump this morning
-
Looks like someone of the core team are going out. forme2cu, the 6th richest blockpay owner are selling all tokens.
-
Looks like someone of the core team are going out. forme2cu, the 6th richest blockpay owner are selling all tokens.
Nobody from the core team is selling BlockPay Tokens, and all three parties are well known. I don´t know forme2cu, but I am happy to connect and have a chat. The new BlockPay engine will be amazing.
-
@kenCode you are one of the last hope for bts to succeed. Thank you very much +5% +5% +5%
there's nothing out there that can beat our platform in speed, scalability and features. why more businesses aren't building on it is beyond me.
I'm gonna guess total transparency is a huge part of the reason. Especially over there, from what I gather, Germans tend to be serious about privacy ..
I think even today the lack of STEALTH is routinely minimized by the community; we automatically lost all relevant demographics: some rich dude doesn't want the whole world to know he just invested half a million in bitshares, your average crypto user (who may be fine with bitcoins' pseudoanonimity or really not even be aware that it's pseudonymous, not anonymous) sees public account names and public transfer amounts and runs away never to look back, and merchants and users alike are not interested in broadcasting their entire financial life to the entire world until the end of time.
Can't blame them - I myself have always done minimal transactions with BTS, and under several aliases, on different computers, all through proxy/vpn/tor, in a gynormous effort to keep identities unlinked. And I'm a technical guy, working in security - it's hard even for me to keep matters separate, average joe doesn't stand a chance.
Privacy was never taken seriously by the wallet developer(s) either, there is no proxy support, changing wallet from settings happily queries the now-active wallet using the same TCP connection (trivial for the server to correlate who is who - sure, nobody does this. maybe. how do we know?), and so on.
I hope I'm mistaken that the timing to get some privacy on this blockchain has since passed, time will tell.
Anyhow @kenCode - for sure you guys have done an awesome work, of course I'm not even putting that into question. BTS Munich is one of, if not the most, prolific group of entrepreneurs around here.
Last I heard, you were putting together a team to implement STEALTH -- are there any news on this, and most importantly, any ETAs? (next summer? :D)
-
@kenCode you are one of the last hope for bts to succeed. Thank you very much +5% +5% +5%
there's nothing out there that can beat our platform in speed, scalability and features. why more businesses aren't building on it is beyond me.
Anyhow @kenCode - for sure you guys have done an awesome work, of course I'm not even putting that into question. BTS Munich is one of, if not the most, prolific group of entrepreneurs around here.
Last I heard, you were putting together a team to implement STEALTH -- are there any news on this, and most importantly, any ETAs? (next summer? :D)
Thanx karnal :)
One of the long-time Bitshares Devs has agreed to help us with the Stealth UI when we get to that point.
Right now, I have 2 full-time guys (Gordon and Jose) doing all the blockchain-level code for graphene. Lots of existing code has had to be cleaned up first though, it's quite a mishmash in there. Final product will be wicked clean though. We are hiding all of the amounts and most of the metadata too, so Stealth is going to smoke everything else that is out there now. Fast, scalable, anonymous, untraceable, totally private... it's everything I'd hoped Stealth could become.
Right now, we are working on all of the IPFS implementation in C. The new BlockPay Core is in C as well. The IPFS and new Core should be ready by Christmas. If all goes well with Stealth, I really hope you guys can pop in to our testnet and start helping us with testing it out by Christmas as well. When we are ready for that, I will send you guys the testnet info then.
-
Right now, I have 2 full-time guys (Gordon and Jose) doing all the blockchain-level code for graphene. Lots of existing code has had to be cleaned up first though, it's quite a mishmash in there.
Erm .. the code is actually very clean and separated into functional parts. If I were you, I wouldn't mess with the existing code base if you want code changes to be merged into bitshares quickly.
Final product will be wicked clean though. We are hiding all of the amounts and most of the metadata too, so Stealth is going to smoke everything else that is out there now. Fast, scalable, anonymous, untraceable, totally private... it's everything I'd hoped Stealth could become.
That is what STEALTH can do today: Hide sender, receiver, amount and memo .. don't know what kind of meta data is missing ..
Right now, we are working on all of the IPFS implementation in C. The new BlockPay Core is in C as well. The IPFS and new Core should be ready by Christmas. If all goes well with Stealth, I really hope you guys can pop in to our testnet and start helping us with testing it out by Christmas as well. When we are ready for that, I will send you guys the testnet info then.
Looking foward to it!
-
BlockPay "S" v1.0.5 is now available for download on google play. Please update all installs!
https://play.google.com/store/apps/details?id=de.bitsharesmunich.blockpay
note: please update all brainkey PIN numbers to 8-digits instead of 6-digits. i added support for web wallet accounts too (numeric PIN's only though, not 8-digit brainkey passwords). by changing your brainkey PIN to 8-digits, this will allow you to use the same bts account inside of BlockPay as well as in your web wallet.
-
BlockPay "S" v1.0.6 released today:
https://play.google.com/store/apps/details?id=de.bitsharesmunich.blockpay
UI/UX updates, and beginning the implementation of a new Blocktrades API that will make signups with Blocktrades (for coin to coin bridging) a bit easier. Right now, the initial setup of BlockPay is still a pain in the butt because the user has to setup multiple accounts, but this new API will help our a bunch.
We are also making a lot of headway on our IPFS implementation in C. Over the next couple weeks we will be uploading a lot more to these repos:
https://github.com/kenCode-de
-
Security Alert: https://bitsharestalk.org/index.php/topic,23494.0.html
-
LOTS of progress being made on the android security audits, c-ipfs and stealth this week:
https://github.com/kenCode-de?tab=repositories
-
We are going to beat my Christmas deadline (completing our IPFS work for Stealth and BlockPay Core).
We also have the IPFS implementation in C running 1 week ahead of schedule:
https://github.com/kenCode-de/c-ipfs
https://github.com/kenCode-de/c-libp2p
https://github.com/kenCode-de/c-multiaddr
https://github.com/kenCode-de/c-multihash
https://github.com/kenCode-de/c-multicodec
https://github.com/kenCode-de/c-ipld
https://github.com/kenCode-de/c-iprs (on hold, lack of docs)
Config file is done, Protobuff needs to be figured out, r/w storage operations in progress, implementing lightningDB (instead of leveldb), c-ipns datastore is in progress (with speed improvements), node is in progress, cid is usable now but needs a use case, also in progress: c-libp2p routing, c-libp2p crypto, c-libp2p network, is-domain, proquint, pin, key, merkledag, daemon, c-libp2p tcp, sctp, utp, udp, udt and open_tcp.
Pull Requests welcomed!
We released a second debug apk of the android security update yesterday, and after this next security audit is done tonight, and it passes with flying colors, then I will probably feel comfortable enough to flip the servers back on and launch the update on google play by end of next week.
Also, by Christmas, we should have Stealth integrated with IPFS and the new graphene-ui well underway. At the same time we're building out the new BlockPay Core with IPFS so that BlockPay can be installed on anything (vending machines, cash registers, iOS, etc).
In next weeks update, I will try to include all the download links for you guys.
edit: Details posted to steemit: http://steem.link/wQXc4
-
Just a few more weeks and C-IPFS is ready for its first release! This is so exciting because C-IPFS will serve as the main component in the new Core for every single product we have created, will create, and all of the BlockPay Integrations that are stacking up right now, including a meshnet project but I will reveal more about that later.
c-ipfs storage is now in full swing (mekledag, links, blocks, etc). c-ipns is being finished up, it was running too slow before. is-domain is done. c-ipfs-node and c-ipld-node will be done by december 2nd.
The security upgrade that we have been working on for our android apps is almost done too, should be ready by friday of next week on google play, upgrades will be required to use our new server configs. We released another debug apk last night and running one more audit on it (as well as upgrading the Faucet itself to support our BIP39 and other lib mods). Also, we felt adding BIP39 support would be nice since Brainkeys are kind of annoying with all those weird words. The first transactions with this upgraded security model are now going through, ie: https://cryptofresh.com/u/bilthon-2016
Tons of work being committed for Graphene, some graphene-ui, C-IPFS, the Smartcoins Wallet and more:
https://github.com/kenCode-de?tab=repositories
As you know, the Smartcoins Wallet supports eReceipts, Loyalty Points, Overdraft Protection and a lot of things that no other mobile wallet out there can do yet. Well, starting next week we are also adding support for Bitcoins, Dash, Doge, Ether, Litecoin, Steem and SBD. Why? Because we can't wait for all those mobile wallet providers to add eReceipts, Loyalty Points and Overdraft Protection support in the near future. Those 6 additional communities will now be able to take advantage of all the things that BlockPay has to offer. As always, everything we build is open source though so that when they do get around to it, they can grab the code they need for their wallet upgrades.
See you in mumble today guys, have a great week ahead!
-
The security upgrade that we have been working on for our android apps is almost done too, should be ready by friday of next week on google play, upgrades will be required to use our new server configs. We released another debug apk last night and running one more audit on it (as well as upgrading the Faucet itself to support our BIP39 and other lib mods). Also, we felt adding BIP39 support would be nice since Brainkeys are kind of annoying with all those weird words. The first transactions with this upgraded security model are now going through, ie: https://cryptofresh.com/u/bilthon-2016
Nice to see BIP39 .. how do you deal with multiple accounts? I gave it some thoughts for Trezor integration (https://github.com/chainsquad/slips/blob/steem/slip-0048.md). Would love to hear your thoughts about this .. unless you go it entirely different, we could make your wallet be compatible with how trezor will deal with BIP39/BIP44.
Where can I read more about your implementation?
-
The security upgrade that we have been working on for our android apps is almost done too, should be ready by friday of next week on google play, upgrades will be required to use our new server configs. We released another debug apk last night and running one more audit on it (as well as upgrading the Faucet itself to support our BIP39 and other lib mods). Also, we felt adding BIP39 support would be nice since Brainkeys are kind of annoying with all those weird words. The first transactions with this upgraded security model are now going through, ie: https://cryptofresh.com/u/bilthon-2016
Nice to see BIP39 .. how do you deal with multiple accounts? I gave it some thoughts for Trezor integration (https://github.com/chainsquad/slips/blob/steem/slip-0048.md). Would love to hear your thoughts about this .. unless you go it entirely different, we could make your wallet be compatible with how trezor will deal with BIP39/BIP44.
Where can I read more about your implementation?
right now it's just code, but in a couple weeks i would definitely like to look at this before we begin the c-ipfs integration. everything will be posted on my github. working with Trezor would be amazing.
-
TONS of work done this week:
https://github.com/kenCode-de?tab=repositories
C-IPFS and BlockPay related:
Work continued on the development of c-ipfs, in the area of data storage. Blocks are now written to both the lightningdb database, and the /blocks directory. We also wrote tests to cover more code, and adjusted existing code to clean up memory leaks. Valgrind now runs fairly clean over our tests of c-ipfs.
The difference between what is stored in the /blocks directory and what is stored in the database is not totally clear yet, but this week will hopefully uncover the rest of it. While successfully writing to block storage is a big accomplishment, block retrieval isn't finished yet. This task is minor in complexity though. Also, block storage must now be leveraged to take on the MerkleDAG and the unixfs code that runs on top of it. This will allow for files to be placed in namespaces (aka: directories), be broken into pieces, and read/found by local and remote BlockPay or mobile wallet clients.
More c-ipfs and c-ipns (was running very slow) commits:
https://github.com/kenCode-de/c-ipfs/commit/8da6e2df690d698067b2cb5615cce12f00a1f3bd
https://github.com/kenCode-de/c-ipfs/commit/0f5964ad3cb6fca94651001b43e76ae0ef3032ec
https://github.com/kenCode-de/c-ipfs/commit/ac4cc8feaaef747295b8705fa7f1b6d43d72f4dd
https://github.com/kenCode-de/c-ipfs/commit/a21330af436c0b9c6e8628f6f15acf1f0e2d37c0
https://github.com/kenCode-de/c-ipfs/commit/47e035e29f8d4870b6a9def0cb1a397cb91ac5bf
https://github.com/kenCode-de/c-ipfs/commit/d761e6062b7e92b69b604d96e42b80d58f7ebad9
https://github.com/kenCode-de/c-ipfs/commit/cba5839f5623af89bd969a959de1a7b0012bf908
https://github.com/kenCode-de/c-ipfs/commit/75f86b4107f87489efcd7b4ebea230cb8e24dd71
https://github.com/kenCode-de/c-ipfs/commit/8f686f6115c613614382e4599d73aa5e8d118bd6
https://github.com/kenCode-de/c-ipfs/commit/e89b5515c24ed32334f7bff04224b79b19257e7e
https://github.com/kenCode-de/c-ipfs/commit/a4b6a14ea524689556e9f9cf927a3519c64c0e24
https://github.com/kenCode-de/c-ipfs/commit/9ba3112b9705d48b7a333f43a4d11a45c5ad5d8f
https://github.com/kenCode-de/c-ipfs/commit/33afac194a0d6e6f153d3408ebacb3a2565ba030
https://github.com/kenCode-de/c-ipfs/commit/316c880bd1354a4649302c4429559c9f681de69e
We've been redesigning go-ipld-node + go-ipfs/merkledag/node + go-ipld, etc. to actually work together in C as they can't be preserved in go's form, the languages differ too much. Creating merkledag nodes, which can either be links to other nodes or data nodes, these will process data stored in files in the future (with merkledag done) assure validity of data, etc.
Android Smartcoins Wallet and security audits:
This week we streamlined a bunch of code and moved more of it to the client side so that now hardly any trips to the server need to be made. By letting the client do more of the work, it has sped the app up a bit and greatly reduced bandwidth utilization. BIP39 support has been added too (real words, instead of brainkey "weird" words). During the security audit, we have also made some other improvements this week:
- Improved Websocket communication
- Create Account Activity
- Debugging Python server-side components
- Encrypt/Decrypt AES
- Compress/Decompress LZMA library
- Export / Import Bin File Library, compatible with old bin files now
- Export bin file Activity
- Import bin file Activity (in progress)
A bug with the transfer transaction was fixed. The problem happened randomly and because of that was not caught initially. The reason has to do with the strictness of the graphene network on its approval of signatures. Sadly the bitcoinj doesn't provide support for non-deterministic signature generation, so we had to be creative when coming up with a solution. A valid compromise was deemed to slightly change the expiration time of the transaction in order to generate a valid signature. It is important to note however that this has no visible impact whatsoever for the user and the transaction gets processed super fast as always.
Improvements were made to the QR-code generation mechanism. The reliance on a server for the QR generation, encoding and compression of the eReceipt data has been dropped. This has had a dramatic improvement in the speed of the generation of a QR-code. And of course to be able to generate the QR-code while off-line is also a major advantage in speed and bandwidth utilization. The corresponding change in the procedure of decompression and decoding the data when reading a QR-code with the camera also had to be adjusted, since a server was being used there too.
graphenej in progress, BIP39 support added and now being tested.
Stealth related:
Libsnark is now fully integrated, replaced libsodium crypto primitives, finished notes encryption/decryption and fully tested. UI now being worked on, will upload more screenshots soon.
-
TONS of work done this week:
https://github.com/kenCode-de?tab=repositories
C-IPFS and BlockPay related:
Work continued on the development of c-ipfs, in the area of data storage. Blocks are now written to both the lightningdb database, and the /blocks directory. We also wrote tests to cover more code, and adjusted existing code to clean up memory leaks. Valgrind now runs fairly clean over our tests of c-ipfs.
The difference between what is stored in the /blocks directory and what is stored in the database is not totally clear yet, but this week will hopefully uncover the rest of it. While successfully writing to block storage is a big accomplishment, block retrieval isn't finished yet. This task is minor in complexity though. Also, block storage must now be leveraged to take on the MerkleDAG and the unixfs code that runs on top of it. This will allow for files to be placed in namespaces (aka: directories), be broken into pieces, and read/found by local and remote BlockPay or mobile wallet clients.
More c-ipfs and c-ipns (was running very slow) commits:
https://github.com/kenCode-de/c-ipfs/commit/8da6e2df690d698067b2cb5615cce12f00a1f3bd
https://github.com/kenCode-de/c-ipfs/commit/0f5964ad3cb6fca94651001b43e76ae0ef3032ec
https://github.com/kenCode-de/c-ipfs/commit/ac4cc8feaaef747295b8705fa7f1b6d43d72f4dd
https://github.com/kenCode-de/c-ipfs/commit/a21330af436c0b9c6e8628f6f15acf1f0e2d37c0
https://github.com/kenCode-de/c-ipfs/commit/47e035e29f8d4870b6a9def0cb1a397cb91ac5bf
https://github.com/kenCode-de/c-ipfs/commit/d761e6062b7e92b69b604d96e42b80d58f7ebad9
https://github.com/kenCode-de/c-ipfs/commit/cba5839f5623af89bd969a959de1a7b0012bf908
https://github.com/kenCode-de/c-ipfs/commit/75f86b4107f87489efcd7b4ebea230cb8e24dd71
https://github.com/kenCode-de/c-ipfs/commit/8f686f6115c613614382e4599d73aa5e8d118bd6
https://github.com/kenCode-de/c-ipfs/commit/e89b5515c24ed32334f7bff04224b79b19257e7e
https://github.com/kenCode-de/c-ipfs/commit/a4b6a14ea524689556e9f9cf927a3519c64c0e24
https://github.com/kenCode-de/c-ipfs/commit/9ba3112b9705d48b7a333f43a4d11a45c5ad5d8f
https://github.com/kenCode-de/c-ipfs/commit/33afac194a0d6e6f153d3408ebacb3a2565ba030
https://github.com/kenCode-de/c-ipfs/commit/316c880bd1354a4649302c4429559c9f681de69e
We've been redesigning go-ipld-node + go-ipfs/merkledag/node + go-ipld, etc. to actually work together in C as they can't be preserved in go's form, the languages differ too much. Creating merkledag nodes, which can either be links to other nodes or data nodes, these will process data stored in files in the future (with merkledag done) assure validity of data, etc.
Android Smartcoins Wallet and security audits:
This week we streamlined a bunch of code and moved more of it to the client side so that now hardly any trips to the server need to be made. By letting the client do more of the work, it has sped the app up a bit and greatly reduced bandwidth utilization. BIP39 support has been added too (real words, instead of brainkey "weird" words). During the security audit, we have also made some other improvements this week:
- Improved Websocket communication
- Create Account Activity
- Debugging Python server-side components
- Encrypt/Decrypt AES
- Compress/Decompress LZMA library
- Export / Import Bin File Library, compatible with old bin files now
- Export bin file Activity
- Import bin file Activity (in progress)
A bug with the transfer transaction was fixed. The problem happened randomly and because of that was not caught initially. The reason has to do with the strictness of the graphene network on its approval of signatures. Sadly the bitcoinj doesn't provide support for non-deterministic signature generation, so we had to be creative when coming up with a solution. A valid compromise was deemed to slightly change the expiration time of the transaction in order to generate a valid signature. It is important to note however that this has no visible impact whatsoever for the user and the transaction gets processed super fast as always.
Improvements were made to the QR-code generation mechanism. The reliance on a server for the QR generation, encoding and compression of the eReceipt data has been dropped. This has had a dramatic improvement in the speed of the generation of a QR-code. And of course to be able to generate the QR-code while off-line is also a major advantage in speed and bandwidth utilization. The corresponding change in the procedure of decompression and decoding the data when reading a QR-code with the camera also had to be adjusted, since a server was being used there too.
graphenej in progress, BIP39 support added and now being tested.
Stealth related:
Libsnark is now fully integrated, replaced libsodium crypto primitives, finished notes encryption/decryption and fully tested. UI now being worked on, will upload more screenshots soon.
+5% massive update, thanks for that.
what's the ETA for re-adding app to playstore?
-
+5% massive update, thanks for that.
what's the ETA for re-adding app to playstore?
I'll probably be happy with the smartcoins wallet relaunch in the next few days, but to be safe timeline-wise, I will say 1 week or so give or take kind of sort of around then approximately roundabout roughly... :o
From that point, we will just put all those same updates into BlockPay and relaunch it just a few days after.
-
+5%
bump this beautiful update.
-
Would help with these situations:
https://steemit.com/steem/@charlieshrem/i-got-usd5-000-scammed-last-night-problems-with-the-modern-banking-system-by-charlie-shrem
-
+5%
bump this beautiful update.
Thanx fuzzy! Ok, so more uploads to my github this week:
https://github.com/kenCode-de?tab=repositories
C-IPFS and BlockPay related:
C-IPFS merkledag and data storage is under heavy development. Working with the "protobuf" protocol from google (data stream called Marshal and Unmarshal) was a requirement for storage (and probably networking in the near future), and we completed a very basic implementation of this late last night. We also added roll your own encode/decode, with helpers to make it easier. More features will need to be added as the use cases evolve, but this will be enough for now, for our needs.
Storage is a bear. At times it feels as if we're walking in mud. But then things start coming together on it. We're trying to be careful to not waste time on things we won’t be using.
Nodes with links will be finished up this coming week. Once nodes are a bit more finalized, namespaces (aka: directories) will need to be handled. These are not easy tasks, and are time-consuming. This coming week more of the storage "todos" are completed and we can move forward with the new BlockPay Core integrations.
More c-ipfs and c-ipns(lots of speed improvements thanx to the protobuf work) commits:
https://github.com/kenCode-de/c-ipfs/commit/496ae3ec6c13d1aaab1a630d8e7e8c425175d907
https://github.com/kenCode-de/c-ipfs/commit/f8723eb8c741a02dab3e7cc2096e989c27cb3425
https://github.com/kenCode-de/c-ipfs/commit/84f24797f4485b7b3eff14a99501a50a40f1fe9b
https://github.com/kenCode-de/c-ipfs/commit/7a3d0c5e0bf241d6126a125fc19fa8b3460b9af5
https://github.com/kenCode-de/c-ipfs/commit/73a76907258b1842dc77428f8cf756b3f7037b0a
https://github.com/kenCode-de/c-ipfs/commit/786bd5d80b729f33f0a97f331e0cdecfc8a87b49
C-IPFS to CJDNS protocol will be finished this week for our meshnet support. Everything becomes a node. Will reveal more on this later. The cryptography and IPv6 stuff should be done by tuesday. Tamper-resistance is built-in to C-IPFS, so this turned out to be the perfect marriage. If someone tries to hurt or stop BlockPay via http, ssl, dns, ddos or even killing the ISP itself, BlockPay now has its Plan B ready to go. (yeah, I have a lot of tinfoil)
Sealed up memory leaks and finished dnslink. Tons of additional work being performed/finished up this week on c-ipld (linked data), c-ipns, namesys, path and the command line interpreter.
We are also speeding up the Bridge (for shifting bitcoins/altcoins into Smartcoins, account creation etc) and I hired a UX girl to give the look a bit of a facelift in the next major version release, and make my dream of a 1-step setup a reality.
Android Smartcoins Wallet and security audits:
Added support for the 'account_update_operation' into our graphenej library being developed to enclose all graphene-related functionalities that might be re-used in other android (or java powered) projects. With this operation, it will now be possible to change permissions of any given account. The most relevant classes here are the AccountUpdateOperation, Authority and AccountOptions. I will post our graphenej open source on my github page once it's ready. This weekend I am doing a lot of beta testing first.
With this in place in the library it is now possible (and has been fully tested) to swap all keys for the owner, active and memo fields. It should also be possible (however this still has to be tested) to add an account as the authority for another account. For now only key authentication has been fully tested.
The immediate use for this newly supported feature is the swap of old keys for fresh new ones. And it will also be possible to give the user the possibility to change the controlling keys any time he/she desires.
More features updated: - Import new .bin (since we are adding support for 6 additional blockchains)
- Export/Import compatibility with old .bin files
- Encode/Decode Memo Operations (this was a living hell)
- Beta testing debug apk's before we relaunch on google play
- Testing new form of websocket for multiple accounts
- The new client-side version-10 QR codes are working perfectly
- BIP39 is now fully supported and will work with the additional 6 chains
- Support added for importing/exporting to/from web wallets and light clients
Hopefully publishing the Smartcoins Wallet to google play tonight or monday.
Stealth related:
Finished up Stealth memo encryption/decryption, running final tests this week. UI now being worked on, will upload more screenshots soon.
-
Great work as usual Ken!
Will the smartcoin wallet be on the google play store by today? Looking forward to testing it!
-
Great work as usual Ken!
Will the smartcoin wallet be on the google play store by today? Looking forward to testing it!
i think so, but no promises. since we have upgraded the key handling we are just trying to figure out today what to do with the old memos from old transactions. the plan right now is to just store the old memos in the local db. not sure how many people really need their old memos, but honestly i am thinking that a lightweight wallet is more preferable to 51% of the people out there than spending time adding a bunch of code just to view old encrypted memos in transactions that they had. anyway, once this last feature update is done, then i will republish the wallet to google play tonight or tomorrow.
we wrote an entire java library for this too that people can use if they like, i called it graphenej for all those mobile devs out there who want to build mobile wallets for graphene: https://github.com/kenCode-de/graphenej
edit: if you really really really need the wallet right now, it works great with new accounts, but still having some issues importing those old bin files. once the old bin files are importing properly, then i will publish the release on google play. just pm me though if you really need the debug apk from me right now.
-
a java library ... cool .. is there any documentation or intro material to it besides the code?
-
a java library ... cool .. is there any documentation or intro material to it besides the code?
nope, haven't had the time yet. i suppose once we finish it up next week, one could gen some via doxygen or something.
-
Every few hours we are making more commits:
https://github.com/kenCode-de?tab=repositories
C-IPFS and BlockPay related:
Regarding c-ipfs read/write storage, Merkledag is now done. The storage components are now importing files, splitting them if necessary, and saving them in a format for retrieval. With files being stored, now the work begins on overlaying a "unix like" interface over saving and retrieval. The notion of directories and files needs to be used so it looks like a traditional filesystem to the network and local clients. The primary goal in this final week (fingers crossed) is the implementation of directories and files, which will make c-ipfs look like a traditional filesystem.
Blocks are now written to the disk, and a reference to them is put in the lightningdb. Links to the child blocks are also stored within the block and in the database. With that out of the way, focus changes to storing path information (an overlay of unix directory and file operations), and connecting storage to the rest of c-ipfs and c-ipns.
Wiring in the networking pieces is the last big job that we foresee around storage. Command Line Interface should be done this coming week too. CJDNS support final tweaks also being finished up. C-IPNS now just needs libp2p-routing and namesys-protobuf and we should be good to go for the first formal Release before Christmas.
More c-ipfs and c-ipns commits:
https://github.com/kenCode-de/c-ipfs/commit/9ec06749f253c6a2b0ecea10fffc0022acd930ca
https://github.com/kenCode-de/c-ipfs/commit/aa49c7dc35c4693ea128cbd4380db9efa7130e38
https://github.com/kenCode-de/c-ipfs/commit/fea5d3b8bf62253168afabde5b4cb03c1e21ebc9
Android Smartcoins Wallet and security audits:
The 'account_update_operation' support developed for our graphenej library has now been introduced into the Smartcoins Wallet in two ways. The first one was by adding an extra option in the settings screen that will allow the user to manually update the controlling keys whenever he feels like it. It is a simple feature that can later be extended by adding more complex update options. Currently we’re just updating all 3 keys (owner, active and memo) at the same time, but more granular control over every key would also be possible, if the community wants us to add that (but adding too many features like this could make the wallet settings more confusing for people imo).
The second way in which the ‘account_update_operation’ was introduced into the Smartcoins Wallet was via an automatic update procedure. For this, it is required that the app recognizes old accounts from newly created ones. And of course, just apply the automatic key update to the old accounts. Since we can’t be sure that an account imported via bin backup is in fact an old account (after all, it could be just a bin backup imported from another service, like openledger) we decided to prevent the automatic update from accounts imported via bin backups. Also, in order to further safeguard the user’s controlling keys we’re automatically creating a new bin backup of the newly generated keys as soon as we receive confirmation of the successful key update operation, and storing it in the sdcard.
After a close inspection of the code that makes up the list of past transactions of a given user in the Smartcoins Wallet, it was decided to completely discard the current architecture in favor of a more sophisticated and reliable strategy that makes use of the native sqlite database provided by the operating system (android in this case). The most relevant classes for this new feature are in the newly created ‘database’ package. The idea here is to keep a persistent cache of the user’s transactions in order to avoid having to keep asking the network about this information over and over. Bandwidth is expensive. The network should still be contacted, but just for updates of the database. The UI is updated directly from the database, and as such the information is displayed almost instantly now.
The procedure was further complicated by the fact that the raw information provided by the ’get_relative_account_history’ API call has to be processed in order to be nicely displayed to the user. The API call refers to user and asset ids for instance, and we’re required to display user names and asset symbols and take in consideration each asset’s precision. Since this is a completely new implementation of this feature, all these details had to be taken care of and as a result, not all data that was previously being displayed is yet supported. The following is the list of information already ported to this new architecture: - Date
- Time and time zone
- From account name
- To account name
- Asset amount, correctly adjusting for the damn precision
- Asset symbol
- Equivalent values (at the moment of the transaction)
- Encode/Decode Memo Operations
Since we are adding support for 6 additional blockchains to the Smartcoins Wallet, we are also redesigning the homescreen just a bit so that the balances section can slide sideways so that you can view the balances of your additional cryptocurrencies if you own any. Bitcoin of course is the first chain being added, and this week we have finished up the BTC account-create method and are now building in the Overdraft Protection feature (in case you are at a BlockPay merchant and do not have enough Smartcoin to cover your bill, the wallet can cash out some of your BTC automatically to cover the balance for you). Once Overdraft Protection is done, then we have to build in the QR and NFC support next...
Due to our trip to Stuttgart (Chris, Sylvia and I) it put back the wallet release just a tad, but I will try to republish the Smartcoins Wallet to google play by tomorrow.
Stealth related:
We are working on a wallet api for new functions to test the graphene-ui stuff we're working on now. Shared key derivation for memo field encryption/decryption is updated now and we have run all the joinsplit tests.
On the graphene-ui, the Create Account window is done. Some of the Stealth ui features need to wait though until we formally Release our C-IPFS stuff around Christmas (9 more days aaahh!).
We created a branch for the ui stuff at the moment so bugs are easier to trace (https://github.com/kenCode-de/graphene-ui/tree/graphene-ui-dev-graphics-acc_creation).
For now the only visible change is the Create Account window which does as requested, and shows private/public keys if forms contain what they need. Stealth core and our c-ipfs stuff will be needed to complete this in order to hash check for the public key to show. We are nearing completion of the UI for transferring accounts. This week we are starting the transaction modals, and label creation/editing/deleteing, and then on to the send and receive windows themselves.
Once our Stealth ui stuff is a little prettier to look at I will upload some more screenshots.
-
Very good of you to write all those updates Ken!
-
Very good of you to write all those updates Ken!
Thanx serejandmyself :)
Just fyi, Chris, Rodrigo and Sylvia are posting BlockPay video blogs too:
https://www.youtube.com/channel/UCJl3M4kuMaihU-yUQvnexkg/videos
-
I just listened to Christoph's Blockpay update on Beyond Bitcoin (E185 2016-12-09). He mentioned a Stealth transaction would be fully invisible except for the time stamp. It would be able to compete w/ the likes of Monero and Dash. A full stealth transaction would cost roughly 40 cents. His stealth talk starts around the 01:42:00 hour mark.
I wasn't aware of all this and think this is a huge development. I thought stealth would only hide the transaction amounts. Considering all the hype from Monero and Zcash, I would've thought everyone would be pumping BTS. Are we going to see any of this info coming from the new Social Media Manager and Content Manager hired at Blockpay?
And how does the $0.40/txn compares to Monero or Dash? This amount seems a bit high.
-
Thanks kenCode +5%
-
I just listened to Christoph's Blockpay update on Beyond Bitcoin (E185 2016-12-09). He mentioned a Stealth transaction would be fully invisible except for the time stamp. It would be able to compete w/ the likes of Monero and Dash. A full stealth transaction would cost roughly 40 cents. His stealth talk starts around the 01:42:00 hour mark.
I wasn't aware of all this and think this is a huge development. I thought stealth would only hide the transaction amounts. Considering all the hype from Monero and Zcash, I would've thought everyone would be pumping BTS. Are we going to see any of this info coming from the new Social Media Manager and Content Manager hired at Blockpay?
And how does the $0.40/txn compares to Monero or Dash? This amount seems a bit high.
Yes, stealth will hide all sensitive information and just show "unknown send to the unkown unknown amount" . Plus a timestamp on the blockchain. We will share more news about our development over our social media channels soon too. However, stealth is another product of BitShares Munich and will be added to our products in 2017. It has been developed for our supermarket clients who want to gain more privacy in their daily business.
$0.40 USD/txn seems high at the beginning, however, I am convinced that stealth should be used more for high-value transaction and not micropayments. Also adding a higher price for privacy will keep black market money away because they can launder their money cheaper elsewhere. We are not interested in any illegal activities nor do we support black market trades. There is enough white market business for all of us.
-
RE: BlockPay - Chris, Rodrigo and Sylvia at Thrive Int'l:
https://vimeo.com/196627019
-
Another mountain of commits:
https://github.com/kenCode-de?tab=repositories
C-IPFS and BlockPay related:
Tons of work finishing up the data storage algo. The storage components are now importing files and raw data, as well as retrieving what was stored. - config file "ipfs init" is done
- cli is done (not robust, but it's enough for our needs) and usable for end users (or anyone who wants to start playing around with c-ipfs now)
- "ipfs add [filename]" done, still need "ipfs add -r [directory]"
- "ipfs object get [hash]" done, still need "ipfs object get [path]"
They all work today, but the hashes that you add are not perfectly compatible with the existing Golang ipfs implementation. By the end of this coming week, you should be able to do those commands, plus.. - “ipfs add [directory]” and “ipfs add -r [directory]” and the hashes will match the Go version.
- In IPNS, DNS is now implemented with the "ipfs dns" cli command completed as well.
- libp2p-routing is near completion, just a few more days on this one.
The goal for this last week was to get something installable. While an end user could install the application and use it, I do not feel the goal was reached. I feel that at a minimum, the following 3 items must be completed: - Storing of files (done) and directories (almost done)
- Go versions and C versions should perfectly generate and share the same hashes for the same file.
- Connecting and retrieving / sending data over a network. Not necessarily bitsharing, but the ability to get and share a file from/to peers.
What is planned for this coming week:
In order to share files between the C version of ipfs and other versions, the hashes must match perfectly. We are a lot closer to making that happen, but not yet. I am hoping this will be perfect in about a week. As well, the ability to import directories needs to be finished. That's almost done too.
Just a few of this week's IPNS commits:
https://github.com/kenCode-de/c-ipfs/commit/b914745b476926a5bd0d4c254aed8bec51707b5c
https://github.com/kenCode-de/c-ipfs/commit/a94aa609b968ffe4ad6bad0c7366212c4104a383
https://github.com/kenCode-de/c-ipfs/commit/41b7579f21b9ccdb10dc407d2055fa6e43fa8335
https://github.com/kenCode-de/c-ipfs/commit/6b9d205ef2c3b09c4e0511d10303d83259fedcc6
https://github.com/kenCode-de/c-ipfs/commit/b17403b61acbea5cf87a55f560705e30be11a243
https://github.com/kenCode-de/c-ipfs/commit/049078effcd5468c750292162dc9577ffe54ea86
https://github.com/kenCode-de/c-ipfs/commit/7691fe0dc223b42db415a1e7b7cf6ffadac9bb15
https://github.com/kenCode-de/c-ipfs/commit/5f22be643cfd50b7390778397a911fcedef32796
https://github.com/kenCode-de/c-ipfs/commit/a569159cc2355b9c04b97083575040a4e62ee0b6
So, the cli is ready if you would like to grab it from my github, and a download with the 3 remaining things above will be published in a week or so with the Release here:
https://github.com/kenCode-de/c-ipfs/releases
Android Smartcoins Wallet and security audits:
The automatic key update was deemed too dangerous and thus was replaced by a new more detailed walk through process, with more information about which accounts are being updated and the results.
The PIN/lock dialog as it was implemented, was very easily bypassed, so a more robust scheme has been introduced and applied over every activity in the app. At some point that introduced a bug that displayed the dialog when it was not supposed to, but that too has been fixed.
The support for memo encoding/decoding in our new graphenej library (https://github.com/kenCode-de/graphenej) was broken, in the sense that it was not following exactly the same procedure the network expected. As a result, memos sent and received by the app were not being properly encoded/decoded, sometimes displaying some garbage (like "**") instead. This was fixed and memo information was also introduced in the database schema. So now they appear properly in the list of transactions on the homescreen.
Also the support for the 'get_market_history' API call was added to graphenej. With this in place we'll be able to query the market historical data and get equivalent values for past transactions. This will be done only once upon app install, and kept locally in the database. Minor bugs and problems were fixed.
One user reports not being able to send the bitUSD out of his mobile wallet, so we are looking into that this week after the holiday.
eReceipts, Export features based on timeframe, and Equivalentvalue display has also been upgraded to use graphenej. Lots of speed improvements added throughout the app.
Regarding adding support for real Bitcoins: - Implementing CryptoCore Design (in progress). Since the Smartcoins Wallet will support 7 different blockchains, we are modularizing the code quite a bit more, streamlining where possible.
- Creating Bitcoin Account on testnet (done)
- Getting Balance from testnet (done)
Other than that, it's mainly just UI fixes at this point to take advantage of our graphenej and all the new backend security work that has been done. Plus, we now have interoperability with the web wallets and light client wallets.
Swapping out the keys on your accounts (if you desire) costs 0.2 BTS so make sure you have at least a little bit of BTS in the accounts that you want to leverage the new upgraded security model.
As always, never store more funds in your wallet than you can afford to lose. With your understanding of that disclaimer, the latest version of the Smartcoins Wallet can be downloaded from here:
https://play.google.com/store/apps/details?id=de.bitsharesmunich.smartcoinswallet
Stealth related:
All functionality for Stealth transactions consists of 3 layers: base crypto mech, joinsplit itself, and the graphene integration (https://github.com/kenCode-de/graphene/tree/stealth). First layer is completed and tested, the second is mostly completed, and the third is not ready yet (waiting on c-ipfs above). My guess, the way we are going, we might be able to have Stealth ready for launch by end of february (no promises). This includes public beta testing time on our testnet too. So, cross your fingers for us, we're rockin this hard.
The Stealth api emulator is running on our testnet already which is what the UI guys are working with, but the final api can be launched once the c-ipfs stuff (above) is completed. In other words, about a week.
Other items finished: - joinsplit implementation
- Stealth api emulator in wallet, interface, emulation, debug
- Installed local testnet to debug stealth wallet api
We've got some decent work done on the UI, but now the UI is on hold for a few days until the c-ipfs stuff (for Auto-Backup) is ready next week. At that point, the UI work can resume again and I can start uploading more of the screenshots.
-
RE: BlockPay - Chris, Rodrigo and Sylvia at Thrive Int'l:
https://vimeo.com/196627019
Is this the very same "Thrive" movement as in the 2012 movie of the same name created by Foster Gamble?
I think that was an A W E S O M E flick, and totally believe in it's thrust, especially the free energy movement on which I have experimented and confirmed actual phenomena, like magnetic monopoles which I confirmed by building this:
(http://www.mo-techgarage.com/images/vortexCoil.jpg)
-
Not sure Thom, you'd have to ask Chris. I love that flic though, have it in my favorites:
https://www.youtube.com/watch?v=lEV5AFFcZ-s
-
Anyone contacted BlueSystems? Please have a try.
http://www.blue-systems.com/contact/
They funded ZeroNet.
-
stealth by February all I care about! I'm not a criminal. thanks.
-
stealth by February all I care about! I'm not a criminal. thanks.
Stealth transactions (in my opinion) are imperative to the survival of Liberty. February is my goal for the formal Stealth launch, but this has to be perfect, via the cryptography that we have to work with right now. Zero Knowledge ("zk") transactions are the holy grail of financial privacy, and I want this to be impenetrable. Besides completion of the UI for Stealth, there was one final issue with Stealth that we had to tackle, called "trusted setup".
What is trusted setup?
zkSNARK allows us to implement the perfect anonymity, the only issue is the fact that verification of the proof requires some interaction among Prover and Verifier. They should generate some kind of “shared secret”, after that the Prover can prove something without disclosing any additional info. But this way is not acceptable in cryptocurrencies for transaction verification, because it's impossible to interact with the transaction issuer every time somebody verifies the transaction. The workaround for this issue is pre-generation of this “shared secret” (usually it is called public parameters, or "pp") for all transactions and Verifiers at the very beginning. Very roughly speaking this pp is the constant value in the zkSNARK library code. The problem is that if somebody knows some data (let’s call it “toxic waste”) that was used during this pp generation, he can counterfeit any proof that was generated with using this pp. Library authors didn’t include this pp in the original zkSNARK implementation code because it is difficult to prove that they didn’t know this toxic waste for this predefined pp. So every zkSNARK client app should invent the way to generate this pp and prove to the community the fact that they are not storing the toxic waste for this pp. If they can do that, then it is safe to use the same pp in every other app that uses zkSNARK in the future. Zcash was the first client app with the zkSNARK library and that’s why they should generate this pp. If this pp generation is safe, then we can use the same pp value. If we think this generation is not safe, then we can generate it one more time in another, safer way. If zkSNARK has the pp generated one time in a safe manner, then all the other apps that use it don’t need any trusted setup or something like this anymore.
What is wrong with Zcash trusted setup?
The only weak place in Zcash cryptography is in the pp generation, usually called the trusted setup. They found the way to generate it in a safe enough manner, but were criticized because it's still the weakest place in their system (but it’s still safer than many other cryptocurrency weak places are). They can generate this pp by several participants so that if at least one of the participants will not save his part of the toxic waste and share it with other trusted setup participants, pp generation will be safe and nobody can counterfeit the generated proofs. Their error was that they use a predefined small number of participants, so it's possible that the 6 participants weren’t honest and modified the pp generator code and saved their toxic waste parts. All other procedures were safe; there are several participants, if only one of the participants is honest then the generation is safe, and there are participants that are not associated with Zcash.
How can we improve upon their trusted setup?
Our main idea is to allow anyone/everyone to participate in the trusted setup who's interested in security. These participants should not only be the members of the Bitshares community, but there are at least several Zcash forks that need zkSNARK pp too. So we are preparing a generator (open source of course), that every web user can install and start it on a predefined date, and the network of these generators will generate safe pp for zkSNARK. If only one of these users will be honest and will not save his part of the toxic waste, the pp is safe and can be used (not only by Bitshares, but by any other zkSNARK client too (Zcash forks, for example)). So if you don’t want to trust anybody in trusted setup you can just participate in this setup and be sure it was honest by destroying your part of the toxic waste (you don’t need to do something special for this, just build the source code without modification and start up the generator).
The main risk in this case is performance (the more participants, the more generation rounds), so in the worst case we should limit the number of participants. We think it’s ok however, because Bitshares already has a set of trusted members (thanx to DPOS). It can be any number of Committee members, Witnesses, or Stakeholders, for example. We hope to create the algo without any participation limits and should be finished with it very soon.
We have kept the new algo (more or less) the same in our libsnark implementation (github.com/kenCode-de/libsnark), and mainly edited the build scripts to facilitate this “trustless” setup redesign. This procedure should be started only once and after that, its result will be hardcoded into the code. Stealth transactions will not require any additional actions from any Bitshares system participants.
BlockPay of course, will soon include this extra layer of privacy via Stealth transactions as an option in the Settings screen.
edit: ps: I will post my normal weekly update in just a few hours...
-
Tons of code uploaded to my github this week:
https://github.com/kenCode-de?tab=repositories
C-IPFS and BlockPay related:
To align the hashes with what is stored in the Go version of IPFS, the hashes must match. That was the purpose of these commits this week:
https://github.com/kenCode-de/c-ipfs/commit/914d3caaeda5cfbdcb2a9f5cf80012768b496262
https://github.com/kenCode-de/c-ipfs/commit/8d2aeab0167a7e5145d07659c6d0e5a03ef9fd41
https://github.com/kenCode-de/c-ipfs/commit/15b432c70e977b9682b35c9690e6a10b49f42b03
https://github.com/kenCode-de/c-ipfs/commit/1dcbf8962e14d490ee331668966b3dff2bc54754
https://github.com/kenCode-de/c-ipfs/commit/3004f1411a121c9e7a085e6945a6de93c452a8b4
https://github.com/kenCode-de/c-ipfs/commit/8f44c857db04812267928f69b69177ab8597949c
After that, we began working on importing of directories...
https://github.com/kenCode-de/c-ipfs/commit/9d77b2709f6e59b7dc388b7136466dd35b9e65df
https://github.com/kenCode-de/c-ipfs/commit/fa3dd77e96544863c238096a23442ddc28dd4263
..and making the directory hash match the Go version:
https://github.com/kenCode-de/c-ipfs/commit/396dfc6abc45d664c5240e002a3295fe991b0b67
We have now added the code to retrieve a file based on the hash of the directory and the path to the file:
https://github.com/kenCode-de/c-ipfs/commit/addb5ba302cdb102a6ec2362d64adb2a5655ed42
The storage system is now to a point where it is functional and installable. It is not perfectly tested, but a damn good number of use cases work.
What is planned for the coming week: - More testing / commenting / docs (the IPFS community will be helping us with this)
- Error handling around user input and better responses to the user
- Resolving files across networks
More c-ipfs and c-ipns(lots of speed improvements thanx to our protobuf completion) commits:
https://github.com/kenCode-de/c-ipfs/commit/00bf29b0fafc37e7e058c8cfa2d43d6b5c891fe9
https://github.com/kenCode-de/c-ipfs/commit/37bab54a5c7d7cb4015ec97bb0e9515f4f9c952e
https://github.com/kenCode-de/c-ipfs/commit/d9774095d3948afd4abd537ea8d80d42e77b96ea
https://github.com/kenCode-de/c-ipfs/commit/ef380f2a6915e978bbd9f28fb7a7a1b495c6e94d
https://github.com/kenCode-de/c-ipfs/commit/9d194ad484a540cad515c015ca203f8abb847200
https://github.com/kenCode-de/c-ipfs/commit/f7a029ade3422fe636373df721925d265bedcc16
..and more: - "ipfs add [filename]" and "ipfs add -r [directory]" are now both functional
- "ipfs object get [hash]" and "ipfs object get [path]" are now both functional
- namesys-protobuf, c-ipfs-node and CJDNS basic support are also complete
Early next week we will finish pin, routing, libp2p-routing and c-ipns.
The CLI was released right before Christmas, and we now have Pre-Releases ready for Linux and Mac here:
https://github.com/kenCode-de/c-ipfs/releases
We should also have a Windows, and first formal Release for all platforms ready by next week at the link above.
Android Smartcoins Wallet and security audits:
We found a very rare bug that was preventing the storage of newly created keys to persistent storage. The previous procedure was storing them in memory and just promoting them to the shared preferences once we got the response back from the network and the account update procedure was deemed successful. This of course leaves a small breach that would happen if something were to happen in case the account update was successful, but the network response failed to reach the user. The situation described before never actually happened, but it could be emulated by purposely crashing the thread at a very specific point. Most users are not going to try to crash a thread on purpose.
The code written to treat this very rare situation also took special care of checking if the stored key actually does match the public address of the "active" role of the account, and only then it proceeds to replace it. The described changes can be inspected in this commit (https://github.com/kenCode-de/smartcoins-wallet/commit/4ea07e741223680363225c5a038769988927a95f).
After having added support for the 'get_market_history' API call in our new graphenej library (https://github.com/kenCode-de/graphenej), this was introduced in the Smartcoins Wallet and used to obtain the historical market data, which in turn is useful to calculate the equivalent fiat values of past transactions. This was previously being done on-demand every time the app was restarted, a solution which was very inefficient and actually wrong, because the equivalent values were being calculated with current values, not past ones.
With the new changes introduced, after a batch of transactions is loaded and stored into the database, the app will perform a query looking for historical transactions that don't have an equivalent fiat value. With this in hand, the aforementioned 'get_market_history' API call is used to obtain historical market data and calculate the equivalent value.
Because not every token might have a very active market with the user desired Smartcoin, we make a 2-step equivalent value calculation. First calculating the historical relationship of the token with the BTS, and then in turn finding out how much that amount of BTS would have been in bitUSD or bitEUR (or the desired Smartcoin) at that point in time.
If the transaction was already made in BTS the first step was avoided, and if it was already a Smartcoin no conversion is needed of course. Every one of these special cases was treated and upgraded.
Also a mapping was created to match the location of the user with a set of Smartcoins. If no Smartcoin exists for a specific country (a situation that applies for most countries actually) then bitUSD is now used as a default.
The relevant commits for this work are:
https://github.com/kenCode-de/smartcoins-wallet/commit/0decd87e1f8160d98e7d77b458cae698072b67d0
https://github.com/kenCode-de/smartcoins-wallet/commit/ee7ac88eb45dd21fb19353d44f9e8f92bc029a51
https://github.com/kenCode-de/smartcoins-wallet/commit/39b581d17a36e230b779bd7e9451f5018bb1c060
And a more detailed description of the specific details about this procedure:
Transactions loading (on the home screen) - The procedure to load the database with historical transfers is somewhat complex due to the fact that what we want to display and what the API gives us is slightly different. Namely time and equivalent value information is missing. There is of course ways to obtain this data, but more on the specifics of this later. Let us first focus on obtaining the list of transactions and display whatever it already gives us.
The list of historical transactions is obtained by using the ‘get_relative_account_history’ API call. And even though this call has a hard limit on 100 operations per request, we can easily schedule a new request in case we note the user might have more than 100 transactions already. It is not really a problem to chain operations like this, since this procedure is only performed once upon installation to initially fill the database with operations performed prior to the apps' (Smartcoins Wallet and BlockPay both) install.
With this in place, we can already display information about what was sent, and if it was an incoming or outgoing transaction. A quick search to this newly loaded database can also give us the list of assets used and that information is used to obtain more information about each one of them. Specifically we would like to know each asset’s symbol and precision, in order to properly format them to the user. So that we can display USD 1.00 to the user instead of its raw value of 1000 for instance.
The first complication arises from the fact that the list of operations retrieved by this API call doesn’t explicitly have the time information in it. Instead each operation does indicate the block number in which it was included in the blockchain.
By taking the block number information however, we can then use the ‘get_block_header’ API call to get the UTC time for that specific block. The downside of this API call is that it doesn’t support batched calls. That is, a request has to be made specifically for every missing block header. This can be time-consuming, especially if we decide to load all historical transfer’s time information and then proceed to calculate equivalent values.
Since the user is more likely to be interested in the most recent transactions first, and recalling that this operation is only performed ONCE upon app install, it was decided to split the timestamp query and equivalent value calculations into batches. So this way the app will load all transactions first, and display the information about every transfer without any date and time or equivalent value first.
Then we’ll proceed to load date time information from top to bottom, but not going all the way down the list. But instead stopping at a specific batch size, and then proceed with the equivalent value calculation. In other words, don't annoy the user.
Please note that the equivalent value calculation depends on us having the specific date and time for every operation, since we’re using the ‘get_market_history’ API call, which takes a timestamp information instead of block number.
The timestamp query and the equivalent values thus are performed going from most recent to older transactions, which will appear low in the list anyways. Once this operation is finished, the app will just query the local database.
This initial database loading operation can take a while to conclude, but since it is done in the background by threads filling in the database the user doesn’t have to wait for it to conclude and is free to use the app. He can even interrupt the procedure by pressing the home button, and it will just resume from where it left when the app is reopened.
With the information about historical equivalent values in the databse, it was now possible to re-enable the "export to PDF/CSV" and "eReceipt" functionalities (which will be included in v1.5.6). This was done here:
https://github.com/kenCode-de/smartcoins-wallet/commit/a341882bb4e96c567be545be5c8641b2eb73b116
https://github.com/kenCode-de/smartcoins-wallet/commit/6e4325bfd6a51bc912a70b80879946e10c9e7c28
More features updated: - Caching for getAssets (more speed improvements)
- Changing BalanceFragment Structure (Separating the view from the logic for the future c-ipfs integration)
As always, never keep more money in your wallet than you can afford to lose. Latest release can be downloaded from google play:
https://play.google.com/store/apps/details?id=de.bitsharesmunich.smartcoinswallet
Stealth related:
Finishing the "trustless" setup algo now, see my details on that in the forum post just above.
UI now being worked on, will upload more screenshots soon.
-
By taking the block number information however, we can then use the ‘get_block_header’ API call to get the UTC time for that specific block. The downside of this API call is that it doesn’t support batched calls. That is, a request has to be made specifically for every missing block header. This can be time-consuming, especially if we decide to load all historical transfer’s time information and then proceed to calculate equivalent values.
I wonder if block time could be just calculated from: Head block time, number of block with transaction and average block production per second. If that average keeps tight result could be accurate enough.
-
By taking the block number information however, we can then use the ‘get_block_header’ API call to get the UTC time for that specific block. The downside of this API call is that it doesn’t support batched calls. That is, a request has to be made specifically for every missing block header. This can be time-consuming, especially if we decide to load all historical transfer’s time information and then proceed to calculate equivalent values.
I wonder if block time could be just calculated from: Head block time, number of block with transaction and average block production per second. If that average keeps tight result could be accurate enough.
Interesting point. I actually don't know how the bitshares, being a distributed network manages to keep producing blocks in such a precise 3 seconds interval. But regardless of that, I guess the real question here would be how precise the block production is. I did some quick comparisons and produced this preadsheet https://docs.google.com/spreadsheets/d/13H4qqgMosIb_ON3dbBqBIKna_3Z1SLLIRCRZgC2X7sk/edit?usp=sharing (https://docs.google.com/spreadsheets/d/13H4qqgMosIb_ON3dbBqBIKna_3Z1SLLIRCRZgC2X7sk/edit?usp=sharing).
As you can see if the block are closely spaced the error is low. For market data I suppose we don't need extremely high time accuracy, but anything that deviates more than an hour from its "real" trading time might be too much.
-
Lots of updates this week:
https://github.com/kenCode-de?tab=repositories
I am very sick tho. First my girls got it, then my wife got it, now I have it. Going back to bed now. Will try to post a more thorough update for you in a couple days.
-
Good work, get well!
-
Still got a waterfall coming out of my nose and a massive headache, so I will briefly try to post some of last weeks progress:
C-IPFS and BlockPay related:
https://github.com/kenCode-de/c-ipfs/commit/9882c28743f8d1669e966afddfcbeb628d948c54
https://github.com/kenCode-de/c-ipfs/commit/61d0adc445445a7fbe689203915a544d7b695756
https://github.com/kenCode-de/c-ipfs/commit/4c330e29bef529f5de854b3ee54506d6253e82aa
https://github.com/kenCode-de/c-ipfs/commit/6448a35a72ee87a5f137d6f0b0e1030b357233b7
https://github.com/kenCode-de/c-ipfs/commit/3c3474eacd859cacc1050e6474500e23fc954f78
The upgrade of BlockPay to v1.5.0 (with graphenej) should be done, tested and posted to google play by friday the 20th.
Android Smartcoins Wallet and security audits:
The wallet is on google play (v1.5.7), but I still need to add some more UI tweaks to the transactions list, the way dates and equivvalue are displayed, etc. Those little things should all be done in a week or so and then a v1.5.8 will be published to google play.
Stealth related:
Finishing the "trustless" setup algo now so that Stealth Core is complete and we can resume work on the UI.
-
Tons of updates this week!
https://github.com/kenCode-de?tab=repositories
C-IPFS and BlockPay related:
On C-IPFS, need to fix the windows resolver, gcc for windows doesn't have libresolv. Next week we'll work on c-libp2p-peer and c-ipfs-routing, so we can finish up namesys/publisher and can launch the final Release. C-IPNS can resolve names, but not publish yet.
We got the first debug apk of BlockPay v1.5.0 packaged up yesterday, so final bug checking over this coming week before I launch it on gplay.
We should also have the fist formal Release of C-IPFS ready for public download by end of next week.
Android Smartcoins Wallet and security audits:
Smartcoins Wallet
An efficiency problem has been detected in the smartcoins wallet by analyzing the mechanism by which the app gets notified of account balance updates. It turns out the 'set_subscribe_callback' API call will get us subscribed to a feed of information that notifies us of many more events than we are asking for. Worst of all, is that these notifications do not stop when the user leaves the app, instead just keeps on running in the background consuming both network traffic and battery.
There seemed to be a mechanism in place to try to stop this notifications, but it wasn't working every time. Instead of trying to debug the existing code, we actually decided to perform call to the 'cancel_all_subscriptions' at the onPause life cycle callback of every activity of the app. This is not the best possible solution to the problem, because you still get a unsubscribe-subscribe pair of messages sent on every activity transition, but since the focus of this week was blockpay and considering that any other "better" solution could end up leaving situations where the feed is not canceled after the user leaves the app, it was decided to opt (for now) for the most simple but secure fix. So, after the BlockPay v1.5.0 launch next week, we will revisit this one and tighten the network usage down even more.
BlockPay
The same classes previously developed for smartcoins wallet and included in our graphenej lib that made possible to remove the dependency on the server components at the QR-code creation step when dealing with smartcoins. For bitcoin we still need to fetch the QR-code data from the bridge, which in this case is the blocktrades API. This work can be found at this commit bc2415bcb60aa09b50dad8f1e5877a55b67f1574.
Different methods have been tried in order to obtain an accurate exchange rate between smartcoins, but the one that finally worked best both in terms of speed and exchange data accuracy was to take the data from the witness feeds. With the conversion rate in place, it was possible to replace the calls that made the same thing to the shared components and create the same output classes in order to "fill the void" left by the removal of the server components.
In order to be able to display a list of smartcoins, the raw list of assets obtained from the witness had to be filtered. Telling a UIA from the rest is easy, since they lack a field (bitasset_data_id) that both smartcoins and prediction market tokens have. Now in order to be able to tell these two apart, a 'get_objects' API call had to be performed on each of the id's indicated by the 'bitasset_data_id' field. In the response object, the 'is_prediction_market' field was used in order to verify the specific class of a given witness-fed asset. With this in place it was possible to present the user with a list of only smartcoins. This processing was previously also being done in the server side by the server components, but the overhead of doing it in the mobile device is not so much since we just require 2 API calls and everything is stored locally for future use. The added support for the 'get_objects' API call has also been included in our new graphenej library. This work can be found at commit 01b8a6187bd83392cb4c99a0c4e37436f152afb5
The mechanism by which balance updates were being handled was broken, a new scheme of BalanceListener and BalanceNotifier was built using the existing infrastructure that receives the network notification feed. The app is now reacting to incoming transactions while in the activity displaying the QR-code to the user. And the same efficiency problem that was present in the smartcoins wallet was also affecting the blockpay app. But it was fixed as well. This work can be found in the following commit: d7a552bfcf7b6597251ce52e126ffc72e4a66299.
The marketcap data, that was previously obtained from the server components is now retrieved directly from the 3rd party API, we still need to use this response though.
Ideal situation here is that BlockPay will no longer rely on any third party api's whatsoever, and once 2.0 is built and launched, our apps won't even need to rely on http, ssl or dns anymore either, furthering the app security and endurance even further.
Stealth related:
Many improvements done to our new "trustless setup" algorithm, no viewable code on github yet, algorithm development only. Incremental merkle tree implementation and tests, https://github.com/kenCode-de/graphene/commit/c1b1d2c6e3a1d9a53efb53e277f4296cd274a7d8
Once I feel comfortable with the new algo, then we can resume the work on the UI and connect it to our graphene coding.
-
Tons of updates this week!
https://github.com/kenCode-de?tab=repositories
C-IPFS and BlockPay related:
We are just finishing up the c-libp2p and c-ipfs-routing components this week (eliminating reliance on http, ssl and dns is no easy task) and will have the first formal Release of C-IPFS for Linux and Mac published here by friday, january 27th:
https://github.com/kenCode-de/c-ipfs/releases
So, with Storage and Routing completed and the first formal public Release of C-IPFS by end of next week, we can finally begin on the "2.0" architecture for BlockPay 2.0 as well as the Smartcoins Wallet 2.0 by end of next week. The mobile wallet will get a new brand too, still tossing around different name ideas... Smarty, Cirrus, Toke, Chainz, ..if you have ideas for the rebranding of Smartcoins Wallet, let me know. It will support 7 different chains and their tokens/assets. It also has a new material design, better UI/UX. Anyway, let me know..
Routing commits:
https://github.com/kenCode-de/c-ipfs/commit/7d3418e9c715e70d86c81452639a5ef239a22f31
https://github.com/kenCode-de/c-libp2p/commit/3b301f823ad3993d25d92fdd3905bdb9b2409487
https://github.com/kenCode-de/c-libp2p/commit/e3fc5f640953ef23eb28ccffd086c05e2e7947c2
Since all of the Core components for 2.0 are near completion now, the upgrade procedure will not be that difficult, since the other libraries have already been published for you as well (like graphenej). Wallets developers should love that lib, it makes it insanely easy to make many different types of graphene-connected mobile wallets now for iOS, Android, Windows Phones, etc. I would love to see Jaxx add support for the Graphene chain now.....
Android Smartcoins Wallet and security audits:
Security audits have been completed and incorporated into our new graphenej library:
https://github.com/kenCode-de/graphenej
Smartcoins Wallet has been upgraded to the new architecture and has been published to google play. Lots of UI fixes (especially in the Transactions and Balances display) to come this week and will be published by end of next week as well.
During this process, we are also upgrading the architecture of BlockPay so that it runs a hell of a lot faster and stronger too. I have a debug apk you can play with if you like, but only bitUSD has been done so far. In the next few days I will publish it to google play once we have all the smartcoins working with this new lib (with direct DEx support in graphenej).
Upgrading the architecture of BlockPay to graphenej:
A huge waste of user's data transfer and battery usage was detected and fixed. This happened because even after the user leaves the app, the android system keeps its process running and its activities and resources are not automatically discarded, but instead kept around as the user might come back. The websocket connection to the witness node in this case was left open and receiving large amounts of data. This is also an issue that affected the Smartcoins Wallet so we fixed that as well.
Another outstanding issue with both apps is that once subscribed to events from the witness node, all sorts of events get broadcasted, essentially spamming the apps with unwanted notifications. This is is why this fix however important, is not reducing all the unused data transfer, just the unused data transfer that used to take place after the user left the app. Since apps can keep running in background for an unlimited amount of time, this was an important reduction of something that otherwise might have turned into an unbounded amount of traffic.
Of course this is not fixing the remaining issue yet with the unwanted notifications while the user is actively using the app, something that might be even more pronounced in the Smartcoins Wallet, since it might be consuming the limited 3G data transfer quota of the user. But in order to fully solve this problem, a modification in the witness code is required (it was not fully fixed in this old Issue: https://github.com/cryptonomex/graphene/issues/540).
Some of the relevant work for this Witness code update can be found at this commit: 3b081c428ec406de46e0f568484d8afeb91dd4d3
A new table called "balances" is used to keep track of the user's balances for every asset. The table is also dynamically updated from the notifications received via the websocket connection. Commit: 2f63eeb1d4b2cc417d1e81bfe00ba9cf6f90cdc7
The assets table has been updated in order to also track the information about the number of holders that each asset has. This is then used to filter the list of UIA and smartcoins, which was featuring a veeeery long list, including many inactive assets. The holders information is obtained from the cryptofresh API, but we now plan to request it directly from the witness node (commit: 5cd0c65d676274b51a88c37001700c8bbb6a5942) so that our software ultimately no longer relies on third parties.
A new table called "bridge_rates" is now used to keep track of not only the transfer rates between any two cryptos that the Bridge offers support for, but also the supported trading pairs. Commit: 706231122c0d2f0fba0938db20e0b8c40913962d
Aditional support for smartcoins and bitcoin input has been extended to all other cryptos supported by the bridge. The conversions can then be classified into 3 distinct categories: - Bitshares assets (no need for a Bridge)
- Bridge-supported using a single conversion
- Bridge-supported using a 2-step conversion
Up till last week, we already had support for conversions 1 and 2. The third case is required because for some cryptocurrencies, there are no direct trading pairs with the user's desired smartcoin. For these cases, which amount to the large majority of pairs, we need to ask for an initial conversion to BTS, and only then convert that BTS into the desired smartcoin.
The ideal solution would be to just use the DEx for this second conversion, but since the graphenej library is currently lacking support for trade operations, we decided to just use the bridge a second time for now. In the short term however, the direct DEx support will be a priority. This work can be mostly found here: 66125491fb2eec6fb2df337666f8735b07512198
After a conversion has been initiated, the expected balance change is calculated and the app signals the success of the transaction only after the desired balance change has been detected. This verification was not being done before and thus it was very easy to scam the merchant by sending any amount of BTS. This has been fixed here: ec8e2d681ed3eeda4d481e68d07a39f6160fa347
A number of other bug fixes and small improvements have also been performed on the apps. An outstanding issue was also detected with the bitEUR conversion. Since the Blocktrades bridge doesn't support direct trading between BTS and bitEUR, the 2-step conversion strategy described above is not enough to obtain bitEUR. So for now the app is not supporting bitEUR as a final smartcoin because of this bridge limitation. This is another important reason to add the direct DEx support this coming week.
Stealth related:
Regarding our new "trustless" setup algo, the original zcash multiparty trust setup was written in Rust. So, we are converting the Rust to C++ for direct graphene integration. The core functionality of this algo will be done in just a few more days, and then the interfaces and objects can be finished up this coming week for all of the UI connections. I also want this packaged up so that other graphene-based wallets can easily take advantage of Stealth, so modularity has been a high priority.
Automated Stealth transaction backups to c-ipfs can be started by end of next week too since the first formal Release of c-ipfs will be published then:
https://github.com/kenCode-de/c-ipfs/releases
Additional work being performed:
Code cleanup, join split implementation, verification, proofs, libsnark integration, commits:
https://github.com/kenCode-de/graphene/commit/849c808ebabebd388641daf8abf75d7b37b78355
https://github.com/kenCode-de/graphene/commit/0983477201821f3856871e09202eb9f8130f4d5c
https://github.com/kenCode-de/graphene/commit/0e70a69c87364107fb51818fb716fc00565097c5
Graphene-UI work can now resume on friday, january 27th so that Stealth actually looks nice too. A simple, logical UI/UX for this is imperative.
Alfredo Garcia, Bitshares Core Dev update:
As I stated in the Worker Proposal, I will be posting updates on his work here each week too.
He is voted in now and his 6-month job technically starts on Monday, January 23rd.
I already got him rolling though on "get_asset_holders_count" and "get_all_assets_holder_count". This is a bolt-on for @ElMato (Matias') asset api. It takes as parameter an asset id just as "get_asset_holders" original function created by him but it returns just an integer with the number of asset holders.
So, using it with wscat: > {"id":1, "method":"call", "params":[2,"get_asset_holders_count",["1.3.0"]]}
< {"id":1,"result":0}
> {"id":1, "method":"call", "params":[2,"get_asset_holders_count",["1.3.0"]]}
< {"id":1,"result":1}
> {"id":1, "method":"call", "params":[2,"get_asset_holders_count",["1.3.0"]]}
< {"id":1,"result":2}
The first call returns 0 and there was no user created in the node, we had an additional window running with the client wallet. The second call is with user nathan created as the cookbook (https://github.com/cryptonomex/graphene/wiki/CLI-Wallet-Cookbook) returns 1. The third call is with user nathan and following the cookbook there is an additional user called "my-account" where we transfer some of the nathan funds. This call returns 2. Nice and clean, minimal bytes transmitted.
By the way, the 7 chains that the mobile wallet will support will require me to add one more expert, so I'm getting him up to speed this week too. Our 2.0 apps are gonna seriously kick ass.
-
call it cosmos
-
The mobile wallet will get a new brand too, still tossing around different name ideas...
Smarty, Cirrus, Toke, Chainz, ..if you have ideas for the rebranding of Smartcoins Wallet, let me know. It will support 7 different chains and their tokens/assets. It also has a new material design, better UI/UX. Anyway, let me know..
call it cosmos
Actually, that's not bad.
Once we have a few more suggestions, I will tally up the votes and get the new app icon designed for it too.
-
ZSmart
SmartPay
-
ChainWallet
-
Gatekeeper.
-
hey @kenCode, I thought your plan was to combine all of the Smartcoins wallet functionality into Echo once you have the messaging piece worked out. If that's the case, why not rename the SmartCoins wallet EchoPay and then later combine it with EchoChat? To refine it further, maybe the app itself is called Echo, and EchoPay is the first feature, while EchoChat will be the next feature.
Just some ideas.
-
No, it's two different use cases and UI's entirely. Echo will use all of the core components that we have been building, but also include voice, video, chat and things that the Smartcoins Wallet just doesn't need.
-
No, it's two different use cases and UI's entirely. Echo will use all of the core components that we have been building, but also include voice, video, chat and things that the Smartcoins Wallet just doesn't need.
Got it. In any event, cosmos is already a blockchain project and you probably don't want that confusion. How about calling it Jupiter?
-
No, it's two different use cases and UI's entirely. Echo will use all of the core components that we have been building, but also include voice, video, chat and things that the Smartcoins Wallet just doesn't need.
Got it. In any event, cosmos is already a blockchain project and you probably don't want that confusion. How about calling it Jupiter?
I like the name "Nebula", as in sprawling, or scattered over a broad area (not my idea BTW).
-
Carbon Wallet "C"
Why? :P
A link to its graphene base!
-
Carbon Wallet "C"
Why? :P
A link to its graphene base!
+5%
-
Carbon Wallet "C"
Why? :P
A link to its graphene base!
ooooooooooo i like that one! +5%
we might butt heads with these guys though:
https://play.google.com/store/apps/details?id=com.sairk.sonythemes.carbon&hl=en
-
How about Nebula.
Sent from my SM-N920T using Tapatalk
-
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.
-
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
-
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
-
BlockPay v1.5.3 released. Updated Bridge communications, connectivity improvements.
https://play.google.com/store/apps/details?id=de.bitsharesmunich.blockpay
-
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.
-
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
-
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.
-
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
-
Keep up the great work. I always look forward to Friday's updates!
-
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!
-
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
-
Any teaser pictures or more details on the transaction flow of stealth?
-
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.
-
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?
-
don't care about stealth, please keep the updates as detailed and broad as possible.
-
GREAT JOB KEN, YOU AND CHRIS ARE AN INSPIRATION +5% +5%
-
Keep up the great work. I always look forward to Friday's updates!
Ken, thank you for the updates.
GREAT JOB KEN, YOU AND CHRIS ARE AN INSPIRATION +5% +5%
Thank you guys :)
What portion of time are you dedicating to the the wallet improvements vs stealth?
Each project and product that we are building are being done simultaneously by one or more people on multiple Teams. It is physically impossible to code them any faster than they are being coded right now.
Keep in mind, we are inventing the wheel on most of them, and the api's and libs that we have to create just to support these products don't even exist yet. This is why I will not give out "completion" dates. There is a lot more to these products than what a UI can show you. If it makes you feel any better, I hope to get an income from these products as well, so rest assured, I also want them built as fast as a humanly possible.
Odoo and all of the BlockPay Integrations will take advantage of the new Core (we'll be finishing up the DHT and swarm in the next week or so). Once I am comfortable with the new Core for our products, then the 2.0 Integrations will begin. The Odoo code is already done so we are going to just apply the new Core to it for its immediate release.
Rodrigo (CMO) and Chris (CEO) are Closing deals with major merchants like crazy, including signed Letters Of Intent (LOI). I think they're still up in Berlin right now. They usually post their updates here:
https://steemit.com/@bitshares-munich (http://steem.link/uDujo)
-
VERY nice looking website for BlockPay Mr. Ken, me likes it a lot!
I discovered I can't use blockpay on my Android 4.2.2 phone. However, I was able to create an account and send it some funds on the old 1.05 beta version. If it can send and receive a few coins it will serve my purposes while at Anarchapulco. I also couldn't use the Jaxx wallet, but Mycelium and Electrum mobiile wallets seem to work OK so I'm covered there too.
Looks like I need to update the "ROM" in my phone (if possible) or get a new one to use BlockPay.
Nice work tho, way to go!
-
Thank you Thom :)
BlockPay v1.5.6 released. More cleanup being done on the Settings screen. You can now import .bin files from the web wallets and light client wallets. Some crashes have been reported, so we added support for more device configurations. Loyalty Points section in settings screen is now being upgraded to allow for a searchable/editable auto-complete field instead of one huge list, and we should have that finished up for you this week. Thank You screen updated to show exact (typed in) amounts. More UI tweaks done.
https://play.google.com/store/apps/details?id=de.bitsharesmunich.blockpay
-
Been gone for awhile.
Happy to see that stealth is being worked on, as for everything else, need to take a few days to catch up with things.
-
Just saw this. It'd be nice to see more media attention like this paid to BlockPay.
https://coinidol.com/bitshares-munich-to-unleash-project-stealth/
Thanks for all the hard work @kenCode, Christoph, and the whole blockpay team.
-
BlockPay v1.5.7 released.
https://play.google.com/store/apps/details?id=de.bitsharesmunich.blockpay
Loyalty Points section in settings screen bug found where it forgets which token was to be sent, or not. Fixed. Speed improvements made to the QR code display. Less bandwidth is now consumed due to our api upgrade at our servers.
Up next this week: Give the Transactions display a facelift and tighter integration with graphenej library. Clean up the settings screen. Human update the 44 language files. Upgrade the LifeTime Member feature to graphenej. More UI and speed improvements coming...
-
Tons of updates this week!
https://github.com/kenCode-de?tab=repositories
edit: removed this old image
BlockPay related:
The work from the previous week done in graphenej in order to be able to import the .bin backup files from the web wallet and light client wallets has been introduced now into both BlockPay and the Smartcoins Wallet. The commit adding this fix to the Smartcoins Wallet is here:
https://github.com/kenCode-de/smartcoins-wallet/commit/00ddf4e788eecb34b5ea63b8a32f64d115c7be63
An important bug that made it impossible to read the backup codes being generated by the BlockPay app was fixed in this commit:
https://github.com/kenCode-de/blockpay-s/commit/7167803e380da3ead24b9f0532d8766c63aad806
The last screen in the checkout process on BlockPay now also displays the Total, and is sending the customer 0.5% fee to the bitshares-munich account:
https://github.com/kenCode-de/blockpay-s/commit/9ecb736c43abb90b44520746fbe619b31f64da12
Small adjustments done in the settings screen, like selecting the "None" option for the UIA as a default, hiding the "reward ratio" line when this option is checked, a small issue with the wrong UIA being selected was fixed, and also fixed the lack of an asset description.
https://github.com/kenCode-de/blockpay-s/commit/96666c233bfd246ba8d2f1028cf78bb2cf6b076a
https://github.com/kenCode-de/blockpay-s/commit/be999af7d7bb9d5ff5befda496038e1c792d3a42
https://github.com/kenCode-de/blockpay-s/commit/c0a631b4c372854c55cd186ae7107903caa7023e
It was requested that the BlockPay app only could hold one merchant account at a time, and for that we had to disable the options to add more accounts once we already had one. Check this commit for that work:
https://github.com/kenCode-de/blockpay-s/commit/65cc60aa2cf51b3fbbe960dd03f855cd836bdd43
We now also correctly handle "partial payment" attempts for Smartcoin transactions, playing a special sound (transaction-error.mp3) and updating the UI to give the customer an additional 60 seconds (and new QR code) to pay the cashier what was supposed to be paid. Now it's impossible to cheat the merchant! This feature will of course be extended to disallow partial payments from Bitcoin and Altcoin customers as well, in a few days in the v1.5.8 release.
https://github.com/kenCode-de/blockpay-s/commit/72afc056181f4b4e3305e398a44df1fa64f4c89e
We are also removing the need to press that stupid Save button on the settings screen. We'll try to remove that button completely in the next release. Just gotta beta test it like crazy first.
https://github.com/kenCode-de/blockpay-s/commit/7eeb87dcaa4f605978f2681abfaf3d1f01b551bf
C-IPFS related:
This week we worked on file sharing between 2 networked nodes. While we're close to getting it to work, we still lack some functionality.
The good news is that we made good progress this week. The majority of the items we are building out will continue to be used in future versions. Only some of the "glue" that gives current users some functionality will need to be replaced. Here is a list of "critical path" items: - We are missing the ability to join the swarm. Procedures, encryption, and time to tinker are lacking, so we cannot perfectly connect to the go-ipfs implementation yet.
- Because we are not part of the swarm, we do not have a list of peers to query for objects.
- Because we do not have a list of peers, a C-IPFS peer must know the hostname and port of the machine that hosts the file.
If the user uses the hostname and port, he will (soon) be able to download an object. The good news here is that the swarm, protocols, and peer stuff are "front-end" pieces. The underlying querying and storing is almost complete. That means:- We are (or will be soon) able to move files around using the underlying mechanisms very close to existing GO versions.
- The "glue" pieces that currently do this with the user specifying details do not have details buried deep in the code. When we sort out the swarm / encryption / peer stuff, we will finally be part of the swarm and can query and serve files to/from anywhere as existing peers do.
The reason I've got (soon) in there, is that the file transfer is still being worked on, and has not had enough beta testing done on it yet. I'm hoping to get some kind of working POC done tonight (Monday latest). But the clock is ticking.
Here's a rundown of our commits from this week:
c-multiaddr: We're finally getting down to needing this library, and the code was difficult to understand, and not efficient enough. We made modifications to make it more solid, but broke a few things that were not fully understood. That's all been fixed and upgraded, and here are the commits related to addressing:
https://github.com/kenCode-de/c-multiaddr/commit/fcb0cce437cea8b028bc8d52af921de41301b803
https://github.com/kenCode-de/c-multiaddr/commit/4e281ddd0877db8451e62554be310b264c280f39
https://github.com/kenCode-de/c-multiaddr/commit/0b8789ebbcdb30d4614b22fdc6c93c9caed42cc9
https://github.com/kenCode-de/c-multiaddr/commit/7da26ca04d050cbe6fdd926bbb6dd119f8b4e2f1
c-libp2p: The first part of the week was the buildout of protobuf-compatible objects that can be sent through the wire.
https://github.com/kenCode-de/c-libp2p/commit/cd27026cb5cd7691e210cb5865bf63a0f5635940
https://github.com/kenCode-de/c-libp2p/commit/7f00ce69fe14114e7df1bf23f18bfdfcb2507eb7
https://github.com/kenCode-de/c-libp2p/commit/4555cdfdf1c335bf2cf42295ea3f005b8d7da916
c-libp2p: The peerstore will be where remote connections to/from the local peers will be stored:
https://github.com/kenCode-de/c-libp2p/commit/9f0ee0cdb9a2c095713e4a6033897eeb17a6a2f6
https://github.com/kenCode-de/c-libp2p/commit/ddb12745968b0d7b7e0d0f065333b5ef8ee955c5
https://github.com/kenCode-de/c-libp2p/commit/e4a4226f5d9fcf584fefafab6ee4d7d924c39c25
c-libp2p: Finally the more ipfs-like ping was implemented. This is good because it also tests some of the same code that is used in file/object sharing:
https://github.com/kenCode-de/c-libp2p/commit/8139dc9d4806c86ec71c1a38b3e9d83cca2e481c
https://github.com/kenCode-de/c-libp2p/commit/f1aaae0f17a0b00f6f94b1122edefe4b31ee8ee2
c-ipfs: Many of the pieces that were built earlier are now being put to use. Network communications was the focus this week:
https://github.com/kenCode-de/c-ipfs/commit/f8e42867405c18aebeb1ad9cf9d0387bff7f40a8
https://github.com/kenCode-de/c-ipfs/commit/daefe7604fc00b8da28dc1aeb14bbf93fd197734
https://github.com/kenCode-de/c-ipfs/commit/ae48e058dd2e162dc3a29c709e8a6bd6b06daa3b
https://github.com/kenCode-de/c-ipfs/commit/7a6b1384448a303f115e9bc5fd6eb273e40eaf8f
Up this next week:
With the focus on file transfers, we didn't get a chance to work on the higher level encryption and connectivity portions like we wanted. If we can get the file transfer stuff working by Monday, even in a cobbled together way, we can work on breaking through this connectivity barrier, so as to join the swarm. That will be a huge step towards global acceptance.
Android Smartcoins Wallet:
A small improvement was done in the way the app checks the input fields of the send screen. Especially after you scan a QR code. The previous method not only was kind of wasting CPU by performing a check every 100 ms, but it was also unreliable, leaving sometimes the Send button disabled when the fields were actually correct and thus preventing the user from sending the funds. This commit contains that work:
https://github.com/kenCode-de/smartcoins-wallet/commit/77b849f40ec88be56eb7bfa7636eb21b67e6a970
Since the Smartcoins Wallet will soon support 6 chains (Bitshares assets, Bitcoin, Litecoin, Dash, Dogecoin and Steem), here is the rundown on that feature: - Added confirmation text and colors to the bitcoins transactions
- Added confirmation text and colors to the bitcoins balance (using the transaction with less confirmations)
- Changed Balance to get confirmed balance and unconfirmed balance and get the less confirmations
- Test send in the api, to see what's needed to construct the transaction using existing libraries in Smartcoins Wallet
- Change Transactions in database added blockheight, transaction index, priv script and pub script
- Changed the primary keys of all tables in Smartcoins Wallet from string to integers
- Adjusting BalanceFragment to work different with other coins than Bitshares
- Adding labels and confirmations needed to the Coin information. With this the app now prints "BTC", or whatever the symbol is for the altcoin, and the number of confirmations needed can be changed for every supported coin.
- Added send logic. This involved changing the account logic to get the proper change address and getting each utxo from each address.
At this point, we have completed all of the main functions that the wallet needs, send and receive transactions, also check the balance and get the balance history. The only thing left is to support memo/note fields for coins that support it. We should have that done by end of this weekend.
The work for next week is almost all UI, because the logic part is essentially done. So, for next week: - Upgrade the database where we store Contacts, but that should only take a few hours at most
- For the QR code (sending and receiving); working on this, but this one will take a couple of weeks
- See if we can begin with the testing on other coins (Dash and Litecoin will be first)
- UI: Send Page
- UI: Create QR Code
- UI: Scanning a QR Code
..and if time allows this week:- Sending memos
- Receiving memos
- Add new BTC Contact
- Make it easier to share your Contact address
- Import contacts
- Create eReceipt from multicoinsj
- Add option to set preferred unit (ie: BTC, mBTC, uBTC)
- Show the equivalent fiat value
If we keep moving at this pace, then at least the Bitcoin support will be completed in around 2 weeks, and the other coins will be very easy to add and finish since all of the base code is written already.
Stealth related:
Lots of progress made on Stealth this week! The 2 "serious issues" that we found last week with the libsnark and gadgets have been solved. So, now that that is out of the way, we have been debugging libsnark proofs and proving keys. This entire week has been spent in the debugger and logs, so no github commits to link here.
Now that we have reached this point in the core code, I am able to add another cryptographer to the Stealth team in about a week. This will help us speed the Stealth project up of course, and add more security auditing as we go, but I also require my teams to cross-train just in case someone has a family emergency or something.
We should be able to start proving transactions within 3 weeks, and then begin closing the gaps in the api, which is needed to connect to the UI. Most of the UI work, at least in a rudimentary sense, is already done. We can make it pretty later, for now, I just want it working asap. I pushed hard on that too because I want to begin public beta testing on our testnet as soon as possible.
Alfredo Garcia, Bitshares Core Dev update:
Fixed: Don't print private keys in log on witness startup
https://github.com/bitshares/bitshares-core/issues/93
PR: https://github.com/bitshares/bitshares-core/pull/236 - merged
Added function to "api call to obtain an account's trad history for a specific asset-pair" issue:
https://github.com/bitshares/bitshares-core/issues/222
PR: https://github.com/bitshares/bitshares-core/pull/237 - not merged yet. we want to enhance performance on this one a bit more first.
Testing additional changes at nospam branch (websocket spammed too much data).
Testing xeroc comment "sending notification twice". This is now fixed in the nospam branch at:
https://github.com/bitshares/bitshares-core/pull/234/commits/2487689f26a81a633cc2659d7d0311c6d848f467
Fixed: Uninstall light client does not remove "personal info"
https://github.com/bitshares/bitshares-core/issues/227
Issue is fixed at https://github.com/bitshares/bitshares-ui/pull/82 - merged
-
Smartcoins Wallet v1.5.11 released.
https://play.google.com/store/apps/details?id=de.bitsharesmunich.smartcoinswallet
Sending Smartcoins and UIA's has been fixed.
Added support for importing bin files from web wallet and light client wallets.
Speed improvements.
What's up for next week:
Update eReceipts display, and make them look nicer.
Update Transactions display and make it work in real-time.
Add support for WIF key importing.
More speed and UI improvements.
-
Stealth related:
Lots of progress made on Stealth this week! The 2 "serious issues" that we found last week with the libsnark and gadgets have been solved. So, now that that is out of the way, we have been debugging libsnark proofs and proving keys. This entire week has been spent in the debugger and logs, so no github commits to link here.
Now that we have reached this point in the core code, I am able to add another cryptographer to the Stealth team in about a week. This will help us speed the Stealth project up of course, and add more security auditing as we go, but I also require my teams to cross-train just in case someone has a family emergency or something.
We should be able to start proving transactions within 3 weeks, and then begin closing the gaps in the api, which is needed to connect to the UI. Most of the UI work, at least in a rudimentary sense, is already done. We can make it pretty later, for now, I just want it working asap. I pushed hard on that too because I want to begin public beta testing on our testnet as soon as possible.
I will use as soon as I am allowed +5% +5% +5%
-
Smartcoins Wallet v1.5.12 released.
https://play.google.com/store/apps/details?id=de.bitsharesmunich.smartcoinswallet
- UI improvements in the brainkey backup dialog prompt
- Fixing bug that made the app crash if the user requested having the PIN dialog to be shown also before the send of funds
- Fixed another minor bug that made the app crash upon receiving a balance update.
-
BlockPay v1.5.8 released.
https://play.google.com/store/apps/details?id=de.bitsharesmunich.blockpay
More speed improvements and UI cleanup in this release.
In v1.5.9 we will be doing some hardcore speed improvements, so it might take a week or so till I release v1.5.9.
-
Smartcoins Wallet v1.5.13 released.
Storing more in the local database now, means less trips to a server, means less bandwidth used by the device :)
As always, never store more in a wallet than you can afford to lose.
Google Play:
https://play.google.com/store/apps/details?id=de.bitsharesmunich.smartcoinswallet
Open source:
https://github.com/kenCode-de/smartcoins-wallet/releases/tag/v1.5.13
You should see v1.5.13 appear on F-Droid, Aptoide, Yandex, SlideMe and AlternativeTo app stores in the next few days too.
-
Tons of updates this week!
https://github.com/kenCode-de?tab=repositories
(http://i.imgur.com/HAYRSgl.png)
BlockPay related:
The main novelty this week has been the redesign of the Loyalty Points UI in the Settings screen. Instead of displaying a huge list of all of the UIA's that could potentially be used as Loyalty Points, we now have just a text box that uses an autocomplete mechanism in order to present the user with a list of potential UIA candidates. This has the advantage of leaving us with a much cleaner and simple-looking interface, while having access to even more UIA's than we had displayed before. This is because in order to have a list of a more reasonable size (there are more than a thousand UIAs!), we were filtering out UIA's with low usage/holders. The database is finally used as the true source of the data backing the list of suggestions that get displayed as you are typing.
Since we don't need to filter out the list of UIA's based on the number of holders each one of them has, this data doesn't have to be loaded at the initial setup either. Since this procedure was responsible for a considerable amount of time spent at this phase, the database setup step is now visibly faster. It was quite a bit of work removing unneeded procedures, but the result is a more responsive app, easier to setup, and consumes less bandwidth overall.
After selecting the proper UIA as a Loyalty Points reward token, we also now check the user's balance and warn the merchant if there's a zero balance for that specific UIA.
Graphenej (https://github.com/kenCode-de/graphenej) - The library has been updated in order to support multiple operations in a single transaction. With this update, we also did some restructuring of the architecture of the classes that represent transactions and operations. More specifically, the factory pattern is now applied operation-wide instead of being done at the level of the transaction. This makes more sense now that we can bundle together a bunch of operations into a single transaction, which of course ends up charging the customer a bit less in network fees and consuming less bandwidth since less trips to a server are needed.
C-IPFS related:
This week, we worked on file transfer and secure connections. The file transfer works, but it is not the "normal" way to do it, as we have yet to join a swarm. Once secure connections are working, joining the swarm will be the next step. Here are the commits for the week:
Handling the different messages for data transfer in libp2p:
https://github.com/kenCode-de/c-libp2p/commit/c5fa7755342929f2dddac4a578fef065fd68d85c
https://github.com/kenCode-de/c-ipfs/commit/f1aac5d70794bd7f12ae7aba6d03aab96ddcb211
Moving closer to secure connections using the ipfs secio protocol:
https://github.com/kenCode-de/c-libp2p/commit/6d9473069ba17a37dab71d5e33088eb62bb74f5d
https://github.com/kenCode-de/c-ipfs/commit/d4fee344a7e080a21c1c8f4ec5a4df9c5f84e466
Additional:
https://github.com/kenCode-de/c-ipfs/commit/3a38623dccd6039ece496399d75a00485c341ea8
https://github.com/kenCode-de/c-libp2p/commit/386fe24f70b9d9eca16472fb2071416fc178f14d
Kademlia is almost functional, we just need to implement the search and then add it to the core. CJDNS will be plugged in as well for our meshnet/openwrt stuff (will talk about this more later). In the coming week, we're working hard to get secio finished, then link it to the swarm. With that done, many of the underlying functions will exist to handle the basic needs of our first public C-IPFS release. Less than 2 weeks away now, which means we get to start on BlockPay 2.0 features (employee tracking, brand new UI/UX, Bridge work, some offline abilities, and at least 20 more Integrations (besides Odoo, Tetra OS, hotel/gas chains, etc)).
Android Smartcoins Wallet:
Some bugs that were detected and reported by crashlytics over the weekend were promptly fixed. The first one had to do with the lack of a UI element (a button) in the PIN dialog, and its solution can be found here (https://github.com/kenCode-de/smartcoins-wallet/commit/abe73d18cfd6bac8e92ad3d4f9b46c747d5490c3). Another one had to do with the selection of a "backup asset" (Overdraft Protection) on the settings screen. We are building directDEx support for this feature now. Support for further operations that handle market orders is required from the graphenej library in order to re-enable this feature. So in the meantime, in order to avoid crashes due to an nonexistent feature, we just deactivated it in the UI for now. This work can be found here:
https://github.com/kenCode-de/smartcoins-wallet/commit/141f6a067ea3c894aa6664085e709d78cd25c7cc
And finally, a bug that may prevent users from registering new accounts was promptly fixed in a patch that was quickly released yesterday to all users. This fix can be found here:
https://github.com/kenCode-de/smartcoins-wallet/commit/1b2cf1c9b2d99af9ea95f577a1f0e72653ee84a0
WIF key support is another feature that is about 95% done right now, but we just want to test it a bit more and make sure it works perfectly with the bin file backups etc too. Once testing of the new WIF import/export feature is complete, I will publish a version update on google play as usual.
Stealth related:
We finally got all the crypto working this week! The api is now being created which will connect our UI work to the core. From that point, we are finishing up conversion of that zcash Rust code I mentioned into C++ so that it works more natively with the bitshares-core.
If we keep moving at this pace, I hope to have the first Stealth testnet online for public testing in less than 6 weeks. This will include the new core, the api with functional UI, and conversion of most of the Rust code for our "trustless setup" algo.
I know 6 weeks sounds like an eternity, but I want this to be done right. The UI/UX has to be perfect too, or else we will never get any mass adoption. First impressions are everything.
Alfredo Garcia, Bitshares Core Dev update:
Alfredo is kickin butt and takin names! It's hard to keep up with him, but I will summarize some of what he has fixed this past week:
CLI wallet issue: https://github.com/bitshares/bitshares-core/issues/92
Tested and closed.
https://github.com/bitshares/bitshares-core/issues/193
Same as 93. Removed note requested by abitmore in pull request:
https://github.com/bitshares/bitshares-core/pull/240 merged.
api call to obtain an account's trade history for a specific asset-pair
https://github.com/bitshares/bitshares-core/issues/222
Added function. pull request https://github.com/bitshares/bitshares-core/pull/237 merged
https://github.com/bitshares/bitshares-core/pull/5
Research of current seed nodes.
Forum post: https://bitsharestalk.org/index.php/topic,23715.0.html
Pull request with the last updated seed nodes info:
https://github.com/bitshares/bitshares-core/pull/241
Final updated in commit:
https://github.com/bitshares/bitshares-core/commit/c149a5b9b1f85577ce7f04226e4b0786d21ca104
https://github.com/bitshares/bitshares-core/issues/168
Requested more info in github. theoreticalbts is not in the bts team anymore but waiting reply from someone else.
Talked with vikram if no reply, issue will probably be closed.
https://github.com/bitshares/bitshares-core/issues/158
Tested and closed. the bug is not happening in the current version.
https://github.com/bitshares/bitshares-core/issues/191
Added feature to cli wallet to be the same as rpc call, this is with start and end time arguments.
Pull request: https://github.com/bitshares/bitshares-core/pull/242 merged
https://github.com/bitshares/bitshares-core/issues/103
This request is very old, most of them not needed anymore, we spoke with the issue initiator (Sigve) and decided to close the issue.
----------------
Like I mentioned in my last posts, we are implementing a lot of speed and UI improvements into BlockPay this coming week, so I might not want to publish a version upgrade till the end of the week this time, as it is some very large chunks of code that I will need to sift through. Like what? Transactions display, eReceipts redesign, fixing bin file importing on web wallets from mobile, and many different code improvements and tighter integration with our graphenej lib so that less trips to a server are needed. Not sure if I mentioned this or not, but we are installing BlockPay onto vending machines too, and those vending machine owners pay (on average) $1 per MB. So, cpu/mem and especially bandwidth utilization is a very major concern. Every byte counts as I always say. Let's do it right the first time.
edit: updated Project Leads in Jira
-
well done +5% +5% +5%
-
If we keep moving at this pace, I hope to have the first Stealth testnet online for public testing in less than 6 weeks. This will include the new core, the api with functional UI, and conversion of most of the Rust code for our "trustless setup" algo.
I know 6 weeks sounds like an eternity, but I want this to be done right. The UI/UX has to be perfect too, or else we will never get any mass adoption. First impressions are everything.
Awesome update kenCode. Especially looking forward to this :D
-
Tons of updates this week!
https://github.com/kenCode-de?tab=repositories
BlockPay related:
A bug that made the app crash after selecting BTS as a Loyalty Points token has been fixed. Some unused string resources were also removed speeding the app up. A protection against a crash that seemed to be produced when no currency was being selected was put in place. And a small bug in the numerical keypad screen was fixed.
The hierarchy of views used to build the keypad view was using a deeply nested chain of linear layouts, which constitutes a sub-optimal design choice. Since some changes were required for this view anyways, it was decided to replace the set of nested linear layouts for a newer and more efficient component called ConstraintLayout (https://developer.android.com/reference/android/support/constraint/ConstraintLayout.html). With it is possible to design complex UI structures like the keypad view while keeping the view hierarchy relatively flat. These efficiency improvements make BlockPay run faster and more stable.
The QR code screen has been cleaned up and simplified.
The selected language was not using the required pointer in order to obtain the value from the shared resources. As a result, the app's default language was always being selected in some parts of the app, not all. This has also been fixed.
The Bridge has undergone some extensive upgrades too. We are hiding some tokens that were just cluttering up the settings screen. By showing less on the settings screen and automating more of the processes, like requiring the blockpay tokens for surety, it makes initial setup of the app much quicker and easier. We should have the new settings screen complete in less than 3 weeks which will really make the blockpay ambassadors and merchants happy. This will be the v1.7 release. Remember, my ultimate goal is to have a 1-step setup.
The numerical keypad was extended with the introduction of a "+" (plus) button, that will allow the merchant to enter a list of individual prices chained together. All the work relating to both the ConstraintLayout, some corner cases, and the introduction of the new "+" button have been finished. You will see these enhancements in the upcoming v1.5.9 release (most likely tonight or tomorrow).
Graphenej (https://github.com/kenCode-de/graphenej):
After some more research, it was finally possible to make the backup files generated using the graphenej library completely compatible with the web wallet and light clients. This .bin backup interoperability is now complete and will be published this week in both BlockPay v1.5.9 and the Smartcoins Wallet v1.5.14.
This week we also started to work on the support for direct-DEx operations. The first operation that was introduced was the limit_order_create_operation, with this commit having most of the new classes and tests. The binary serialization (required for the local tx signing procedure) is matching the serialized version of the operation produced by the cli_wallet tool, but the transaction built using this newly introduced operation is still being rejected by the network. Further tests, especially on the JSON serialization are required and should be completed this week as well.
C-IPFS related:
This week, we continued to work on tying the C-IPFS implementation to the IPFS swarm. There will probably be more commits before the end of the day, as this just about wraps it up.
The underlying c-libp2p was modified as follows..
secio protocol:
https://github.com/kenCode-de/c-libp2p/commit/6d9473069ba17a37dab71d5e33088eb62bb74f5d
https://github.com/kenCode-de/c-libp2p/commit/0e0b6b15465c224235e78f91056d5dc0accf23e3
https://github.com/kenCode-de/c-libp2p/commit/c343d2d0ad1e2d4def471064f4e7593f2f61ac88
https://github.com/kenCode-de/c-libp2p/commit/e092a0e974689fa15be17f0bc7f59c9634db1863
https://github.com/kenCode-de/c-libp2p/commit/05cc6e9bd3f025316ce4d95f080eeb21a3e57b38
https://github.com/kenCode-de/c-libp2p/commit/3d53c470a50a2a75bda41d32706b6a3bc31f7c4e
https://github.com/kenCode-de/c-libp2p/commit/a6fe0fda4765b41fb371cf48787db4038e7429bf
We then made the interface to streams a bit more generic:
https://github.com/kenCode-de/c-libp2p/commit/d0512d90847dbc95283e1f5f38afbda1adedccd8
https://github.com/kenCode-de/c-libp2p/commit/74d95cb696b6da141e6b751faa8abb5495d5ee45
c-ipfs was then modified to use the new code:
https://github.com/kenCode-de/c-ipfs/commit/cd5d347e6346e26256c1bc96b92dbb62bf741e17
https://github.com/kenCode-de/c-ipfs/commit/15a8abff9a7abd417b90a4ebda39ecfa9fac27ad
https://github.com/kenCode-de/c-ipfs/commit/43ca31385463774f2466eb55efced36a94b7d82d
Additional c-libp2p work finished up:
https://github.com/kenCode-de/c-libp2p/commit/0ffe73ae28202df7453be74b6502093a0c2df13b
https://github.com/kenCode-de/c-libp2p/commit/1b5b7c7cbacd354938c377788ef1e6af180b65e5
https://github.com/kenCode-de/c-libp2p/commit/018923ad0964c558a19c5d65688ab9ff503c7c55
https://github.com/kenCode-de/c-libp2p/commit/1fa0d4bd682060e5f60afbd4ff38f116d49713c7
Kademlia/DHT will finally be completed by tonight or tomorrow, just need to finish the callback work for returning search results.
Plans for the final week:
Lots of code cleanup now. Tidy up the comment lines, indenting and spaces, remove unused code/methods, and add efficiency wherever possible. Like I always say, every byte counts. Our v1.0.0 release will be for *nix systems and the RasPi3 first. Then the build for android the following week.
Android Smartcoins Wallet:
As you guys know, the Smartcoins Wallet is about to natively support 6 blockchains. Bitshares, Bitcoin, Dash, Litecoin, Dogecoin and Steem. In v1.7 our new streamlined Overdraft Protection feature (aka: "backup asset") will be upgraded to graphenej. In 2.0 (I'll upload a youtube vid for you guys this week I hope so that you can see the new ui/ux concepts in action) we add our c-ipfs and initial meshnet support and the rebrand of the wallet to "Carbon". Also, a big shoutout to @iHashFury for the suggestion (https://bitsharestalk.org/index.php/topic,22576.msg302196.html#msg302196)!
Work done this week: - Bitcoin support is done and tested (send/receive, balances, transactions, qr, import/backups, eReceipts, etc)
- Change api to new server parameters
- Testing of our altcoin fullnode servers (Dash was first, then Doge and Litecoin...)
- Change contacts to use sqlite db
- Changed contacts fragment, add and edit activity to work with BTC/alts
- Changed the Send screen to enable selecting BTC/alts Contacts
- Create base Custom Network Parameters for altcoins
Most of the upgraded UI (for multi-chain support) is ready, the thing to note is the interface is implemented with a new line for each coin right now, but this basic UI will be replaced in v2.0.0 ("Carbon"). Also the send and receive screens had to be modified to adapt to the upcoming 2.0 UI (I'll post a youtube vid so you can see our progress on it in the next week or so).
Work coming this next week: - Figure out Dash InstantSend and get it finished
- The code we had created for the original Contacts screen needs to be cleaned up now that multi-chain support has been added
- The network parameters in bitcoinj are used to calculate all the transactions and the addresses, which is needed to use the api, so we standardized this to use each altcoin, which in turn makes the implementations much faster
- Upgrade our fullnode servers to support the additional coins
- Make sure all the chains we offer native support to can also take advantage of BlockPay Loyalty Points, Overdraft Protection, eReceipts and so on
- Testing Litecoin
- Testing Dogecoin
- Test and bug fix the Bridge so that users can shift between coins when desired
Stealth related:
We're now into week 2 of 6 for the Stealth api creation. In the UI, I have also designed a "3-way switch" that allows you to just do a Normal, Blinded, or Stealth transaction simply by flipping an animated switch. This is a compact way for users to just flip the switch and sends funds however they like. I will try to get you guys some screen shots in the next couple weeks so that you can see it in action.
I also am adding an option in the wallet Settings where you can choose the default setting for that switch, so that you don't always have to remember to set your transaction to Stealth, or just Blinded mode, etc. If you have ever seen that "Propose" 2-way switch when you send funds, well, just imagine that as a 3-way switch on the Send screen. Grayed out for Normal, the switch turns yellow if you flip it to Blinded, and it turns red if you flip it to Stealth mode.
This 3-way switch also works nicely on mobile since it is so compact, colored, etc. BlockPay merchants and users alike want an easy way to use Stealth so I went with the k.i.s.s. method on this. The further we get on the Stealth api, the more UI hooks we can make. Lots of Stealth coding to show this week:
https://github.com/kenCode-de/bitshares-core/commit/009b3e6c8e99349450349913b12a0bced6631cec
Besides the 3-way switch, we have also made huge progress on the database, account and contacts editor screens, and initial outlay for the automated backups feature using our c-ipfs implementation. Now that the encryption work is done, it's just down to the api and "trustless setup" algo (which we already have the plan for and will be relatively easy to implement and prove thanx to DPOS). More on that in week 6.
Lots of logic has been added this week too which prevents users from screwing anything up. Besides Chrome support, we are also writing the necessary code to make Stealth as portable as possible in different browsers and configurations such as Firefox and non-websql compatible browsers.
By the way, I don't know if you guys ever saw the original drawings that bytemaster did for Stealth when he used the "@" symbol for addresses. I use a lot of keyboard shortcuts and don't reach for my mouse much, so by having an easy way to access Stealth accounts and addresses by just typing that one character is a nice feature, so I have implemented that in the UI as well. You don't have to type it, as flipping the 3-way switch will do it for you, but I like having that option available. Not that reaching for my mouse is hard or anything..
Alfredo Garcia, Bitshares Core Dev update:
Alfredo has some monster updates done this past week. The segfault issue in the get_ticker api call has been fixed. The cause of the segfault has been found and removed but this led us to a new additional bug that was found in an api call get_trade_history used by get_ticker and get_24_volume calls.
Those new bugs found are being researched as we speak and we should have a solution for them as well in the coming week. In the process of a change in get_ticker and get_24_volume, calls to don't use get_trade_history or fix the get_trade_history function. So fixing this is definitely a priority too.
Regarding the "Socket spamming too much data." issue:
https://github.com/bitshares/bitshares-core/issues/231
New commits from elmato in his branch: https://github.com/elmato/bitshares-2/tree/no-spam-sub-function
We tested and setup a node for sigve to make the final tests before the merge. Everything is working great now so as long as our final tests work as expected, we will finally commit this one (hopefully by monday)
Regarding "Can operation_results please show the operation id(s) of all ops in the tx?" issue:
https://github.com/bitshares/bitshares-core/issues/243
This one is now in progress.
Regarding "https://github.com/bitshares/bitshares-core/issues/159" issue:
https://github.com/bitshares/bitshares-core/issues/159
This one is done as well and I will close it in the next 24 hours.
Here is a list of some of the other bitshares-core issues that Alfredo is tackling right now:
https://github.com/bitshares/bitshares-core/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc
As for new features, I would like Alfredo to also work on Dividends, Black Swan prevention and recovery, advanced Trading functions to DEx (Margin Trading, Stop Loss, Trailing Stop etc.), selling/dumping a UIA that you no longer want, Worker proposal upgrade (as per Data and Jonny's ideas), Recurring and Scheduled Payments feature, make it so that FBA's don't always need a hardfork, and a lot more. If you have ideas for new features, please contact chris4210 since he maintains the Bitshares wishlist.
Over the weekend I will also publish more app updates to google play for both BlockPay and the Smartcoins Wallet so stay tuned if you want to see all the new stuff we've been working on. As usual, I will post the download links here for you guys too.
-
@kenCode Are -- are you a machine??
:o
-
Yes, I think he is a machine :)
Well done my friend, awesome report!
Tons of updates this week!
https://github.com/kenCode-de?tab=repositories
BlockPay related:
A bug that made the app crash after selecting BTS as a Loyalty Points token has been fixed. Some unused string resources were also removed speeding the app up. A protection against a crash that seemed to be produced when no currency was being selected was put in place. And a small bug in the numerical keypad screen was fixed.
The hierarchy of views used to build the keypad view was using a deeply nested chain of linear layouts, which constitutes a sub-optimal design choice. Since some changes were required for this view anyways, it was decided to replace the set of nested linear layouts for a newer and more efficient component called ConstraintLayout (https://developer.android.com/reference/android/support/constraint/ConstraintLayout.html). With it is possible to design complex UI structures like the keypad view while keeping the view hierarchy relatively flat. These efficiency improvements make BlockPay run faster and more stable.
The QR code screen has been cleaned up and simplified.
The selected language was not using the required pointer in order to obtain the value from the shared resources. As a result, the app's default language was always being selected in some parts of the app, not all. This has also been fixed.
The Bridge has undergone some extensive upgrades too. We are hiding some tokens that were just cluttering up the settings screen. By showing less on the settings screen and automating more of the processes, like requiring the blockpay tokens for surety, it makes initial setup of the app much quicker and easier. We should have the new settings screen complete in less than 3 weeks which will really make the blockpay ambassadors and merchants happy. This will be the v1.7 release. Remember, my ultimate goal is to have a 1-step setup.
The numerical keypad was extended with the introduction of a "+" (plus) button, that will allow the merchant to enter a list of individual prices chained together. All the work relating to both the ConstraintLayout, some corner cases, and the introduction of the new "+" button have been finished. You will see these enhancements in the upcoming v1.5.9 release (most likely tonight or tomorrow).
Graphenej (https://github.com/kenCode-de/graphenej):
After some more research, it was finally possible to make the backup files generated using the graphenej library completely compatible with the web wallet and light clients. This .bin backup interoperability is now complete and will be published this week in both BlockPay v1.5.9 and the Smartcoins Wallet v1.5.14.
This week we also started to work on the support for direct-DEx operations. The first operation that was introduced was the limit_order_create_operation, with this commit having most of the new classes and tests. The binary serialization (required for the local tx signing procedure) is matching the serialized version of the operation produced by the cli_wallet tool, but the transaction built using this newly introduced operation is still being rejected by the network. Further tests, especially on the JSON serialization are required and should be completed this week as well.
C-IPFS related:
This week, we continued to work on tying the C-IPFS implementation to the IPFS swarm. There will probably be more commits before the end of the day, as this just about wraps it up.
The underlying c-libp2p was modified as follows..
secio protocol:
https://github.com/kenCode-de/c-libp2p/commit/6d9473069ba17a37dab71d5e33088eb62bb74f5d
https://github.com/kenCode-de/c-libp2p/commit/0e0b6b15465c224235e78f91056d5dc0accf23e3
https://github.com/kenCode-de/c-libp2p/commit/c343d2d0ad1e2d4def471064f4e7593f2f61ac88
https://github.com/kenCode-de/c-libp2p/commit/e092a0e974689fa15be17f0bc7f59c9634db1863
https://github.com/kenCode-de/c-libp2p/commit/05cc6e9bd3f025316ce4d95f080eeb21a3e57b38
https://github.com/kenCode-de/c-libp2p/commit/3d53c470a50a2a75bda41d32706b6a3bc31f7c4e
https://github.com/kenCode-de/c-libp2p/commit/a6fe0fda4765b41fb371cf48787db4038e7429bf
We then made the interface to streams a bit more generic:
https://github.com/kenCode-de/c-libp2p/commit/d0512d90847dbc95283e1f5f38afbda1adedccd8
https://github.com/kenCode-de/c-libp2p/commit/74d95cb696b6da141e6b751faa8abb5495d5ee45
c-ipfs was then modified to use the new code:
https://github.com/kenCode-de/c-ipfs/commit/cd5d347e6346e26256c1bc96b92dbb62bf741e17
https://github.com/kenCode-de/c-ipfs/commit/15a8abff9a7abd417b90a4ebda39ecfa9fac27ad
https://github.com/kenCode-de/c-ipfs/commit/43ca31385463774f2466eb55efced36a94b7d82d
Additional c-libp2p work finished up:
https://github.com/kenCode-de/c-libp2p/commit/0ffe73ae28202df7453be74b6502093a0c2df13b
https://github.com/kenCode-de/c-libp2p/commit/1b5b7c7cbacd354938c377788ef1e6af180b65e5
https://github.com/kenCode-de/c-libp2p/commit/018923ad0964c558a19c5d65688ab9ff503c7c55
https://github.com/kenCode-de/c-libp2p/commit/1fa0d4bd682060e5f60afbd4ff38f116d49713c7
Kademlia/DHT will finally be completed by tonight or tomorrow, just need to finish the callback work for returning search results.
Plans for the final week:
Lots of code cleanup now. Tidy up the comment lines, indenting and spaces, remove unused code/methods, and add efficiency wherever possible. Like I always say, every byte counts. Our v1.0.0 release will be for *nix systems and the RasPi3 first. Then the build for android the following week.
Android Smartcoins Wallet:
As you guys know, the Smartcoins Wallet is about to natively support 6 blockchains. Bitshares, Bitcoin, Dash, Litecoin, Dogecoin and Steem. In v1.7 our new streamlined Overdraft Protection feature (aka: "backup asset") will be upgraded to graphenej. In 2.0 (I'll upload a youtube vid for you guys this week I hope so that you can see the new ui/ux concepts in action) we add our c-ipfs and initial meshnet support and the rebrand of the wallet to "Carbon". Also, a big shoutout to @iHashFury for the suggestion (https://bitsharestalk.org/index.php/topic,22576.msg302196.html#msg302196)!
Work done this week: - Bitcoin support is done and tested (send/receive, balances, transactions, qr, import/backups, eReceipts, etc)
- Change api to new server parameters
- Testing of our altcoin fullnode servers (Dash was first, then Doge and Litecoin...)
- Change contacts to use sqlite db
- Changed contacts fragment, add and edit activity to work with BTC/alts
- Changed the Send screen to enable selecting BTC/alts Contacts
- Create base Custom Network Parameters for altcoins
Most of the upgraded UI (for multi-chain support) is ready, the thing to note is the interface is implemented with a new line for each coin right now, but this basic UI will be replaced in v2.0.0 ("Carbon"). Also the send and receive screens had to be modified to adapt to the upcoming 2.0 UI (I'll post a youtube vid so you can see our progress on it in the next week or so).
Work coming this next week: - Figure out Dash InstantSend and get it finished
- The code we had created for the original Contacts screen needs to be cleaned up now that multi-chain support has been added
- The network parameters in bitcoinj are used to calculate all the transactions and the addresses, which is needed to use the api, so we standardized this to use each altcoin, which in turn makes the implementations much faster
- Upgrade our fullnode servers to support the additional coins
- Make sure all the chains we offer native support to can also take advantage of BlockPay Loyalty Points, Overdraft Protection, eReceipts and so on
- Testing Litecoin
- Testing Dogecoin
- Test and bug fix the Bridge so that users can shift between coins when desired
Stealth related:
We're now into week 2 of 6 for the Stealth api creation. In the UI, I have also designed a "3-way switch" that allows you to just do a Normal, Blinded, or Stealth transaction simply by flipping an animated switch. This is a compact way for users to just flip the switch and sends funds however they like. I will try to get you guys some screen shots in the next couple weeks so that you can see it in action.
I also am adding an option in the wallet Settings where you can choose the default setting for that switch, so that you don't always have to remember to set your transaction to Stealth, or just Blinded mode, etc. If you have ever seen that "Propose" 2-way switch when you send funds, well, just imagine that as a 3-way switch on the Send screen. Grayed out for Normal, the switch turns yellow if you flip it to Blinded, and it turns red if you flip it to Stealth mode.
This 3-way switch also works nicely on mobile since it is so compact, colored, etc. BlockPay merchants and users alike want an easy way to use Stealth so I went with the k.i.s.s. method on this. The further we get on the Stealth api, the more UI hooks we can make. Lots of Stealth coding to show this week:
https://github.com/kenCode-de/bitshares-core/commit/009b3e6c8e99349450349913b12a0bced6631cec
Besides the 3-way switch, we have also made huge progress on the database, account and contacts editor screens, and initial outlay for the automated backups feature using our c-ipfs implementation. Now that the encryption work is done, it's just down to the api and "trustless setup" algo (which we already have the plan for and will be relatively easy to implement and prove thanx to DPOS). More on that in week 6.
Lots of logic has been added this week too which prevents users from screwing anything up. Besides Chrome support, we are also writing the necessary code to make Stealth as portable as possible in different browsers and configurations such as Firefox and non-websql compatible browsers.
By the way, I don't know if you guys ever saw the original drawings that bytemaster did for Stealth when he used the "@" symbol for addresses. I use a lot of keyboard shortcuts and don't reach for my mouse much, so by having an easy way to access Stealth accounts and addresses by just typing that one character is a nice feature, so I have implemented that in the UI as well. You don't have to type it, as flipping the 3-way switch will do it for you, but I like having that option available. Not that reaching for my mouse is hard or anything..
Alfredo Garcia, Bitshares Core Dev update:
Alfredo has some monster updates done this past week. The segfault issue in the get_ticker api call has been fixed. The cause of the segfault has been found and removed but this led us to a new additional bug that was found in an api call get_trade_history used by get_ticker and get_24_volume calls.
Those new bugs found are being researched as we speak and we should have a solution for them as well in the coming week. In the process of a change in get_ticker and get_24_volume, calls to don't use get_trade_history or fix the get_trade_history function. So fixing this is definitely a priority too.
Regarding the "Socket spamming too much data." issue:
https://github.com/bitshares/bitshares-core/issues/231
New commits from elmato in his branch: https://github.com/elmato/bitshares-2/tree/no-spam-sub-function
We tested and setup a node for sigve to make the final tests before the merge. Everything is working great now so as long as our final tests work as expected, we will finally commit this one (hopefully by monday)
Regarding "Can operation_results please show the operation id(s) of all ops in the tx?" issue:
https://github.com/bitshares/bitshares-core/issues/243
This one is now in progress.
Regarding "https://github.com/bitshares/bitshares-core/issues/159" issue:
https://github.com/bitshares/bitshares-core/issues/159
This one is done as well and I will close it in the next 24 hours.
Here is a list of some of the other bitshares-core issues that Alfredo is tackling right now:
https://github.com/bitshares/bitshares-core/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc
As for new features, I would like Alfredo to also work on Dividends, Black Swan prevention and recovery, advanced Trading functions to DEx (Margin Trading, Stop Loss, Trailing Stop etc.), selling/dumping a UIA that you no longer want, Worker proposal upgrade (as per Data and Jonny's ideas), Recurring and Scheduled Payments feature, make it so that FBA's don't always need a hardfork, and a lot more. If you have ideas for new features, please contact chris4210 since he maintains the Bitshares wishlist.
Over the weekend I will also publish more app updates to google play for both BlockPay and the Smartcoins Wallet so stay tuned if you want to see all the new stuff we've been working on. As usual, I will post the download links here for you guys too.
-
Serious congratulations for BlockPay kencode
BitShares need more business people like you
You're a pioneer
Best BitShares product. An actual economic benefit to existing fiat companies to use the bts blockchain.
+5% +5% +5% +5% +5%
-
Thanks for all the hard work @kenCode, Christoph, and the whole blockpay team.
+5% +5% +5%
well done +5% +5% +5%
Awesome update kenCode.
@kenCode Are -- are you a machine?? :o
Yes, I think he is a machine :)
Well done my friend, awesome report!
+5% +5% +5% +5% +5%
Thank you guys :)
BlockPay v1.5.9 released. In this version we cleaned up the settings screen quite a bit, removed more of the redundant stuff that just annoyed people. At the end of this coming week we will start cleaning up the Blocktrades screen too so that it is easier to get the app setup initially. Lots of cpu/mem/bandwidth and speed improvements in this release. Known issue: Transactions screen is disabled for now and still needs to be upgraded to our new graphenej library and it looks like hell imo.
https://play.google.com/store/apps/details?id=de.bitsharesmunich.blockpay
ps: i hate to ask, but if you haven't done so already, can you please leave me 5-stars on the google play store? it really helps with exposure and promotions of the app. thank youuu!
-
In China , we cant visit in google.
Why not add apk in https://github.com/kenCode-de/smartcoins-wallet/releases
-
In China , we cant visit in google.
Why not add apk in https://github.com/kenCode-de/smartcoins-wallet/releases
Feel free to build it from src yourself, or download the Smartcoins Wallet from aptoide, yandex, alternativeto, slideme or f-droid (they should have it live by now).
If you meant the BlockPay apk, I really don't want to post the src for that just yet and give the competition an edge, at least not until it gets some traction first.
edit: belay my last on those alternative app stores. apparently, they disapprove any apps that include crashlytics. i want to keep crashlytics in our apps for just a couple more weeks until there are no more crashes reported. it helps us to more accurately determine the cause of the devices that crash (make, model, os version and so on).
-
Tons of updates this week!
https://github.com/kenCode-de?tab=repositories
(http://i.imgur.com/HAYRSgl.png)
BlockPay related:
Lots of work being done on the Settings screen this week and next. My goal is to have a 1-step setup. I'll upload some more this coming week so you guys can have a look but for right now the code is a mess while everything on that screen is being reorganized.
Another major thing that I am cleaning up is the way transactions and eReceipts are displayed. This will be updated this week as well and then I will get you guys another version release published on google play, probably on thursday or friday.
C-IPFS related:
Final cleanup being done now, efficiency improvements in the code, and also adding support for Coral, Bitswap and Cjdns. With the completion of C-IPFS, at least to the point where it is perfected for our needs, this allows us to begin the 2.0 Core for BlockPay and Carbon (the rebrand of the Smartcoins Wallet for v2.0).
Related commits:
https://github.com/kenCode-de/c-libp2p/commit/17dfadb6fd1f4032dcc439a19cb24dd337b96b4b
https://github.com/kenCode-de/c-libp2p/commit/52f8ce2b3dd96868785413a60c6dc687e4e8232f
https://github.com/kenCode-de/c-libp2p/commit/f0bb7375c39d1d0d951ca490a2a2520a945f43be
https://github.com/kenCode-de/c-libp2p/commit/8463e0b06b0943a7dbba9972f1cd036af844e1fd
Android Smartcoins Wallet:
Adding native support for 6 chains is not easy. Native Dash support and InstantSend is in progress now and into next week. This means we are almost done with 5 of the chains already. Just another couple weeks and they will be ready for our v1.7 release. Work finished this week: - Fix logged UI logic OR in imported account
- Add Support for WIF Imported Account
- Fix UI Problem with Upgrade account button in Settings
- Export Bin for WIF Imported Account
- Import backup bin logic for WIF only based accounts
- Partial fix for instant update for Transaction
Related commits:
https://github.com/kenCode-de/smartcoins-wallet/commit/15fac5ac9e442d35118f23b8df66e704fb1ab39c
https://github.com/kenCode-de/smartcoins-wallet/commit/6c7ff95fdc28ccf75f79db72ad5c1c46e351abe1
https://github.com/kenCode-de/smartcoins-wallet/commit/c70b342962449be09b273b9852bb8985c1fb35f2
https://github.com/kenCode-de/smartcoins-wallet/commit/abc866528c5977655a28c0f81c44a8267542ecff
https://github.com/kenCode-de/smartcoins-wallet/commit/45c6ad95f5e10b31631e45bf216e8b07936c7bec
https://github.com/kenCode-de/smartcoins-wallet/commit/a66863e4c8825a1e518191c03eecc159bc5f4bbe
https://github.com/kenCode-de/smartcoins-wallet/commit/67e240802f828a82a231413a0309a67460726362
https://github.com/kenCode-de/smartcoins-wallet/commit/d0d921bf2b7eb4c5aa4889c7ec549f2fb317b5d7
https://github.com/kenCode-de/smartcoins-wallet/commit/ec5e124428907bf49bd0bfb9624c27eefd2a4404
https://github.com/kenCode-de/smartcoins-wallet/commit/7426d7014295a14bba587c145ec5db4e9c5be134
Details: - Testing Dash masternode api
- Implement the Dash api library (Java)
- Implement Dash coin logic
- Changed the Balances screen to work with all coins
- Add Dash Manager
- Implemented Dogecoin and Litecoin networks into the java library
The masternodes server and other full nodes are running great, no problems so far. Network parameters are set. For Dash, we are using this lib as our main reference point:
https://github.com/HashEngineering/dashj
Now that we have full, native Dash support in Carbon (Smartcoins Wallet 2.0), the only feature that needs to be finished up and thoroughly tested now is the InstantSend feature.
For the native Litecoin and Dogecoin support... - For address creation we'll use this link https://iancoleman.github.io/bip39/ -this will give a good address of each network and we compare with the one our libs calculated
- For transactions we'll use this link https://live.blockcypher.com/btc/decodetx/ -this also can send data
We've had to change several things in the UI, but if we keep moving at this pace then we should be able to merge the develop branch in the next week for final testing (assuming the Dash InstantSend feature goes smoothly).
With these tasks finished, it looks like we'll be finishing 1 week ahead of schedule. Then, just two things left: - The Equivalent Value feature: This is the small fiat value that shows underneath of each of your crypto balances.
- Contact sharing: This is done more or less but we have not had a chance to fully test it yet
Stealth related:
The new api is coming along nicely. No problems encountered, no bugs, no memory leaks or any problems communicating with the core. Seamless. This is week 3 of 6 for the api, and as each new function is built, the UI connections are being hooked in and tested. The 3-way switch too. Man I'm glad I thought of that as there was no easy way earlier to give the user so many options. We'll never get mass adoption if grandma can't use it.
Additional Stealth API related work: - Stealth joinsplit wrapper to use in trx objects
- Fix the proof construction for multiple asset types
- Fix some compiler errors:
https://github.com/kenCode-de/bitshares-core/commit/24d247a3df984438a205e558e89640cab5035133
In the UI, we're OOP'ing both Stealth, and the Blinded transfers for ease of future use, and use by our mobile and Integrated BlockPay installs {Contacts-Accounts-Database-Transfer}. We also prepared the modes functions for future tri-state (Normal, Blinded, Stealth (3-way switch)) transactions {for Account creation & transfer screens}.
Alfredo Garcia, Bitshares Core Dev update:
Failed is_valid for address in get_account_history
https://github.com/bitshares/bitshares-core/issues/159 closed
issue “Throw / catch specific exception in db.close()”
https://github.com/bitshares/bitshares-core/issues/81
pull request: https://github.com/bitshares/bitshares-core/pull/246 closed
Why is bitcoin being exported with the bin file backups? see the second code chunk nelson posted:
https://bitsharestalk.org/index.php/topic,23798.msg302837.html#msg302837
@sigve Deposit keys are just addresses for withdrawal of OPEN.X assets, blocktrades has made use of the database to store them. DONE.
Need ability to poll for all holders of an asset
https://github.com/bitshares/bitshares-core/issues/107 closed
issue: “Get rid of fc::time_point::now()”
https://github.com/bitshares/bitshares-core/issues/76 closed
pull request: https://github.com/bitshares/bitshares-core/pull/247
Remove NTP time
Vikram didn't merge Alfredo’s exactly, but used it to merge another one here:
https://github.com/bitshares/bitshares-core/commit/8ae1f6b3a52c36b0c9c454654a338511c0f4812b
Lots of contributions to the BitShares StressTest; servers, code, consulting with other sysadmins, etc.
Preparing for the next stress test, evaluating p2p code now to make the next stress test blow through that 3300tps barrier.
-
Impressive as always kencode!
-
+5% +5% +5%
-
Impressive as always kencode!
+5% +5% +5%
Thank you guys :)
Tons of updates this week!
https://github.com/kenCode-de?tab=repositories
BlockPay related:
Graphenej (https://github.com/kenCode-de/graphenej): After having partially implemented the limit_order_create_operation, some issues were still present and transactions with the new operation were being rejected by the network on a missing authority error. This usually means a discrepancy between binary serialization used to generate the signature and the provided JSON-formatted string describing the transaction itself.
A couple of errors were found and fixed, which finally made the transactions bearing that operation to be accepted by the network. This commit also introduces a simple test suite for the transaction using this operation as well as minor adjustments to the test of the operation itself. See:
https://github.com/kenCode-de/graphenej/commit/a9a550491b4a0b4b3cd76b6c8a21f1d4fa8e7b13
Support for the limit_order_cancel_operation was introduced, which also features the corresponding test cases. See:
https://github.com/kenCode-de/graphenej/commit/aa642edce9188185a68695e196244291beb88dc5
Finally, some changes were made to the library in order to make it more easily available for everyone via the maven central repository. This will allow us to seamlessly work with updated versions of the library on multiple projects, by using semantically versioned releases of it. This was required since it was starting to become a hassle to keep the library updated on multiple projects and to manually port the updates coming in from some of my other Devs. See:
https://github.com/kenCode-de/graphenej/commit/c6e4b9ea5b070c8629563e528b4189a376f31ea2
https://github.com/kenCode-de/graphenej/commit/425cb663b1dad8a5c59ad28cf521955a36f1ddda
The result is that our library can now be included in any android project by just dropping these lines in the corresponding build.gradle file:
dependencies {
compile 'com.github.kenCode-de:graphenej:0.4.1'
}
The graphenej library was removed from BlockPay itself and just referenced now like described above. Work has now begun in making use of the 2 additional supported operations that will give us "direct DEx" access and avoid having to use the Bridge services twice for some asset pairs. Speed is everything when standing at the cash register, right? See:
https://github.com/kenCode-de/blockpay-s/commit/8c429fe4c7edd55d76fe409140760fd588796174
C-IPFS related:
This week, we worked on a simple node transfer protocol to allow for easy and wicked fast transfer of files and data, without the overhead of a larger protocol.
We have in place a test that is running the code through a complete startup, connect to the "swarm", ask for an existing file, have the swarm determine the best peer(s) to serve the file, connect to the appropriate peer(s), and retrieve the file. We're currently on the "find the best peer" part. And I am confident that once that is in place, the rest of the test will work fine and will be up and running by tonight (Friday).
DSHT (Distributed Sloppy Hash Table), or "Coral" as it is also known, is being worked on this week too which will radically speed up response times (our way of sneaky "load balancing" (self-organizing clusters) if you will). Speed is everything when you want to access your files, latest BlockPay apk and app assets, etc. Who needs app stores when there are thousands of peers willing to serve it up for you without microsoft, apple or google's "approval".. aaaanyway.. i tip my tinfoil hat to them for trying. #tinfoilken
Development of NodeIO Protocol:
https://github.com/kenCode-de/c-libp2p/commit/69cbff9cd6173177a4b403f9776a3261d3b758d6
https://github.com/kenCode-de/c-libp2p/commit/b6a94c7c11831398e06597f4c804b65ce2b7d885
https://github.com/kenCode-de/c-libp2p/commit/0d0c9bde535062cf8baf175b4c4d84e5b60af1bc
https://github.com/kenCode-de/c-ipfs/commit/e8b8d06f24e6b1275053ce594af9ef208b023b38
https://github.com/kenCode-de/c-ipfs/commit/0b238eb5ace2d7d19f4360949c94fb518e7289ff
https://github.com/kenCode-de/c-ipfs/commit/cfcabaecd0a25f815f9cc1f5095edf9f52b094c7
Compiler changes for CentOS and more extensive tests, plus general code efficiency, cleanup and testing:
https://github.com/kenCode-de/c-libp2p/commit/9776ff15a091507ceb95ccf41c01d09282ae24f8
https://github.com/kenCode-de/c-libp2p/commit/bd9f219b504747c461bc01ae07d17858ebfaa2bd
https://github.com/kenCode-de/c-libp2p/commit/41ef0e54929d8184a808e152b41542f889f5a2f1
https://github.com/kenCode-de/c-ipfs/commit/8edc94509c54e4851d2f929b0e65f6a4ee9530d0
https://github.com/kenCode-de/c-ipfs/commit/83242b0046d2d0b1bba84dbfe698014812a96141
https://github.com/kenCode-de/c-ipfs/commit/618264c70962d17c9f7e4dc7287ac28ea1a825da
https://github.com/kenCode-de/c-ipfs/commit/25a2fa0c65934a66aac39d0dd3a0de2e20149dd2
https://github.com/kenCode-de/c-ipfs/commit/640e4be5be23bf7579cd613999d6bfc95e9ca366
https://github.com/kenCode-de/c-ipfs/commit/d25e088b7c5427fa565b9e299fb268e5c9b2e881
https://github.com/kenCode-de/c-ipfs/commit/6c64b55176e43fe6eb9ff7cbce893620f8a1b49d
Plans for the coming week:
We'll continue to work on the "swarm" features, as well as replication. We'll also look into the modifications the Go-IPFS has done for security and performance improvements of the dht/kademlia standards. Some work is being done to decentralize our access to the Bridge too, so that any server downtime could be handled gracefully. We don't want thousands of merchants unable to process customers because a damn third party's server went down.
Android Smartcoins Wallet:
It's nice having WIF key support now! Minor improvements were made to it this week, where we changed the double account verification logic, just in case it is a WIF based backup bin file to a method which is now calculating and comparing both (vs brainkey derived) and if they differ, assume it is WIF key backup, and avoid double checking at the network. In other words, it operates more efficiently now, is a bit "smarter", and uses less bandwidth overall.
We fixed a memory leak that happens because of an unexpected (yes or cancel) dialog box. Removed it since it's no longer needed anyway.
We switched from TZ to LZMA for compressed files (some parts of the code were still using deprecated code from cryptonomex/graphene lib).
As you know, we are doing a lot of work on the Transactions and eReceipts code for BlockPay and the Smartcoins Wallet, some pretty major refactoring goin on now so it is nice and clean and operates seamlessly with our new graphenej lib too.
Related commits:
f549316cbc1db4d3820ea6f29c3b483890c9de73
341eff49d609854ef7e5dfbd009b0988a5c51f0b
a5cac8de7819132ecadc6b8d0cd8b0591297034b
a8080a05951b385826118cfd902ace2ddf500a71
07180e4327c2d909f7edf787bd851029a224b40f
4d256ab620cda5b9dd68861edb97312d0eb6021e
Once the Transactions and eReceipts code has been finished and thoroughly tested then I will publish an update to google play, probably in the next week or so since I am including a bunch of other cool stuff we have been working on..
Since Smartcoins Wallet 2.0 (codename: "Carbon") will natively support 6 chains, here is some of the work that was completed this week on that: - Added a separate button to send a receive to each coin
- Change the transaction history to display the bitcoin and altcoin transactions
- Make eReceipts work and show which coin you sent/received etc
- Testing several issues showing Balances
- Implementing Litecoin and Dogecoin logic, testing without server
- Researching Dash InstantSend, running first tests
We have all the logic to make the altcoins work, the only problem now is the server software for their chains..
Dogecoin seems to be the most difficult because of the lack of support, their last update was 2 years ago. For Litecoin this week we have the news that they updated their library, so that just leaves Dogecoin.
Lots of server tests too just to make sure their libs don't have any leaks etc. I want these integrations to be as maintenance-free as possible.
For the InstantSend feature for Dash, we have run several tests, and had found that feature on server side, and dug into their libs and found this: - The lines that use the insight part are in https://github.com/dashpay/insight-api-dash/blob/master/lib/transactions.js line 304
- The following code https://github.com/dashpay/bitcore-node-dash/blob/master/lib/services/bitcoind.js at line 1818, in this line we see that the only parameters sent are the transaction, as raw hex, and a boolean
- The previous command reaches the core at https://github.com/dashpay/dash/blob/v0.12.1.x/src/rpcrawtransaction.cpp line 312, in this we see that function can have from 1 to 3 parameters, and the last parameter declares if it's an InstantSend transaction or not
- The rpc module used by bitcore-node-dash is defined here https://github.com/snogcel/bitcoind-rpc-dash/blob/master/lib/index.js, if we see line 206 "sendRawTransaction: 'str'," --We see that the rpc is configured to send only a parameter, the raw transaction as hex string, in theory adding the two booleans, so we can enable the InstantSend feature.
Now we just need to set the servers up for this, change a couple of files on the server (they're all nodejs so no worries), and only affects the Dash libraries. Easy-peasy.
The tasks for this coming week are: - Editing a couple of Dash files on the server to support InstantSend
- Change the Contact screen a bit to support Bitshares and altcoin Contacts
- Change the Send screen so that you can send any of the coins or altcoins that you own
- Merge the develop branch into the main branch
- Begin R&D for the native support of the Steem chain
Stealth related:
Lots of work being done on the new Stealth api so that we can use it in the web wallet, light client wallets and eventually all mobile devices.
More commits:
https://github.com/kenCode-de/bitshares-core/commit/a74639131e0812e2664329037af8b1f7d87daa60
https://github.com/kenCode-de/bitshares-core/commit/6ff204d6f329c14154598997b6f23b37711f5d41
Stealth commands are being ported to javascript too for the UI. As the api grows, so does the UI actual functionality.
So far performance has been good, sending to a Stealth address from public address (cli-wallet), but if it were to become an issue we are already looking at moving that processing to the server along with async. As this progresses I'll keep you guys informed right here on the forum. So far so good though and you guys should be able to join us on our testnet in a few weeks too, at least for the basic stuff. The UI will probably need refinements as always.
Alfredo Garcia, Bitshares Core Dev update:
Alfredo as always is kickin butt too, here is some of his work from the past week:
1) "Clean up re-indexing logic"
https://github.com/bitshares/bitshares-core/issues/175
Tested, commented and requested to close.
2) "Fix the get_ticker crash"
https://github.com/bitshares/bitshares-core/pull/250
There was a segmentation fault in the get_ticker function. Researched. Fixed (found another issue and we're working on that one now too).
Awaiting approval and merge on this one now.
3) Closed github issues: - "No spam sub function" finally merged! https://github.com/bitshares/bitshares-core/pull/249 -which also closes out:
- "No spam sub function2" https://github.com/bitshares/bitshares-core/pull/245
- "No spam sub function" https://github.com/bitshares/bitshares-core/pull/234
- "Socket spamming too much data" https://github.com/bitshares/bitshares-core/issues/231 -running final test today
4) Got this one closed:
"cli_wallet: create_account_with_brain_key doesn't save owner key"
https://github.com/bitshares/bitshares-core/issues/196
5) Requested to close - Closed by TheTaconator with fix..
"Proposed fix for Issue #196: create_account_with_brain_key doesn't save owner key"
https://github.com/bitshares/bitshares-core/pull/235
6) Configured and started using our BitShares Munich testnet server for development environment
7) Helping out Alex a bit on the Stealth UI and getting all the json involved in the blinded and Stealth transactions.
This should be completed by this sunday the 26th.
==============
On a side note, I'd like to ask the community if I can add one more of my Devs to help out Alfredo. If it's cool with you then I will have Chris write up the 6mo Worker Proposal and get it posted asap for your review so we can get him voted in. It's time we ramped things up even more imo.
-
Looks interesting .. seems to be quite some process you are making..
So far performance has been good, sending to a Stealth address from public address (cli-wallet), but if it were to become an issue we are already looking at moving that processing to the server along with async. As this progresses I'll keep you guys informed right here on the forum. So far so good though and you guys should be able to join us on our testnet in a few weeks too, at least for the basic stuff. The UI will probably need refinements as always.
I still haven't understood what you guys are working on with STEALTH on the backend. Could you please provide us with some sort of specifications? You'll need to provide those anyways if you need a hard fork
-
Looks interesting .. seems to be quite some process you are making..
..
I still haven't understood what you guys are working on with STEALTH on the backend. Could you please provide us with some sort of specifications? You'll need to provide those anyways if you need a hard fork
As I learn more, I will keep posting it here. Alfredo is helping gordon and alex a bit now too, so we are moving on Stealth as fast as we can. Hopefully no additional hard fork will be needed for Stealth, but if one is needed, we will most likely roll it in with these others:
https://github.com/bitshares/bitshares-core/issues?q=is%3Aopen+is%3Aissue+label%3Ahardfork
-
Guys!
As the stealth feature development approaches completion (@kenCode, we need to get as close an estimate as possible on the ETA for stealth),
we need to have our marketing approach thought out and started, so we build anticipation in the market that peaks when the feature becomes available.
@kenCode, you provide lots of detail in your updates, but in order to create a marketing plan and begin executing it we need to have:
1) a stealth-specific roadmap (i.e. feature element schedule) of milestones that marketing can use to create a marketing plan that coincides with it
2) screenshots, docs / design elements / use cases and other "bits" for the stealth design for which videos and marketing materials can be produced
We need to start coordinating stealth development with marketing NOW, to build anticipation and capitalize on the demand for stealth in the marketplace.
Let's not let this opportunity slip away!
-
We need to start coordinating stealth development with marketing NOW, to build anticipation and capitalize on the demand for stealth in the marketplace.
Let's not let this opportunity slip away!
+5% Nicely said Thom
-
Let's not let this opportunity slip away!
Well duh.
We're just now starting to test transactions and create the first API. Remember how many months it has taken us just to write all the crypto? Remember the months it has taken us on the "trustless setup" algo? Remember the months it has taken us to develop the C-IPFS implementation for the automated Stealth backups?
In a few months when Stealth has been thoroughly tested by us, AND all of the components above, AND by the public, then we can think about advertising. Until that time, guess what? Like we used to say in the military, hurry up and wait. I'm not going to rush Stealth at all. At, all.
If you want me to stop posting weekly updates on our progress so that you feel better, I will.
-
Let's not let this opportunity slip away!
Well duh.
We're just now starting to test transactions and create the first API. Remember how many months it has taken us just to write all the crypto? Remember the months it has taken us on the "trustless setup" algo? Remember the months it has taken us to develop the C-IPFS implementation for the automated Stealth backups?
In a few months when Stealth has been thoroughly tested by us, AND all of the components above, AND by the public, then we can think about advertising. Until that time, guess what? Like we used to say in the military, hurry up and wait. I'm not going to rush Stealth at all. At, all.
If you want me to stop posting weekly updates on our progress so that you feel better, I will.
While we do not want you to rush something out... the mention of this being months away is concerning. How many months? 1-3, 3-6, 9-12?
This information is important because if it is the latter, I believe there is a high probability that you will need to come back to the market and raise funds via blockpay dilution.
-
@kenCode, take a chill pill man. I agree there's no reason to rush and botch the implementation to meet some arbitrary deadline. We also need to be cautious about what we say prior to release. Not sure why you responded in such a defensive manor, everybody including myself think you're doing a great job. All I'm saying is please give us a ballpark roadmap on the completion dates for various goals to be achieved along the way, so we don't have to serialize marketing with development. They need to be coordinated, and that obviously hasn't happened yet.
The idea of waiting for every single little aspect of stealth to be ready AND tested BEFORE we begin to market is IMO a big mistake. Software is never perfect, there are always tweaks to do. You said it yourself, stealth has been many months in the making, so we need to start thinking about who and how we will market it. Dash says target audience is grandma, so do you.
Fuzzy mentioned there may be a test version coming out for the testnet as early as 3 weeks. Can you confirm that? If not can you estimate when such a test version might first appear on the testnet?
I'm trying to give the marketing people some substance so they can at least start to plan a marketing approach.
Thx
Let's not let this opportunity slip away!
Well duh.
We're just now starting to test transactions and create the first API. Remember how many months it has taken us just to write all the crypto? Remember the months it has taken us on the "trustless setup" algo? Remember the months it has taken us to develop the C-IPFS implementation for the automated Stealth backups?
In a few months when Stealth has been thoroughly tested by us, AND all of the components above, AND by the public, then we can think about advertising. Until that time, guess what? Like we used to say in the military, hurry up and wait. I'm not going to rush Stealth at all. At, all.
If you want me to stop posting weekly updates on our progress so that you feel better, I will.
-
@kenCode,
"I'm trying to give the marketing people some substance so they can at least start to plan a marketing approach."
And just who might these "marketing people" be?
We discussed this in the Mumble, so I don't know why you are bringing it up again now.
When STEALTH has been tested on the testnet and proven to work, that is when marketing is called for, not before. What is the point of paying to bring eyeballs to something that isn't out yet? When there is no action for them to take? And which may prove to not work yet?
Ronny tried to get me to start advertising STEALTH many many months ago when I was the sole token holder. I told him that I am philosophically opposed to advertising vaporware to the public (or to anyone other than early venture capitalist investors who are ready to invest in ideas before there is working software).
Bitshares Munich and I, between us holding a large majority of STEALTH tokens, are in agreement that the project is unfolding as it should and can. Tell these "marketing people" that you mentioned, whoever they may be, to start advertising the features that bitshares already has and which have been operational for ages. Where has this marketing of theirs been until now?
-
We discussed this in the Mumble, so I don't know why you are bringing it up again now.
Regardless of the context of this thread or anyone in it, just as a PSA I think it is VERY important to post/display information in clear terms here on the forums, in a manner that is easy for new-users doing their research to search/query for :)
-
I agree, no reason to limit discussion. Besides, my thoughts here were more to the point regarding stealth marketing.
It seems there's a different opinion of what constitutes "vaporware" and how to market products. I don't see the stealth feature as vaporware, there are resources and progress and actual software in the process of being produced, and using some of that to begin to build awareness in the market a few months prior to release rather than starting when it's released not only stretches the time to achieve market penetration but IMO increases the risk of success.
As to "who are these marketing people?" I have no specific group in mind. I think trying to get professional marketers involved at the 11th hour won't be as easy or as effective than if you started educating them as the product matures. I'm not saying we need to give away all our secrets, holding some information back may have a definite advantage. This is where marketing experience is very valuable, but it's of no value if they aren't involved.
Very few of us here have stellar track records as marketers. Marketing has always been a weakness in this project. We all have opinions and we all want BitShares to be successful. Rather than censor or stifle discussion, how about lets try to be open to it and explore our options.
We discussed this in the Mumble, so I don't know why you are bringing it up again now.
Regardless of the context of this thread or anyone in it, just as a PSA I think it is VERY important to post/display information in clear terms here on the forums, in a manner that is easy for new-users doing their research to search/query for :)
-
Just want to say that I appreciate the details you post Ken. The progress you and your team have made (and will make) is exciting, and I'm glad that you keep us external observers in the loop.
-
I still dont actually understand what the term STEALTH now referrs to (besides being an FBA) ... i had the impression the tech was fully inpmemented and even a GUI available 12 montgs ago but the infrastructure for 'hosted wallets' was the only missing part ... what has changed? Whats the new STEALTH now?
-
I still dont actually understand what the term STEALTH now referrs to (besides being an FBA) ... i had the impression the tech was fully inpmemented and even a GUI available 12 montgs ago but the infrastructure for 'hosted wallets' was the only missing part ... what has changed? Whats the new STEALTH now?
. +5% Me too.
-
I still dont actually understand what the term STEALTH now referrs to (besides being an FBA) ... i had the impression the tech was fully inpmemented and even a GUI available 12 montgs ago but the infrastructure for 'hosted wallets' was the only missing part ... what has changed? Whats the new STEALTH now?
If YOU are asking such questions it only goes to show how poor we are at marketing and planing, AND that despite all the detail in @kenCode's reports, we still don't have a roadmap that allows shareholders to correlate all of ken's report details into the higher level roadmap / schedule. THIS is the very reason I'm bringing up the topic of marketing. We need to get better at it and recognize our skills in marketing need help.
We should also be cautious and not reveal too much to the public that shoots ourselves in the foot or gives the competition an advantage. Kencode appears to be doing a great job at managing a large workload of several projects, not only stealth, but it almost feels like an endless war on terrorism with frequent reports on this battle or that, and no bigger context for how those battles impact the overall war effort. When will the war be over? What are we fighting for?
I am all for giving @kenCode a great deal of latitude (he's earned it!) and I don't want to heap undue pressure on him or rush him. Some people don't work well under pressure, others thrive on it. We all just need to recognize success will come easier if we can learn to work together and not think of ourselves as an isolated individual responsible for a specific contribution.
As those of us who have evolved with the advent of disruptive technologies now know, trying to maintain a tight grip on things, whether it be through IP, patents & copyrights, or through a powerful group of elite "leaders" that centralize power, is counterproductive and less secure than decentralized, cooperative sharing is.
I also think we should be tapping into those of us in this community that have direct experience in marketing like SolarsNsense, Mr. Wang and VirtualGrowth.
This community has been burned so badly before by marketing execs (Brian Page) & their decisions people are being over protective / overly conservative about engaging professional help, and yet we need help with marketing so badly on this project.
-
I also think we should be tapping into those of us in this community that have direct experience in marketing like SolarsNsense, Mr. Wang and VirtualGrowth.
I mentioned this to @MrWang on steemit. I think if we have a Spokesperson to replace @bitmarket (Max Wright, Host of BitShares.TV and Author of BitShares 101). And having people like @MarketingMonk (chris-coney), @JonnyBitcoin, @fav, and many others doing tutorials. We might have something here.
-
If YOU are asking such questions it only goes to show how poor we are at marketing and planing (...)
He just asked what's that smell. I think that's why he is the biggest proxy.
-
If YOU are asking such questions it only goes to show how poor we are at marketing and planing (...)
He just asked what's that smell. I think that's why he is the biggest proxy.
This is what STEALTH can do *TODAY*:
http://docs.bitshares.eu/bitshares/tutorials/confidential-transactions.html
It's all a mature of web-ui which has also been worked on by JamesCalfee in the stealth-wallet branch: https://github.com/cryptonomex/graphene-ui/tree/650-stealth-wallet
All that was need for that to be usable was the deployment of the hosted-wallet branch of graphene-ui: https://github.com/cryptonomex/graphene-ui/tree/server_backups
All I was asking for is a SPEC on what they are actually working on right now, given that STEALTH is already (kind of) available. I hear ken through around terms like SNARK and trusted setup and just wonder why not setup the current STEALTH first before introducing a new extended STEALTH ..
That's what confuses me
-
Why not setup the current STEALTH first before introducing a new extended STEALTH ..
That's what confuses me
That is really interesting question.
-
"unknown" sent "n" "unknown" to "unknown"
Total privacy, that is what was discussed from the beginning, and that is the code that has been worked on since that time. Like so many other things, nobody else picked up the ball, so I did.
Stealth == The accounts, the amounts, the asset that was sent, the metadata.. total anonymity. Backed up automatically for you in C-IPFS, with a new UI that even my Grandma will understand.
I hear ken through around terms like SNARK and trusted setup and just wonder why not setup the current STEALTH first before introducing a new extended STEALTH
We're not going to shift gears now in the middle of the project so that we can start coding a half-assed release for Stealth or its UI. The competition and the media would sure love it if I did that though. Do your job right the first time, or don't do it at all. "current STEALTH" - LOL
i had the impression the tech was fully inpmemented and even a GUI available 12 montgs ago
The existing "blinded" code (or "confidential", whatever you want to call that crap) does not give you Stealth level privacy at all, nor is there a UI that was built for it that was even remotely usable. Don't mislead people into thinking they will be private.
@kenCode, take a chill pill man.
#1 NO. #2 Who's got time to "chill"?! The world is going to shit and I don't see many people getting off their fat asses to do it, let alone do it RIGHT. Time is short and what I see here is a know-it-all, wannabe-Leader, who's posturing for no reason. The products I have built can actually save lives. What are you doing? Maybe we should DOUBLE your pay again, and then you'll feel important.
Now, regarding the STEALTH tokens, I don't see anyone selling those yet, and are not even required if you want to use Stealth transactions.
As for Marketing, I see onceuponatime answered it for me, but I will reiterate. If you're such a marketing genius Thom, then why aren't you out there marketing our prediction market? Or the DEx? Or our decentralized governance? Or our market-pegged assets? Or our advanced multisig? Or our speed or scalability? Or the myriad of other things our platform can already do? Rhetorical question, Farley.
You can either build Stealth yourself, or stfu and let me do it the right way. There's your "SPEC" and roadmap for a product that has never been correctly built before. You can market Stealth months from now once the public has had a chance to test the shit out of it first.
Until then Thom, why don't you build something? Like support for Trezor. Or Dividends. Or a Block Explorer. I don't care, just build *something*.
Rattling my cage will not make me work more than 18 hours per day, 6 to 7 days per week. Or any of my Devs who work just as hard.
@Thom - Maybe we should double your pay again so that we can "market" your great contributions, or buy some more of those reeeeeeally effective banner ads? LOL
As usual, see you on Friday.
-
+5%
-
i had the impression the tech was fully inpmemented and even a GUI available 12 montgs ago
The existing "blinded" code (or "confidential", whatever you want to call that crap) does not give you Stealth level privacy at all, nor is there a UI that was built for it that was even remotely usable. Don't mislead people into thinking they will be private.
Current STEALTH can do this:
"unknown" sent "unknown" amount of ASSET to "unknown"
The only difference to your plans are that the 'asset' is public, nothing else. And that tech
* is implemented in the backend already
* has a working wallet implementation (JS + React)
* does not need a hard fork
* only needs a 'nicer' GUI for grandma
Now, regarding the STEALTH tokens, I don't see anyone selling those yet, and are not even required if you want to use Stealth transactions.
There are around 3 people on the planet that own STEALTH and you are one of them, onceuponatime is another, I guess Dan has some aswell ..
PS.
Assuming you are building a more advanced STEALTH (and I haven't seen the SPECs yet), then I would *highly* recommend you play nice with **ALL** of your shareholders
because you will need their votes for a hard fork
For me, I am fine with having SPECs and being able to verify that the code does what the SPECs say. So as long as those two are not provided, I can not approve a hard fork.
-
Rattling my cage will not make me work more than 18 hours per day, 6 to 7 days per week.
I'm confused...why the hostility? I haven't seen anyone rattling your cage at all, just some basic questions about stealth and suggestions for marketing ideas. Healthy discussion benefits everyone...right?
???
-
Rattling my cage will not make me work more than 18 hours per day, 6 to 7 days per week.
I'm confused...why the hostility? I haven't seen anyone rattling your cage at all, just some basic questions about stealth and suggestions for marketing ideas. Healthy discussion benefits everyone...right?
???
Exactly. Brings to mind a couple of truisms:
1) Good ideas don't need force to spread
2) People who become defensive when none is needed are fighting imaginary phantoms.
I don't know how many times I need to say this before you actually believe it, but you ARE doing a great job @kenCode . All I would like you to hear is please give us a way to put all of the info you provide in your detailed reports into a rough schedule, something other projects call a roadmap. Ever heard of that concept?
No dammit we don't need you getting all defensive and upset. I hate that appears to be occurring but I am not in control of your emotions. I agree, you need to continue working towards your plan, your grand plan to achieve stealth. You probably have the most working knowledge of how to do it. I have seen NOTHING here on the forum that opposes your leadership and ability to manage the technicals, so I am totally puzzled where all this resistance is coming from.
I'm not "posturing", only trying to help all of your hard work @kenCode to be successful. I may not be a great leader or a professional marketer. All I'm doing is trying to stimulate a discussion which you are apparently opposed to. What confuses me is why? Why does this threaten you ken?
Why are you so opposed to providing us a view at a higher level, one that helps us see the bigger picture of the sequence of completion required to arrive at the stealth tech YOU are building, that YOU designed? I can only assume you have sat down and planned the course you're now on, and are not "flying by the seat of your pants" reacting to the technical issues as you figure out a design. Projects that are managed that way are chaotic and rarely on schedule and on budget and I don't believe that is your style.
You obviously spend a not so insignificant amount of time to keep the community informed of all the detailed technical issues you & your team work on each week, so please just consider changing it up enough to show us how and when all those details fit together to achieve the stealth features you have in mind. Don't make such a big deal of that request, it should not be that much of an effort to explain it. I don't believe you have explained that yet, and if I'm wrong and have overlooked that higher level plan you have in mind then just point that out. As you can see from this thread I'm not the only one that has questions about it. Forget about dates, just describe the sequence of elements that need to be built or are already complete.
You would be better served to save your words for describing your project plan than to use them accusing others of what they are doing. Using the strawman or red herring logical fallacies to avoid dealing with the substance of an argument. We all contribute in various ways. It's totally unfair to compare your contribution to mine and say mine is shit or I'm not doing enough. That is divisive and doesn't help.
-
I'm not sure if anyone should demand answers here.
you can either implement stealth as is with a GUI, or wait for ken/onceuponatime (the owners and sole investors by the way) to dock on with their product.
-
I'm not sure if anyone should demand answers here.
you can either implement stealth as is with a GUI, or wait for ken/onceuponatime (the owners and sole investors by the way) to dock on with their product.
Waiting is not going to work in this case, because this "better" stealth requires a hard fork which proxies will not approve before their questions are answered.
-
I'm not sure if anyone should demand answers here.
you can either implement stealth as is with a GUI, or wait for ken/onceuponatime (the owners and sole investors by the way) to dock on with their product.
Waiting is not going to work in this case, because this "better" stealth requires a hard fork which proxies will not approve before their questions are answered.
pretty sure they will answer questions in a few months after the tests.
-
I'm being patient, but I'm also really looking foward to stealth. I will download bitshares daemon and use the API if that can be delivered now.
Also does stealth++ require a fork? that's an important question we should know about
-
Are there any screenshots of alpha or beta versions of the new grandma-friendly UI that includes support for the new stealth?
And realistically speaking, considering the likely extended period of testing this (much needed) feature will require, when are we expecting to have it rolling?
I'd like to write some articles on steemit about all of this and how financial privacy matters, but I don't want people to come and check Bitshares out only to realize that confidentiality is still a year away.
-
I'd like to write some articles on steemit about all of this and how financial privacy matters, but I don't want people to come and check Bitshares out only to realize that confidentiality is still a year away.
Hey, nice to see you here.
Is there any chance that we can read summary of your survey? YES/NO
Still have that in mind. I realize that participation was probably to low but some of us answered bunch of questions.
-
I'd like to write some articles on steemit about all of this and how financial privacy matters, but I don't want people to come and check Bitshares out only to realize that confidentiality is still a year away.
Hey, nice to see you here.
Is there any chance that we can read summary of your survey? YES/NO
Still have that in mind. I realize that participation was probably to low but some of us answered bunch of questions.
I can probably dig up the results if people find it relevant enough.
Participation was <100.
-
Massive work done this week:
https://github.com/kenCode-de?tab=repositories
(http://i.imgur.com/HAYRSgl.png)
I would *highly* recommend you play nice with **ALL** of your shareholders
because you will need their votes for a hard fork
... I can not approve a hard fork.
@xeroc -threatening us with your Proxy-power because I do not "play nice" is not productive at all. We *greatly appreciate* the python that you write. You are not a Core Dev though. Fyi, the 20 other hardforks in the queue will need to be properly audited:
https://github.com/bitshares/bitshares-core/issues?q=is%3Aopen+is%3Aissue+label%3Ahardfork
You are not qualified to do deep-dive security audits.
Advising people that their money is safe with the existing "confidential transactions" code, and, giving people security advice is probably not in your best interests.
Speaking of security, since you did not finish the Trezor integration, I would be more than happy to acquire that project from you as well. As usual, a security audit will be done on it, so please advise to the locations of the work that you did so that we can get it completed.
I don't believe you have explained that yet, and if I'm wrong and have overlooked that higher level plan you have in mind then just point that out.
@Thom -I will tell you when you can start your Stealth marketing campaign once the public has had a few months to fully test and security audit it with us (not just Stealth, but the encrypted C-IPFS backups as well). I do thank you for your efforts, and would love it if you organized the marketing campaign for Bitshares' Stealth.
In the world of software, never give out dates (right Stan? ;)). I learned that lesson 30 years ago. Obviously though Thom, I took your comments very personal, so I sincerely apologize for my knee-jerk reaction. I am building things that have never been built before, so it's a bit tough to even hand out any timelines. I am well aware of what needs to be done, nobody has ever had to ask me for updates, and I do my best to detail our roadmap and progress right here on this lovely forum every week, so nothing more.
BlockPay related:
"Direct DEx" is 99% done and has been merged into our new graphenej repo here:
https://github.com/kenCode-de/graphenej
This week we are:
- Upgrading the Bridge code
- Transactions interoperability with graphenej
- Redesigning the eReceipts a bit so that all devices can display them properly
- Starting the initial wireframe drawings for the new UI/UX and 1-Step Setup
Alfredo Garcia monster updates this week:
1) "Boost libraries could not be found"
https://github.com/bitshares/bitshares-core/issues/251
Working on this issue led to bitshares-core compilation in windows.
3 possible methods: - visual studio. - cygwin. -mingw.
Goal is to make it work locally and then update or create new documentation page for building it in windows:
https://github.com/bitshares/bitshares-core/wiki/BUILD_WIN32
2) Working on a new updated version of market_history plugin. Working in a new version based on the Steem plugin.
Will be ready for testing over the coming days.
3) Resolving Issue 231:
Websocket “spamming too much data” issue
Working on last proposal from Vikram to use a separate file for some changes to don’t break design.
https://github.com/bitshares/bitshares-core/pull/245#issuecomment-286267666
No spam sub function https://github.com/bitshares/bitshares-core/pull/234 closed
No spam sub function https://github.com/bitshares/bitshares-core/pull/249 merged
https://github.com/cryptonomex/graphene/issues/540 closed; moved to issue 231..
Resolving it tonight (Fri the 31st) most likely: https://github.com/bitshares/bitshares-core/issues/231
4) Fixed the get_ticker segfault
5) Assist the Stealth Team with the new api, providing documentation and guidance with hooks in the UI.
6) Working on this week:
Verify that public websocket API does not expose sensitive API calls
https://github.com/bitshares/bitshares-core/issues/33
Tackling more Bitshares Core Issues:
https://github.com/bitshares/bitshares-core/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc
Bitshares StressTest
Looking into why nobody could break through the ~3300tps barrier.
-------
Bitshares PenTest
As you guys know, I take security very seriously (#tinfoilken). I would like to hack on our Witness and full-node operators next. To do so, I will hire an outside Firm which specializes in security auditing and penetration testing. This will require funds from the pool. I am researching the options now, finalizing the formal Proposal, and will post their Bid here as soon as possible.
-------
Smartcoins Wallet:
I might release one more 1.x version of the Smartcoins Wallet on google play, but work has already begun on 2.0.
"Carbon" (Smartcoins Wallet 2.0) features: - Carbon natively supports 6 blockchains (Bitshares, Bitcoin, Dash, Dogecoin, Litecoin and Steem).
- Carbon supports HD Contacts (rotating addresses) and Contacts Groups (for paying multiple people at once).
- Carbon allows you to pay at any BlockPay merchant with just 2 taps (scan and approve the payment).
- Carbon supports both NFC tap and pay, as well as v10 QR Codes.
- Carbon supports eReceipts from BlockPay merchants.
- Carbon supports Loyalty Points from BlockPay merchants.
- Carbon supports Recurring and Scheduled Payments to one, or groups of Contacts.
- Carbon supports "PIN, Pattern, or Pocket" Security (draw patterns and yubikey neo (NFC/U2F)).
- Carbon supports Overdraft Protection (ie: allows you to "cash out" a backup asset to cover your grocery bill).
- Carbon supports automated encrypted backups to C-IPFS.
- Carbon uses C-IPFS as its App Store (no more Apple or Google "approval" needed).
- Carbon cannot be censored or blocked.
- Carbon is a true Dapp, completely decentralized App architecture with C-IPFS.
- Carbon supports coin shifting (bridges one coin into another).
- Carbon supports Key Dump (allows you to change out your private keys if your wallet is stolen).
- Carbon supports 44 languages.
- Carbon uses the Bitshares blockchain for fully-confirmed transactions in 3 seconds or less.
- Carbon allows you to easily share your coin addresses and Contact info via QR Code, SMS, Telegram, etc.
- Carbon supports Transaction searching, filtering and exporting to PDF and CSV formats (for your Accounting).
- Carbon is 100% free and will be open sourced on Github.
- Carbon can be white-labeled with your own logo, color themes, etc...
Some initial mockups we're working on:
(http://i.imgur.com/qbV4c5m.png)
The animation work began yesterday and will probably take a couple of weeks. Once that is complete, I will post a video of it here. Then, coding the new UI/UX will take a few weeks as well. While the Carbon UI/UX is being coded, the new UI/UX for BlockPay will begin. It will follow my agenda for a 1-Step Setup (not sure if we can achieve that with so many features in the software, but I'm sure gonna try).
Here are the high-resolution image mockups if you guys want to start marketing Carbon over the coming days and weeks.
https://drive.google.com/open?id=0B-LdNgnj_1qyUTNPNGI2b2lQcDQ
If anyone is wondering WHEN Carbon will be released, then just give them a link to this forum thread. As usual, I will post as much as I can, when I can.
-
I would *highly* recommend you play nice with **ALL** of your shareholders
because you will need their votes for a hard fork
... I can not approve a hard fork.
Seems I didn't make myself clear. Let me rephrase:
You should place nice with **ALL** shareholders - that statement was meant as an advice not to go against individual shareholders (like @Thom) by any means, because (presumably) he is a shareholder of BTS and has a vote.
because you will need their votes for a hard fork - this comment shouldn't need any explanation, it's a fact due to the governance model of BitShares.
... I can not approve a hard fork. - I can only ask for **not** partly citing me in the future - it reflects poorly on you. The full quote goes like this:
For me, I am fine with having SPECs and being able to verify that the code does what the SPECs say. So as long as those two are not provided, I can not approve a hard fork.
.. and I will stick to it and repeat it as often as needed.
@xeroc -threatening us with your Proxy-power because I do not "play nice" is not productive at all. We *greatly appreciate* the python that you write. You are not a Core Dev though. Fyi, the 20 other hardforks in the queue will need to be properly audited:
https://github.com/bitshares/bitshares-core/issues?q=is%3Aopen+is%3Aissue+label%3Ahardfork
Sorry if that came across as a threat that wasn't the intension. My intension are to merely to ensure that my followers get the best experience
and the most solid and secure platform that is available to them. That said, it is in our both's best interest to prepare proper documentation
of your hard forking proposal in time. This should also be important for your as a developer given that you appreciate valuable feedback.
You are not qualified to do deep-dive security audits.
Even though I doubt that you know much about my 'qualifications', I agree with you but also emphasise that I didn't claim to be ..
BTW, I am not the one that is writing a hard-forking proposal for BitShares but will do the best I can to guarantee that BitShares stays as safe as it is today - even if it means I need to hire someone that can do the review for me.
Advising people that their money is safe with the existing "confidential transactions" code, and, giving people security advice is probably not in your best interests.
Shall I rather advice them to use Stealth2 that isn't even specified publicly?
Speaking of security, since you did not finish the Trezor integration, I would be more than happy to acquire that project from you as well. As usual, a security audit will be done on it, so please advise to the locations of the work that you did so that we can get it completed.
The code I wrote is open source and can be found in my github repository. You are free to do with it as you feel fit.
-
Carbon sounds amazing.
"mint.com"-esc features that truly help people manage their personal finances
Anyone willing&able to work on Trezor support is excellent.
@xeroc your github? Is trezor support already available (sans-GUI)?
-
In the world of software, never give out dates (right Stan? ;)). I learned that lesson 30 years ago. Obviously though Thom, I took your comments very personal, so I sincerely apologize for my knee-jerk reaction. I am building things that have never been built before, so it's a bit tough to even hand out any timelines. I am well aware of what needs to be done, nobody has ever had to ask me for updates, and I do my best to detail our roadmap and progress right here on this lovely forum every week, so nothing more.
Apology accepted. I sincerely hope you realize I'm only trying to open discussion and understand where we are in this process. I am very glad to see the screenshots; you know what they say, a picture is worth a thousand words. They will help a lot for marketing.
Like I said tho, I'm not a marketer, let alone a professional one. My role at this point is simply to gather as much information as possible. Once enough info is known about how your "true and complete" stealth will work (at say a 1000 foot level) then some type of early marketing might be possible. You have provided the 100,000 foot view of how stealth will work, and the contrast of that view to the existing blinded transactions is quite dramatic.
Differences of perspective will always be present, so we all need to learn to work together without alienating one another. It serves none of us if we become divisive and locked into a "my way or the highway" mindset (not saying you're doing that ken).
Regarding the changes your making to the backend code. Those are what dictate whether a hardfork will be required, and IMO should be done very carefully. I agree with you ken, that the existing backend will require changes to implement a deep stealth that hides everything and also provides a backup mechanism for grandma's declining memory. If you can implement your true stealth without touching the existing blinded stealth code it will reduce the impact on testing and avoid issues with anyONE who might be using the old cli stealth code. I frankly don't see how you can avoid a hardfork to roll out your stealth, as it can't be accomplished in the UI / frontend codebase alone. How much of an impact your changes will have on existing operations is the key factor on how much testing will be required. You will also need to make changes (or at least additions) to the API so the UI can access the new stealth functionality.
Could the c-ipfs functionality for the backups be implemented in the frontend code only or will it require backend support as well? I ask b/c if the original wallet was completely stored in the browser I could imagine a direct interface between the UI code in the browser with IPFS, tho it would require porting the c-ipfs over to javascript.
As to when / if a spec will be required to facilitate a release that is up to the shareholders. None have been required in the past, so why should changes for stealth be any different? However, I tend to agree with xeroc's perspective that specs are very useful as a way to characterize functionality and as a tool to help insure test coverage is thorough. Writing a good spec is no guarantee of a successful product, and they do require time to do well.
IMO there are many aspects to the process of code development that could be improved greatly, both frontend AND backend. We will have to come to some type of consensus on what is and is not acceptable minimal standards for the future. I myself would like to see more specs, story boards and use cases as early in the development process as possible.
That is one thing the worker proposal system provides, a type of spec for work to be done. How loose or tight a proposal is and whether it meets minimal standards of acceptability are in the hands of the shareholders. I recall voicing my concerns about Bytemaster's stealth proposal not being adequate and turns out those concerns were valid. Since you have raised your own funds @kenCode the shareholder approval process is moved from the start to the end of the engineering phase, actually all the way to the final deployment phase. I would hate to see all your hard work go to waste due to a failure to convince shareholders of the soundness and reliability of your changes.
Anyway, looking forward to a view out the window that becomes clearer as we descend from 100,000 feet down to the ground. I have complete confidence in your abilities @kenCode to avoid the clouds and pilot this thing all the way down to the users on the ground.
-
Just a friendly reminder that we're all in the same team.
-
Just a friendly reminder that we're all in the same team.
+5%
-
Amazing job Ken +5%
-
Are there any BlockPay ambassadors in Japan? BlockPay would be perfect there. In fact, the Asia market looks more promising than the heavily regulated West.
https://www.cryptocoinsnews.com/bitcoin-accepted-260000-stores-japan/
-
@kenCode Any updates this week? I always look forward to reading this thread on Friday's!
-
@kenCode Any updates this week? I always look forward to reading this thread on Friday's!
I usually enjoy posting my updates every friday too, but this week I was forced to coordinate my post with a couple of community members first, waiting on their approval now, so I will try to post it here as well as soon as allowed, no worries.
-
@kenCode Any updates this week? I always look forward to reading this thread on Friday's!
I usually enjoy posting my updates every friday too, but this week I was forced to coordinate my post with a couple of community members first, waiting on their approval now, so I will try to post it here as well as soon as allowed, no worries.
I was wondering what happened to my clock :) I missed seeing the results of your work here too, so thx for the update ken!
-
@xeroc -threatening us with your Proxy-power because I do not "play nice" is not productive at all. We *greatly appreciate* the python that you write. You are not a Core Dev though. Fyi, the 20 other hardforks in the queue will need to be properly audited:
https://github.com/bitshares/bitshares-core/issues?q=is%3Aopen+is%3Aissue+label%3Ahardfork
Sorry if that came across as a threat that wasn't the intension.
No, of course not.
Anyway, I am hereby making some changes to how our tech updates are disseminated.
I won't be using this forum anymore. I met with the BitShares Munich Marketing team this past week and we unanimously agreed that I will step down from doing the updates, and they will publish my tech updates for me so that I can focus on R&D and product releases. Marketing will obviously play nice and keep everyone updated much better than I can. For example, here is one of Martin's recent updates:
https://steemit.com/life/@Martin-wichmann/cointelegraph-blockshow-europe-2017-in-munich
Since BitShares Munich (https://steemit.com/@bitshares-munich) now has an awesome marketing team, I will be giving all of my updates to them from today forward. They usually post on steemit and all of the social media channels. Rodrigo (at blockpay d0t ch) will take the lead and continue signing on hundreds of Clients. @Chris4210 will still handle company finances and host the weekly Bitshares mumble with Fuzzy. Sylvia, Angie, Maleny, Elia, Martin, Miguel and the others have taken over all of the business development with the 50+ BlockPay Ambassadors. See them on YT:
https://www.youtube.com/channel/UCJl3M4kuMaihU-yUQvnexkg/videos
BlockPay v1.5.10 is scheduled for release on Thursday. It has the new "directDEx" code now integrated with our graphenej library. directDEx has taken us about 3 weeks to build, but it makes it so that the QR Codes are much faster, less bandwidth is used, Transactions load in real-time now (and in proper order), the new database has been built so that users can backup their settings to the C-IPFS BlockPay 2.0 Core, many speed improvements and other fixes.
Smartcoins Wallet v1.5.14 will be launched in less than a week from now as well with many speed improvements and fixes. The animation work for the new UI/UX has also begun and should be done in less than 3 weeks. Dash InstantSend has also been finished and tested. Steem chain is now in progress. Once C-IPFS is integrated and all 6 chains play nice with one another, then we can release Carbon (Smartcoins Wallet 2.0).
Alfredo is helping out a lot now with the Stealth project, as well as his normal bitshares-core duties, especially with the Rust/C++ "trustless" setup algorithm and api. Chris will cover his work on the weekly Bitshares Mumbles with Fuzzy. Finishing that algo should only take a few months, then we will open up the public testnet so that everyone can help us security and bug test everything before the alpha launch.
So, since Marketing is taking over my updates, @xeroc would you like to remove my info from the forum please?
Amazing job Ken +5%
Thank you llildur, and to everyone who believes in me and the world changing products that we are releasing. Now I am more focused than ever :)
-ken
Follow/github: keybase d0t io / kencode
E: kencode at protonmail d0t ch
edit: Strikethrough the above, I think I'll stick around and watch what happens.
-
Well please dont leave the forums altogether!
-
For example, here is one of Martin's recent updates:
https://steemit.com/life/@Martin-wichmann/cointelegraph-blockshow-europe-2017-in-munich
Since BitShares Munich (https://steemit.com/@bitshares-munich)
So, since Marketing is taking over my updates, @xeroc would you like to remove my info from the forum please?
Links from above.
http://bit.ly/2oe1pEL
http://bit.ly/2oePaJS
Don't go away completely. :(
-
Do whatever you need to do to raise the value of blockpay. While having detailed updates here were nice, I'm skeptical that you or bitshares Munich received any actual benefit by doing them. They seemed like they took a long time to prepare, which is something the leader of r&d shouldn't have to do unless absolutely necessary.
-
Do whatever you need to do to raise the value of blockpay. While having detailed updates here were nice, I'm skeptical that you or bitshares Munich received any actual benefit by doing them. They seemed like they took a long time to prepare, which is something the leader of r&d shouldn't have to do unless absolutely necessary.
I will miss seeing you and the updates here @kenCode, but agree with the above comment.
I also appreciate you saying the stealth effort is months away, that lets us relax a bit and sets expectations accordingly. I have no doubts you are well aware of the need to capitalize on the public's desire for an easy to use stealth feature, plus you're well incentivized to complete it as early as possible so you yourself will see the efforts of all your hard work payoff.
I have complete confidence in you ken.
But please, don't be a total stranger!
-
I have complete confidence in you ken.
Do whatever you need to do to raise the value of blockpay. While having detailed updates here were nice, I'm skeptical that you or bitshares Munich received any actual benefit by doing them. They seemed like they took a long time to prepare, which is something the leader of r&d shouldn't have to do unless absolutely necessary.
Don't go away completely. :(
Well please dont leave the forums altogether!
aaaaaah, MUCH love you guys, thank youuuu!
Ok, so I've changed my mind.
I love the feedback that I get, and I love to show the world what I am inventing, building, releasing, and planning next.
I will be locking this thread and using my favorite social media site instead for my weekly updates:
https://steemit.com/@kenCode (shortened: https://steem.ly/46)
Please Follow me there, and hope to see ya soon! :)