Your node software is fine.  But you will never generate a block with that card.  Best to join a pool.

My solution to the headless operation was to set a watchdog that can reboot the server if shares stop coming in.  In my experience, when shares stop coming in, the problem is that the box is locked up solid, beyond the help of SSH.

It isn't easy because of the gigantic amount of resources necessary for the attack.  For example, you could not purchase enough hashing power today to do the attack, because it does not exist in the world in purchasable form.  I would even say that there is only one government in the world that would even have the potential ability to confiscate enough hashing power by sending armed troops into peoples houses and stealing their video cards.  Someone would notice that.  It would require months or years of gathering resources, all while the network is growing, and even a slow acquisition would likely be noticed.

And it isn't useful, because your payback for spending all of this time and money gathering hashing power is the ability to turn back a few transactions.  What possible transaction would you reverse that was worth your 50 million dollar investment?  Keep in mind that as the value of future transactions grows, so will the cost of doing the attack.  Right now you would need to own roughly a quarter of all existing bitcoins, and spend all of them within the attack window, to beat the cost of your investment.  That ratio will probably change somewhat in the future, but the attack will never make sense unless you already control a non-trivial fraction of the bitcoins in the world, and can find enough victims to accept all of them in a short period.

And that other thread you link isn't about this sort of attack at all.  It is about difficulty and price manipulation.

And again, exponential difficulty can make these attacks even more costly.

You should start with more research about how bitcoin works.

After that, if you are still interested in the data, google "bitcoin block explorer".

I had to read this several times, and I still have no idea what you are trying to do.

I think it really just boils down to a really convoluted way to move dollars around.

Maybe you should write down a step by step description of a transaction.  Identify each of the participants in the transaction, what they are holding and exchanging at each step, etc.

This is how I see it happening.

You pull out your Visa or MasterCard, swipe it and the merchant waits a second for confirmation.

In other words, a third party will handle the transaction risk, just like now, but the accounts involved will be denominated in BTC.

That's not what fractional reserve is.  Not even close.  Today, a bank makes a loan first, and then seeks new deposits to cover between 0% and 10% of it.

And yes, the central bank is exactly what makes this scheme possible.  Fractional reserve lending wasn't created in 1913 when the Fed came online, but it did explode around that time.  The whole point of the Federal Reserve System was to set up a bank that could create money at will and lend it to other banks when necessary.  Bank runs simply do not happen now because the Fed can step in with an instant loan and prop up any failing bank.  FDIC stepped it up another notch, but that is a different topic.

It isn't really the length of the message.  It is the salt for the padding.  That just happens to be the size of the message.  See FIPS180-2, section 5.1.1.

The spec calls for a 64 bit value of the length of the message in "a binary representation".  Intel's crazy-endian is what we ended up with here.

I'm not aware of any physical shops currently accepting bitcoins.

There are two versions of the 51% attack, and I have made proposals that would address both of them.

The first is the live attack, where an attacker starts working on the next block, and publishes it as soon as it is ready, and then keeps doing so even while the honest network finds blocks that reveal the double spend, causing the chain to flap between the two branches.  This is of limited value, as it would be very visible, and the attack window would be very short, like 10 minutes to an hour, depending on the actual hashing power of the attacker.  I proposed chain flap dampening, but I'm not sure any more if there is any point.

The second is the dead attack, where the attacker starts working on a new chain, but doesn't publish it until it is very long.  At this point, the transaction the attacker wants to reverse is deep in the chain, and considered very safe by everyone, but since the new chain is longer, it will reverse everything after the start of the attack.  For this one, I proposed exponential difficulty for a deep block chain reversal.

Oh, and by the way, neither of these attacks are anywhere near as easy, nor as useful as popularly imagined.  And we really have read 100 threads on the topic.

Nonsense.  The Federal Reserve System was created in 1913, and enabled all of the banks to take fractional reserve lending to the next level by not having to worry about bank runs.  The inflation caused by all this fractional reserve lending meant that the gold standard was effectively dead.

If you have inflation, you do not have a gold standard.  If you have the gold standard, you do not have inflation.  These are definitions, not arguments.

What they did was pretend that they had a gold standard, while they actually inflated the currency.  Another name for this practice is "lying".

Ahh, good point.

If order doesn't matter, I'm pretty sure it'll just be a binomial distribution.

Yes, but the transactions from the legit chain will now show up, and people will learn of the attack.  And the exponential difficulty rise means that the attacker has a short window to launch his attack, even with unimaginable amounts of hashing power.

A person waiting for a really big transaction can wait something like 30 blocks, and know that unless the attacker has 33 million times as much hashing power as the rest of the planet combined, that transaction will never be reversed.  A day or two would put the attack outside the power of an entity cable of using every particle in the entire universe for his hashing machine.

The chance of no matches is what's left, 38880 out of 46656 (6^5 in 6^6) or ~ 83.333%.

Either your simulation, or your description of the problem is wrong, they don't match.

There are 6^6 possible lists for each party.  The second party's list doesn't matter at all.

6^6 = 46656.

One of the lists matches all six in the second list, so that chance is 1 in 6^6 or 1 in 46656 or ~ 0.0021433%.

Six (6^1) of the lists match in at least 5 places, but one was the answer above, so 5 in 46656 or ~ 0.010716%

Thirty six (6^2) of the lists match in at least 4 places, but 5 matched in 5 places, and 1 matched in six, so 30 in 46656 or ~ 0.0643%

Two hundred sixteen (6^3) of the lists match in at least 3 places, but 36 matched more, so 180 in 46656 or ~ 0.3858%

1296 (6^4) of the lists match in at least 2 places, but 216 already matched, so 1080 in 46656 or ~ 2.314%

7776 (6^5) of the lists match in at least 1 place, but 1296 have already matched, so 6480 in 46656 or ~ 13.88889%

I hope that better explains where all the minuses came from in my first post.

I wouldn't mind taking a look too.

In question 6, for example, would lists A1,A1,A1,A1,A1,A1,B1,B1,B1,B1,B1,B1 be equivalent to A1,A2,A3,A4,A5,A6,B1,B2,B3,B4,B5,B6 for your purposes?

If so, each party will pick one of 6^6 lists, and the other person's choices don't matter, so the chances are 1 in 6^6.

Moving on to question 5, there are 6^1 ways to pick a list that matches in at least 5 places, but one of them is the answer to #6, so the chances are 1 in 6^5 minus 1/6^6.

In question 4, there are 6^2 ways to pick a list that matches in at least 4 places, but some match more, so we have to remove them again.  So, 1 in 6^4 minus 1/6^5 minus 1/6^6.

Question 3, 6^3 possible, minus the extras, so: 1 in 6^3 minus 1/6^4 minus 1/6^5 minus 1/6^6.

Q2: 1 in 6^2 minus 1/6^3 minus 1/6^4 minus 1/6^5 minus 1/6^6.

Q1: 1 in 6^1 minus 1/6^2 minus 1/6^3 minus 1/6^4 minus 1/6^5 minus 1/6^6.

If you have X% of the global hashing power, your probability of keeping ahead of the rest of the network for Y blocks is X^Y.  It vanishes quickly unless you have a huge amount of hashing power, like 95% or more.  That means 20 times more than the rest of the world.  Also, a realtime attack would be very obvious, and could be handled by flap damping.

This is for the attack where they start working, but don't publish their alternate chain until they are far in advance of the rest of the world, effectively reversing all of the transactions in many blocks at once.

Was bitcoin still running when you tried the dump?

If we switch to an exponential difficulty requirement for chain forking, we can amplify the requirements for this type of attack and move it from "incredibly difficult" to "nearly impossible".

http://forum.bitcoin.org/index.php?topic=11464.0