Our priority at Armory is security. We do understand the need for better user experience but not at the cost of our utmost priority. If you reread my post you'll see we have a long term solution, but it will come in due time, because other features have to get there first to allow this solution to implemented. It isn't stand alone solution that we could implement over night or we would have done so obviously.

You're talking about using paper wallets, but they too are inconvenient, until the point when BIP32 is widely implemented. There are also a lot more clients out there that choose user experience over security. We have a role to fulfill before we can get the user experience up to acceptable levels. By far Armory is not considered the easiest nor the most welcoming wallet, but some people think this is an acceptable trade off for the added features, and here we are today. What you are trully experiencing is a software niche that hasn't just matured yet.

Obviously we would like to get rid of all these quirks. As a matter of fact my work for the past 4 months has been towards implementing long term scalability and stability fixes. The problem you describe cannot be dubbed as a "leveldb" error. This is a symptom of your local copy of the blockchain. Simply put, while the you appear to be running a full node, you actually aren't, as you are missing block data.

Let's put aside the consequence that has on the network, and focus on Armory. Armory requires a full node to function. Implementing a long term solution to this issue would require a shift in paradigm. That can't be addressed lightly nor quickly.

Also consider that most of the codebase is still etotheipi's work: about 100k lines of code over 2 years. He had to make some choices to ensure Armory functions overall. You can't just spend 6 month to fix scanning issues that can be effectively decentralized. Consider that the earlier versions of Armory didn't even have a DB: you had to fully scan the blockchain at every load. Now that 5 developers work full time on Armory, we have the resources and talent required to implement long lasting solutions to all the bugs and quirks, while adding new features.



You can copy the signed Tx and broadcast it with another service, sure.

No, we're actually quite a bit away. It's not the daily dividend that needs to be below .2mBTC, but the Reserve that needs to be less than .2mBTC (Reserve = 200 Days of Dividends).

The last published Reserve is 0.04809800 BTC. Since the dividends are made off-blockchain, there's no fee to pay them, but they are getting smaller.

In hindsight, I probably would have chosen a higher Final Reserve / Minimum Reserve, as this Round is currently scheduled to last well into next year. Functionally, everything would operate exactly as-is even if the last published Reserve was ten times less than it is now, but, so far it seems that exchange volume tends to wane with a decreasing NAV/U / Reserve / Daily Div.

DMS, the model upon which BDD is based, had no minimum - holders of SELL had to vote if/when to close the fund. I do think that it was a good idea to build-in a Minimum Reserve, but a .2mBTC Reserve means a daily dividend of 100 satoshi, which the market may tire of.

25,000+ btc will be mined assuming either entire global hashrate remains static, which obviously it won't OR the 2% figure (representing PETA's portion of entire hashrate) used in that calculation will grow proportionally to the rate of growth the rest of the market. This is the reason for 65% rather than 100% towards dividends, which would be a losing proposition over time.

For example the mine initially started with 1G per share. Hardware was sold to expand the farm and instead of quickly paying off investors a lump sum from that sale, a decision was made to withhold those dividends to increase the capacity, therefore GH/s each share is entitled to a higher amount. at 80k shares with current deployment that increased 600%, combatting the difficulty increases.

You can see from dividend history the upwards trend.


Here we come to the second situation where a temporary sacrifice is made to ensure the long-term success of the mine.

My post further up covered this a bit. The chart you are looking at has a category named Dividends to be paid after IPO or something along those lines. What that number is is the total amount of dividends CryptX will not payout to shareholders and instead use them to pay back the company he bought the hashing power from. It also doesn't show what happens if 0 shares are sold and that is 1957 BTC worth of dividends to be withheld.  So when will the dividends start being paid back to investors? After CryptX pays off all his debts is the answer. We can do a quick estimation that is extremely optimistic at the time frame of when you will start to see a single Satoshi paid out to investors right now.

200 BTC was mined last week so tripple hash rate means triple the coins to 600 BTC expected to be mined. 25% is still gone to hosting fees so that leaves 450 BTC left to be paid out as dividends and reinvestment. But what CryptX did was force all shareholders to give up dividends to pay back the company so it's now 100% reinvestment.

Best case scenario and what you should all hope happens: All 33k shares are sold in this IPO and dividends start to be paid out next month.

Worst case scenario no IPO shares are sold and shareholders are stuck with the bill and must pay 1957 BTC. 1957 / 450 = 4.34 and that number is the amount of weeks until the hardware is paid off from shareholders. It will take just over 4 weeks, but remember this is an optimistic calculation as it doesn't take into account the difficulty increase that will happen. That is 4-5 weeks AFTER IPO ends for a total of 6-7 weeks.

If 1 batch of 10,000 is sold only 1007 BTC need to be repaid and that will end up taking 1007/450 = 2.23 weeks of no dividend payments to pay back the company. But again overly optimistic because it doesn't take into account difficulty rise so in this case it will take 4-5 weeks total to start seeing dividend payments again.

You can see that if all the shares are not sold how bad this will be for shareholders and how outraged you should be about CryptX forcing the bill onto holders via holding dividend payments. But he still gets his 25% hosting fee for his pocket. Start asking questions as to why shareholders have to foot the bill and not just use the 35% reinvestment like how the prospectus says. Ask why there was no shareholder vote on the change in direction of the mine when the prospectus says shareholders have voting rights and a few paragraphs away says that shareholders should vote if they want the dividend/reinvestment %'s changed. I am no longer a shareholder because if I still held any shares in this mine I wouldn't see a penny in dividends until at least a month - month and a half out from now. Shareholders have voting rights, it explicitly says it in the prospectus so use your voting rights to keep the mine how it was and only allow CryptX to use 35% reinvestment to pay back the company, not your dividends.

Unless I'm mistaken those 'three' addresses would be your change addresses - you should be able to find them under the 'Receive' tab and click on the small white triangle next to 'Change'.