You mean that some people would actually link this to their main checking account instead of opening a seperate one, disabling overdraft protection on it, only transferring funds into it just before sending those funds to Coinbase, and immediately moving received funds to their main account?

If you could somehow work out a deal with ADP so that any employee of a business that they service could receive their paycheck in bitcoins it might be worth getting those licenses.

It's probably too early for that though.

You misspelled "just us".

That sucks. Another case of laws keeping us from having nice things.

I guess I'll just have to do things manually until someone launches BitPayroll.com.

Irrelevant.

Image displaying software isn't supposed to execute arbitrary code based on the content of a JPEG file, but it still happens sometimes.

That you aren't even acknowledging the existence of an entire category of vulnerabilities does not inspire confidence.

Do we really know sound is safe? Has anyone ever tried to crash the Linux sound drivers via malicious sounds sent to the line in port? Maybe the only reason we don't think a vulnerability exists is because until now nobody has ever had a reason to look for one. Even if the sound drivers and ALSA libs are safe, there's still the matter of hardening the decoding software.

If even a task as old and well-understood as transforming a JPEG image into a bitmap can result in arbitrary code execution you can't just assume that sound is safe without at least some kind of testing.

The attack surface is  never truly zero. Would you bet your life that it's impossible to craft an audio packet that crashes the decoder in such a way to allow code execution?

That being said it's probably safer than anything in use currently.

The answer is to find a transfer method that has higher bandwidth than QR codes.[/quote]Aren't there encoding methods with a higher limit that can be printed out?

If I was working with a savings wallet with > 10^4 USD equivalent I'd buy a printer/scanner for the offline computer and use paper to move the required data if that reduced the potential attack surface.

I think for this use case it's reasonable to look at ways to prevent the number of possible inputs from getting that large that might not otherwise be desirable.

The first thing that comes to mind is only having a single address in the offline wallet (always send change back to the same address), and combine unspent outputs after every N deposits, where N is selected to be small enough to never run into the problem you referenced.

Excluding exchange rate risk, it's perfectly safe for storage. The problem is safely moving funds out of storage without potentially exposing your private keys to malware.

Depending on who you talk to this is irrelevant or even beneficial.

There's a difference between petty cash and your retirement savings.

In the first case convienience is very important and losses, while still undesirable, are expected to occur from time to time.

In the second case no losses are acceptable.

You need different procedures for handling each case because the definition of success is different. I'm satisfied with the security of Bitcoin clients as the currently exist for storing small amounts of money that I could survive losing without taking additional security precautions. On the other hand, I see the existing clients as wholly unsuitable for safely manipulating large and critical sums of money. (not their fault - it's a hard problem that just hasn't been solved yet)

That's why I'm trying to work out now what would solve the problem in an acceptable way before I actually need the capability.

If the online computer which generate the transaction is compromised it can lie about the size of the inputs and cause you to pay a larger fee than you intended, but how credible of a threat is this? The only one who benefits is miners, and would it be profitable for them to fund a malware attack when they can't guarentee to be the ones to mine the blocks containing these transactions?

Any number of services could offer this, but I actually think payment processors like BitPay would be a better fit due to their business models.

BitPay receives bitcoins and pays out dollars. This means they have to route all their incoming bitcoins through an external exchange. If they also start selling bitcoins for dollars then they only need to exchange the difference between the dollar inflows and the bitcoin inflows, which means lower costs for everyone.

Thank you. So the answer is 5.

Sure, but there's only one back account that all the customers use behind the scenes that won't work. For a service like this to happen the service offering this would need a seperate bank account for each of their customers.

Technically that shouldn't be hard - my consumer account with USAA lets me create new checking accounts online literally with seconds so surely a business customer can get similar functionality from their bank too. The only thing that would make this service unviable would be some arbitrary regulation getting in the way.

Stefan Molyneux has some very useful critiques of Ayn Rand's approach to ethics.

http://media.freedomainradio.com/feed/FDR_1506_A_brief_history_of_ethics.mp3

As of block B my address A has a balance of 10 BTC.

I decide to spend some of it so my client generates and broadcasts a transaction (T1) with a 1 BTC output to destination address D and 9 BTC to change address C. At approximately the same time someone else broadcasts a transaction (T2) with a 5 BTC output to address A.

The miner which ultimate solves (B+1) includes T2 in the block but not T1 because it saw T2 first and had already started working on the block before T1 arrived.

T2 gets included in (B+1). T1 gets included in (B+2).

As of (B+3) what is the balance of address A?

Thank you for taking the constructive reply. If you'd also take the time to read the post you're replying to your reply would be even more helpful.

I don't understand why this needs to be a hard requirement.

In theory the offline computer only needs a private key, output amounts, and output addresses to generate a valid transation. Output addresses can be typed in manually and stored in an address book. Amounts can also be manually typed in.

Sure, there's a high potential for user error doing it that way but the biggest risk (incorrectly specifing the amount for the change address output and giving away most of your savings as a transaction fee) could be removed by reusing the input address as the change address or by basic sanity checking built in to the offline program.

Edit. I just found out in a different thread that my understanding of how an input is specfied was incorrect. So now I do understand the requirement to generate the transaction on an online computer.

I have some questions about using Armory in a fully air-gapped offline mode that are relevent to the same scenerio as the OP.

I want to store Bitcoins on a computer which, after the initial software installation and key generation, will never again communicate over a network or accept removable media.

Can Armory generate raw transactions without ever having any knowledge about the blockchain and display them on the screen as a QR code?

If it could do this, and if the QR code was formatted as a URL, it would be possible to create a lightweight web service that would accept raw transactions as a URL parameter, check them for validity, and broadcast them on the network.

Now spending funds from an offline wallet doesn't require a serial cable or a thumbdrive - it just requires a smartphone with a standard QR code reader app.

Obviously not every participant in a market has the same needs so not everyone will use the same set of services so I don't understand the purpose of your comment.