There are at least two ways to store your Litecoin wallet on paper.

One way is using jackjack's version of pywallet with --otherversion=48 to dump all the private keys in the wallet. Make sure the client is not running when you run the script.

The easiest way, if you use a recent enough client, is to use the RPC calls getaddressesbyaccount and dumpprivkey.

One problem is that at present very few processors (Westmere, Sandy bridge, Ivy Bridge, Bulldozer) support the AES instruction set.
http://en.wikipedia.org/wiki/AES_instruction_set#CPUs_with_AES_instruction_set

I think the problem is that there's no way to tell if two blocks come from the same entity. We know the hashing power of pools just because pools make their numbers public.
Maybe someone will come and prove me wrong, but I don't think there's any sensible way to completely avoid the possibility of a 51% attack without giving up decentralization.

The good news, let me state this once again, is that even if one single entity has 51% of the hashing power it doesn't mean that this entity is going to use it to attack the chain.
On the other hand, it would be preferable if miners who want to mine in a pool took advantage of the many Litecoin pools that are available, instead of concentrating in one single pool.

I would try re-downloading the blockchain (or restoring it from a backup).

A higher global hash rate usually means a more secure network (assuming the hardware is not used against the network, of course).

Yes. It is much faster and more power-efficient.

No, it's a purely hardware thing.

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

I wouldn't say "highly" in absolute terms, but I do think it is much more ASIC-resistant (in terms of cost-effectiveness) than SHA-256.

In practice, an SHA-256 ASIC needs no memory at all. The non-negligible memory requirements of scrypt, on the contrary, make CPUs and GPUs more similar to an ideal scrypt ASIC, because fewer of their components are "useless" when it comes to hashing.
The simple fact that a scrypt ASIC would need to resemble more closely a CPU by having relatively large amounts (N * 128 kB) of random-access memory would, logically, make it more expensive than a zero-memory SHA-256 ASIC achieving the same speedup over existing CPUs.

I don't have much experience with FPGAs, but two questions come to mind.

1. How fast is this RAM? Is it fast enough to compete with the L2 cache of modern CPUs?

2. GPUs manage to compensate the lack of local memory by means of massive parallelization, but a lot of global memory is required to do this. If I'm not mistaken, this global memory usually consists of GDDR5 SDRAM, which is still relatively fast. Would it be profitable to make an FPGA with that much quality SDRAM, or would it be cheaper to just get a GPU instead?

Pools have their own threads on this forum.
The litecoinpool.org thread is here:
https://bitcointalk.org/index.php?topic=50946.0
You could also send me a personal message or contact me on Freenode, if you prefer.

Entering the txid above in the search box at http://abe.liteco.in/ took me to
http://abe.liteco.in/tx/e0346cbce045778a3562482f9475cf5f86c7139bc46a5de9e970e4d2c99cb071

Stupid question: did you try installing libidn via macports?
Also, what version of OS X are you running?

The short answer is: only for Intel Atom. Other CPUs running in 32-bit mode shouldn't see any significant difference in performance.

Nevertheless, all Windows users are encouraged to upgrade, because of point #2 above:

Version 2.2.2

• Modest speedups for all x86-64 processors, ranging in most cases from 1% to 3%; about 4% for AMD K8, and about 8% for Intel Atom.
• On Windows, thread priority is now set instead of process priority. This should solve most problems concerning system responsiveness.
• scrypt is now about 12% faster on ARM11.
• Fixed a bug that only made one CPU core accessible on Android.
• A new option (--background) is available to start minerd as a daemon on *nix systems.

The source code is, as always, available at GitHub. Windows binaries are available here. Please note that I have updated DLLs to the latest version of libcurl; older DLLs are no longer needed.

Thanks go to guruvan, xurious and aaa801!

That is the strangest thing of all, and even though I tried I cannot reproduce the problem. With or without long polling, with or without a proxy, I always get shares. It is possible that some of the shares are detected to be stale and are not submitted, but unless the server (or the proxy) is very slow to respond that shouldn't happen frequently. Try using the -D option to see if that is the case.

Now, let me try to make a list of the various errors that have been reported.

I tried mining at MaxBTC for a couple hours, but I was unable to reproduce the problem. I'll keep trying.

If we are to believe libcurl, this means that the connection was closed by the remote server.
I don't think there's much the miner can do to avoid the error, apart from silently ignoring it. Maybe I should consider doing that for the long polling connection?

Under "normal" conditions, data rewind shouldn't be needed: it is usually only necessary for resuming interrupted uploads or for multi-pass authentication.
I suppose the "Operation timed out after 30001 milliseconds with 0 bytes received" error is linked to this.
Implementing data rewind is pretty simple in our case, and cannot do any harm, so I will try to implement it and see if anything changes.

Pontius, have you tried disabling long polling to see if you still get the same kind of errors?

Pontius: regarding 503 errors, they must be generated by the proxy you're connecting through. I contacted p2k, the author of the ecoinpool software used by OzCoin, and he said that under no circumstance the server emits 503 errors.

That is the question.

Just for testing, I tried mining against eu.ozco.in through a public proxy server for a few hours, but I got no errors. At this point I wonder if this is an issue with the particular proxy you're connecting to. Is it a public one, or is there any way I could connect to it to do some direct testing?

I do not mean "hostile" as in "an ASIC would be inefficient". That would be just ridiculous, and I'm sure we both agree on that point.
What I mean is, instead, that the transition to ASIC mining would bring a smaller speedup than it would for Bitcoin.
Suppose that for Bitcoin you spend X to build an ASIC and you get a speed ratio of Y relative to CPU model Z.
What I mean by "hostile" is that to get the same speed ratio relative to the same CPU model you would have to spend significantly more than X.



Because the memory requirements of SHA-256 are virtually zero, and memory (the type of memory used for caches in particular) is not free.

Pontius, that's strange. I have briefly tested Bitcoin mining at OzCoin and BTCGuild and everything seems to work fine.
Do you get the error as soon as you start the miner, or only after some time?

By the way, I ignore what those pools' particular software mean by 503, but usually status code 503 means "The server is currently unable to handle the request due to a temporary overloading or maintenance of the server".

I would try running the miner with the protocol dump turned on  (-P flag), maybe that could provide some clue as to what's going on.

It is my understanding that, in terms of cost-effectiveness, scrypt can be regarded as relatively ASIC-hostile.
Of course you could design a fast (relative to a desktop CPU/GPU) ASIC for scrypt, but because of the memory requirements of scrypt wouldn't it turn out to be way more expensive than a fast ASIC for, say, SHA-256?

"--algo scrypt" is the default, you don't need to specify it. The "--algo sha256d" option was only added in version 2.2.



Well, to be honest I doubt RAM can affect the miner's performance. All the memory used by the miner should fit into L2 cache.

You are connecting to a Litecoin pool (lc.ozco.in) but then you tell the miner to use the Bitcoin algorithm (--algo sha256d) instead of the Litecoin one.
Please make up your mind.

It is important to understand that the --algo option doesn't work the same way as it did in the original cpuminer by jgarzik. In the original version you had a bunch of implementations of the same algorithm (SHA-256d) to choose from, while here you have two completely different algorithms, which are not interchangeable. If you try to use "--algo=sha256d" to mine Litecoins all you will get is invalid shares.