You need to identify the character set used to encode the password. It may be different than the character set used to encode the font displayed by the terminal program and different from the character sett used to store the text of your program in a file.

http://en.wikipedia.org/wiki/Western_Latin_character_sets_(computing)

Those are your basic choices. Note that the Unicode column can have several different encodings:  UTF-7, UTF-8, UTF-16LE, UTF-16BE or UTF-32 (unlikely, but possible; and it still has big-endian and little-endian variants).

Good luck.

Thanks for the explanation. I think such a DoS would/should trigger the "misbehaving peer" defense that is already implemented in the Satoshi's client.

I see still the majority of developers considers the block verification as sort of a race that happens after each block gets broadcast. I consider it the implementation artefact in the proof of concept code. Both from information-theorethic and game-theoretic point of views the block should only refer to the transactions that were already broadcast and are normally verified with at-a-leisure speed during the inter-block period.

I'm not really familiar with game theoretic methods of system analysis. I'm way more comfortable with hierarchical control systems methodology, where the nodes intent to honestly cooperate but have limited information about the state of the whole system or various resource limitations in internal processing.

I'll be watching the evolution of this problem with great interest. Maybe someone has some game-theoretic attack hidden it their sleeve. Or it may turn that this is just a problem in industrial and organizational psychology, where the hard-scientific reasoning have to take the backseat.

Spartan-6 memory controller blocks are designed to control single memory chips, not multi-chip memory modules. There are 4 memory controller blocks in each Spartan-6, but depending on the package not all are connected to pins.

While it isn't impossible to build a memory-module controller from the regular Spartan-6 logic blocks, such controller will be inefficient and slow. In the Xilinx product line only Virtex FPGA can directly interface with multi-chip memory modules.

BTW, bitfury is very busy with his 55nm Bitcoin ASIC project:

https://bitcointalk.org/index.php?topic=140366.msg1641318#msg1641318

I still don't get it.

"My block" consists of (1) header (2) list of hashes of positively verified transactions (3) coinbase transaction. "My block" is the shortest, so it actually has a propagation advantage over the "legacy blocks". "My nodes" don't hide the transactions, they undertake to distribute them as widely as possible before the "my block" gets broadcast. All the nodes operating through "my protocol" have plenty of time to verify the early broadcast transactions and just need to store in the RAM the hashes of positively verified transactions.

The "legacy block" format allowed hiding the blocks from the p2p network by not broadcasting them and disclosing them late at the end of the block. Hence the "block verification" overhead came from and allowed to play the deception games.

The way I see it the "my block" is beneficial over "legacy block" both in the information-theoretic sense (nearly halves the network load) and in the game-theoretic sense.

BTW. "my block" isn't really mine. This optimization was openly discussed after the publishing of Microsoft's "red balloon" paper.

The only game-theoretic advantage that I see for the "legacy block" is that by being "legacy" the code doesn't need to change and the people who memorized the source code of Satoshi's client have an advantage over the developers new to the Bitcoin. If the hard-fork is allowed that advantage is nullified. What else am I missing?

Which branch of computer science postulates that? Transactions arrive nearly randomly during the inter-block period, so the mean time available to verify transaction is about 5 minutes.

What is going on here with this "in-RAM database requirement"?

Edit: I mean the only new transaction in the block is the coinbase. Every other transaction should be already broadcast on the p2p network.

Are you trying to preserve some artefact from the Satoshi's implementation? From the computer science point of view the array of transactions appended to the block is pure overhead and redundant.

Or maybe there is some sort of game-theoretic advantage to broadcasting the transactions as late as possible? I'm not aware of any, but I haven't put much thought into the game-theoretic aspects of this concept of hiding the transactions from the other miners. To me it seems counterproductive globally.

My comment was not about the code but about the code development workflow. Anyone can make a mistake, c.f.
I was just not aware that the problem is so prevalent, that so many people developed such a dependency on build automation that they are incapable of building without it.

It used to be that Microsoft Outlook promised increased productivity by allowing office automation. It ended up with security consultants training the cubicle monkeys to avoid clicking on the e-mail attachments.

Then there was Visual Basic and certain VB programmers for whom any project could be improved by downloading some random ActiveX control from some random web site.

I only just yesterday realized that I've already encountered one such situatuation where the SAP/Netweaver/Java deployment was trojaned. I normally don't do sales calls, but in one unusual situation I've met with a prospective clients after a "security event". They asked if we use "Maven, Netbeans, Eclipse" and were very happy to hear that all our developers are comfortable working with "vi or emacs and our own tools". I didn't pay attention to their secuirity consultants talk about "advanced persistent threats" or some such.

So the summary is that Visual Studio, which I sometimes call Visual Straitjacket has one significant benefit: it makes somewhat more dificult to trojan a whole dev-team using automated dependency collection.

I'm sorry for the off-topic post: it has no relation to Gnutella, but it is related to the security of the build process.

So that's how they trojan the enterprise resource planing systems! I've seen and heard of some deployments getting trojaned through the internal development departments. I thought that it was some sort of more advanced exploit. But all it takes is some lazy-ass Java code-monkeys that press the "collect dependencies" button in their IDE!

Thanks. Very usefull knowledge, that I was completely unaware of. I always thought that it requires some click-on-the-email-attachment social engineering trick. But it is through the click-some-button-in-the-IDE, no need for social engineering, the engineers are already conditioned for brainless clicking.

Thanks again.

The number of locks required depends not only on the number of transactions in the block (N) but also on the size of the blkindex.dat (S). Even if you have a fixed upper limit on N, the S grows without an upper bound.

The most common requested lock is "read with intent to write". As the process descends down the B-tree it takes one of those locks for each page traversed until it reaches the leaf page. Then it promotes the last lock to the "write lock". So the number of locks required to insert single Bitcoin transaction is O(H) where H is the height of the B-tree. This is turn is O(log_b S) where log_b is number of k,v-pairs per page of the B-tree.

So for a single database transaction which consists of all Bitcoin transactions in the block the number of locks required is O(N * log_b S). This number has no upper bound, it logaritmically increases with the size of blkindex.dat.

I'm sorry I can't give a good reference. It is in some of the Springer's series "Lecture Notes in Computer Science", something related to concurrency and deadlock detection/avoidance in database systems. The only thing I remember now is that was one of the thickest LNiCS volumes on the whole shelf with LNiCS.

On one hand this is true. On the other hand the core development team will do everything to make sure that this doesn't happen. Please see the posts of gmaxwell regarding Stratum & Electrum (not to be confused with Stratum mining).

Dream On!

bitcoind is a functional subset of bitcoin-qt: check the function ThreadSafeAskFee(). The version with the UI actually asks and allows yes/no answer. The noUI version always answers yes.

This design mistake is called "inversion of control" and it cannot be easily fixed without significant rearchitecting of the software. It has been discussed several times on this forum, search for "inversion of control". Many people proposed totally unworkable solutions because they didn't understand the difficulty of dealing with the described problem.

Whatever you do, just leave the "set_lg_dir database" line in the DB_CONFIG file. Otherwise you will not be able to use "db_stat" and other Berkeley DB utilities to debug the problems in the future. And then you will be back to being like the Bitcoin core development group: debugging blindly at the lowest level and trying to run the utils will corrupt the DB environment because log files were inaccessible.

Or man up and move the log files up one level from the "database" directory. Then the utilities will work correctly without the configuration file.

Have fun.

Chillax, dude. Your emergency patch is already available:

Mircea Popescu, to see how much support he has. Actual-support as opposed to PR-support.

The "manual tweak" is exactly two lines. Anyone can apply it, because the recompilation is not necessary. All it takes is to create a short text file and restart the bitcoin client.

https://bitcointalk.org/index.php?topic=152208.0

Edit: I'm including the fix here because some users can't easily click through with their mobile browsers:

Just create the file named "DB_CONFIG" in the ".bitcoin" or "AppData/Roaming/Bitcoin" directory that contains the following:

Thanks. Unfortunately this is still a flash drive with RAM cache and still susceptible to write amplification abuse. Thus far we haven't found anything better than discontinued ACARD ANS-9010 (64GB with battery backup) and some other custom-made solutions.

Just create the file named "DB_CONFIG" in the ".bitcoin" or "AppData/Roaming/Bitcoin" directory that contains the following:
The default was 10000. You can monitor the lock usage using "db_stat -e". I've tested it on an old laptop with 0.3.24 and 0.5.0. Obviously it will work with alt-coins based on the Bitcoin & BDB code. The same file should go into the respective "testnet" subdirectories.

Please don't omit the "set_lg_dir database" line. Without it you may corrupt the "_db.00?" and/or "log.*" files if you are unlucky and run the Berkeley DB utilities like "db_stat". With this line you will at worst get the error message from those utilities.

Good luck.

Edit: Oh, I forgot about the most obvious or non-obvious: restart the bitcoind/bitcoin-qt.

Please pardon me for jumping in, but please post the links to those overpriced hardware RAM drives. My friends in IT operations are on the market and have hard time sourcing devices that don't wear out are reasonably non-volatile and can survice reboot/reconfig/reload of the OS.

At a wrong angle that either requires people to tilt their heads to read the USB device screen or worse, encourages people to put tension on the connecting interface to tilt the keyboard itself.
Trezor is USB-only powered and once you disconnect USB it resets itself. You, personally, may not need Trezor at home. Their target market consists of people like cypherdoc, who aren't even aware that their home/office machines are infected by malware.
What you call "harping" I call "market information". Outside of the USA/Canada the nearly all USB interfacing/recharging solutions consit of a power plugin that has a female USB-A connector and an USB-A to Micro-USB male/male cable. Even for the USA market the cheap $19.95 prepaid cell-phones are sold with the solution I described, not the one you pictured. In addition to the above the Micro-USB connectors are designed for up to 10,000 cycles of insertion and removal, compared to 1,500 for the standard USB and 5,000 for the Mini-USB.

Listening to the customers whims has only so much value. Good reliability and human-factor engineering gives more value long term, even if short-term some segment of the prospective customers gets offended. It is just a good business. I'm sorry that you feel offended by my post. I actually consulted a little for a personal medical device project that selected the same connectivity solution as the Trezor after spending 5 figures USD for the market research and ergonomics testing. I'm happy for our Czech friends to arrive at the same solution at the cost of a box of candy bars. In the medical field there is a big concern about liability for creating procedures that are prone to errors and omissions. Again, I'm glad that the Czech team came up with the solution that forces people to sit down and concetrate on the task at hand when operating their device. They wont be liable for the mistakes of the scatterbrains in the strict legal sense, just in the PR sense.

Edit: Since cypherdoc decided to utilize Streisand-effect, here's the link to the relevant thread about malware on his machine. As of the time of this edit it still has the screenshot of the infected browser's window.

https://bitcointalk.org/index.php?topic=141448.msg1516165#msg1516165

Basically bitomat.pl administrator didn't read the AWS documentation. He tried to upgrade his instance which triggered erasing of the ephemeral storage and EBS volumes not marked persistent. Only his trading database files that were on a separately attached volume survived. He even purchased the Platinum-level support from Amazon, because he didn't believe that Amazon really throws away the encryption keys to the customer's data when the contract is closed. Mt.Gox acquired bitomat.pl and made customers good on BTC deposits, PLNs weren't affected. Mt.Gox still uses Polish bank relationships established by Bitomat to operate in the SEPA zone.

Recent EC2-related thread in the Newbie zone:

https://bitcointalk.org/index.php?topic=151640.0

Reboot doesn't erase the ephemeral disks. Stopping (by you or by Amazon due to hardware failure) erases the ephemeral disks.

I see no point of storing blockchain and IRC logs on EBS. You pay both for space (per GB) and accessing it (per I/O). Blockchain is easily replaceable, store it on a local disk where both space and i/o are included in the price of the instance. IRC logs should be compressed and stored in a way that makes them hard to accidently erase or alter. So store them in Amazon S3 or RRS or Glacier.

Basically you'll need to set up a sensible backup schedule for your instance. Use the ec2-make-ami as a backup until you'll learn how to properly operate everything and make minimal backups.

You can also have both local and EBS storage attached to your instance and size the EBS appropriately to the task, the smallest volume is only 1GB. You can have both combinations: boot from local disk and attach EBS or boot from EBS and attach local disk. But your first investment should be to read the available documentation, the pricing plans and the invoices you are getting.