Impressive as always kencode!
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:
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.
Show Posts
Same thing goes for the balances and metadata. We're also doing our own coin tumbling and extra layer of coin/address mixing and if all goes as planned, we should be able to keep almost all of it on-chain. 
