I had to quit the apps about two times. Maybe I was just impatient.
First of three wallets synched now. Testing commences
My observations:
As I said, I have three devices.
Iāve send one transactions with three outputs to each of the devices.
The app was open and running on all of them, all apps were synced. The devices did not go to sleep mode, I kept the displays active.
The first device recognized the transaction after one minute, the other two needed five and five and a half.
My feeling is, that the app does not keep up with the relatively low block timing.
Have the CPU peaking now on the blockexplorer. So running at capacity if you all trying at once. Will continue to monitor this and assess whether I need to add CPU power. Thanks for the feedback.
Edit: this was a peak for a few minutes. Possibly memory/CPU constraints, but need to dive into this. If it is just three devices syncing then we might have to upscale a bit. Will keep an eye on the logs, please donāt constrain any further testing.
Furthermore, Iāve tried sending and receiving with and without trusted peers. Without trusted peers was a bit faster.
No crashes on any of my droids (Sony Xperia Z1 Compact - 4.4.4, Acer Iconia A1 (rev. 1) - 4.4.2, Moto G (rev. 1) - 4.4.4)
Seems fantastic so far. Performance needs adjustment, but you guys seem to be on it
Still trying to figure out whether the slow syncing at times is App related (low intervals or sleeps) or server related or worse a combination of them. Will share my thoughts with Matthew and see what we can improve.
Thanks for sharing the test results. Your results confirm my own results that it is good to have your own nearby trusted peer uniquely configured. I did also notice that it drops connections after a while which makes sense otherwise you would have a resource hog and a lot of battery drain on your mobile. However this makes it a bit slow when you wake it up and it needs to find nodes before updating the blockchain. I suppose it is similar when you start-up your PC wallet.
Maybe something for the wish-list to be able to temporarily force to keep the connection(s) to 1 or more peers in order to speed up expected incoming transfers and payments.
Looking at the statistics on the server, it can easily cope with the load. It looks it only got stressed when 3 or more devices at the same time are making payments or synchronising as you tried yesterday. The Nu daemon also takes a bit of resource (up to 32% CPU and 33% memory) when a new block comes through. When all these events coincide it might temporarily slow down and disk swap a bit, but this is clearly not the main constraint.
On a different note, I also started to write down some use case and required functionality for shapeshift support in the Android client.
Here is one of the scenarios as a teaser. Will share more and hope on feedback later.
Use case Success Bitcoin:
Alice want to pay merchant Bob. Bob only accepts Bitcoin. Alice scans the Bitcoin QR code and the App translates the address and the BTC amount into the designated fields. Her App queries the latest Shapeshift rate and maximum allowed coins. Based on the rate the number of NBT required is presented to Alice. Alice approves the amount and the rate and sends the coins. The App shapeshifts the NBT into BTC and sends the coins to the designated BTC address.
(Note, need to have the fiat value (e.g. USD), the BTC value (second row?) and the NBT value in the āSendā screen)
Optional: Alice has completed the field email address in Settings. When that is true the App sends Alice a confirmation of the payment (using Shapeshift API for sending email).
Once the Android app gets used frequently and not just for testing it will occur that lots of devices are making payments or are synchronizing. I think this needs to be prepared for.
Iāve made some tests with the app as well. Here are the tests and the results:
Installation and synchronization went smoothly and in very little time
Receiving and sending NBT: check
Creating a new receiving address: check
Creating a password protected backup: check
Assistant for sending the backup via email (filling in useful information in the body of the email): check
I need to test it a little bit more (e.g. restoring a backup), but Iām impressed how well this app works and how easy it is to use it!
I appreciate that connections are dropped after some time, because the impact on the battery would be horrible. Thatās for sure not what a user expects: to have an app that drains the batteryā¦
And even if you have several hours to sync and donāt have WiFi available, itās only a matter of very little time until there are peers connected and the sync is complete.
The only thing I didnāt find out: can the number of confirmations for a transaction be retrieved in any way? I understand that a transaction is considered complete once the circle is fully green, but thereās no way to show it like x/y confirmations, right?
That will be a very big step for the near future use of this app!
It will take some time until NBT is widely accepted.
With an app that is able to make use of the great shapeshift.io service every point of sale that accepts any of the cryptos shapeshift.io has in its portfolio can be used with the Nubits app.
Awesome!
Awesome and thanks for the testing. Restoring works fine for me, you only need to sync the whole blockchain again but that takes about 15-20 minutes on a good connection. Suggest you restore only when on wifi or if you have 3g or 4g with a high or no cap. Keen to hear how it went for you.
The confirmation question you asked triggered me into finding an issue. When you click on the transaction and choose setting (upper right corner in brown bar) you have an option to directly browse to the blockexplorer. Unfortunately the link is broken. Will log this one with Matthew. When it works you should be able to check the number of confirmations relatively easy looking at the blockexplorer website. It is a bit of a workaround, but how often would you check the number of confirmations? With NuBits you have a number of confirmations in minutes anyway.
Edit: the blockexplorer doesnāt mention number of confirmations in the tx window. Will add that to the wishlist.
BTW Matthew will look into pulling the code to protect the wallet with a password. This might take a while though. In the mean time just keep a balance you can afford to loose or protect your device with a passcode.
Not very often. In fact Iād be willing to accept 0-confirmation transactions and bet most of the recipients do the same (not for the amount that will be paid typically with an app on a mobile phone; I mean, Iām not going to buy a car with NBT from my phone - at least not soon ).
Thatās what made me look how many confirmations are required to have a full green circle. Iād be happy to configure it to 1 of 1 for a full circle
This would be a nice optional feature - especially if you plan to have bigger amounts in your wallet.
I recommend the former because a password protection of the device doesnāt protect the flash memory unless you have a fully encrypted file system.
I donāt know what @Cybnate meant and I donāt know how many Android devices are encrypted (although that feature is available for some time now - at least since Gingerbread 2.3.4 - with some constraints), but I doubt that a majority or even a big share of phones and tablets is encrypted.
Encrypted file systems are much less convenient for trouble shooting, they should drain the battery faster and I expect the devices to be (at least a little bit) slowed down by the encryption.
And convenience is still a major factor for making decisions (although I think itās often based on the wrong decision making algorithms) - or why do you think encrypted emails never went mainstream?
E-mail encryption usually requires both ends to have the encryption key. Constant exchange of keys between you and your recipient is necessary.
An encrypted android file system only requires you to enter the key at booting. Thatās basically exactly the amount of times you need to enter your SIM code.
Itās easy. People protect SIM cards with codes. While not file systems? NuBits private keys might be worth protecting.
Iāve encrypted all of my devices and did not experience a feeling, as if something would slow down my system. I know, that this can be very subjective thoughā¦
Using PKI for key exchange itās not that big a deal.
I see another reason: itās less convenient, because it requires extra steps.
The same is true for encrypted file systems.
There are a lot of things that are worth being protected.
Ever thought why lots of people use google services, facebook, etc.? These services are convenient. And as you donāt have to pay anything you need to be aware that you and your private data are the product the business cases are built around.
While one could argue that privacy is worth being protected, itās convenient to use these services.
Thatās one of the reasons why I see huge success for NuBits coming. Using NuBits is convenient (and luckily for the users with no drawbacks or risks except for sudden system failure ).
Nevertheless we shouldnāt get detracted from the reasons for that success.
Before it completely drifts off-topic:
the Android wallet still works like a charm. I already love it!
Itās nice to show people NuBits on the phone
Lol, that sounds a little bit like āNew kids on the blockā - for those who can (and want to) remember.
ā¦some want to have NuBits once theyāve seen what they areā¦
The Andoid app is great for marketing - whatās at the current stage more important and more useful than the real-world use of NBT on the phone. I hope that will change soon!
Have to admit that it was what I thought not knowing about the lack of default device/file based encryption.
So pin-protection alone is not very helpful, at best only against your 10 year old cousin.
It is hard to find a dev willing and available and from what Iām hearing it would be at least 2x to 3x times more expensive to build than this Android wallet. Dogecoin is the only one besides Bitcoin to have one (soon). Given the marketshare of iOS and the current NBT usage Iām not sure if there is value in doing so in the short term. Maybe we can run a motion like a poll to test the waters and see how many people would be interested and whether the Shareholders are prepared to pay that premium in the short term?
Matthew just fixed this issue (see above). Just clear the browser cache and it works as advertised
Iāve also uploaded a new APK Matthew provided me which links direct into https instead of using the automatic redirect. A bit more secure.
Please make sure you have a backup of your wallet when you have coins in there before you install the new APK! Iāve added the link here: Proposal to develop a NuBits Android wallet - Final version now available
One thing to note that some people may have concern over is that the block download should stall about every 49,999 blocks, as the app needs to download valid block hashes from the server. This shouldnāt take long but it is a noticeable stall.
Using the āexperimentalā BIP70 feature, payments can be made over bluetooth and this is virtually instant. This works with both QR and NFC payments. The BIP70 feature would be enabled by default if I updated the app to the latest code. However the latest code is not ready yet. As things exist currently, you need connected peers to receive transactions and transactions can take a while to be received.
Would someone be able to confirm the working of this interesting hidden feature? I only have one Android device.
You would be able to transfer value with peers even when internet is blocked or unavailable. This is a great feature to have in countries hostile to cryptocurrencies or where the internet is patchy or blocked by the government. Not sure how best to market this as they are very different markets. It probably needs to go together with NFC pre-paid cards with a dollar value which can easily be added to the wallet? But Iām going a bit off-topicā¦
Edit: a useful link to read more about BIP70. It refers to bitcoinj, but we basically have a nubitsj implementation so just replace Bitcoin with NuBits. https://bitcoinj.github.io/payment-protocol
).