One more idea! We could use platform for charity.

me too. i heard about guy who lost 7500 btc - incredible

About keys safety... I store my keys on paper and made several copies which are distributed to the closest friends but I don’t know whether my friends still have them

Great feedback! Which background has mr. Machihin?

so just copy the .dat file in the ETHD Wallet AppData folder? I created my backup on MacOS and want to restore it on Windows

Maybe not the right thread to ask this question, but is here support available? I want to know, how I can restore my ETHD Wallet from backup?

Huh..
The name is a vey important thing. Did you see the movie the Founder ? He says something really important about McDonald, the thing he wanted the most was the name of the McDonald Brothers company, because it was the perfect name for such a company. Name plays a bigger role than you imagine.

Every ICO calls "new uber"

Thanks gents. Thank you all for trusting me with your DRK. I may revisit this in the future if I'm convinced that I won't see weird issues if I were to jump back in. I still feel awful that I can't seem to get the funds back from Node 1 and 3. Perhaps if only one node was fatally problematic I'd tough it out and hope they become profitable and that code and network would improve over time, but to have two nodes go down permanently for different reasons was too much and the results have been weighing heavily on my mind although I can't think of anything I couldn't have done differently at the time, since the setup processes for RC2 and RC3 nodes are the same steps we all have to take to set them up. C'est la vie.

It's been an interesting experiment/project and I wish I hadn't seen these problems. I would've been willing to operate them at a loss for months if necessary but all the troubleshooting, rebuilds, and transferring of funds to other local wallets I had to do to get just a handful of nodes back up and running over and over again were a PITA that a user shouldn't have to go through just to get a node working again. Anyway, enough of that. Just a bit of post mortem analysis and another major contributing factor to end this community service.

Tips are appreciated: XcbPGJKXPq4UMNrCBzza7kWEWeDjLSsTdq

Cheers.

Sorry it didn't work out. I may revisit this service in the future but for now your DRK was sent back via Tx ID a71949c665945339f1f01a40c1f459d9b7434a9250379167e19268d4033e86b0 to the address above.

Cheers.

Thanks for the feedback guys. The loss of access/control on 8/1 of two nodes at Amazon doesn't appear to be MN software related at first glance.

These were all Amazon Linux remote servers with Windows local wallets. All nodes had cold wallets except Node 1 with an RC2 hot wallet that we never got our funds returned back after server shutdown/rebuild prior to RC3's release. Setups were basic except that I added additional node connections besides the default IP address to try to improve node stability. Besides the fact that they were unprofitable at 10% management fees with inconsistent payouts, I just can't go on with 2 completely failed nodes with irretrievable stake funds and having to worry that I could see another database error or yet some other weird crap that causes additional loss of control of stake funds.

These nodes *should* be able to just run weeks or even months without issue (barring updates) like a good server should, but I just haven't seen it and I had 4 different nodes running at one point to give me my own "field data" to draw my own conclusions. Even if everything was running perfect, with current exchange rates the nodes would have to average something like 0.8 to 1 DRK a day for it to not run at operating losses at 10% management fees. I only saw an average like this over the course of 6 days and that was only for 1 of the 4 nodes.

==

Final payouts have been sent and refunds were sent for Nodes 2 and 4.

Since not everyone has a BTC account to share this, here's the spreadsheets on Node 2: http://xle3harsc3jjowqx.onion/omqmyb5w5k6nfaefol32yisvke

and Node 4: http://3edyzzs7i4sj6rxu.onion/4hou5odynz7ioh4tnavss2u6ai

You'll need to have the Tor Browser running to view it.

It's late I'll finish up tomorrow. Approx. 2650 DRK refunded so far during this project. To do: refunding Node 5 tomorrow (thanks for the DRK address CripLib), and catching up on a ton of PMs.

I'd try to work it out but man its taking up too much time even just for 2 simple servers on Amazon.

Its so hit and miss too. For instance: Node 2 didn't have any mining payouts from 7/15 to 7/20 having gone down on 7/19. Couldn't revive the node no matter what I tried so I had to transfer the stake & rebuild the node on another local wallet/PC and another remote server on the 20th. It was up without incident but then nothing happened from the 20th to 27th. However from the 27th to the 1st  it did about 6.9 DRK over 6 days which is great if it was consistent; then it'd actually be profitable and worth the amount of troubleshooting effort involved. As far as luck: they seem to be streaky. It was on a hot streak but as of last night I can't seem to remotely log into the server itself for some reason.

Node 4 also saw that same inconsistency. This was actually the most stable node of the four I had set up, but that didn't help its profitability much IMO. It "only" needed one re-activation during 2 weeks and only proved problematic last night on 8/1 when I couldn't log in to the remote server itself. There were 2 payouts on the 19th, then nothing till the 25th six days later, then nothing again until the 1st last night, meaning there were only 4 payouts for a node that was relatively stable in that it only had to be dealt with twice (the second time "fatally", unfortunately) from the 16th to the 1st.

At the moment my best bet would be to do another 2 server rebuilds since as of last night I can't get into either instance even after rebooting them. Regardless of the alleged safer cold wallet method introduced by RC3, I'm tired of fighting these things at a loss and at risk with everyone's funds.

I work in labs and field tests of mostly low Tech Readiness Level products and prototypes that are usually between TRL levels 2-7. For a consumer products example: a new refrigerator model would likely be TRL 9-10. I'm comfortable working with and troubleshooting or assisting with troubleshooting various types of early beta software and hardware. Some would see it as a bad sign that an ubernerd like myself that makes a living in R&D no longer wants to lose money managing beta masternodes.

Nodes 2 and 4 should be seeing payouts in a few hours. The refunds should arrive in the evening after I get back from the beach.

Final tally:

Node 1: RC2 Hot wallet method; stake funds never sent back from mempool when server shut down/rebuilt prior to RC3. Owned 45% stake in this node and no idea who has control of the address the getaccountaddress 0 command yielded on the local wallet with RC2. Asked for help but ignored by Evan.
Node 2: RC3 (as are Nodes 3/4). Refunding. Luckiest of the nodes but still a net loss to operate even with low cloud hosting fees. 7 rebuilds in July, about 10 rebuilds total. Ended w/ inaccessible remote server which doesn't appear to be MN software related but can't be rules out either.
Node 3: Was operational from about 6/25 to 7/2. Database error appeared on 7/2. Phantom self-payment upon rebuild to inaccessible self-address not listed in receiving addresses. Shows up as grayed out address in parentheses but balance of payments equal 1000DRK instead of 0DRK. Copies of orig. wallet file and database/blockchain weren't helpful as soon as it syncs to 7/2, the phantom self-payment appears rendering the stake as unreachable. No idea where this DRK is or if its recoverable. Community help (including offers to pay for help) didn't yield a fix for something that could happen to anyone that sees a database error.
Node 4: Refunding. Most stable of nodes, needed 2 rebuilds in July and 1 re-activation. Had highest uptime of nodes set up but earned less than node 2 in latter half of July.
Node 5: Refunding, was half full and could've been filled easily with community support but declined to host with problems shown and costs of running nodes taken into consideration.

Full Node setups AND management: Canceled.

Full Node Setups ONLY: Available shortly. After refunds are complete, will shift to only doing cold wallet setups for 1 or 2 full node setups (since multiple wallet setups are still somewhat complicated) where I don't have to touch stake funds. More importantly: I won't have to be responsible for stake funds. Except for one large order: Management will have to be self-management or management by a 3rd party. Client will need to set up a host service and allow me temp. admin access. Setups should take less than an hour providing the hosting service is set up and 1000DRK is ready.

MN Repair services: Considering this for a worthwhile fee but would rather just set up nodes and turn over admin access going forward.

All 4 nodes operated at a net loss from 6/25 to 8/2, with 2 of 4 nodes stake funds currently (and possibly permanently) inaccessible without some sort of developer (or divine) intervention. I wasn't trying to get instantly rich from offering this service but I can't operate at a net loss with what appears to be a coin that has twice showed me whimsical and capricious loss control of hard earned stake funds from external/internal factors at a 50% rate, and requires excessive babysitting for the nodes that do work without major issues.

Guys, the nodes are down again but doesn't seem to be related to masternode software; seems to be cloud provider related this time (the first time a node issue was cloud provider related from what I can tell). The bad news is they need to be rebuilt (yet again) which is what I was attempting again this evening. Sigh. They're cloned servers but there's still things you need to customize or set up from server to server.

Wish I had some good news to report on Node 3's database error. Was giving it another go but it seems to be out of my hands that when the wallet updates to July 2, it executes the phantom self-payment to an inaccessible self-address the same day the database error showed up. System restore points and having access to the orig. wallet file (and a copy of the corrupted database) are useless to address this database error. I can add an address label but there doesn't seem to be a way to manually add a receiving address (the receiving address is grayed out on the local wallet using the latest wallet client) else this would be a simple fix.

Re: Community and Full Nodes: Had to do some soul searching about this and made a difficult decision. I've talked this over with my wife; these nodes are just too finicky, and unstable right now IMO. Having to do constant server rebuilds and trying to troubleshoot Nodes 1 & 3 during a short vacation attempt wasn't fun either.

The nodes that were running operated at a net loss since payouts are so hit and miss and stability was a major issue. For over a decade I've worked with dozens of remote and local servers of various types and applications; remote servers running a non-taxing single simple task aren't supposed to need this much babysitting. For a remote server - except for patches and updates - You should be able to "set it and forget it" for the most part. I admin many remote servers that need attention a few times a year, if at all.

The excessive troubleshooting of this RC3 beta software and nodes might be worth the trouble if they paid out more often but to run these nodes with the services currently set up they would have to average more DRK a day for this to not be a net loss.

==

I'll be shutting down this community node service tomorrow on 8/2. Even with 2 nodes "running" they weren't profitable with current payouts and node instability. Perhaps they'd be more profitable if they weren't so unstable (IMO).

I may look at opening up this up again if nodes seem to be more stable after RC4 or RC5 but I feel that I may have gotten involved with this too early. There doesn't seem to be a good mechanism to get help if something weird goes on with node transactions: such as Node 1's RC2 hot wallet never being returned from mempool (where Evan ignored my polite request to take a look) or a database error on Node 3's local Cold wallet introducing a phantom self-payment to a self-address that doesn't appear accessible.

For myself: I'm out 450 DRK from Node 1's hot wallet payment never being returned from mempool when the orig. first server was shut down for a rebuild, and the node service/management fees have been a net loss so far, so I've lost funds on that end as well. In perfect hindsight, if I could pick a better time to be involved, I would've gotten involved either after RC5 or during Version 1.0 (whenever that is) and I would've spread that 450 DRK out to 4 nodes with 100 DRK in each node, to have spread "risk" to 4 nodes instead of 1.

==

Thank you for being part of this experiment/project. I didn't want to shut this down because I was the first to offer these setup services. I wish I could report this as being more successful but for now I deem this as too high risk even for someone with my high risk tolerance and willingness to operate and troubleshoot beta software/servers. Even though its beta software, I've spent way too much time troubleshooting what are supposed to be simple, single use application servers.

In the morning: I'll finish the payouts I didn't get to because I was trying to get the nodes back up this evening without having to build new servers or having to do another round of self-payments for cold wallets (because these self-payments sometimes"go bad").

In the afternoon/evening after those payouts: I'll be refunding Nodes 2, 4, 5 without any refund penalties. Please provide a payout address for this refund if I don't have one on record for you.


I am halting the setup AND management of full nodes as well. I'll still be willing to set them up but besides one large previous agreement which I plan to co-admin with another administrator, I'm now unwilling to manage a bunch of nodes if they're going to be this much trouble. Except for a large order I'll be able to focus on: the only nodes I plan to set up going forward would be 1 or 2 full nodes where I don't touch funds...and they'll need to find someone else to manage them (which I could point out to a couple of capable and experienced admins I met on DRKcoin talk).

Still working it. Have some promising things to try. One of the DRK talk forum admins has seen this database error problem before but it was on a Linux PC and his fix may not be directly applicable to our error.

As for Node 2 which was down: Couldn't get it working no matter what I tried so I transferred the 1000DRK to a different local wallet and started from scratch on a different server. It was up during the weekend then it went down again yesterday. At least I only had to restart it this time instead of having to do July rebuild #7 for this node.

Node 2 has a new IP address since I had to house it on a new server. I'll just list it here so I don't have to re-share the Node 2's spreadsheet: 54.186.252.193

Node 4 has been steady (knock on wood) and has been up since the 7th without incident. All of these nodes are configured the same; just seems to be random chance whether a node is stable or if it needs constant rebuilds or re activations.

Weird. The PC that hosts those files is up 24/7 except for patch reboot because it does Scrypt and x11 mining, so those files should always be available from this end.

Then again, it's the first public release of Onionshare (and I opted for this as there's no centralization of data by a corp. 3rd party like Dropbox) so bugs may need to be squashed. I'll send you another link tomorrow evening and if that doesn't work I'll just email you instead.

Ok, spreadsheet links sent to BTC members. I'll have to track down non-redditors tomorrow as its 11PM here (bregge, RyanArr, sabermage, mm....j).

I need an easier way to share these links with non-BTC members.

==

I capped fees at 10% otherwise with the poor mining results due to constant rebuilds (where a new privkey had to be prepped. Sometimes more than once a day) the fee percentages would have been very high, and unfair.

Hey CripLib,

You would be in Node 5, but the problem is I'm concerned about starting a 5th community node with all the unintended extra work and troubleshooting just 4 beta nodes has caused me.

I'm concerned enough to hold off full node setups unless the full node user only does 1 Node...and they may have to find someone else to manage it because 10% really isn't enough if some nodes require literally 5 rebuilds in a 2 weeks span. I can't be servicing full nodes in volume if each one is going to require excessive troubleshooting or that a cold wallet could get hosed from.

*If* I can get Node 3's control of the stake back into the wallet its meant to be in, I'll continue this service past this month. If not, I'm going to have to consider this too high risk for even someone with my high risk threshhold. This software's essentially Version 0.61 at the moment, before Version 1.0 in a few months.

Let me know if you just want me to send the 280DRK back or if you want to hold off to see if Node 3's phantom self-payment can be resolved.

Oh, it definitely is! I am so stressed out trying to do right by you guys. This was also in the middle of tense negotiations with a Govt. Accreditor re: the prototype Linux system I designed and hardened recently. As for Node issues: I donated the last of my held DRK (only about 6.5-7 DRK) to Node 3 and Node 4. This is the last of my DRK held after I couldn't regain control of our Hot Wallet in RC2 Node 1 which held 450DRK of mine.

To Node 3 Owners: My apologies that this is so late or if you didn't hear about the problems with Node 3 or that I was trying to deal with it during a family reunion. I froze this account while I was dealing with Node 3's local wallet database becoming corrupt on 7/2 and trying to fix this (and Node 1 and negotiations with a difficult Govt. Accreditor) during breaks during a family reunion. The latest rebuild still fails when the local wallet syncs to July 2.

All mining payouts have been sent and everything should up to date. I took the day off from work this morning and have been doing additional efforts to deal with the corrupt database error I saw on 7/2 and to get your mining payouts sent out. chaeplin and Propulsion have been contacted to see if they've ever seen this database error or if this is recoverable somehow.

It appears to be a phantom self-payment after the database was rebuilt (transaction shows a weird time of 00:16; I wasn't even up at midnight but would match a database being rebuilt at a perceived system time of about 00:00): http://i286.photobucket.com/albums/ll87/SurfSkateKauai/coldwalletdisappears.png

If its an external payment its supposed to show the receiving address as solid black instead of gray and there shouldn't be parentheses around the address. If it's a self-payment for a cold wallet node registration its supposed to show as 0 DRK with an address of (n/a), and our balance isn't supposed to be affected.

If I could somehow freeze the sync at 7/1 and then move the coins elsewhere, everything would be hunky dory. I have to get some work at the lab done but I'll send out the latest spreadsheet links this evening (which includes more info on Node 3 problems with the Cold Wallet). If you don't already have it: Please download and run the Tor Onion Browser to be able to access the PM link(s).

Thanks. I actually reached out to one of the guide creators to be a co-admin but this person went on vacation, then I went on vacation. I have been too busy after getting back from this short vacation to follow up with this individual. This person is interested so perhaps reinforcements and improvements in code could convince me to continue this service which I think has a lot of potential (if the dang bugs and masternode disconnects could be stomped out).

Yeah, regarding that one. Node 1 re-build attempt was attempted a final time when I wasn't trying to rebuild Node 3's local wallet association. I moved away 1K from this Node 1/2 wallet (that originally had at least 2k) and restarted the node using a different PC. Therefore, the local wallet was now only associated with just one node instead of using a Cold Wallet and a Hot Wallet with different launch conf files to try to connect to 2 nodes.

So, the local wallet was the orig. wallet associated with the Hot Wallet payment. Problem was even with a fresh darkcoin client install and restoring the orig. wallet file, the hot wallet stake payment still looks to go to some accountaddress0 representing a privkey that never released the coins back when I took the RC2 Hot Wallet node down.

I can't regenerate another privkey because we never got our DRK back (45% which was mine) after the hot wallet payment was sent to whereever it is that hot wallet payments hold these funds to register as a masternode.