Divi Beta Notes: Day One

So . . . . the race for riches is ON! Or, at least, for some modest divi prizes. Our first contestant alphabetically was also the first to set up their wallet and request funds, so they have won the first prize (we'll announce their name if we get their permission).

At this point, we have funded six beta testers and they have moved on to setting up their masternodes. Thus far, participants have been successful in performing the first three steps described here. Steps four and five still require more explanation and clarification, but the participants' level of success in them will indicate the effectiveness of our instructions. This is an important part of a structured beta: to figure out what we have not communicated and how best to do so. Currently, the beta testers are using the most primitive tools (divi-cli rather than a nice graphical wallet) so the details of what is going on aren't obscured and so that it is much easier to make mistakes. The more we learn from users' mistakes now, the simpler and easier we can make the process for subsequent users.

Masternode vs Funding wallets

One point which is evidently unclear is the difference between a masternode and a funding wallet. Both are comprised of exactly the same two pieces of software (the back-end divid blockchain client and the front-end divi-cli user interface to that back-end) and they run off exactly the same config, wallet, and blockchain files. They just run very differently based upon the settings in their two identically-named configuration files.

Some of the confusion is undoubtedly spawned by the fact that the masternode has a wallet that is entirely separate from the funding wallet. But the most critical point is that they can NOT co-exist on the same machine (unless you are running virtual machines). You could run them alternately by swapping the config and wallet files, but introduces another set of complexities.

As developers, we're just a bit too blasé about firing up another Docker virtual container or another machine in the cloud. But, realistically, hosting in the cloud is the best way to run a masternode. And Docker containers are a relatively easy way to run multiple wallets and masternodes on one physical machine. We will post Docker, Azure, Digital Ocean, and AWS instructions in the coming days. As a point of interest, the current mainnet backbone is just four Azure Docker instances.

Clearing up the confusion

The address referred to in step one is for the wallet that is specific to your masternode, which you get upon setting it up. If the address does not come from your masternode's wallet, all the necessary cryptographic signing is impossible because your masternode won't have the keys to that address.

NOTE: We would appreciate it if each of the beta participants could put their masternode identifying addresses in the spreadsheet pinned in the #beta-testers Discord channel.

When beta participants first requested funds, they should have done so from their funding wallets, not their masternodes. It is possible to do everything from one wallet, but then you are mixing "funding" funds and whatever operational funds the masternode processes require. It also leaves your funding funds on an exposed masternode -- never a good idea. Any beta participants who did conflate the two wallets just need to start up a second machine as their masternode and follow the instructions from the beginnng.

We will expand upon these concepts further and provide more details for steps four and five in tomorrow's blog post.