I would go with GPG/PGP or, maybe more appropriately, a signed message signed using the private key of either their payout address or, if they prefer when setting up the account (not after their phone with the privkey on it was stolen) another bitcoin address they do not keep the key of on any of the machines involved in their two factors. Or, let them associate an Open Transactions nym simularly so as to be able to sign a message using the nym's key.

Basically all three of these suggestions amount to have them provide (in advance, at original account-creation time) a public key any messages sent by are to be taken as from them, and that thus they should not keep on any of their N-factor-authorisation devices and maybe should consider splitting up into many parts scattered across many devices or something depending on how paranoid they are.

Or, three-factor: have them provide three keys, one being a bitcoin address, one being an Open Transactions nym, the third being a GPG/PGP key, and require all three for any reset of their two-factor authorisation.

-MarkM-

I am not sure bitcoin-otc limits one to small chunks. Some of the people there might be well able to handle larger chunks than you might think, if you are willing to trust them. I imagined that getting trusted yourself would be the main problem if you didn't want to trust others, but that some of the people that are well trusted there might be able to handle quite large orders. I do not know quite what size of orders they can actually handle though.

-MarkM-

Yeah, the more I hear about this fiat stuff the less I like it.

I try to avoid the stuff as much as I can.

I would love to handle such things with my Open Transactions server but big brother makes the whole concept so scary it seems like they don't really want anyone but them using the stuff at all for anything, yet they also seem to go out of their way to try to prevent people using anything else. Very scary stuff. Bitcoins and similar currencies seem so much more civilised.

You could try asking on #bitcoin-otc on Freenode IRC though. Maybe a private exchange between friends might not be so scary in terms of people with guns knocking on the door. Or do they go after friend to friend exchanges of such amounts too?

-MarkM-

TL;DR: My backups setup might seem pretty good compared to some, however I would like to convince myself it is adequate as I am probably less likely to imagine it so than others might be.

A lot of the posts talk about security too, not just backups, and many people may not even know what it is that I do, so I will start by describing some of what it is that I have that could benefit from backups.

I have some game sites on third party hosting, basically as tests of different game software and with so far so little money involved that if they needed to be restored from backups it is likely they'd just be shut down instead, the players compensated with in game goods/currencies from some other game such as whichever one is up next for testing. So I won't worry about their backup situation right now, they are not mission-critical and we might be better off without them as most turn out to be fundamentally flawed or, even if they work, to just be black holes to throw money at with no return. If they do pay for themselves though, then maybe I could also consider using them as yet another place to push triply-crypted backups to. Currently I have their level of hosting tier low enough though that using them to store such things would be frowned upon as they are currently a tier of hosting intended only for websites not for file-serving or file-storage.

So the servers I am concerned with right now are the cryptocoin-mission-critical servers, which are right here with me behind my steel-plated door.

Mostly of importance is the Open Transactions server. It is not accessed by means of web-browsers but, rather, by its own crypto-secured communications protocol by which remote users' clients communicate with it.

I have a second server that is not even powered up, because it is horribly noisy and does not need to be turned on most of the time, but which has a hard disk as large as the main drive in the running server so can be fired up to transfer backups onto.

I wrote scripts for doing backups, but no longer remember the exact details of what it is that they do (as in which username exactly sends on to which username type details); I am glad to have run across this thread as it motivates me to go look at those scripts to check exactly what they do and whether there is more I should now have them do in the light of development that has taken place since they were written.

Offhand I recall that they have three separate usernames involved, so that a backup once made is sent gpg-encrypted to a second user's pubkey then that second user re-crypts it to a third user's pubkey, because I did not want to risk offsite backups' security to just a single layer of 4096-bit encryption.

I would also like any ideas people can offer about how to deal with /home/*/.ssh and /home/*/.gpg directories, which I deliberately leave out when backing up home-directories partly because there is not much use having a backup of those types of keys if one needs them in order to access and/or decrypt the backups. I would prefer not to let backups of those critical (due to containing keys) directories onto third party machines at all, so I am considering using USB flash drives physically stored in safe deposit boxes or some such approach for offsite backup of that key (pun intended) data.

Having thus sanitised the normal backups from containing any .ssh or .gpg directories and triple-crypted them using keys located in the areas that they no longer themselves contain, I have been trying out various third party online data-storage sites whereby I can copy a backup to a certain directory on my hard drive that is automatically copied over to offsite storage.

Since I have not so far been dealing with significant sums of money, I have so far included among the offsite storage sites tested some that require me to run a daemon in order for this copying over to their site to happen. I create a new username for each such service, running its daemon as that user, and having it mirror only a directory located in that user's homedirectory. I have also been looking at things like GNUnet.

One of the offsite storage solutions I looked at offered to back up even stuff that does not live in that user's home-directory; I am thinking that a (closed source) daemon that is willing to go browsing over my entire filesystem, even as one specific user, is probably a bit too nosy to be considered for use once I do switch over to "real use", working with serious real money.

At least one service actually works using normal existing remote disk access systems instead of closed source (thus totally untrustable on general principles) custom daemons of their own devising. Those are kinds I am most interested in hearing about more of as it seems likely they are ultimately the only ones I should be considering using.

As to frequency of backups, that I will have to tune in accordance with usage. Right now days or weeks go by between third party tests of my Open Transactions server, so simply doing a backup after each such testing-session seems sufficient. As we move into "real use", maybe hourly will seem reasonable. Having cron run the scripts at any desired frequency is hardly rocket-science.

However, I believe the /home/*/.ot directories are also being segregated out like the .ssh and .gpg directories, so in any case the OT server and all the clients I use with it can be backed up more regularly than other less mission-critical subsystems once actually in constant use.

Input on how best to do these backups is very welcome.

-MarkM-

Its a secret closely held secure from your eyes by Google.

-MarkM-

No-one expects Cardinal BIggles...

-MarkM-

The meaning of the term bitmuggles was instantly apparent totally without any knowledge that geocachers had also appropriated the term muggles.

In fact, maybe the geocachers should be using geomuggles or geocachemuggles or some such for greater clarity in their own appropriation of the concept.

-MarkM-

From the sound of it, scammers should have no problem providing other people's identity documents since they can obtain such documents simply by extorting them from anyone whose money they manage to get hold of by means of any pretext that they can later relate to "need to know" rules?

The documents exchanges are obtaining might for some exchanges be worth far more than any potential commissions they could make on actual trades, and this makes it sound somewhat unlikely that people who complain about exchanges holding lots of their money for such extortion purposes are scammers since if they were scammers the large sums involved would have already made it well worth their while to have already run precisely such an extortion scheme themselves thus to have ready for use lots and lots of people's identity forms, which they would presumably be well prepared to spend whenever someone else tries the same scam on them over a large sum of money.

Whole thing kind of smells.

Is there at least some standard system that is used in imaging one's identity that watermarks it as being only a copy and specifically as a copy submitted into the safekeeping of a specific blackmailer/extortionist/KYC-excuse-purporter?

-MarkM-

Yes try the FreeNode IRC channel #opentransactions for sure.

Like most IRC channels, people lurk there 24/7 so will eventually see any questions etc when they wake up if they happen to be asleep when you type something.

The latest wave of upgrades to Open Trnasactions has been another massive one, involving setting up ultra-security for your private keys so that they never reside on disk un-encrypted. This initially meant having to enter the passphrase you chose for encrypting the keys over and over and over again, as each time it needed the passphrase it would use it once and scrub it from memory instantly even if it immediately found it needed it again. Now there is a timer available for the secure portion of non-swappable memory used, so that you can configure for how many seconds it should remember your passphrase once you provide it.

This still can involve inputting the passphrase multiple times initially, certain at least twice when you first choose a passphrase as it wants you to tell it twice to make sure you typed it correctly; but after the initial run all keys should be crypted and it should on future runs be able to remember the phrase for the configured number of seconds (default configuration is 300 seconds aka 5 minutes) before having to ask you for it again.

This has been a horribly annoying feature to work through the development of, but is a very important security feature that should in retrospect have been well worth all the hassle its development and testing has involved.

There is also a very high level API for scripts now, though again the passphrase feature will cause inconvenience since unless a human is going to sit by when scripts are run to provide passphrases to the scripts each developer of scripted systems will have to choose a method of getting around the passphrase security system in order to set up trading bots or whatever with it. Worst case though one could use a completely separate user to run bots, a user that does not crypt its keys on disk thus does not need passphrases, to which they give only a small amount of assets at a time to play with. Or, one can use "expect" or similar software to automate responses to the scripts. Or an openssl agent type system can be used. The choices are actually mindbogglingly diverse, lots of choices on how to do it. All there because some people's disk drives cannot be trusted not to end up some day being read by an attacker. This will not protect you from a keylogger but nonetheless is pretty good protection, along the lines of existing openssl agents, keyring handling apps etc. (In fact it is also planned to add choice of configuring it to use an existing third party keyring handler if the user prefers to do so.)

-MarkM-

DeVCoin addresses are BiTCoin addresses.

The only difference is which wallet you put their private key in. You can export a private key from a BiTCoin wallet and import it into a DeVCoin one and vice-versa.

This was originally done so that people's BiTCoin donation-addresses can be used with DeVCoin as their DeVCoin donation address, so people could get onto the developer share reievers list without having to get DeVCoin up and running first in order to do so.

But it also happens incidentally to mean the BiTCoin address a miner normally gives to p2pool for mined BiTCoins to be shared out to is equally (from the server's point of view) useable for sending out DeVCoins to miners. Miners who generate a mining address using their BiTCoin client instead of their DeVCoin client will have their priavte key in their BiTCoin wallet rather than their DeVCoin wallet admittedly, thus have to import it to a DeVCoin wallet eventually in order to access the address on the DeVCoin side, but things like proving to the admin of the Open Transactions server that you control that address can be done with any proof method that can use BiTCoin addresses, such as a signed message signed by that address created by any *coin client that can work with BiTCoin addresses, such as a BiTCoin client or a DeVCoin client.

I haven't hacked p2pool to actually send out DeVCoins itself, so I could even give people their DeVCoins in the form of dDVC (DigiDeVCoins; DigiDVC; DeVCoin tokens) on the Open Transactions server so they can trade them for whatever type(s) of assets they choose that that server supports.

I have not in fact actually looked deeply enough into the internals of p2pool to know exactly what statistics it keeps, so we should regard this as initially a test run to test out exaactly how best to do it and that it can in fact provide the statistics we need and even that setting its commission percentage to 100% will in fact cause it to not send out any bitcoins but yet to keep statistics on numbers of shares solved.

So don't redirect huge amounts of hashing there yet, lets make sure first that is will in fact keep track of everything sufficiently before relying on its accounting. Right now I do not even know whether it even pretends to work for remote users yet, I opened its port in the router but have not heard yet of anyone successfully connecting to it and using it.

-MarkM-

http://sourceforge.net/projects/galacticmilieu/files/

Specifically, the DeVCoin subdir of that dir.

-MarkM-

Okay, my merged-mining p2pool should now be reachable over the net as port 10332 at ot.knotwork.com

It is a p2pool set up as 100% commission to prevent it paying out any bitcoins. It merged-mines currently bitcoins, namecoins, devcoins, groupcoins, ixcoins, i0coins and coiledcoins.

Payouts will only be in devcoins. All the other types of coin will be sold, hopefully on my Open Transactions server which functions as an exchange for many types of cryptocoins and other assets, and the proceeds used to pay out in DeVCoins.

Still to do is working out the details of exactly how to compute payouts, presumably after sale of the coins it should be possible to simply divide the number of devcoins by the number of shares it took in order to figure out how much each share ended up being worth.

Part of the purpose of this pool is to provide liquidity to the exchange by using everything other than devcoins to buy devcoins; part is to help keep up the value of devcoins by creating demand for them in terms of each of the other coin-types.

-MarkM-

Okay, my DeVCoin Pool mentioned previously now has routing, it should be reachable on the net now as port number 10332 at ot.knotwork.com

Also now routed should be ports for the MUDgaard MUD that had hitherto only been reachable over i2p in web mode, with port 5555 as the telnet-type port used by MUD clients and port 27744 as the port web-browsers can visit to access it via browser.

-MarkM-

I am preparing to open up my merged mining setup as a "DeVCoin pool", that is, as a pool that pays out only in DeVCoins.

It merged-mines as many coin types as is practical, currently bitcoins, namecoins, devcoins, groupcoins, ixcoins, i0coins and coiledcoins; that much already works, and is done by means of p2pool.

It will pay out only DeVCoins though, which it will accomplish by selling all the other types of coins for DeVCoins, hopefully mostly on my Open Transactions server.

It looks like I should be able to set p2pool's "commission" to 100% so that it does not pay out any bitcoins, and compute how much each completed share submitted is worth up to a any given moment by compating how many shares in total have been completed to how many DeVCoins in total have been realised by mining them and by selling all the other types of coins mined. So this should hopefully be opening shortly.

-MarkM-

I suppose. I don't see more chains as a threat to bitcoin at all, rather they are ads for bitcoin and they give people easier-to-mine coins they can spend instead of spending their bitcoins, so that they can save up their bitcoins, much like the old "bad money drives out good" thing whereby people get rid of their crappy fiat much more willingly than their actual gold. They are maybe like loyalty points systems too since they are a free reward you get on the side for supporting the bitcoin network by mining.

It seems a bit crazy to think they would drive down the value of bitcoin, it seems to me quite the opposite, any increase in perceived value of any of the altcoins would lead to a rise in the market price of bitcoins if only because "everyone knows bitcoins are worth more than any of the altcoins". We want altcoins to go up in value because if they do then obviously the more-valuable bitcoin will too.

A lot of roleplaying game players are long used to so many copper coins per silver coin, so many silver coins per gold coin, so many gold coins per platinum coin and so on; to them it often seems intuitive that if copper coins increase in buying power obviously silver gold and platinum do too because they are simply larger numbers of coppers in effect.

I see this happen already with GRouPcoins... like DeVCoins, GRouPcoins will keep on generating the same number per block forever, but the number per block is only 50 whereas devcoin generates 50000 per block. Many players simply take it for granted that in the long run this means a GRouPcoin is basically a 1000-DeVCoin coin; the fact that GRouPcoin's difficulty is currently much lower just means now is a good time to pick up 1,000-devcoin coins for less than 1000 devcoins, much like someone stumbling on a gold mine could pick up gold for less than the normal amount of copper per amount of gold...

-MarkM-

Autotools (./configure etc) build-system is now in place, hopefully that will help make the build process easier for everyone... So its getting to be time to have another try at getting a client fired up if you had found the build process too daunting in the past...

-MarkM-

Merged-mining a whole bunch of other chains alongside bitcoin does seem to be resulting in more return on investment for mining, so it doesn't make much sense to me not to merged-mine as many chains as I practically can. It is all very well to play bitcoin-elitist and turn up one's nose at many of the chains one can merged-mine, but that brings in no knowledge about how many chains it is in fact practical to merged-mine and "leaves on the table" lots of flavours of coin that are basically cheap and easy to obtain given one is already mining at all.

Chains that *are* merged-mine-able alongside bitcoin though *are* vulnerable to attack by bitcoin-elitists, as Luke-Jr showed by using his pool-users' hashing power to attack coiledcoin.

Hopefully in the long run the people who turned up their noses at various altcoins will find they are simply people who missed an early-adopter boat; if they were early-adopters of bitcoin they might be happy with that, but people who feel they came into bitcoin a little late can basically be early adopters of other coin types while also picking up "free" bitcoins on the side due to merged-mining, thus bitcoin effectively becomes for them a subsidy subsidising their entry into mining the various other kinds of coins that can be merged-mined alongside bitcoins.

I currently merged-mine bitcoins, namecoins, devcoins, groupcoins, ixcoinns, i0coins and coiledcoins, all using p2pool. I was mining geistgeld and rucoin alongside those too some tiem ago but had to drop those two from my roster. I think though I could put two others in their places quite practically, as long as they didn't have the ridiculously fast block times that geistgeld uses. I would in fact like to keep adding more and more chains if only to find out what the practical limit on number of chaisn one can merged-mine turns out to be.

I plan soon to open up my merged-mining setup to others by providing access to it as "a devcoin pool", a pool which will merged-mine as many types of coins as it can, turn all except the devcoins into devcoins by trading them (hopefully mostly on my Open Transactions server) and pay out only in devcoins.

-MarkM-

I am p2pool merged-mining bitcoins, namecoins, devcoins, groupcoins, ixcoins, i0coins, and coiledcoins currently.

I used to also have geistgeld and rucoins merged in with those but turned those two off a while back.

I use Linux though not windows.

-MarkM-

I am already merged-mining using p2pool, merging as many coin types as I practically can, but I now want to use it as a "devcoin pool", paying people only in devcoins for using the pool.

It looks like I should be able to set commission percentage to 100 percent to prevent anyone being paid out any bitcoins, yes?

But where would I look to find statistics I can use to divide up the devcoins once I sell all the coins except the devcoins for devcoins to pay to the users?

-MarkM-

I don't know of a command to make it tell me what IPs it is connected to. Maybe some kind of search of the log could figure it out?

It seems strange we are using same version and I have your node specified with the add commandline yet we see such different difficulties...

-MarkM-