Just for the posterity:

You get hit by the per-i/o-operation charges on EBS volumes. Convert your system to use 160GB local disk available with the small instance and then the charges will be much lower. Also make sure you use the "Instance store" version not the "EBS-Backed" version.

The smallest has 160GB of the local storage. That is more than enough for couple of years. I/O to the local storage is free of charge. Just don't pull a bitomat.pl and don't store the backup copy of the wallet on the same ephemeral storage as the working blockchain.

That the people will plug it into their desktop, which actually sits under the desk or otherwise in a non-easily viewable place. Then they will blindly press the acknowledge buttons without really checking the display on the Trezor.

Outside of North America pretty much every household already has the required cable. It is a cell-phone industry standard charging and interface cable.

Exactly. Block should consist of: header,Merkle tree&coinbase transaction. All the remaining transactions should be transferred before the block. This "array of transactions" appended to the block is just an artefact of the awkward implementation and from the information-theoretic sense serves no purpose.

Well, not exactly. 200 is a wrong arbitrary number, 64 is better. And not multiplied by the number of transactions but by the size of the merkle tree of transactions.

Finally it is possible that the Merkle tree is just like a Christmas tree: a decoration. Plain old array of transaction hashes could be sufficient.

Only the cynical survive in the Bitcoin milieu. And your project just basically shows that you've neglected to consider side-channel attacks. How is anybody knowledgeable in cryptography supposed to believe that the random-looking text on your page is actually random?

I'm very curious where this project is going. I expect to learn a new way of harvesting the unsuspecting users of cryptography once the final site will be deployed.

What future? It is about sending information to Mr. TimeScramble. Mr. TimeScramble is in posession of special snake-oil that somehow obscures the information for the pre-selected amount of time.

Serve a subpoena on you or on Amazon and boom! instant travel to the future.

What is the point of this exercise? Besides the obvious: snagging the private keys from the unsuspecting public?

Yes, but nowadays they are considered high-end devices. The main market is secure printing of multi-carbon-copy forms. The impact printing process and ballpoint pen handwriting are difficult to forge and easy to discover forgery attempts, even using automated processing of optically scanned forms.

Edit: D&T made a good point about ribbons. I've never seen or used a dot-matrix or daisy-wheel printer with carbon-copy-paper ribbons. The ones I've used were all using woven-fabric ink ribbons that are impossible to read from unless you print only repeated patterns (which is not impossible).

Edit2: In addition to the insecurities described in the article linked by etotheipi there are another problems with multifunction devices: many of them have large amounts of memory that is made nearly-nonvolatile by a capacitor or battery backup. It could store hundreds or thousands of simple, text-only pages for later retrieval.

A cheapie printer used with the OS-provided drivers is probably the best choice.

For anyone who took an introductory course to database systems there isn't anything even mildly offensive or controversial. So you either never took any database courses or took one, flunked and now you are resentful.

In regards to the bit errors: the issue is error detection not error correction. It is a well known problem since around 2000, when the database systems started to be deployed on desktops and mobiles, no longer only on the server-class systems. This was also the time when the majority of the desktop systems no longer had even the parity error detection like the original IBM PC and clones. The silent, undetected corruption is such a widespread problem that most modern commercial database systems include in software page parity error detection and torn i/o detection (a closely-related problem with non-server class i/o subsystems).

Nowadays the situation is much worse: even the brands like Apple which formerly were beyond reproach now mass-ship the machines that reproducibly suffer bit-errors under load. Some modern game engines (yes, game engines, not database engines) include on-the-fly hardware error detection for CPU/RAM/GPU.

So the question still remains: which DB engine to choose? The answer is the same as for the old choice of cars: cheap, fast, reliable; pick two. I had a similar conversation in another thread and I managed to condense to a short soundbite that doesn't require computer science education and any MBA-type could understand it.
I recall from my school days the level of frustration we had with our professor who taught database systems. He always refused to straightforwardly answer the question about any concrete specific implementations. He would always talk about "dBaseXXVI", like the folks who don't like Sylvester Stallone talk about "Rocky 26". His test problems would involve tri-sex and quad-sex personal records to force the students to actually work on the problems and not just transcribe them from a textbook.

I cannot advise everyone to take an intriductory database course. But if you have just a couple of hours of time read this article from wikipedia:

http://en.wikipedia.org/wiki/View_(database)

If you take one thing from it: thanks to views the logical storage schema can be different than physical storage schema. With this klowledge you will be ahead anyone who hawks any single database choice.

The reality of Bitcoin could be summarized as follows:

1) nobody has any reliable data describing and modeling the access patterns for Bitcoin storage systems.
2) Bitcoin developers routinely work in a way that isn't representative of normal business operation: they constantly reload the blockchain from scratch. Any problem? Delete ~/.bitcoin/* or %AppData%/Roaming/Bitcoin and redownload everything.
3) people who try to run 24*7 Bitcoin services are at a serious disadvantage: they cannot do normal livedatabase backups; the filesystem snapshots they can make are not ACID and not internally consistent; database consistency cannot be checked while online.  More and more they find themselves in the situation where the troubleshooting resembles the old MS-DOS days: press Ctrl-Alt-Del, if that doesn't work, unplug the computer and plug it back.
4) even minimal storage schema tuning will show that storing blockchain in the raw on-the-wire format is far from efficient. There are three really disjoint data subsets in the raw blockchain:
4a) block headers chain or tree/trunk/orphan-branches
4b) merle trees, each used only once
4c) heap of transactions that could be extensively garbage-collected.
5) creating a separate database-loader tool for whatever blockchain representation you use is the most crucial task for the Bitcoin business operators.

ISO 639-3 szl? What is the probability that of the about half-million of the speakers of that language a handfull of them is on this forum? Is that somehow related to the fact that Bitcoin is mined and most of the people from Silesia were involved in coal mining?

You are doing this backward. If you have Visual Studio then start the Litecoin program under the debugger and it will point you to the problem which causes the crash.

Well, this stuff was discussed already a couple of times. It is my understanding that the consensus is that it would create more problems that it would solve. It creates a circular dependency: a transaction is valid/not-valid depending on the block in which it was included.

I don't think Bitcoin has an operator that pushes the blockchain height onto the stack. Could you briefly describe how would you implement that check?

OK, the phrase "divine design" is just so funny that I had to quote it for the future reference.

Luke-Jr is again posting about something that he has not even basic understanding: financial networks. This by itself isn't new.

But I think it is worthwhile to show that the classic credit card are using two messages per transaction: authorization and capture.

http://www.authorize.net/support/merchant/Submitting_Transactions/Credit_Card_Transaction_Types.htm

Typical self-serve fuel pump would use two transactions: the authorization to unlock the dispenser and capture one the dispenser is put back in the locked position. Physical store checkout stand transactions typically roll those two phases into a single compressed form.

Directly the above information has no bearing to Bitcoin. But the "payment protocol" is an area of the active development in Bitcoin. It would be great that more people understood how the typical payments work and think on how to translate them to the Bitcoin global broadcast network.

One thing is to prevent double-spends. But there is additional value to be gained from discovering who even attempted to authorize more spending that they really had available funds.

Thanks for the referral. I couldn't vouch for "Jesus-freak-repeal-factor", but it is indeed an entertaining sci-fi story. Fiii-Fuuu-Fiii...

The real GPU development on Raspberry Pi requires the Broadcom/VideoCore toolchain. It is only available through an NDA to the large-scale developers and Broadcom partners. It isn't open-source, it isn't even available for a normal purchase.

http://en.wikipedia.org/wiki/VideoCore

From the very limited public information about the VideoCore one can surmise that the architecture resembles the old Texas Instruments VLIW DSP chip TMS320C80 MVP (multimedia video processor).

Hit a plus sign that is to the right of the date and time, second line of the forum header, underneath the "simple machines forum" logo. The plus will change to minus and your missing things will reappear.

OK, I wanted to sumarize what happened around the time that the Litecoin was launched. I want to do this while I still have some recollection of the events and discussions that occurred on the IRC.

1) There was a period of alt-chain wars where various groups launched a slight or extensive modification of Bitcoin and the groups that tried to take those down.

2) There were two prominent competing groups in the history of Litecoin:

2a) ArtForz and BitcoinExpress group. Their first main contribution was the fix for the off-by-one error in the Bitcoin difficulty calculation and exploits for the coins that could be attacked with the so called "time travel" attack that relied on this bug (among other faults). Their second main contribution was a selection of Colin Percival's scrypt() algorithm and its parameters, which got included in Litecoin through Tenebrix and Fairbrix. The scrypt() parameters were meant to be make GPU mining impossible, but they turned out to just within their outer limits of possibility. But that discovery was made by the other group and the this group GPU-mined the scrypt() coins only after the other group published their code. 

2b) RealSolid/CoinHunter group. Their main contribution was funding the developer "mtrlt" to develop "reaper": a GPU miner for both coins based on scrypt() (as an attack) and SolidCoin (as a defense). The GPU implementation of scrypt() from the "reaper" was later added nearly verbatim into the popular cgminer Bitcoin mining software.

3) Neither group succeeded at causing massive damage to the coins of the other group.

3a) SolidCoin adoption stalled due to erratic behavior of its lead developer.

3b) ArtForz got preoccupied by maintenance of his Bitcoin mining operation with FPGAs and metal-programmable structured ASICs. First, he stopped getting involved in the scrypt()-based coins he co-created and then he ceased to publicly participate in discussions anywhere.

Please feel free to quote me and make the corrections that you think are required to make this historical account reasonably fair and accurate.

Thanks.