If you use something such as the CIYAM Safe (http://susestudio.com/a/kp8B3G/ciyam-safe) then you just make sure your tx computer is *permanently* offline (by that I mean *remove* the WiFi card and disable/destroy any other standard way to get network connectivity such as plugging in an ethernet cable).

It is a LiveOS and doesn't even access the HDD of the machine being used so it doesn't matter how infected its OS is.

It also doesn't require you to use a USB for comms (that can be all done via QR codes for 100% "air-gapped" safety).

I am guessing you are trying to work out where to send funds back to (most likely for the purpose of some sort of gambling game) - the short answer is that you *cannot* determine this as the protocol doesn't have such information.

If you want to be able to reliably send money *back* to an address you should ask the user/player to provide a "payment" address.

DeathAndTaxes is "right on the money" here.

OpenCoin has tried to be "very clever" but they have been *anything but* open.

Now that is surprising - although there was some OSX specific change in the latest release I think that was only to do with LevelDB.

Assuming you didn't do a large # of transactions since your "old password" backup then using that should be fine (of course don't delete the latest backup until you are 100% certain everything is okay and even then wait a week or so before deleting it just in case).

Not trying to be too negative but adding a % on top of a VISA/MC transaction just to use BTC is not a good model.

One of the most fundamental points about Bitcoin is to be cheaper as it doesn't need the "charge back insurance" that those payment systems require.

It doesn't seem very likely that anyone would be able to buy flowers *cheaper* through this service at all (so unless you're offering *anonymous* flower sending then there doesn't seem to be any reason for wanting to use such a service).

Fiat currencies have not been backed by gold for quite a long time.

The "coinbase" isn't but all the other (non-coinbase) UTXOs are (i.e. only the initial 50 BTC can't be spent).

You might want to look into SPV - it is very likely that in the next major version (or the one after) the standard Satoshi client will be able to be configured in a way that you can choose how much space it should use (within minimal limits).

Clearly it would be pointless with $100 itself - but an asset is something that presumably you don't want to lose ownership of (i.e. the selling of and buying back would either represent a timing issue or might be expected to be of greater cost due to fees or rising asset values than the paying of interest for the loan).

So I can see the point of using a BitGold asset as collateral for a loan of USD fiat but I could not see the point using a BitUSD asset for that.

For a start Bitcoin hasn't really got to the point of deflation at the moment (still many new bitcoins being mined every day increasing the supply of currency).

We did see a marked changed at the first block reward *halving* (that pushed its price up dramatically) and I expect we'll probably see a similar event when the next halving occurs (still a few years away).

The argument in comparison with gold has a lot of problems because you can't send gold through the internet to anyone else in a matter of minutes and the whole Keynesian model of inflation is clearly starting to have problems of its own as we see currency wars constantly reducing the value of fiat.

Also this has been argued to *death* on this forum - so rather than create *another* topic the same as 1000 others perhaps do some searching instead.

If Authenticator is working with one website but not theirs then perhaps it is their clock that is out or something else has gone wrong.

I think only their support can help you further with this.

If they are using some sort of time zone adjustment in regards to RFC 6238 (aka Google Authenticator) then they are doing it wrong.

Understand the part of the algo that deals with the current time is as follows:


where "freq" is 30 (for 30 seconds) and time( 0 ) has no tie to a time zone (it is *always* seconds since UTC epoch).

CIYAM Open uses Authenticator and the server is set to UTC time - I have tested using a Galaxy S3 set to China time (UTC +8.0) and it works perfectly as expected - so in short a correct implementation doesn't care about whatever time zone you are using.

Are you sure the time is correct (to within say 10 seconds) on your device?

A couple of suggestions I'd make for anyone implementing Authenticator would be:

1) don't enable its use at login *until* the server has verified you are able to give back a correct PIN

2) keep one previous value to help out with possible time variance (so you can test what the user provides against the current PIN and that of 30 seconds ago)

Google authenticator uses unix time epoch (i.e. # of seconds since 1970-01-01 UTC) so timezone has absolutely nothing to do with it.

Either your device is not in sync with network time or their server isn't (if others aren't having this problem then most likely it is your device).

You would always want to be able to receive money to old addresses (even if you never expect to) but it does make sense to have perhaps an "Active" status that can be switched on or off (with a check box for displaying "Active Only" that is checked by default).

It *is* Bitcoin (the pic is from blockchain.info) - presumably the recent high increases in hashing power and some luck managed to give us 6 confirmations in 10 minutes rather than the average 1.

Am guessing by @jan you meant @ian and so have now deleted all the rejected bids for the Moneychanger project (allowing yourself and Xenland to bid any of the tasks again).

Although generally one bid per task makes sense this scenario wasn't one I had actually considered and so will give it some thought (maybe the limit should just be for one *active* bid per task).

It would be nice to perhaps have an option not to have it appended (I also find it to be annoying to have to always remove the trailing -000 when looking up on blockchain.info although I guess they could strip it off at their end if they wanted to).

As it is clearly not a bug you should update the title of this topic.

The Moneychanger tasks have all been re-opened but before others create bids they should consider that although once your bid has been accepted you are not competing with any other developer you are competing against the clock with the Delivery date and time that you provided.

Also if your bid ends up being rejected due to not having a deliverable or only having partially completed it you will end up losing Project Skill points.

So carefully consider a task before "trying to get dibs on it" and only bid on tasks that you are sure you can complete and the Delivery date and time should be carefully chosen (hint: don't just use the default value).

My point with Shantaram was that it's philosophy is based upon *complexity* instead of *morals* and it cleverly describes morals in terms of *complexity*.

The prime example is that: To kill a human is wrong because you are destroying complexity (destroying entropy), to kill an ant is also therefore *wrong* (but less so) and to kill a plant by the same thinking less so again.

It is a very interesting way to re-think things IMO (although maybe not relevant to this discussion so I won't continue - I would recommend you read the book though - it was a "page turner" for me).