Damn, you're right.  It really does need the entire blockchain.



Ok.  But you're assuming the compromise was the wallet file rather than the wallet code.  If the compromise was in the wallet code then analysing the wallet file on another computer isn't going to demonstrate anything.

No, that is one possible compromise.  But I'm not jsut assuming that the wallet file might be compromised.  I'm assuming that the wallet code might be compromised.  I'm assuming that the computer that is running the wallet might be rooted.  It might be doing anything.  It might be displaying addresses and balances given to it by the attacker via a command and control connection, for all I know.


What if the real problem I want to solve, is to determine, reliably and in the presence of possibly compromised computers, how many coins I own?

I don't know about you - but I actually want to know how many coins I own.  That is the sole requirement here.  I currently think I own X coins, but it's possible that an attacker somehow tricked me into believing that.

I don't care about the details of how the attacker tricked me - the problem statement is precisely this: "How can I determine, with a high degree of certainty, how many coins i really own."

It is not every transaction.  It might be a lot of transactions, but it is still a minority of transactions that are needed (i.e. the amount of data needed is considerably smaller than the entire blockchain)


But how do I know that the online computer didn't lie about the merkle hash?

Let me restate the problem.

Assume the online computer might be compromised, and I can't trust anything it displays, or anything it generates.  How can i determine the balance of my cold wallet, given that the offline computer is, well, offline.

Oh, simple.

Assume an attacker compromises the computer with my watching only wallet and arranges so that every time I asked for a new receiving address it actually displays addresses under the attacker's control.  I then transfer coins to this address, intending to place them into cold storage; but unbenowst to me I'm actually paying them to the attacker.

In order to keep up this attack for as long as possible, it's in the attackers interests for the attacker to arrange for the watching only wallet to display the balance I think I should have, not the balance I actually have, so that I don't notice the attack.  If this is a savings wallet which I never withdraw from, the attacker could keep this up for years.  The compromised watching only wallet would display a balance that taliies with what I think I should have, but in reality the wallet is essentially empty because I never paid any coins into the real wallet.

An attacker that compromised my online computer to give out incorrect addresses would probably want to fake the balance so that I didn't notice.


And to be 100% sure, I have to retrospectively verify every address it's ever given out.  Not entirely realistic.

I don't understand that statement.  I believe I have X coins in my offline wallet.  But I only believe that because a (possibly compomised) online computer tells me that.

In what way could it be anything other than useful to verify that I really do have the X coins I think I have?

Yes, currently the offline wallet knows nothing about the blockchain, and therefore can't computer the balance of the wallet.

I'm proposing an audit mode whereby the offline wallet could be given a file containing just enough of the blockchain to determine the balance, and I'm also proposing countermeasures to guard against some possible attacks against that mechanism (since the offline wallet has no access to the Bitcoin network and hence can't apply the usual rules to determine the longest chain)

So, there's been some discussion of the idea that a watching-only wallet might be compromised in such a way that it gives out receiving addresses that are actually controlled by an attacker.  If the compromised wallet actually correctly faked the balance your off-line wallet should have, it might be possible for such an attack to go unnoticed for a considerable time.

One obvious countermeasure would be to periodically audit the balnce of the offline wallet by setting up a new watching-only wallet on a clean machine, and verifying the balance that way.  However, since this involves getting the blockchain onto the new system, such an audit is never going to be a quick and easy process.

I'm wondering whether the following process for a wallet-supported audit would be viable.

[NM, this doesn't work.  DeathAndTaxes points out to me that it's impossible to determine whether those coins have already been spent without access to the full blockchain.  I guess the only way to audit a cold wallet really is to set up a new watching-only wallet on a known-good machine.  Or at least, to maintain sufficient watching-only wallets that compromise of all of them is unlikely]

In order to conduct an audit, the watching-only wallet would write a flie to a flash drive, containing the following:

• Block headers of the entire block chain
• The complete transaction history of all UTXOs in the wallet, stretching back to the coinbase transactions that mined those coins
• The merkle branches that prove these transactions are in the relevant blocks

This file could then be loaded into the offline wallet, which could then verify the header chain, and compute the balances of all the UTXOs.  The above information is enough to prove that some chain exists that contains the purported transactions.  It's not, in theory, quite enough to prove that that chain is the real blockchain, but that could be assured by a system of signed checkpoints.

It would also be possible to get a reasonable degree of assurance in a trust-free manner, simply by having the offline system display the difficulty after the last block, which the user can verify is roughly correct.  This is enough to prove that whoever constructed this chain expended work at least equivalent to the entire bitcoin network hashing at current speeds for several weeks over four days, which is still a pretty high bar to faking an audit.

It's not conclusive, though, if the attacker has had months or even years to prepare the fake chain, but for the truly paranoid you could display a more detailed difficulty history, which would defeat an attacker who used lots of 4x difficulty increases to minimise the amount of work they needed to do.

Is this idea viable, or is there some reason I'm missing why this wouldn't work?

roy

EDIT: Rather than displaying the difficulty after the last block, display the difficulty value that was current immediately before the last difficulty change.  An attacker would have to have mined a full 2016 blocks at this difficulty, so it raises the bar significantly.  Signed checkpoints aren't as useful as I first thought, but I think there are still relatively simle checkpoint schemes that help here

EDIT: Better: pick the block midway between the last two difficulty changes, and display the date and time, balance, and difficulty as of that block.

Yes, I think so - although then I don't know what you would do with the totals.  As I said, it's still a bit of a thought-in-progress.

roy

Ah, so the long delay before Armory displays the balances is actually a feature, to give me time to do this....   That works

EDIT: Actually, that doesn't help if I actually do want to check the balance of the wallet I'm paying with - without revealing the balance of any other wallet(s)

I have a feature request, that's kind of a thought-in-progress...

The other day I fired up Armory on my laptop while I was at work because I needed to transfer a small quantity of coins from my online Armory wallet to my Bitcoin Core wallet.  (I normally use Bitcoin Core for day to day purchases, but by balance was a little low.)  But I was conscious that anyone who happened to walk past and see my screen (and knew what they were looking at) would also know exactly how much I had in cold storage.

I'm not sure what UI change I'm really asking for here - maybe a preference that hides balances when the client is launched (and allows an individual wallet balance to still be viewed by means of a UI action)?

It's true that my bank's Internet banking has the same problem - launching it would reveal the balance of my current account (checking account), credit card account, and savings account.   The difference, of course, is that I can make payments from the first two just by typing my debit or credit card number into a merchant's web site, so the privacy issue never arises in normal use...

Thoughts, anyone?

Or, it is an increase of 2, and next year 4 will give up

I see you've dropped the message 'No Wallet Error Found'.

The first time I saw that, my brain parsed it as 'Error: No Wallet Found' :-)

With the proviso that mining at a loss may be rational, if you have difficulties accessing other ways of obtaining BTC.  Consider, if China continues to make it hard to deposit money to exchanges, then many Chinese miners might quite rationally continue to operate their older ASICs, even if they are effectively paying a substantial premium for their coins, because it may still be cheaper and easier than the alternatives (e.g. an in person transaction might involve travelling to another town, which obviously has its own costs associated with it).

roy

I think you forgot to divide by the velocity of money.

Put another way, GDP is the value of goods and services sold in a year.  But the same coins might be used for more than one transaction in a year, so a 1.5 trillion USD contribution to GDP doesn't mean a bitcoin money suppy ('market cap') or 1.5 trillian dollars.  Some coins might be used in many transactions in the space of a year - hence requiring a significantly lower valuation to be able to account for all those transactions.  Of course, this is balanced by the fact that other coins won't be spent at all in any given year.

roy

Thanks for the quick response, Alan!  Signature and hash verify fine.

Thanks again

roy

Could someone tell me where to get the signed hash for the Mac version of 0.91?  It seems to be missing from the download page.

Thanks

roy

Okay, well if it's of any interest to anyone, this is the patch I'm now running my CoinCraft Desk with (against the original MinerOS my Desk shipped with - which may not be the same as the MinerOS that your Desk shipped with.  I kept it simple - I didn't want to do more than the bare minimum to meet my needs since there might be new firmware coming soon anyway.  My patch implements the following:

• Front panel shows the higher temperature of the two sensors (standard code just picks the first one it finds)
• Performs an emergency halt if either sensor exceeds 70C.  Note:
  
  • This doesn't power off the machine (last thing I want to do with an overheating miner is shut off the fans) but it does stop all mining.
  • There's no auto-restart.  The easiest way to manually restart mining once the unit has cooled down is to press the "Save and Restart CgMiner" button in the settings page of the web interface (you don't have to make any changes to settings.)
    
  • When halted the LCD display shows the word 'halted' in place of the hash rate.
  • I've not done any work on the web interface, so this simply fails to update the displayed hash rate since it can't contact cgminer.  (It's fairly obvious that the system has halted though given that temperature and CPU will be much lower than normal.)
  • The cutoff temperature is not configurable (except by editing the constant at the top of the code)

You're welcome to use this freely if it's any use to you but please note:

• I don't support this, and can't provide assistance in applying patches
• You should review the code yourself and decide whether you are happy with it
• If the patch doesn't apply cleanly, it probably means your unit shipped with a slightly different version of the code than mine.  You did review the code and decide you were happy with it, right?
• I'm not responsible for bricked devices, and can't provide assistance in recovering from problems.  (Did I say already, I don't support this.)

Patch against the original minerosd.py is here:

https://www.dropbox.com/s/b1lfs9dsp9pmatl/mineros.patch

'Fraid I don't have time to keep up with the official thread, so I'm hoping someone here knows:

Is there any newer firmware for the Desk yet, or is the firmware that the units shipped with the latest available?

Thanks

roy

Which appears to be this place, I think:

http://tinyurl.com/l67qjuf