This part of the code doesn't even run when doing the decryption. It has nothing to do with the problem. The code you need is in Bip38KeyPair.cs.

Anyway, doing SHA256 on the entire input range takes about 100 seconds, so that's more or less what you could save (out of decades) by offloading such calculations (if they exist).

Perhaps for the first clue casascius will say if the password is random or meaningful.

Modified your software into a script that tries all combinations...

Then realized it will take 36 years to run.

So a much more efficient calculation method would be needed.

You can always attempt to double spend, and your chance to succeed depends on your hashrate and the number of confirmations the receiver waits for. With >50% you always succeed (given enough time) no matter how many confirmations are used. With <50% you can fail. With 10% you have some chance if the merchant waits for 1-2 confirms, but with 6 confirms you'll almost certainly fail.

1-confirm txs are practically safe because there aren't many people with 10% hashrate. But if you receive a 10K BTC transaction you'll want to wait for more confirms, depending on how much hashrate an attacker is likely to have (and again, if he has >50% all bets are off).

That's not how it works. 6 confirmations is considered secure because someone with 10% of the hashrate has a tiny chance of catching up from 6 blocks behind. It doesn't matter how much time each block takes because the relevant process is non-temporal. Assuming sustained 10% attacker hashrate, 6 confirmations in Litecoin is as secure as 6 confirmations in Bitcoin. This is clearly explained in Satoshi's paper.

But yeah, it's not a significant feature, for other reasons.

Looks correct. There are a few things to nitpick but they are acceptable for pedagogical purposes.

One thing however I think is simply not true: "The block chain is stored in a Merkle tree data structure" - the transactions within each block are stored in a Merkle tree, the blocks themselves are not.

I can't reproduce, for me it works on both. Though strangely, it now takes 10-20 seconds to load, earlier it was faster.

For the purpose of researching the Quantitative Analysis of the Full Bitcoin Transaction Graph paper, Adi Shamir and Dorit Ron have parsed the blockchain data, put it in a query-friendly database and built some tools to analyze it.

The particular metrics they have so far chosen to extract from this data, and their interpretation of them, have been the subject of some criticism. However, now that they have this infrastructure for analysis, they would like to leverage it to analyze more useful metrics.

They are asking the Bitcoin community - what information do you want to try to extract from the transaction graph?

In Hebrew it is usually simply transliterated as ביטקוין.
There is also a translation of sorts, transliterated as "Matbit", and written מטביט or מטבית.

Given a transaction, what methods exist to detect which of the outputs is most likely to be the change?

How do different clients choose the order of the outputs? Assuming no order information can be used, what kind of other heuristics can be used?

We can assume that no custom anonymization techniques are used. Among other things it means that there will be at most 1 change output.

Looking at some transactions I've made, it looks like Bitcoin-qt always puts the change first, and blockchain.info MyWallet always puts the change last. Do they consistently do so? What about other clients?

Some suggested heuristics:

1. In sendmany, if the outputs have simple integer ratios between them, the transaction is likely to be some proportional distribution, and the one output which isn't an integer multiple of the GCD is the change. Example: In this transaction, all outputs are a multiple of 0.01648442, except for the change.

2. Change outputs are likely to have more decimal places (or be otherwise more complicated). Example: In this transaction, 114 is the real transfer, while 7.527 is the difference which has 3 decimal places since that's what the input had.

3. (Assuming no anonymity-targeted coin selection): The change must be lower in value than all inputs (otherwise that input would not have been selected). This is especially useful for transactions where multiple coins are combined.

4. Transactions involving addresses known to belong to some service can have their own rules to be deduced on a per-service basis.

Any other suggestions?

Just in case you're unaware - the first ever Bitcoin block is block 0, and the first block with a reward of 25 BTC is 210000.

When people mention microtransactions (or instant confirmation) I tend to refer them to my Trustless, instant, off-the-chain Bitcoin payments suggestion, which I believe is a foundation for solving both problems. Given this I have no qualms saying Bitcoin supports microtransactions.

Hm, I never thought of this. I guess this is solvable in a color-friendly alt; it would have a mechanism to associate a colored output with an uncolored output that will pay upkeep on its behalf.

I'm not sure this is a great idea. With such a list. If you know someone's email address you can know his number of bonds.

What's worse, even without knowing someone's email address, you can sometimes find his email address and the number of bonds. Emails don't have that much entropy and SHA256 is fast. With a GPU working the case you should be able to deanonymize many of the claimants.

Bitcoin addresses also have very little entropy once they're in the blockchain. Once those addresses are paid by anyone, you can run over all 7M addresses and match them to the hashes.

The Bitcoin address - shares association is likely to become public knowledge anyway. The Email - Bitcoin, however, shouldn't be, and the way this list is written it makes it easy to find in many cases.

Yes. As I said BFL has chosen to trade in these devices at their original ticket price. This has nothing to do with what those devices would trade for in the secondary market if it weren't for these upgrade plans, which is what I was talking about in the last few posts. Nor does it have anything to do with the output generated from them until the upgrade.

I've already addressed all the moving parts here and have suggested a "fair for everyone" solution (keep it separate until the upgrade, upgrade each at the trade-in value).

I imagine that new paragraphs would have two line breaks. So what about replacing double line breaks with a temporary character, removing all line breaks, and replacing the temporary character with a line break? Then every paragraph would be in a single line.

Would it help to obtain the original TeX?

I know and mentioned it in the OP. The problem is that as far as I know it doesn't do anything salient when the halving arrives.

I don't consider this a desirable feature.

Party goers may find the block halving party countdown useful.

You're welcome. I guess I made some kind of record then

Sadly the problems are far from over as most bondholders still haven't been paid. I hope Nefario can provide more data soon.

Coupon payment for blocks 201935 to 209327 was sent to bondholders in Nefario's first list. 0.0164844138 BTC per bond were paid to 6943 claimed bonds, for a total of 114.45128549 BTC. Transaction is f69173bf19362f7aff12081e41f119fd30b4e43bb39f837c1274e67bedf4915d. The change address is 1JPFCUtH2gcADar9xi3A9vStTr9Ba5XKvy. (Note: One payment address was changed at the signed request of its owner.)

Now we wait.

Yes, skipping large blocks of text that remained the same. Something like molecular's diff. PS myself I know what changed, but other people may be interested in clearly seeing the improvements.