RAM errors on non-overclocked systems are probably much rarer than meteorite strikes damaging the computer. In most cases the error will lead to BSOD and reboot. The CPU itself are more prone to rare occurrences when it executes some instruction improperly because of defective chip, overheating or poor power supply. Also it will either deadlock or reboot as a result.
RAM should be tested overnight using my favorite tool - a bootable Memtest86+ CD. Select to include the optional memory fade tests. If it passes overnight then RAM subsystem is fully functional. From my experience of system tweaking and overclocking.
Topic: On bitflips and Armory security (Read 1200 times)
I have received a lot of questions about RAM errors potentially causing users to lose coins. gmaxwell has made some statements about this in the past, and I want to give people an opportunity to find a hole in my logic. Admittedly, I haven't spent a ton of time thinking about this, and I'm probably overlooking something.
My Statement:
Offline transactions: Armory offline transactions are not vulnerable to bitflips, if you verify addresses and values on both the online and offline computer.
Online transactions (hot wallets): There is a remarkably narrow window in which a bit-flip could result in loss of coins. This could be mitigated with a secondary verification window after signing is complete.
Neither of these conditions hold true if you are assuming the possibility of multiple, perfectly-inconvenient bitflips. DRAM errors are so rare, that squaring that error and assuming that the two errors are perfectly correlated in the worst way possible -- is effectively impossible.
My justification:
Offline transactions: I can't enumerate all the possible times and places a bitflip could happen. But here's a few:
Online transactions (hot wallets):
For this situation, a bitflip after confirming the outputs as correct, but before the system actually creates the signature, is the black swan event. But it could be caught if there was a second verification window that displayed the final, signed transaction before it actually broadcasts. At least in Armory, it is always re-parsing the raw transactions and displaying information from that parse. So, a check of every character of the output address both before and after signing would catch this.
The only other time I can think that this would be a real issue, is a bit flip in the address as it is sent to you by the other party. Perhaps their system bitflips the hash160 value pulled out of the wallet, before they even give you the address. That would be undetectible. But if you are moving life-changing quantities, of money, I'd always recommend calling and verifying every character of the address, anyway. That would catch bitflips after the transfer of the address (and technically the checksum should catch that, too).
Lessons learned: When executing an offline transaction, always check every character of the recipient addresses and values, both on the offline computer before signing, and on the online computer before broadcasting.
What am I missing?
P.S. - We could also just recommend that all systems handling large BTC volumes use ECC RAM. But I'm not convinced it's necessary for an online-offline setup if you do the appropriate checks.
My Statement:
Offline transactions: Armory offline transactions are not vulnerable to bitflips, if you verify addresses and values on both the online and offline computer.
Online transactions (hot wallets): There is a remarkably narrow window in which a bit-flip could result in loss of coins. This could be mitigated with a secondary verification window after signing is complete.
Neither of these conditions hold true if you are assuming the possibility of multiple, perfectly-inconvenient bitflips. DRAM errors are so rare, that squaring that error and assuming that the two errors are perfectly correlated in the worst way possible -- is effectively impossible.
My justification:
Offline transactions: I can't enumerate all the possible times and places a bitflip could happen. But here's a few:
- Online computer creating the transaction, value or address: you catch it when you check the addresses and values on the offline computer (check every character!)
- Offline computer before signing: you catch it when you verify the address and value on the online computer before broadcasting.
- Either computer, after signing: signature breaks, tx is invalid.
Online transactions (hot wallets):
For this situation, a bitflip after confirming the outputs as correct, but before the system actually creates the signature, is the black swan event. But it could be caught if there was a second verification window that displayed the final, signed transaction before it actually broadcasts. At least in Armory, it is always re-parsing the raw transactions and displaying information from that parse. So, a check of every character of the output address both before and after signing would catch this.
The only other time I can think that this would be a real issue, is a bit flip in the address as it is sent to you by the other party. Perhaps their system bitflips the hash160 value pulled out of the wallet, before they even give you the address. That would be undetectible. But if you are moving life-changing quantities, of money, I'd always recommend calling and verifying every character of the address, anyway. That would catch bitflips after the transfer of the address (and technically the checksum should catch that, too).
Lessons learned: When executing an offline transaction, always check every character of the recipient addresses and values, both on the offline computer before signing, and on the online computer before broadcasting.
What am I missing?
P.S. - We could also just recommend that all systems handling large BTC volumes use ECC RAM. But I'm not convinced it's necessary for an online-offline setup if you do the appropriate checks.
Jump to: