I have also heard about this "stoned" virus in the block chain.  It looks like some prankster added the virus signature to a transaction to cause false positives.  There is no way the stuff in the block chain can get executed, so you don't get real virusses this way.

Anyway, the "stoned" virus can only run on really ancient DOS machines.

Armory depends on Bitcoin Core having the full blockchain.  On some platforms Armory can even "seed" Bitcoin Core with a newer version of bootstrap.dat than the one usually used by Bitcoin Core, helping significantly on Bitcoin Core's startup time.  But since Armory also has its own database, you unfortunately end up with two copies of most of the data, and once Bitcoin Core is up to date Armory needs to build this second database, which also takes some time (but is faster than Bitcoin Core's startup).  Running Armory requires significant disk space. 

You cannot pull an app from some storage device (including a disk image using for distributing software or a .zip file) directly onto the dock.  The dock only contain links to the actual programs in /Applications.  Pull the program onto the /Applications folder, and then pull it from there onto the dock.

The .5 version fixes a missing QtNetwork framework on the Mac.  Seems consistent.

http://www.reddit.com/r/BitcoinDK/comments/21en2y/den_oprindelige_afgørelse_fra_skatterådet/


Edit: OK, så bitcointalk kan ikke klare et Ø i en url, prøver at rette.  Teksten er her: https://www.facebook.com/BitcoinDK/posts/10202461070862014

Så er indtægten temmeligt sikkert skattepligtigt.  Men hvis du gemmer bitcoinsene og kursen ændres, er kursgevinsten/tabet ikke skattepligtigt/fradragsberettiget.  Sådan læser jeg det.

Men hvad hvis man ikke er en virksomhed, men en privatperson som købte en håndfuld bitcoins og har tjent på dem.  Er det så stadigt skattefrit?  Skatterådets svar virker ret specifikt, og jeg ved ikke hvor meget man kan generalisere.  Er der en jurist (eller juridisk kyndig) til stede der kan svare på det?

Cool!  I think I will wait a bit before upgrading the offline machine and the offline wallet - after all, you have often been saying that it should be pretty safe to use a bleeding-edge online Armory as long as the offline one is a well-tested version, as that would catch any coin-losing bugs.

But great to see you have added this!

And they are resending SMSes and emails about old transactions - this is probably what freaked out the OP.

Interesting!  Once you have integrated that into a reasonable safe release I think I will make a new offline wallet (with the new Armory on the offline computer) and transfer everything - just to be safe against future attacks against undiscovered bugs in /dev/random.  Yes, I know it is paranoid...

I think OP has a valid point - I would be much more worried about an unknown bug in /dev/random being discovered, and allowing people to later brute-force Armory wallets en masse than I would be about malicious printers or USB-stick firmware virusses or some of the other in my opinion pretty unlikely attack vectors that are being addressed by Armory.  The attacker would not even need access to your machine!  What if I created an offline wallet on a Raspberry Pi and Raspbian is later discovered to have a flawed /dev/random?  Suddenly, all my funds will be gone.

I understand why you do not want to add an alternative source of entropy in the GUI, people will use it to generate bad Armory brain wallets.  But what about a source of supplementary entropy?  I can type in "correct horse battery staple" and it is SHA-256'ed and combined with /dev/random.  Even if my extra passphrase is lousy (as in my example), I am saved by /dev/random.  And if /dev/random is partially compromized, even a mediocre passphrase entropy-phrase may save the day, and a good long one certainly will.

Only risk: The user confuses this with the encryption passphrase - but maybe you can just use the encryption passphrase as the extra source of entropy for the seed generation, in addition to /dev/random.

I hear the blockchain is useful for that kind of time stamping.   

Can someone please point me to some information about this weakness?  What is the problem with SSL in relation to bitcoin, and how does address reuse affect it.

This is very good advice.  Bad RAM is more common than one should think, and causes all kinds of symptoms.  memtest86 will usually find it, in particular if left to run overnight.  Usually, it just confirms that the RAM is OK, but then you don't have to worry about that

And who "initiated" the trade?  The one who posted the limit order (the first to act, one possible meaning of initiating), or the one who takes it and actually cause the trade to take place?

There *is* a backup option in Armory, just click on a wallet and then click on Wallet Properties.

On that screen, there is also an option to import private keys.  However, be aware that not all of the backup options also include the private keys, in particular the N-of-M paper backup does not.

There are two rules.  The one for what it takes for a transaction to be build into a block, and one for what it takes for a transaction to be propagated.  If you run afoul of the first rule, your transaction is likely to sit in the network for a while, but eventually it will confirm.  If you run afoul of the second rule, the transaction will never even be accepted by the network and will *never* confirm.

Just ignore it.  blockchain.info seems to be broken, that has no relevance for your transaction.  Blockchain.info is just one of many tools that allows you to examine the state of the "real" bitcoin block chain, and this particular tools seems to have a bug.

If you just received or moved the coins, then a tx fee is necessary, otherwise the network will refuse to propagate the transaction.  I think the age of the coin multiplied by the size should be 1 day or something like that.

Armory refuses to make a transaction that bitcoind or bitcoin-qt would refuse to propagate.

Normally, it says 0 blocks.  0 and False are different object in Python, although they both have the truth value false.

If it says False blocks, then it could be a symptom of something returning False as an error condition.  Sounds strange.