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.
Show Posts
