Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - kenCode

Pages: 1 ... 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 ... 153
136
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.

137
RE: BlockPay - Chris, Rodrigo and Sylvia at Thrive Int'l:
https://vimeo.com/196627019

138
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

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

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

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

142
+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.

143
General Discussion / Re: Bitshares price discussion
« on: December 08, 2016, 12:09:47 pm »
Much >3 @serejandmyself
 +5% +5% +5% +5% +5%

144
General Discussion / Re: Bitshares price discussion
« on: December 08, 2016, 06:43:06 am »

Bitshares has the tools, but in needs:

a) to become friendlier to users
b) market itself
c) people to stop hoarding tons and use it

a) Bitshares people are the friendliest crypto-community I have experienced.
b) Setup a Meetup group in your local town. Use local coffee shops, libraries etc for your monthly meetings. Look at http://meetup.com/bithares-munich as an example. You can have co-organizers too so your friends can help create meetings so the burden is not totally on you. Tell them about OpenLedger, BlockPay, Stealth, C-IPFS support in graphene (the one chain that is actually scalable), our mobile apps, Echo and all the privacy tools we are releasing, our prediction market, decentralized governance and voting system, 3-second transactions, the list goes on and on.
c) "use it" can come with BlockPay, and trading with friends using the mobile wallet at local Meetups :)

145
General Discussion / Re: Bitshares price discussion
« on: December 06, 2016, 08:07:24 am »
they all love the idea however have issues getting money in/out of the system. 

Bingo!
I see this as one of the biggest issues that Bitshares has right now. On and off ramps to and from fiat currencies. "Gateways".
 
I want to help the project, but I have no technical abilities at the moment.

You don't need any "technical abilities" to contact exchanges CONSTANTLY and talk about the reasons why they should at least support the core BTS and top 3 smartcoins.
 
A.B.C.
Tell them about OpenLedger, BlockPay, Stealth, C-IPFS support in graphene (the one chain that is actually scalable), our mobile apps, Echo and all the privacy tools we are releasing, our prediction market, decentralized governance and voting system, 3-second transactions, the list goes on and on. Email them, call them, skype them... Again and again and again and again. If even 10% of the people in this community would do that we would see gateways galore imo. Get a YES out of them. Motion creates emotion! The squeeky wheel gets the grease, so BE RELENTLESS.
 
There is no such thing as a "no sale" call.
https://www.youtube.com/watch?v=1X3p42GaM5I

146

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

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

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

149
I do think a UIA fits more in Gridcoin's situation, perhaps with a special owner/committee like the STEALTH asset (check https://cryptofresh.com/u/stealth-mgmt , the owner is a multi-sig account, automatically controlled by top 5 holders)
I was hoping that we can have a hard fork to make this particular sub-feature of STEALTH be used for any asset .. that would be super super cool!!!

yes, i chose to hide the name of the asset too. i assume that's what u mean.
a bitshares stealth transaction = "unknown" sent n "unknown" to "unknown".
first mentioned here: https://twitter.com/kenCode_de/status/796350090856267776

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

Pages: 1 ... 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 ... 153