HashEngineering
Well-known member
As some know work is proceeding with some success to add more InstantX support to the Dash Wallet for Android.
In short this requires:
1. Receiving IX Requests and Consensus Votes from the top 10 masternodes (based on the rules)
2. Receiving 6 of the 10 Consensus Votes and Locking the IX Transaction, then the app can report the IX Transaction as locked, but we should do more verification.
3. Verifying that the Consensus Votes came from existing masternodes.
4. Verifying that the Consensus Votes came from to the top 10 masternodes (based on the rules).
It is possible to do all most of this with my Java implementation of Dash Core. Currently #4 is not always possible and my code currently has bugs on calculating maternode ranks.
The point that I want to raise here is Bandwidth Usage. If the Dash Wallet uses lots of bandwidth to have the InstantX feature, many will complain, possibly finding the feature useless because they cannot afford to use it. some will complain because they didn't read or understand the warnings about bandwidth usage.
To achieve #3 in the list above, the app must sync with the network to get the Masternode List. My app can do this and after this it continues to get Masternode Pings and Broadcasts as masternodes send out information to the network.
I added a counter to the message receiving part of the Java version of Dash Core. Here is what was found:
For 16 hour period, it received 64 MB of information, which is 90MB per day (2.7GB per month). This can be compared with Dash Core (C++ Client), which for 8 hours received about 160 MB, which is 480 MB per day. The java version uses less bandwidth because it does not pay attention to Masternode Winners or Budgets.
Will an average phone user like to use 90MB to receive InstantX messages? Even if the use of InstantX will be limited to store owners who have unlimited bandwidth, it would be good to lower the bandwidth usage.
Anyone have any ideas on this? The app referred to here is still underdevelopment and will be released for testing when it is deemed ready by the development team.
In short this requires:
1. Receiving IX Requests and Consensus Votes from the top 10 masternodes (based on the rules)
2. Receiving 6 of the 10 Consensus Votes and Locking the IX Transaction, then the app can report the IX Transaction as locked, but we should do more verification.
3. Verifying that the Consensus Votes came from existing masternodes.
4. Verifying that the Consensus Votes came from to the top 10 masternodes (based on the rules).
It is possible to do all most of this with my Java implementation of Dash Core. Currently #4 is not always possible and my code currently has bugs on calculating maternode ranks.
The point that I want to raise here is Bandwidth Usage. If the Dash Wallet uses lots of bandwidth to have the InstantX feature, many will complain, possibly finding the feature useless because they cannot afford to use it. some will complain because they didn't read or understand the warnings about bandwidth usage.
To achieve #3 in the list above, the app must sync with the network to get the Masternode List. My app can do this and after this it continues to get Masternode Pings and Broadcasts as masternodes send out information to the network.
I added a counter to the message receiving part of the Java version of Dash Core. Here is what was found:
For 16 hour period, it received 64 MB of information, which is 90MB per day (2.7GB per month). This can be compared with Dash Core (C++ Client), which for 8 hours received about 160 MB, which is 480 MB per day. The java version uses less bandwidth because it does not pay attention to Masternode Winners or Budgets.
Will an average phone user like to use 90MB to receive InstantX messages? Even if the use of InstantX will be limited to store owners who have unlimited bandwidth, it would be good to lower the bandwidth usage.
Anyone have any ideas on this? The app referred to here is still underdevelopment and will be released for testing when it is deemed ready by the development team.