Dash Network Bandwidth Usage (Re: Java SPV Implimentation)

[HashEngineering]

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.

 

[AndyDark]

HashEngineering I don't think there's a way around this in the current architecture without adding e.g. a gateway that can do the IX checks and callback to connected wallets but that's a lot of work and centralized anyway. In Evolution the masternodes send client callbacks for events like IX transactions which will solve this.

 

[nmarley]

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.

I thought that InstantX code already did #3 here: https://github.com/dashpay/dash/blob/master/src/instantx.cpp#L316-L320

... by preventing masternodes from creating MX locks. I guess a rogue MN could add locks?

 

[HashEngineering]

I thought that InstantX code already did #3 here: https://github.com/dashpay/dash/blob/master/src/instantx.cpp#L316-L320

... by preventing masternodes from creating MX locks. I guess a rogue MN could add locks?

You are correct that Dash Core (C++) already does #3. However, I am working on a Java Implementation of Dash Core that until recently didn't do any of #1 to #4. To make the Java version as secure as the C++ version, I would need to implement the same security checks.

 

[nmarley]

Oh, ok, I misunderstood what you were doing.

I thought you were trying to read/verify the MN locks from the MN network, in which case, the network itself already verified that before creating a lock.

 

[HashEngineering]

Actually, I am trying to read and verify the MN locks from the MN Network, but every node does this as it should in a trustless system. A masternode will send out a Lock in the DoConsensusVote function if it is in the top 10 masternodes according to the rankings that are calculated.

The other nodes will then receive the Lock messages and they will verify that it is in the top 10 masternodes according to the rankings, and verify the masternode signature.

Currently, my code doesn't correctly calculate ranks, so I have skip that check for the time being, but I can verify the other necessary parameters. I hope to fix this bug, but need to develop some unit testing, which is difficult.