+1 for amusement value.

Onkel Paul

Why do you think ASICs will be obsolete in 2014?
Currently I don't see a technology that could replace them (of course newer ASICs that are built with denser structures will provide some more bang for the buck).

The next technology that could in theory make ASICs obsolete are quantum computers. But I don't see them around the corner, at least not models that could hash Bitcoin blocks.

Of course there will be many people who bought ASICs and realize that they will never get enough ROI.

Onkel Paul

That's perfectly reasonable (and I wasn't questioning your reasons but the OP's reasons).
People can do whatever they want, I don't care much about their reasons.
But I do care (or rather, I am wondering) when people are inconsistent.
If I want to play a risky game, I have to accept that I could lose or that someone cheats on me.
If I don't want to be cheated, then I choose a safe game (escrow, atomic transactions etc).
So if I want to buy XRP with BTC, I could risk trading with someone who offers an exchange rate that is too good to be true, or I could go through a gateway who would risk their reputation if they scammed people, and use the market within ripple.

Onkel Paul

I know.
But if you don't want to deal with IOUs or don't trust a BTC gateway such as bitstamp or dividendrippler you just shouldn't deal with ripple.

Onkel Paul

Sent one as well (noticed the other reply only after that).
Enjoy :-)

Onkel Paul

What I don't understand is why you didn't just trade on ripple. You would have gotten only ~6000 XRP for a BTC, but as the transactions are atomic, there would have been no risk involved.
Even if you think that 1BTC for 6000 XRP is too much (I would agree with that) you should be asking yourself why someone offers to sell 8000 for 1 BTC when he could get 1.3 BTC for his 8000 within ripple...

Onkel Paul

Sorry, this probably won't happen - I'm not a C++ programmer, and my rather limited spare time is already devoted to some projects... :-(
But good luck in getting things done!

Onkel Paul

Thanks, that's generous - forum advice is normally free :-)

POP3 sadly is a totally different beast - unlike some other line-oriented protocols such as SMTP, NNTP or FTP, they have a different command/response structure. In particular, it depends on the command that was sent whether the client can expect a single-line or multi-line response. However, parsing the responses is pretty easy in POP3: The first response line always starts with +OK or -ERR (additional text can follow, a client should not interpret that but it can give useful additional hints during debugging).
If a command expects a multi-line response, the server sends a line containing just a single period as the last line. The client should check the first character of each received line, if it is a period but there's more stuff in the line it should drop the initial period (the server can use this to escape lines containing a single period). This is basically the reverse of what SMTP does in the DATA command.

I found the RFCs for these standard protocols to be pretty readable. POP3 is described in http://www.ietf.org/rfc/rfc1939.txt.

Onkel Paul

One other thing I noticed: although you're talking to a local server that most likely will not try to exploit your SMTP client, your code is just asking for buffer overflows. Never read a line of input into a fixed-size buffer without giving a buffer size limit!
You can of course interpret the delays as a kind of "greylisting" to limit the usefulness of the interface to spammers, however, this looks a bit like defensive post-hoc reasoning.
Handling multi-line responses in SMTP is really simple: every SMTP response starts with a 3-digit code. After that code you always have a space (which indicates that the response is finished) or a hyphen (which indicates that this is a line of a multi-line response, and more lines should be read).

Onkel Paul

Well now you have unnecessary 1.5 seconds per SMTP command instead of unnecessary 5 seconds...
A timeout value does not mean that you need to wait that long before looking at the server response, but that you signal an error if you don't receive a server response within that time. If you get a response before, just continue.
So the problem is most likely in your SMTP client's timeout handling.

Onkel Paul

Bitcoin as it is does not need such a rule - I'm pretty sure that the loss of coins can be handled well already.

But if you design an alt coin (do we have enough already?) you might add this as one of its rules.
I don't know whether it would really have a positive effect - it would make those "lost" coins available again, but there might be some folks who put coins in a cold storage wallet as savings, and they might not be happy to find that their coins have been given to someone else.
Of course, people adopting such a coin would know that they need to touch (move) their coins once in a while to keep them, so it might not be a big problem after all.

Onkel Paul

This is really cool. If the need for an ethernet connection limits your available placement options, you might have success with a WiFi USB dongle - the Pi handles most without hassle if the power supply is sufficiently stable, but of course this would increase your power requirements a little bit.
I don't know whether there is a software way of disabling the ethernet port, that might cut away a little bit of power consumption when you're only using WiFi.

Onkel Paul

Actually, (2^48/65536) is exactly 2^32. You most likely meant (2^48/65535).

Since the relative difference (0.015%) is way smaller than the measurement and prediction errors, it really does not matter.
If the calculation shows that you might get $100 +/- 20%, calculating the $100 to 4 digits after the decimal point does not make a lot of sense.

Onkel Paul

Who forced you to use Windows? Will you bring them before a human rights court?

Onkel Paul

This is the "selling shovels in a gold rush" thing on steroids.
If you can sell ASICs for more than they ever produce during their lifetime, you make a better profit than if you let them mine for yourself.
Of course, letting them mine for a time while the difficulty is still low enough and only selling them later is a guarantee for even better profit.

And I am absolutely convinced that the ASIC sellers can calculate and know at what price they must sell to make a profit.
The shovel makers in the gold rush could at least plausibly claim that dealing with them would create a win-win situation, as they themselves could not deliver the amount of work needed to mine with their tools.
But in the ASIC mining case there is no win-win - if it is more profitable for the seller to sell the hardware than to mine with it, it is with certainty not profitable for the buyer to mine with it.

Onkel Paul

Since we're german and need proper laws for everything, what about a new Geschwindigkeitsbegrenzungencoininverkehrbringungsüberwachungsgesetz?
Now that the "Rinderkennzeichnungs- und Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz" has been put out of force just a week ago, we need a suitable successor.

Onkel Paul

Thx 
No wonder you missed it all the time, because it just wasn't there all the time, we just implemented it a few days ago.

Your observation about expert mode is correct - the calculation can't be exact because it simplifies (uses a continuous exponential function instead of the 2016-block stepwise difficulty correction) and of course it can only extrapolate from existing data. The assumption that difficulty growth will be exponential will of course be moot as soon as there is some saturation. All exponential approximations of real-world systems break down when they approach saturation.
The idea of the expert mode is to get a rough feeling how the increase in difficulty will affect future mining results.

For back-of-the-envelope calculations assuming an exponential reward curve, you should find the half-life of your mining reward (time until the reward halves due to difficult increases, not the 4-year block reward halving built into bitcoin). Half of the total reward will be gained before that point in time, and the other half will take forever after that.
At a daily difficulty increase of 1.3 percent, the half-life is about 54 days. So if your mining rig does not yield significantly more than half of its investment cost during those 54 days, it never will pay for itself.

And since mining produces bitcoins, profitability calculations should primarily be done in bitcoins. If the total lifetime yield of your mining rig is fewer bitcoins than what it took to buy and operate it, it's a loss even if fiat exchange rate increases by a factor 10000, because you would have been better off just keeping the bitcoins in your wallet.

Onkel Paul

Selfish plug: http://coinish.com/calc is a calculator that takes projected difficulty development and time to delivery into account, you might want to run your options through it (disclosure: I wrote the calc routines, if you find bugs you may keep them but please tell me about them).

The bitcoin exchange rate can make a difference in the ROI calculation in fiat money, so even mining with a graphics card might yield a good return in dollars once BTC skyrockets.
But if the ROI in BTC is negative, you'd be better off to just stay with the BTC in the first place and wait for its value to increase.

Onkel Paul

Well such a stream of useless replies just urges me to click on "ignore" - problem solved.
The 5 post rule also serves to show who does not have anything meaningful to say...

Onkel Paul

Since you only want to emulate, you don't need to execute the actual proof of work (hashing).
The scenario you're describing is the classic 51% attack. Basically, an attacker needs to have more hashing power than all other hashing nodes in the network combined. For each block mined, the probability that the attacker will mine a block in his own chain is roughly proportional to his relative hashing power.
So if your attacker can divert the hashing power of more than half of all miners (which means he would have to usurp the biggest mining pools), he could theoretically do it. Alternatively, he could buy ASIC chips totalling a bit more than the current worldwide hashing power to gain 51% hash performance.

Both of these attacks would not go unnoticed, so in addition to the simple costs of the attack, the attacker would have to deal with the effects which would likely more than offset his possible gains.

Onkel Paul